3.1 Peruskäsitteitä

Tällä sivulla esitellään tärkeimmät Openshiftin ja Kuberneteksen käsitteet, jotka on tarpeen ymmärtää sovelluskehityksessä alkuun pääsemiseksi. Lisää käsitteitä löydät täältä.

Openshiftissä ja Kuberneteksessa podien tietoliikenne on toteutettu tavalla, johon on syytä perehtyä tarkkaan. Liikenne toimii eri tavalla kuin esimerkiksi Docker Compose- tai Docker Swarm -ympäristöissä.

Lisätietoja löytyy seuraavista osoitteista:

• https://kubernetes.io/docs/concepts/
• https://kubernetes.io/docs/concepts/workloads/pods/

PodKuberneteksessa kaikki kontit ajetaan Podeissa. Pod on pienin yksikkö, jota Kubernetes hallinnoi yhtenä kokonaisuutena. Pod voi sisältää yhden tai useamman kontin. Jokaisella podilla on oma ip-osoite Kubernetes-klusterin sisällä 10.* -verkosta. Tiken Openshiftin tapauksessa podien IP-osoitteet ovat verkossa 10.12.0.0/14.

Seuraavassa tärkeimpiä podien ominaisuuksia. Tässä sanalla "noodi" tarkoitetaan Openshift-järjestelmän yhtä alustavirtuaalikonetta.

• Saman Podin kontit jakavat keskenään localhostin, porttiavaruuden ja mahdollisesti PersistentVolumeClaimit.
• Yksi pod on aina jollain, yksittäisellä noodilla. Kaikki yhden podin kontit ovat samalla noodilla.
  • Jotta projektin toteuttama palvelu olisi vikasietoinen, podeista on hyvä skaalata ajoon useampi kopio (replica). Kopioille on myös hyvä asettaa affinity-asetus, joka määrää eri kopiot ajettavaksi eri noodeille.
• Yleensä yksi pod sisältää vain yhden kontin, mutta joissain erityistapauksissa voi olla perusteltua rakentaa myös pod, joka sisältää myös useamman kontin.
• Sovelluksen skaalaaminen tapahtuu lisäämällä podien lukumäärää.

Podeja ei yleensä pidä luoda suoraan, vaikka se onkin mahdollista! Kehittäjät ja ylläpitäjät luovat Deployment-, DeploymentConfig-, CronJob-, Job- ja StatefulSet -objekteja, jotka puolestaan käynnistävät podeja. Jos luodaan "paljas" pod, jolla ei ole omistajaobjektia, Openshift ei huolehdi siitä, että pod käynnistetään uudelleen tarvittaessa. Irrallisia podeja kannattaa hyödyntää lähinnä interaktiiviseen debuggaukseen.

Podiin ei ole mahdollista ottaa yhteyttä klusterin ulkopuolelta sen ip-osoitteella. Myös klusterin sisällä suora yhteydenotto podiin on sekä mutkikasta että kannattamatonta, koska:

• Podit ovat väliaikaisia. Virtuaalikoneet, joissa podeja ajetaan, voivat uudelleenkäynnistyä. Prosessi kontissa ja näin ollen kontit podeissa voivat myös kaatua.
  Molemmissa tapauksissa lähtökohtainen tapa, jolla Openshift korjaa tilanteen, on käynnistää podeja uudestaan (mahdollisesti jollain toisella virtuaalikoneella eli noodilla). 
• Podien nimissä on satunnainen osa nimikonfliktien välttämiseksi. 
  
  • → Podin nimeen viittaaminen on siis hyvin hankalaa.
  • → Podin, sen nimen tai ip-osoitteen pysyvyyteen ei voi luottaa.

ServiceKoska podeihin ei saada suoraan verkkoyhteyksiä, Kubernetes tarjoaa Service-objektin. Se on abstraktio, jolla luodaan klusterin sisällä pysyvä, nimetty resurssi, jolla voidaan viitata podiin tai joukkoon podeja.

• Myös serviceillä on omat ip-osoitteet, jotka saadaan osoiteavaruudesta 172.30.0.0/16.

Podeilla voi olla nimiö – esim. "app=mun_hieno_applikaatio". Podien nimiön ja servicen selector-määrityksen avulla service osaa ohjata liikenteen oikeisiin podeihin.

• https://kubernetes.io/docs/concepts/services-networking/service/
• https://kubernetes.io/docs/tutorials/kubernetes-basics/expose/expose-intro/

Route ja ingressRoute on Openshiftin ominaisuus, jolla projekti voi tarjota palvelua ulospäin näkyvässä verkko-osoitteessa. Route kohdistetaan serviceen, joka taas ohjaa liikenteen oikeisiin podeihin. Routessa määritellään myös, miten HTTPS puretaan. Kubernetes-järjestelmässä routen sijasta käytetään suoraan Ingressiä, mutta ingressin luominen tai muokkaus on klusterin laajuisia ylläpito-oikeuksia vaativa operaatio, joten Openshiftissä yksittäinen projekti ei voi koskea ingresseihin suoraan. 

• Route toimii rekisteröimällä itsensä klusterissa valmiina olevaan ingressiin.
  • Tiken klustereissa on kaksi ingressiä, joista toinen on palomuurin tasolla rajattu pelkästään sisä- ja eteisverkkoon ja toinen avattu koko internetiin.
  • Routen määrityksessä projektin kehittäjät voivat valita, kumpaan ingressiin route sidotaan. Tämä samalla toimii valintana sille, tarjotaanko palvelua vain yliopiston sisälle vai myös ulkopuoliseen internetiin.
  • Routen annotaatiolla voidaan myös antaa lista ip-osoiteavaruuksia joista tuleva liikenne sallitaan ja muut suljetaan pois. Tämä ei vaikuta ingressien palomuuritasolla tehtäviin rajauksiin, eli sisä- ja eteisverkon ingress estää edelleen ulkoverkon liikenteen. Annotaatioon asetettavalla listalla on myös maksimipituus, 61 osoiteblokkia. Lisätietoja: https://docs.openshift.com/container-platform/4.12/networking/routes/route-configuration.html#nw-route-specific-annotations_route-configuration →  haproxy.router.openshift.io/ip_whitelist
• Lisää ohjeita: 3.7 Miten julkaisen sovellukseni internetiin?