Kubernetes 1.19: liikenteen sisääntulon ja reitityksen tulevaisuus

Kubernetes-yhteisö luopuu Ingressistä ja uudistaa liikenteen reitityksen skaalautuakseen paremmin useiden tiimien ja roolien tarpeisiin.

Michael Vittrup Larsen

Michael is a Consultant at our office in Aarhus. He has an MScEE from Aalborg University where he specialized in digital signal processing. Before joining us Michael was working on building and optimizing cloud infrastructure for the telecoms sector. In his spare time, he likes to explore the wilderness on his mountain bike.

Kubernetes 1.19 ja Ingress-resurssi

Kubernetes 1.19:ssä Kubernetesiin saapuvan ja siellä reititettävän HTTP-liikenteen määrittävä Ingress-resurssi siirtyi betavaiheesta GA-vaiheeseen. Ingress-resurssin ollessa betavaiheessa Kubernetes 1.18:ssa tehtiin joitakin muutoksia, kuten hostname-yleismerkkien käyttöönotto. Näkemykseni on, että Kubernetesin liikenteen sisääntulon ja reitityksen jatkokehitys tapahtuu muiden resurssityyppien avulla. Kubernetes 1.18:ssa tehdyt muutokset ja Ingressin päivitys GA/v1-versioon 1.19:ssä voidaan nähdä kiireellisimpien ongelmien ratkaisemisena ennen kuin Ingress-resurssin suunnittelu vakiinnutettiin.

Kiinteään revisioon perustuva resurssi saa vain virheenkorjauksia ja taaksepäin yhteensopivia muutoksia, joten Ingress-resurssiin tuskin nähdään merkittäviä muutoksia jatkossa. Pitkä betavaihe yhdistettynä Ingress-resurssin laajaan käyttöön tarkoittaa myös, että se oli pitkään de facto GA -tilassa eikä sitä voitu kehittää merkittävästi rikkomatta taaksepäin yhteensopivuutta. Tätä voisi kutsua malliksi korjaa, (unohda) ja katso eteenpäin: lukitse suunnittelu, korjaa jatkossa vain virheitä ja luo uusia resurssityyppejä kehittyneempää suunnittelua varten.

Ingress-resurssin ongelma on, ettei sen suunnittelu ole aidosti kehitettävissä poikkeamatta merkittävästi nykyisestä mallista. Jos siis haluamme innovoida ja muuttaa Ingress-resurssia olennaisesti, meidän on luotava uusi resurssityyppi. Tämä näkyy myös Kubernetes service API -SIG-ryhmän ja esimerkiksi Gateway API:n ympärillä tehtävässä työssä.

Mitkä ovat siis Ingress-resurssin suurimmat ongelmat, ja millaista mallia Ingress-resurssityypin versiosta 2 pitäisi odottaa? Jatka lukemista...

Kubernetes Ingress -resurssi

Kubernetesin Ingress-resurssi on virallinen tapa julkaista HTTP-pohjaisia palveluita. Ingress-resurssin elämä on ollut epävarmaa: se on ollut beta-resurssi viimeiset 18 Kubernetes-versiota – kyllä, Kubernetes v1.1:stä lähtien! Pitkä aika beta-API:na sekä Ingress controller -kohtaiset annotaatiot, joilla Ingress-resurssin toimintaa on laajennettu ja muokattu, osoittavat, ettei Ingress-resurssin suunnittelu ole yhtä onnistunut kuin muiden Kubernetes-resurssien. Seuraavassa osiossa kuvaamme Ingress-resurssin skaalautuvuusongelman ja tavan ratkaista se.

Erilliset roolit

Yksi Ingress-resurssin ongelmista on, että se yhdistää seuraavat asiat samaan resurssimäärittelyyn:

Identiteetti – verkkotunnus
Todennus – TLS-sertifikaatti
Reititys – mitkä URL-polut reititetään millekin Kubernetes-palvelulle

Kun henkilö hallinnoi monimutkaisehkoa sivustoa, jonka komponentteja hallinnoi useita itsenäisiä tiimejä, edellä mainitut vastuut kannattaa ihanteellisesti jakaa eri rooleille. Esimerkiksi:

Tietoturva-/infrastruktuuriylläpitäjä – hallinnoi verkkotunnuksia ja TLS-sertifikaatteja
Sivustoylläpitäjä – hallinnoi yksittäisten tiimien hallinnoimiin komponentteihin ja sovelluksiin tehtävää reititystä
Sovellustiimit – hallinnoivat reititystä sovellusten eri versioihin, canary-versioihin, blue/green-versioihin ja niin edelleen

Kuvitellaan, että meillä on sivusto example.com, joka koostuu kahdesta komponentista: login ja mainsite. Kumpaakin hallinnoi oma tiiminsä. Voimme havainnollistaa eri roolit ja liikenteen reitityksen seuraavan kuvan mukaisesti. Siniset laatikot kuvaavat roolia ja punaiset laatikot liikenteen reititysmäärittelyä. Reititysmäärittelyt käyttävät valitsimena joko URL-polkua tai HTTP-otsaketta.

the-future-of-traffic-ingress-and-routing-1

Tässä ”tietoturvaylläpitäjän” rooli hallinnoi sivuston identiteettiä verkkotunnuksen ja TLS-sertifikaattien kautta sekä mahdollisesti myös DNS:ää, joka ei kuulu tämän kuvauksen piiriin. Verkkotunnus ja TLS-sertifikaatti muuttuvat vain harvoin, ja tämän roolin käyttöoikeuksien tulisi olla hyvin rajoitettuja. Jos sertifikaatteja hallinnoidaan Lets Encryptillä, rajatut käyttöoikeudet tarkoittavat myös sitä, etteivät sivustoylläpitäjät tai sovellustiimit voi käynnistää sertifikaattien uusimista. Tämä pienentää riskiä ylittää Lets Encryptin sertifikaattien nopeusrajoitus: TLS-sertifikaatin saaminen ei siis epäonnistu nopeusrajoituksen vuoksi.

”Sivustoylläpitäjän” rooli määrittää ylimmän tason reitityksen, esimerkiksi reitityksen kahteen sovellukseen, joita kaksi tiimiämme hallinnoi. Tämä reititys muuttuu vain, kun sivustolle lisätään tai sieltä poistetaan sovelluksia.

”Sovellustiimit” hallinnoivat kunkin sovelluksen alikomponentteja, mukaan lukien testikäyttöönotot. Kukin sovellustiimi voi määrittää reitityksen esimerkiksi testi-instansseihin toteuttaakseen canary- ja blue/green-testausta.

Kubernetesissa Ingress-resurssi määrittää verkkotunnuksen, TLS-sertifikaatin ja reitityksen Kubernetes-palveluihin yhdessä objektissa. Tämän seurauksena esimerkiksi canary-testausta haluvalle sovellustiimille on annettava oikeudet muokata koko sivuston globaalia Ingress-resurssia. Tällä on vaikutuksia sekä tietoturvaan että vakauteen: ilmeisin niistä on, että Ingress-resurssiin tehty syntaksivirhe tekee koko sivustosta saavuttamattoman.

Kubernetes API SIG:n Gateway API:n parissa tekemän työn tavoitteena on tukea tätä moniroolista mallia. Vaikka Gateway API:n toteutuksia ei vielä ole, API pohjautuu vahvasti Contour Ingress controllerin API:in. Seuraavissa osioissa näytämme, miten voit toteuttaa tämän moniroolisen mallin Contourilla. Samalla saat käsityksen Kubernetesin mahdollisesta tulevasta Gateway API:sta.

Moniroolisen mallin toteuttaminen Contourilla ja Envoylla

Envoy on Cloud Native Computing Foundationin (CNCF) valmistunut proxy, ja Contour on Envoyn päälle rakennettu Ingress controller. Contour laajentaa Ingress-resurssien ideaa HTTPProxy-objektilla, joka mahdollistaa yhden HTTPProxy-objektin delegoinnin toiselle. Toisin sanoen sen avulla liikenteen reititys voidaan määrittää useilla HTTPProxy-resursseilla useissa Kubernetes-nimiavaruuksissa, joiden käyttöoikeuksia rajoitetaan eri roolien mukaan. Tätä havainnollistetaan alla.

Contour graph with security admin role, site admin role and login application team role

Kubernetesta kertova kirjoitus ei ole täydellinen ilman YAMLia, joten katsotaan yllä kuvatun toteutuksen YAMLia. Ensin sivuston identiteetin määrittävä ylimmän tason HTTPProxy:

Nimiavaruudessa security-admin-only oleva HTTPProxy-resurssi example-com-root määrittää sivuston identiteetin verkkotunnuksen ja TLS-varmenteen avulla sekä delegoi jatkoreitityksen nimiavaruudessa site-admin-only olevalle HTTPProxy-resurssille site-fanout:

HTTPProxy-resurssi site-fanout määrittää kaiken /login-polun alle tulevan liikenteen reitityksen nimiavaruudessa login olevalle HTTPProxy-resurssille login. Kirjautumissovellusta hallinnoivalla tiimillä on täydet oikeudet login-nimiavaruuteen, joten se voi luoda seuraavan HTTPProxy-resurssin reitittämään Kubernetes-palveluihin, joita se myös hallinnoi:

HTTPProxy-resurssi login määrittää reitityksen Kubernetes-palveluun test-login-app-service, kun HTTP-otsikko x-test sisältää arvon true (esimerkiksi blue/green-testissä), ja muussa tapauksessa Kubernetes-palveluun login-app-service.

Rego ja Conftest

Yllä esitetyt nimiavaruudet tulisi luonnollisesti lukita Kubernetes RBAC:llä siten, että esimerkiksi login-tiimi voi luoda HTTPProxy-resursseja vain omassa login-nimiavaruudessaan. Saatat kuitenkin pohtia, miten root HTTPProxy -resurssien, kuten yllä olevan example-com-root-resurssin, luominen voidaan rajoittaa security-admin-only-nimiavaruuteen.

Tällaisten resurssien luomista voidaan rajoittaa OPA GateKeeperin avulla. GateKeeper on Kubernetes admission controller, joka hyväksyy Rego-kielellä määritettyjä käytäntöjä. Olen luonut esimerkin Rego-pohjaisesta testistä, joka testaa root HTTPProxy -resursseja. Testi on osa GitOps CI:ssä hyödyllistä testikokonaisuutta, esimerkiksi kun haluat validoida Kubernetes-resurssisi ennen niiden käyttöönottoa Kubernetesissa.

Milloin Kubernetesissa nähdään uusi Ingress-resurssi?

Todennäköisesti ei koskaan.

Kubernetesissa suuntauksena on, että laajennukset toteutetaan CRD:illä (custom resource definitions) – dynaamisella lähestymistavalla, jossa laajennukset tuodaan Kubernetesin ytimen ulkopuolelta. Tämä tarkoittaa, että Contourin tai Istion kaltaiset projektit tuovat omat CRD:nsä, joiden avulla voimme määrittää liikenteen Ingressin ja reitityksen. Näistä syistä Kubernetesin ytimeen tuskin tuodaan uutta yhteistä Ingress-määritelmää.