Keskitaso

Tarvitset OKD:n CLI-työkalun oc ja Routejen API:n tuntemusta sekä Kubernetesin Podien ja Servicejen tuntemusta.

Johdanto

Tässä oppaassa käsitellään Kubernetesin keskeisiä käsitteitä podit, servicet, routet ja ReplicationControllerit sekä niiden YAML-esitykset. Näiden Kubernetes API -objektien havainnollistamiseksi rakennetaan Apache HTTP Server -sovellus kirjoittamalla näiden objektien pelkät tekstimuotoiset YAML-esitykset.

Objektit, jotka on vähintään määriteltävä klusterissa, jotta palvelin toimii:

Podi, joka suorittaa kontin.
Service, joka julkaisee podin sisäisesti ja antaa sille ennakoitavan nimen.
Route, joka julkaisee servicen internetiin ohjaamalla liikenteen osoitteesta <myservice>.2.rahtiapp.fi service-objektiin.

Info

Käytännössä sovelluksia ei tulisi ottaa käyttöön tässä oppaassa kuvatulla tavalla. Sen sijaan tämän tarkoitus on opettaa Kubernetesin peruskäsitteitä.

Network

Valmistelut

Varmista, että oc-komentorivikäyttöliittymä on asennettu ja että olet kirjautunut sisään. Katso tarvittaessa komentorivityökalun asennus.

Projektit

Komento oc projects näyttää projektit, joihin sinulla on käyttöoikeus:

$ oc projects
You have access to the following projects and can switch between them with 'oc
project <projectname>':

    someone-elses-public-project
  * my-project-with-unique-name

Using project "my-project-with-unique-name" on server "https://api.2.rahti.csc.fi:6443".

Info

Luettelo voi sisältää projekteja, joita muut käyttäjät ovat luoneet julkisten Docker-imagien ylläpitoon. Vaikka voit vaihtaa näihin projekteihin, sinulla on niissä vain lukuoikeus ylläpidettyihin Docker-imageihin.

Jos sopivaa yksittäistä projektia ei ole, uuden voi luoda komennolla oc new-project:

oc new-project my-project-with-unique-name

Projektin nimen on oltava yksilöllinen koko Rahti-konttipilvessä, ja lisäksi nimi saa sisältää vain kirjaimia, numeroita ja yhdysmerkkejä, eikä siinä huomioida kirjainkokoa. Käytännössä nimen on oltava käyttökelpoinen osana DNS-nimeä.

Jos olet usean Rahtiin pääsyn sisältävän CSC-projektin jäsen, projektin kuvauksen on sisällettävä csc_project: #######, missä ####### on laskutettava projekti (katso Projektit ja kiintiö).

Kuvaus voidaan sisällyttää new-project-komentoon:

oc new-project my-project-with-unique-name --description='csc_project: #######'

Vaihda projektia komennolla oc project:

oc project another-project

Podit ja komentorivikäyttöliittymä

Podit ovat objekteja, jotka suorittavat yhden tai useamman kontin. Podin kontit jakavat IP-osoitteen, ja ne voivat kommunikoida localhost-osoitteen tai jaetun muistin kautta. Siksi niiden on toimittava samalla fyysisellä solmulla.

Meidän tapauksessamme podi suorittaa kontti-imagen, johon on asennettu selainkäyttöliittymäpalvelin:

pod.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
  labels:
    app: serveapp
    pool: servepod
spec:
  containers:
  - name: serve-cont
    image: "image-registry.openshift-image-registry.svc:5000/openshift/httpd"

Tämä podi suorittaa yhden kontti-imagen, joka on määritelty kentässä spec.containers.image.

Podin nimi annetaan kentässä metadata.name. Podiin voidaan viitata oc-työkalulla:

oc get pods mypod

Kenttä metadata.labels.pool on mielivaltainen avain-arvo-pari, jonka avulla podit voidaan ryhmitellä ja niihin voidaan viitata esimerkiksi servicejen avulla.

Kubernetes API -objektit esitetään YAML-muodossa. Lyhyt johdanto YAMLiin.

Podit ja muut Kubernetes/OKD API -objektit luodaan oc-komentorivityökalulla:

oc create -f pod.yaml

Podin pitäisi nyt näkyä Rahtin selainkonsolin "Overview"-sivulla, kun projektia tarkastellaan.

Podeja voidaan poistaa komennolla oc delete:

oc delete pod mypod

Tämän seurauksena podin pitäisi kadota Rahtin selainkonsolista, mutta pidetään tämä toistaiseksi käynnissä.

Resurssipyynnöt ja -rajat

Tyypillisesti konteille varataan resursseja käyttämällä pyyntöjä ja rajoja, mutta näissä esimerkeissä emme tee niin lyhyyden vuoksi. Jos arvoja ei anneta, käytetään oletusarvoja. Sama podi kuin yllä, mutta muisti- ja CPU-resursseilla 200 Mt–1 Gt ja 0,2 CPU–1 CPU, näyttäisi tältä:

pod.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
  labels:
    app: serveapp
    pool: servepod
spec:
  containers:
  - name: serve-cont
    image: "image-registry.openshift-image-registry.svc:5000/openshift/httpd"
    resources:
      requests:
        memory: "200M"
        cpu: "200m"
      limits:
        memory: "1G"
        cpu: "1"

Lue lisää pyynnöistä ja rajoista Kubernetesin dokumentaatiosta.

Service

Podien IP-osoitteet eivät ole pysyviä ja voivat muuttua, jos esimerkiksi podi lopetetaan ja luodaan uudelleen. Jotta podiin voidaan siis luotettavasti ottaa yhteys, sen IP-osoitetta on seurattava ja säilytettävä. Service-objektit tekevät juuri tämän, ja sen seurauksena ne tarjoavat podeille pysyvän verkkoidentiteetin:

service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: serve
  labels:
    app: serveapp
spec:
  ports:
  - name: 8081-tcp
    port: 8081
    protocol: TCP
    targetPort: 8080
  selector:
    pool: servepod

Tämä service ohjaa TCP-liikenteen projektin portista 8081 sisäisesti niiden podien porttiin 8080, joiden tunnisteet on lueteltu kohdassa spec.selector. Tässä tapauksessa liikenne ohjataan podeihin, joilla on tunniste pool: servepod. Jos spec.selector vastaa useita podeja, liikenne jaetaan niiden kesken. Oletuksena jako tehdään round-robin-periaatteella.

Ainoa pakollinen kenttä kohdassa spec.ports on port. Jos protocol jätetään pois, oletuksena käytetään TCP:tä, ja jos targetPort jätetään pois, oletuksena käytetään port-kentän arvoa.

Varmistetaan, että service on määritelty, avaamalla etäkuori podissa mypod käynnissä olevaan konttiin ja kysymällä sisäiseltä DNS-palvelulta:

$ oc rsh mypod
sh-4.2$ nslookup serve
Server:     172.30.0.10
Address:    172.30.0.10#53

Name:   serve.test-sidecar.svc.cluster.local
Address: 172.30.103.178

Route

Route-objekti on OKD:n Kubernetes-laajennus, joka ohjaa HTTP-liikenteen internetistä (tai mistä tahansa verkosta, johon OKD-klusteri on yhdistetty) OKD-klusterin serviceihin.

route.yaml:

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  labels:
    app: serveapp
  name: myservice
  annotations:
    haproxy.router.openshift.io/ip_allowlist: 192.168.1.0/24 10.0.0.1
spec:
  host: <myroute>.2.rahtiapp.fi
  to:
    kind: Service
    name: serve
    weight: 100

Tämä route ohjaa liikenteen internetistä siihen klusterin serviceen, jonka metadata.name on sama kuin spec.to.name.

Sinun täytyy korvata <myroute> millä tahansa arvolla, joka on kelvollinen DNS-nimi (suositeltavaa on käyttää projektin nimeä).

Kyseinen route sallii lisäksi liikenteen vain aliverkosta 192.168.1.0/24 ja IP-osoitteesta 10.0.0.1. Tietoturvan kannalta on erittäin suositeltavaa käyttää IP-sallintalistaa palveluille, joiden ei ole tarkoitus näkyä koko internetiin.

Jotta voit muodostaa yhteyden, sinun täytyy lisätä (tai korvata) oma IP-osoitteesi tai aliverkon peite, joka sisältää IP-osoitteesi. Voit selvittää IP-osoitteesi esimerkiksi komennolla curl ipinfo.io/ip omalta tietokoneeltasi. Toinen vaihtoehto on poistaa annotaatio kokonaan; tällöin kuka tahansa maailmassa voi muodostaa yhteyden.

Voit nyt siirtyä selaimeesi ja kirjoittaa asettamasi osoitteen: <myservice>.2.rahtiapp.fi. Sen pitäisi palauttaa Apache-testisivu:

Apache test page

Warning

Jos sallintalistan merkintä on virheellinen, OKD hylkää sallintalistan ja sallii kaiken liikenteen.

Oletuksena isäntänimi on metadata.name + - + project name + .2.rahtiapp.fi, ellei kohdassa spec.host ole määritelty muuta.

Tähän mennessä olemme määrittäneet podin, servicen ja routen. Jos fyysinen palvelin, jolla podi sijaitsee, sammutetaan, sinun on käynnistettävä podi manuaalisesti uudelleen komennolla oc create -f pod.yaml. ReplicationController- ja ReplicaSet-objektit ovat mekanismi, joka tekee tämän karkeasti ottaen käyttäjän puolesta.

ReplicationController

ReplicationControlers deprecated

ReplicationControllerit ovat vanhentuneita nykyisissä OKD-versioissa yhdessä DeploymentConfigien kanssa. Noudata ohjetta muunna DeploymentConfig Deploymentiksi.

ReplicationController varmistaa, että klusterissa on käynnissä spec.replicas kappaletta podeja, joiden tunnisteet vastaavat spec.selector-määrittelyä. Jos podeja on liikaa, ReplicationController sammuttaa ylimääräiset, ja jos niitä on liian vähän, se käynnistää podeja spec.template-kentän mukaisesti. Käytännössä template-kenttä on täsmälleen sama podi kuin pod.yaml-tiedostossa, paitsi että kentät apiVersion ja kind puuttuvat.

ReplicationController.yaml:

apiVersion: v1
kind: ReplicationController
metadata:
  labels:
    app: serveapp
  name: blogtest-replicator
spec:
  replicas: 1
  selector:
    app: serveapp
    pool: servepod
  template:
    metadata:
      name: mypod
      labels:
        app: serveapp
        pool: servepod
    spec:
      containers:
      - name: serve-cont
        image: "image-registry.openshift-image-registry.svc:5000/openshift/httpd"

ReplicationControllerit ovat toiminnallisesti lähellä ReplicaSetejä, joita käsitellään luvussa "Kubernetesin ja OKD:n käsitteet". ReplicationController voidaan muuntaa ReplicaSetiksi muuttamalla spec.selector muotoon spec.selector.matchLabels ja asettamalla kind: ReplicaSet.

Info

Keskeinen Kubernetes-käsite nimeltä reconciliation loop ilmenee ReplicationControllereissa. Reconciliation loop on mekanismi, joka mittaa järjestelmän todellisen tilan, muodostaa mittauksen perusteella nykyisen tilan ja suorittaa sellaisia toimia, että järjestelmän tila vastaisi haluttua tilaa.

Tässä terminologiassa ReplicationControllerit ovat objekteja, jotka kuvaavat klusterin haluttua tilaa. Toinen tällainen objekti on aiemmin kohdattu service-objekti. Siinä toinen reconciliation loop vertaa servicen endpointteja todellisiin valmiina oleviin podeihin ja säätää niitä vastaavasti. Tämän seurauksena servicen endpointit osoittavat aina podeihin, jotka ovat valmiita, ja vain niihin podeihin, joiden tunnisteet sisältävät kaikki service-objektin selectorissa olevat kentät. Itse asiassa jokainen spec-esiintymä Kubernetes-objektin YAML-esityksessä kuvaa reconciliation loopin määritystä. Podien loopit vain sattuvat olevan sidottuja Kubernetesin worker-solmuihin, ja siksi ne ovat alttiita poistumiselle, jos tai kun worker-solmujen provisiointi puretaan.

Siivoaminen

Kun olemme tyytyväisiä sovellukseen, emme jätä sitä käyntiin klusteriin vaan poistamme sen komennolla oc delete:

oc delete all --selector app=serveapp

Tämä poistaa kaikki objektit, joilla on tunniste app: serveapp.

Yhteenveto

Tässä oppaassa otettiin käyttöön staattisen verkkosivun palvelin käyttämällä YAML-tiedostoja, jotka esittävät Kubernetes-objekteja. Luotuja objekteja voidaan muokata edelleen Rahtin selainkonsolissa, jossa:

Routeja voidaan muuttaa turvallisiksi TLS:llä salatuiksi versioiksi.
ReplicationControllereihin voidaan lisätä autoskaalaimia, pysyvää tallennustilaa, resurssirajoja ja terveystarkistuksia.
Serviceihin voidaan lisätä uusia routeja.