Kirja "Kubernetes for DevOps"

Hei Khabron asukkaat! Kubernetes on yksi nykyaikaisen pilviekosysteemin avainelementeistä. Tämä tekniikka tarjoaa luotettavuutta, skaalautuvuutta ja joustavuutta kontin virtualisointiin. John Arundel ja Justin Domingus puhuvat Kubernetes-ekosysteemistä ja esittelevät hyväksi havaittuja ratkaisuja arjen ongelmiin. Askel askeleelta rakennat oman pilvipohjaisen sovelluksesi ja luot sitä tukevan infrastruktuurin, määrität kehitysympäristön ja jatkuvan käyttöönottoprosessin, joka auttaa sinua työskennellessäsi seuraavien sovellusten parissa.

• Aloita säilöjen ja Kubernetesin käyttö perusteista: aiheen oppiminen ei vaadi erityistä kokemusta. • Suorita omia klustereitasi tai valitse hallittu Kubernetes-palvelu Amazonilta, Googlelta jne. • Käytä Kubernetesiä kontin elinkaaren ja resurssien kulutuksen hallintaan. • Optimoi klusterit kustannusten, suorituskyvyn, joustavuuden, tehon ja skaalautuvuuden perusteella. • Opi parhaat työkalut sovellusten kehittämiseen, testaamiseen ja käyttöönottoon. • Hyödynnä alan nykyisiä käytäntöjä turvallisuuden ja hallinnan varmistamiseksi. • Ota DevOps-periaatteet käyttöön koko yrityksessäsi, jotta kehitystiimit voivat toimia joustavammin, nopeammin ja tehokkaammin.

Kenelle kirja on tarkoitettu?

Kirja sopii eniten palvelimista, sovelluksista ja palveluista vastaavien hallintoosastojen työntekijöille sekä kehittäjille, jotka ovat mukana joko uusien pilvipalveluiden rakentamisessa tai olemassa olevien sovellusten siirtämisessä Kubernetesiin ja pilveen. Älä huoli, sinun ei tarvitse osata työskennellä Kubernetesin tai säiliöiden kanssa – me opetamme sinulle kaiken.

Kokeneet Kubernetes-käyttäjät löytävät myös paljon arvoa, sillä ne kattavat perusteellisesti aiheita, kuten RBAC, jatkuva käyttöönotto, arkaluonteisten tietojen hallinta ja havainnointi. Toivomme, että kirjan sivuilta löytyy varmasti jotain kiinnostavaa sinulle, taidoistasi ja kokemuksestasi riippumatta.

Mihin kysymyksiin kirja vastaa?

Kirjaa suunnitellessa ja kirjoittaessamme keskustelimme pilviteknologiasta ja Kubernetesista satojen ihmisten kanssa, keskustelimme alan johtajien ja asiantuntijoiden sekä täysin noviisien kanssa. Alla on valikoituja kysymyksiä, joihin he haluaisivat vastauksen tässä julkaisussa.

• ”Olen kiinnostunut siitä, miksi sinun pitäisi käyttää aikaa tähän tekniikkaan. Mitä ongelmia se auttaa minua ja tiimiäni ratkaisemaan?"
• ”Kubernetes vaikuttaa mielenkiintoiselta, mutta sillä on melko korkea pääsyn este. Yksinkertaisen esimerkin valmistaminen ei ole vaikeaa, mutta jatkohallinta ja virheenkorjaus on pelottavaa. Haluamme saada luotettavia neuvoja siitä, kuinka ihmiset hallitsevat Kubernetes-klustereita todellisessa maailmassa ja mitä ongelmia tulemme kohtaamaan."
• "Subjektiiviset neuvot auttaisivat. Kubernetes-ekosysteemi antaa uusille tiimeille liian paljon valinnanvaraa. Kun on useita tapoja tehdä sama asia, mistä tiedät, mikä niistä on paras? Kuinka tehdä valinta?

Ja ehkä tärkein kaikista kysymyksistä:

• "Kuinka voin käyttää Kubernetesia häiritsemättä yritystäni?"

Ote. Kokoonpano ja salaiset objektit

Kyky erottaa Kubernetes-sovelluksen logiikka sen kokoonpanosta (eli arvoista tai asetuksista, jotka voivat muuttua ajan myötä) on erittäin hyödyllinen. Määritysarvot sisältävät yleensä ympäristökohtaisia ​​asetuksia, kolmannen osapuolen palvelun DNS-osoitteet ja todennustiedot.

Tietysti kaikki tämä voidaan laittaa suoraan koodiin, mutta tämä lähestymistapa ei ole tarpeeksi joustava. Esimerkiksi määritysarvon muuttaminen edellyttää sitten koodin luomista ja käyttöönottoa uudelleen. Paljon parempi ratkaisu olisi erottaa kokoonpano koodista ja lukea se tiedostosta tai ympäristömuuttujista.

Kubernetes tarjoaa useita erilaisia ​​tapoja hallita määrityksiä. Ensin voit välittää arvot sovellukselle pod wrapper -määrityksessä määritettyjen ympäristömuuttujien kautta (katso "Ympäristömuuttujat" sivulla 192). Toiseksi määritystiedot voidaan tallentaa suoraan Kubernetesiin käyttämällä ConfigMap- ja Secret-objekteja.

Tässä luvussa tutkimme näitä objekteja yksityiskohtaisesti ja tarkastelemme joitain käytännön lähestymistapoja konfiguraatioiden ja arkaluonteisten tietojen hallintaan esittelysovelluksen avulla.

Pod-kuoret päivitetään, kun kokoonpano muuttuu

Kuvittele, että klusterissasi on käyttöönotto ja haluat muuttaa joitain arvoja sen ConfigMapissa. Jos käytät Helm-kaaviota (katso "Helm: Package Manager for Kubernetes" sivulla 102), voit automaattisesti havaita kokoonpanomuutoksen ja ladata pod-kuoret uudelleen yhdellä siistillä temppulla. Lisää seuraava huomautus käyttöönottomääritykseen:

checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") .
       | sha256sum }}

Käyttöönottomalli sisältää nyt määritysparametrien tarkistussumman: jos parametreja muutetaan, summa päivitetään. Jos suoritat ruoripäivityksen, Helm havaitsee, että käyttöönottomääritykset ovat muuttuneet, ja käynnistää kaikki pod-kuoret uudelleen.

Arkaluonteiset tiedot Kubernetesissa

Tiedämme jo, että ConfigMap-objekti tarjoaa joustavan mekanismin kokoonpanotietojen tallentamiseen ja käyttämiseen klusterissa. Useimmissa sovelluksissa on kuitenkin arkaluonteisia tietoja, kuten salasanoja tai API-avaimia. Se voidaan myös tallentaa ConfigMapiin, mutta tämä ratkaisu ei ole ihanteellinen.

Sen sijaan Kubernetes tarjoaa erityisen objektityypin, joka on suunniteltu tallentamaan arkaluontoisia tietoja: Secret. Seuraavaksi tarkastellaan esimerkkiä siitä, kuinka tätä objektia voidaan käyttää esittelysovelluksessamme.

Aloita katsomalla Secret-objektin Kubernetes-luetteloa (katso hello-secret-env/k8s/secret.yaml):

apiVersion: v1
kind: Secret
metadata:
    name: demo-secret
stringData:
    magicWord: xyzzy

Tässä esimerkissä magicWordin yksityinen avain on xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing)). Sana xyzzy on yleensä erittäin hyödyllinen tietokoneiden maailmassa. ConfigMapin tapaan voit tallentaa useita avaimia ja arvoja Secret-objektiin. Käytämme tässä yksinkertaisuuden vuoksi vain yhtä avainarvo-paria.

Salaisten objektien käyttäminen ympäristömuuttujina

Kuten ConfigMap, Secret-objekti voidaan asettaa saataville säilössä ympäristömuuttujina tai tiedostona sen levyllä. Seuraavassa esimerkissä määritämme ympäristömuuttujan Secret-arvolle:

spec:
   containers:
       - name: demo
          image: cloudnatived/demo:hello-secret-env
          ports:
             - containerPort: 8888
          env:
             - name: GREETING
               valueFrom:
               secretKeyRef:
                  name: demo-secret
                  key: magicWord

Suorita seuraava komento esittelyvarastossa ottaaksesi luettelot käyttöön:

kubectl apply -f hello-secret-env/k8s/
deployment.extensions "demo" configured
secret "demo-secret" created

Kuten ennenkin, välitä paikallinen portti käyttöönotolle nähdäksesi tuloksen selaimessasi:

kubectl port-forward deploy/demo 9999:8888
Forwarding from 127.0.0.1:9999 -> 8888
Forwarding from [::1]:9999 -> 8888

Osoitetta avattaessa localhost:9999/ sinun pitäisi nähdä seuraava:

The magic word is "xyzzy"

Salaisten objektien kirjoittaminen tiedostoihin

Tässä esimerkissä liitämme salaisen objektin säilöön tiedostona. Koodi sijaitsee demo-arkiston hello-secret-file-kansiossa.

Yhdistäksemme Secretin tiedostona käytämme seuraavaa käyttöönottoa:

spec:
   containers:
       - name: demo
          image: cloudnatived/demo:hello-secret-file
          ports:
              - containerPort: 8888
          volumeMounts:
              - name: demo-secret-volume
                mountPath: "/secrets/"
                readOnly: true
   volumes:
      - name: demo-secret-volume
        secret:
           secretName: demo-secret

Kuten alaosiossa "Konfigurointitiedostojen luominen ConfigMap-objekteista" sivulla s. 240, luomme taltion (tässä tapauksessa demo-secret-volume) ja asennamme sen spesifikaation VolumeMounts-osiossa olevaan säiliöön. mountPath-kenttä on /secrets, joten Kubernetes luo tähän kansioon yhden tiedoston kullekin Secret-objektissa määritetylle avain/arvo-parille.

Esimerkissämme määritimme vain yhden avain-arvoparin nimeltä magicWord, joten luettelo luo yhden vain luku -tiedoston /secrets/magicWord, jossa on arkaluontoisia tietoja säilössä.

Jos käytät tätä luetteloa samalla tavalla kuin edellistä esimerkkiä, sinun pitäisi saada sama tulos:

The magic word is "xyzzy"

Salaisten esineiden lukeminen

Edellisessä osassa käytimme kubectl description -komentoa ConfigMapin sisällön näyttämiseen. Voiko samoin tehdä Secretin kanssa?

kubectl describe secret/demo-secret
Name:          demo-secret

Namespace:      default
Labels:             <none>
Annotations:
Type:               Opaque

Data
====
magicWord: 5   bytes

Huomaa, että itse dataa ei näytetä. Kubernetesin salaiset objektit ovat tyyppiä Opaque, mikä tarkoittaa, että niiden sisältöä ei näytetä kubectl-kuvauksessa, lokimerkinnöissä tai päätteessä, mikä tekee arkaluonteisten tietojen paljastamisen vahingossa mahdottomaksi.

Voit tarkastella arkaluonteisten tietojen koodattua YAML-versiota käyttämällä kubectl get -komentoa:

kubectl get secret/demo-secret -o yaml
apiVersion: v1
data:
   magicWord: eHl6enk=
kind: Secret
metadata:
...
type: Opaque

base64

Mikä on eHl6enk=, täysin erilainen kuin alkuperäinen arvomme? Tämä on itse asiassa salainen objekti, joka on edustettuna base64-koodauksella. Base64 on menetelmä mielivaltaisten binääritietojen koodaamiseksi merkkijonoksi.

Koska arkaluonteiset tiedot voivat olla binaarisia eikä niitä tulosteta (kuten TLS-salausavaimen tapauksessa), salaiset objektit tallennetaan aina base64-muodossa.

Teksti beHl6enk= on base64-koodattu versio salaisesta sanastamme xyzzy. Voit varmistaa tämän suorittamalla komennon base64 —decode terminaalissa:

echo "eHl6enk=" | base64 --decode
xyzzy

Vaikka Kubernetes suojelee sinua vahingossa lähettämästä arkaluontoisia tietoja päätteeseen tai lokitiedostoihin, jos sinulla on lukuoikeudet salaisia ​​objekteja varten tietyssä nimiavaruudessa, tiedot voidaan base64-muuttaa ja sen jälkeen purkaa.

Jos haluat koodata tekstiä base64:llä (esimerkiksi laittaaksesi sen salaisuuteen), käytä base64-komentoa ilman argumentteja:

echo xyzzy | base64
eHl6enkK

Salaisten esineiden käyttö

Kuka voi lukea ja muokata salaisia ​​objekteja? Tämän määrittää RBAC, kulunvalvontamekanismi (käsittelemme sitä yksityiskohtaisesti alaosiossa "Johdatus roolipohjaiseen pääsynhallintaan" sivulla 258). Jos käytät klusteria, jossa ei ole RBAC:ta tai se ei ole käytössä, kaikki salaiset objektisi ovat kaikkien käyttäjien ja säilöjen käytettävissä (selitämme myöhemmin, että sinulla ei pitäisi olla tuotantoklustereita ilman RBAC:tä).

Passiivinen tietojen salaus

Entä ne, joilla on pääsy etcd-tietokantaan, johon Kubernetes tallentaa kaikki tietonsa? Voivatko he lukea arkaluontoisia tietoja ilman lupaa lukea salaisia ​​objekteja API:n kautta?

Versiosta 1.7 lähtien Kubernetes tukee passiivista tietojen salausta. Tämä tarkoittaa, että etcd:n sisällä olevat arkaluontoiset tiedot tallennetaan salattuna levylle, eikä niitä voi lukea edes ne, joilla on suora pääsy tietokantaan. Sen salauksen purkamiseen tarvitset avaimen, joka on vain Kubernetes API -palvelimella. Oikein määritetyssä klusterissa passiivisen salauksen tulee olla käytössä.

Voit tarkistaa, toimiiko passiivinen salaus klusterissasi seuraavasti:

kubectl describe pod -n kube-system -l component=kube-apiserver |grep encryption
        --experimental-encryption-provider-config=...

Jos et näe kokeellisen salauksen tarjoajan määrityslippua, passiivinen salaus ei ole käytössä. Kun käytät Google Kubernetes Engineä tai muita Kubernetes-hallintapalveluita, tietosi salataan eri mekanismilla, joten lippua ei näy. Tarkista Kubernetes-toimittajaltasi, onko etcd-sisältö salattu.

Luottamuksellisten tietojen tallentaminen

Joitakin Kubernetes-resursseja, kuten erittäin herkkiä Secret-objekteja, ei pidä koskaan poistaa klusterista. Voit suojata resurssin poistamiselta käyttämällä Helm Managerin antamaa huomautusta:

kind: Secret
metadata:
    annotations:
        "helm.sh/resource-policy": keep

Salaiset objektien hallintastrategiat

Edellisen osan esimerkissä arkaluontoiset tiedot suojattiin luvattomalta käytöltä välittömästi sen jälkeen, kun ne oli tallennettu klusteriin. Mutta luettelotiedostoissa ne tallennettiin pelkkänä tekstinä.

Älä koskaan aseta luottamuksellisia tietoja tiedostoihin, jotka ovat versionhallinnassa. Kuinka voit hallita ja tallentaa näitä tietoja turvallisesti ennen kuin käytät niitä Kubernetes-klusteriisi?

Voit valita mitä tahansa työkaluja tai strategioita arkaluonteisten tietojen käsittelyyn sovelluksissasi, mutta sinun on silti vastattava ainakin seuraaviin kysymyksiin.

• Mihin arkaluonteisia tietoja tulisi säilyttää, jotta ne ovat helposti saatavilla?
• Kuinka saada arkaluontoiset tiedot aktiivisten sovellusten saataville?
• Mitä sovelluksille pitäisi tapahtua, kun vaihdat tai muokkaat arkaluonteisia tietoja?

Tietoja kirjoittajista

John Arundel on konsultti, jolla on 30 vuoden kokemus tietokonealalta. Hän on kirjoittanut useita kirjoja ja työskentelee useiden eri maiden yritysten kanssa neuvoen heitä pilvipohjaisen infrastruktuurin ja Kubernetesin suhteen. Vapaa-ajallaan hän harrastaa surffausta, on hyvä pistooliampuja ja soittaa amatöörinä pianoa. Asuu satumökissä Cornwallissa Englannissa.

Justin Domingus — Järjestelmänhallintainsinööri, joka työskentelee DevOps-ympäristössä Kubernetes- ja pilvitekniikoilla. Hän nauttii ulkoilusta, kahvin juomisesta, rapsahtamisesta ja tietokoneen ääressä istumisesta. Asuu Seattlessa, Washingtonissa, ihanan kissan ja vielä upeamman vaimon ja parhaan ystävän Adriennen kanssa.

» Lisätietoja kirjasta on osoitteessa kustantajan verkkosivuilla
» sisällysluettelo
» Ote

Khabrozhitelille 25% alennus kupongista - Kubernetes

Kun kirjan paperiversio on maksettu, sähköpostiin lähetetään e-kirja.

Lähde: will.com