Knjiga »Kubernetes za DevOps«

Pozdravljeni prebivalci Khabra! Kubernetes je eden ključnih elementov sodobnega ekosistema v oblaku. Ta tehnologija zagotavlja zanesljivost, razširljivost in odpornost na virtualizacijo vsebnikov. John Arundel in Justin Domingus govorita o ekosistemu Kubernetes in predstavljata preizkušene rešitve za vsakodnevne težave. Korak za korakom boste zgradili svojo lastno aplikacijo v oblaku in ustvarili infrastrukturo za njeno podporo, nastavili razvojno okolje in cevovod za neprekinjeno uvajanje, ki vam bo pomagal pri delu na naslednjih aplikacijah.

• Začnite uporabljati vsebnike in Kubernetes od osnov: za učenje teme niso potrebne posebne izkušnje. • Zaženite lastne gruče ali izberite upravljano storitev Kubernetes iz Amazona, Googla itd. • Uporabite Kubernetes za upravljanje življenjskega cikla vsebnika in porabe virov. • Optimizirajte gruče na podlagi stroškov, zmogljivosti, odpornosti, moči in razširljivosti. • Naučite se najboljših orodij za razvoj, testiranje in uvajanje vaših aplikacij. • Izkoristite trenutne industrijske prakse za zagotovitev varnosti in nadzora. • Implementirajte načela DevOps v celotnem podjetju, da bodo lahko razvojne ekipe delovale bolj prožno, hitro in učinkovito.

Komu je knjiga namenjena?

Knjiga je najbolj relevantna za zaposlene v upravnih oddelkih, ki so odgovorni za strežnike, aplikacije in storitve, ter za razvijalce, ki se ukvarjajo bodisi z gradnjo novih storitev v oblaku bodisi s selitvijo obstoječih aplikacij v Kubernetes in oblak. Ne skrbite, ni vam treba znati delati s Kubernetesom ali vsebniki – vsega vas bomo naučili.

Izkušeni uporabniki Kubernetes bodo prav tako našli veliko vrednosti s poglobljeno pokritostjo tem, kot so RBAC, neprekinjeno uvajanje, upravljanje občutljivih podatkov in opazljivost. Upamo, da bo na straneh knjige zagotovo kaj zanimivega za vas, ne glede na vaše znanje in izkušnje.

Na katera vprašanja odgovarja knjiga?

Med načrtovanjem in pisanjem knjige smo razpravljali o tehnologiji v oblaku in Kubernetesu s stotinami ljudi, se pogovarjali z vodilnimi v industriji in strokovnjaki ter popolnimi novinci. Spodaj so izbrana vprašanja, na katera bi želeli videti odgovore v tej publikaciji.

• »Zanima me, zakaj bi morali porabiti čas za to tehnologijo. Katere težave bo pomagal rešiti meni in moji ekipi?«
• »Kubernetes se zdi zanimiv, vendar ima precej visoko oviro za vstop. Priprava preprostega primera ni težka, nadaljnje upravljanje in odpravljanje napak pa je zastrašujoče. Radi bi dobili zanesljiv nasvet o tem, kako ljudje upravljajo gruče Kubernetes v resničnem svetu in na kakšne težave se bomo verjetno srečali.«
• »Subjektivni nasveti bi bili koristni. Ekosistem Kubernetes daje novim ekipam preveč možnosti izbire. Če obstaja več načinov za isto stvar, kako veste, kateri je najboljši? Kako narediti izbiro?

In morda najpomembnejše od vseh vprašanj:

• »Kako lahko uporabljam Kubernetes, ne da bi motil svoje podjetje?«

Izvleček. Konfiguracija in tajni objekti

Možnost ločevanja logike aplikacije Kubernetes od njene konfiguracije (to je od vseh vrednosti ali nastavitev, ki se lahko sčasoma spremenijo) je zelo uporabna. Vrednosti konfiguracije običajno vključujejo nastavitve, specifične za okolje, naslove DNS storitve tretjih oseb in poverilnice za preverjanje pristnosti.

Seveda je vse to mogoče dati neposredno v kodo, vendar ta pristop ni dovolj prilagodljiv. Na primer, če spremenite konfiguracijsko vrednost, boste morali znova zgraditi in razmestiti kodo. Veliko boljša rešitev bi bila ločiti konfiguracijo od kode in jo prebrati iz datoteke ali spremenljivk okolja.

Kubernetes ponuja več različnih načinov za upravljanje konfiguracije. Najprej lahko aplikaciji posredujete vrednosti prek spremenljivk okolja, ki so podane v specifikaciji ovoja sklopa (glejte »Spremenljivke okolja« na strani 192). Drugič, konfiguracijske podatke je mogoče shraniti neposredno v Kubernetes z uporabo predmetov ConfigMap in Secret.

V tem poglavju podrobno raziskujemo te predmete in si ogledamo nekaj praktičnih pristopov k upravljanju konfiguracije in občutljivih podatkov z uporabo predstavitvene aplikacije.

Posodabljanje lupin podov ob spremembi konfiguracije

Predstavljajte si, da imate v svoji gruči razmestitev in želite spremeniti nekaj vrednosti v njenem ConfigMap. Če uporabljate grafikon Helm (glejte »Helm: Upravitelj paketov za Kubernetes« na strani 102), lahko samodejno zaznate spremembo konfiguracije in znova naložite lupine podov z enim čednim trikom. Svoji specifikaciji uvajanja dodajte to opombo:

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

Predloga za razmestitev zdaj vsebuje kontrolno vsoto konfiguracijskih parametrov: če se parametri spremenijo, se vsota posodobi. Če zaženete nadgradnjo Helm, bo Helm zaznal, da se je specifikacija uvajanja spremenila, in znova zagnal vse lupine podov.

Občutljivi podatki v Kubernetesu

Že vemo, da objekt ConfigMap zagotavlja prilagodljiv mehanizem za shranjevanje in dostop do konfiguracijskih podatkov v gruči. Vendar ima večina aplikacij informacije, ki so občutljive in občutljive, kot so gesla ali ključi API. Lahko se shrani tudi v ConfigMap, vendar ta rešitev ni idealna.

Namesto tega Kubernetes ponuja posebno vrsto predmeta, namenjenega shranjevanju občutljivih podatkov: Secret. Nato si oglejmo primer, kako lahko ta predmet uporabimo v naši predstavitveni aplikaciji.

Za začetek si oglejte manifest Kubernetes za predmet Secret (glejte hello-secret-env/k8s/secret.yaml):

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

V tem primeru je zasebni ključ magicWord xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing)). Beseda xyzzy je na splošno zelo uporabna v svetu računalnikov. Podobno kot ConfigMap lahko shranite več ključev in vrednosti v Secret predmet. Tukaj zaradi enostavnosti uporabljamo samo en par ključ-vrednost.

Uporaba tajnih predmetov kot spremenljivk okolja

Tako kot ConfigMap je lahko predmet Secret na voljo v vsebniku kot spremenljivke okolja ali kot datoteka na njegovem disku. V naslednjem primeru bomo vrednosti iz Secret dodelili spremenljivko okolja:

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

Zaženite naslednji ukaz v predstavitvenem repozitoriju, da uporabite manifeste:

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

Kot prej posredujte lokalna vrata uvedbi, da vidite rezultat v brskalniku:

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

Pri odpiranju naslova localhost:9999/ bi morali videti naslednje:

The magic word is "xyzzy"

Zapisovanje skrivnih predmetov v datoteke

В этом примере мы подключим объект Secret к контейнеру в виде файла. Код находится в папке hello-secret-file репозитория demo.

Za povezavo Secret kot datoteke bomo uporabili naslednjo uvedbo:

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

Kot v pododdelku “Ustvarjanje konfiguracijskih datotek iz objektov ConfigMap” na str. 240, ustvarimo nosilec (v tem primeru demo-secret-volume) in ga pritrdimo na vsebnik v razdelku volumeMounts specifikacije. Polje mountPath je /secrets, zato bo Kubernetes v tej mapi ustvaril eno datoteko za vsak par ključ/vrednost, definiran v predmetu Secret.

V našem primeru smo definirali samo en par ključ-vrednost, imenovan magicWord, tako da bo manifest ustvaril eno datoteko /secrets/magicWord samo za branje z občutljivimi podatki v vsebniku.

Če ta manifest uporabite na enak način kot prejšnji primer, bi morali dobiti enak rezultat:

The magic word is "xyzzy"

Branje tajnih predmetov

V prejšnjem razdelku smo uporabili ukaz kubectl describe za prikaz vsebine ConfigMap. Ali je mogoče enako storiti s Secret?

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

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

Data
====
magicWord: 5   bytes

Upoštevajte, da sami podatki niso prikazani. Skrivni predmeti v Kubernetesu so vrste Opaque, kar pomeni, da njihova vsebina ni prikazana v kubectl describe izhodu, vnosih v dnevnik ali terminalu, kar onemogoča nenamerno razkritje občutljivih informacij.

Za ogled kodirane YAML različice občutljivih podatkov uporabite ukaz kubectl get:

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

base64

Kaj je eHl6enk=, popolnoma drugačen od naše prvotne vrednosti? To je dejansko skrivni objekt, predstavljen v kodiranju base64. Base64 je shema za kodiranje poljubnih binarnih podatkov kot niza znakov.

Ker so občutljive informacije lahko binarne in niso izhodne (kot v primeru šifrirnega ključa TLS), so skrivni predmeti vedno shranjeni v formatu base64.

Besedilo beHl6enk= je base64 kodirana različica naše skrivne besede xyzzy. To lahko preverite tako, da v terminalu zaženete ukaz base64 —decode:

echo "eHl6enk=" | base64 --decode
xyzzy

Medtem ko vas torej Kubernetes ščiti pred nenamernim izpisom občutljivih podatkov v terminalu ali dnevniških datotekah, je mogoče te podatke, če imate dovoljenja za branje za skrivne objekte v določenem imenskem prostoru, obdelati po osnovi 64 in jih nato dekodirati.

Če morate base64 kodirati neko besedilo (na primer, da ga postavite v Secret), uporabite ukaz base64 brez argumentov:

echo xyzzy | base64
eHl6enkK

Dostop do tajnih predmetov

Kdo lahko bere in ureja skrivne predmete? To določa RBAC, mehanizem za nadzor dostopa (podrobneje ga bomo obravnavali v pododdelku “Uvod v nadzor dostopa na podlagi vlog” na strani 258). Če izvajate gručo, ki nima RBAC ali ni omogočena, so vsi vaši skrivni objekti na voljo vsem uporabnikom in vsebnikom (kasneje bomo pojasnili, da brez RBAC ne bi smeli imeti produkcijskih gruč).

Pasivno šifriranje podatkov

Kaj pa tisti, ki imajo dostop do podatkovne baze etcd, kjer Kubernetes shranjuje vse svoje podatke? Ali lahko berejo občutljive podatke, ne da bi imeli dovoljenje za branje skrivnih predmetov prek API-ja?

Od različice 1.7 Kubernetes podpira pasivno šifriranje podatkov. To pomeni, da so občutljive informacije v etcd shranjene šifrirane na disku in jih ne morejo prebrati niti tisti z neposrednim dostopom do baze podatkov. Za dešifriranje potrebujete ključ, ki ga ima samo strežnik Kubernetes API. V pravilno konfigurirani gruči mora biti omogočeno pasivno šifriranje.

Na ta način lahko preverite, ali pasivno šifriranje deluje v vaši gruči:

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

Če zastavice eksperimentalnega-encryption-provider-config ne vidite, pasivno šifriranje ni omogočeno. Ko uporabljate Google Kubernetes Engine ali druge storitve upravljanja Kubernetes, so vaši podatki šifrirani z drugačnim mehanizmom, zato zastavica ne bo prisotna. Pri svojem prodajalcu Kubernetes preverite, ali je vsebina etcd šifrirana.

Shranjevanje zaupnih podatkov

Obstaja nekaj virov Kubernetes, ki jih nikoli ne bi smeli odstraniti iz gruče, kot so zelo občutljivi skrivni predmeti. Vir lahko zaščitite pred izbrisom z opombo, ki jo zagotovi upravitelj Helm:

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

Strategije upravljanja tajnih objektov

V primeru iz prejšnjega razdelka so bili občutljivi podatki zaščiteni pred nepooblaščenim dostopom takoj po shranjevanju v gručo. Toda v datotekah manifesta so bili shranjeni kot navadno besedilo.

Zaupnih informacij nikoli ne postavljajte v datoteke, ki so v nadzoru različic. Kako lahko varno upravljate in shranite te informacije, preden jih uporabite v svoji gruči Kubernetes?

Izberete lahko poljubna orodja ali strategije za ravnanje z občutljivimi podatki v svojih aplikacijah, vendar boste še vedno morali odgovoriti vsaj na naslednja vprašanja.

• Kje naj bodo občutljivi podatki shranjeni, da bodo zelo dostopni?
• Kako narediti občutljive podatke dostopne vašim aktivnim aplikacijam?
• Kaj bi se moralo zgoditi z vašimi aplikacijami, ko zamenjate ali uredite občutljive podatke?

O avtorjih

John Arundel je svetovalec s 30-letnimi izkušnjami v računalniški industriji. Napisal je več knjig in sodeluje s številnimi podjetji iz različnih držav ter jim svetuje o izvorni infrastrukturi v oblaku in Kubernetesu. V prostem času se ukvarja z deskanjem, je dober strelec s pištolo, ljubiteljsko igra klavir. Živi v pravljični koči v Cornwallu v Angliji.

Justin Domingus — inženir sistemske administracije, ki dela v okolju DevOps s tehnologijami Kubernetes in oblak. Rad preživlja čas na prostem, pije kavo, lovi rakce in sedi za računalnikom. Živi v Seattlu v Washingtonu s čudovito mačko in še bolj čudovito ženo in najboljšo prijateljico Adrienne.

» Več o knjigi najdete na spletno stran založbe
» Kazalo
» Izvleček

Za Khabrozhiteley 25% popust z uporabo kupona - Kubernetes

Ob plačilu papirne različice knjige vam po elektronski pošti pošljemo elektronsko knjigo.

Vir: www.habr.com