Raamat „Kubernetes DevOpsile“

Tere, Hubrijad! Kubernetes on üks peamisi elemente tänapäeva pilveökosüsteemis. See tehnoloogia tagab konteinerite virtualiseerimise usaldusväärsuse, skaleeritavuse ja vastupidavuse. John Arundel ja Justin Domingus räägivad Kubernetes'e ökosüsteemist ja tutvustavad tõestatud lahendusi igapäevaste probleemide lahendamiseks. Samm-sammult ehitate oma pilvepõhise rakenduse ja loote selle toetamiseks infrastruktuuri, seadistate arenduskeskkonna ja pideva juurutamise toru, mis on kasulik järgmiste rakenduste loomisel.

• Alustate tööga konteinerite ja Kubernetes'ega nullist: teema õppimiseks ei ole vajalik eriteadmisi. • Käivitate oma klastreid või valite Amazon, Google jms hallatava Kubernetes'e teenuse. • Rakendate Kubernetes'e konteineri elutsükli ja ressursside haldamiseks. • Optimeerite klastreid kulude, jõudluse, vastupidavuse, jõudluse ja skaleeritavuse näitajate järgi. • Uurite parimaid vahendeid oma rakenduste arendamiseks, testimiseks ja juurutamiseks. • Kasutate aktuaalseid tööstusharu praktikaid turvalisuse ja kontrolli tagamiseks. • Rakendate ettevõttes DevOpsi põhimõtteid, et arendusteamid saaksid tegutseda paindlikumalt, kiiremini ja tõhusamalt.

Kellele raamat on mõeldud

Raamat on eriti asjakohane administraatorite osakondade töötajatele, kes vastutavad serverite, rakenduste ja teenuste eest, samuti arendajatele, kes tegelevad kas uute pilveteenuste loomise või olemasolevate rakenduste migratsiooniga Kubernetes'e ja pilve. Ärge muretsege, Kubernetes'e ja konteineritega töötamise oskusi ei nõuta – me õpetame teid kõike.

Kogemustega Kubernetes'e kasutajad leiavad samuti palju kasulikku: siin käsitletakse põhjalikult selliseid teemasid nagu RBAC, pidev juurutamine, konfidentsiaalsete andmete haldamine ja jälgitavus. Loodame, et raamatu lehekülgedelt leiate kindlasti midagi huvitavat, sõltumata teie oskustest ja kogemustest.

Millistele küsimustele raamat vastab

Raamatute kavandamise ja kirjutamise käigus arutasime pilvetehnoloogiaid ja Kubernetes't sadade inimestega, vesteldes nii valdkonna juhtide ja ekspertidega kui ka absoluutsete algajatega. Allpool on eraldi küsimused, millele nad tahaksid nähes vastuseid selles väljaandes.

• „Mind huvitab, miks peaksime selle tehnoloogiaga aega veetma. Milliseid probleeme see aitab mul ja mu meeskonnal lahendada?“
• „Kubernetes tundub huvitav, kuid sellel on üsna kõrge sisenemispiir. Lihtsa näite koostamine ei valmista probleeme, kuid edasine haldamine ja silumine on hirmutav. Sooviksime saada usaldusväärseid nõuandeid selle kohta, kuidas inimesed haldavad Kubernetes klastreid reaalses maailmas ja millega me tõenäoliselt silmitsi seisame.“
• „Subjektiivne nõuanne oleks kasulik. Kubernetes'e ökosüsteem pakub algajatele meeskondadele liiga palju valikuvariante. Kui sama asja saab teha mitmel viisil, kuidas mõista, milline neist on parim? Kuidas teha valik?“

Ja võib-olla kõige olulisem küsimus kõigist:

• „Kuidas kasutada Kubernetes't, rikkumata oma ettevõtte tegevust?“

Lõik. Konfiguratsioon ja Secret objektid

Võime eraldada Kubernetes'i rakenduse loogika selle konfiguratsioonist (st kõik väärtused või seaded, mis aja jooksul võivad muutuda) on väga kasulik. Konfiguratsiooniväärtuste alla kuuluvad tavaliselt keskkonnaparametrid, kolmandate osapoolte teenuste DNS-aadressid ja autentimiseks vajalikudCredentials.

Muidugi saab kõik selle koodi sisse panna, kuid selline lähenemine ei ole piisavalt paindlik. Näiteks juhul, kui konfiguratsiooniväärtust tuleb muuta, tuleb teie kood uuesti üles ehitada ja juurutada. Tunduvalt parem lahendus oleks eraldada konfiguratsioon koodist ja lugeda seda failist või keskkonnamuutujatest.

Kubernetes pakub mitmeid erinevaid viise konfiguratsiooni haldamiseks. Esiteks saate edastada väärtusi rakendusele keskkonnamuutujate kaudu, mis on määratud pod-koreade spetsifikatsioonis (vt alajaotust „Keskkonnamuutujad“ lk 192). Teiseks, konfiguratsioonid saab salvestada otse Kubernetes's, kasutades ConfigMap ja Secret objekte.

Selles peatükis uurime neid objekte põhjalikult ja vaatleme mõningaid praktilisi lähenemisviise konfiguratsiooni ja konfidentsiaalsete andmete haldamiseks näidisrakenduse näitel.

Pod-ümbriste värskendamine konfiguratsiooni muutmisel

Kujutage ette, et teie klastris on rakendus ja te soovite muuta mõned väärtused selle ConfigMap'is. Kui kasutate Helm'i chart'i (vt peatükki "Helm: Kubernetes'i paketihaldur" lk 102), saate automaatselt tuvastada konfiguratsiooni muutuse ja oma pod-ümbrised uuesti käivitada elegantse nippiga. Lisage järgmine annotatsioon oma rakenduse spetsifikatsiooni:

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

Nüüd sisaldab rakenduse mall konfiguratsiooniparametrite rikka summat: parametrite muutmisel värskendatakse summat. Helm'i uuendamise korral tuvastab Helm, et rakenduse spetsifikatsioon on muutunud ja käivitab kõik pod-ümbrised uuesti.

Konfidentsiaalsed andmed Kuberneteses

Me juba teame, et ConfigMap'i objekt pakub paindlikku mehhanismi konfiguratsioonandmete salvestamiseks ja neile juurdepääsuks klastris. Kuid enamikul rakendustel on teave, mis on salajane ja konfidentsiaalne: näiteks paroolid või API võtmed. Seda saab salvestada ka ConfigMap'i, kuid selline lahendus ei ole ideaalne.

Selle asemel pakub Kubernetes spetsiaalse tüübi objekti, mis on ette nähtud konfidentsiaalsete andmete salvestamiseks: Secret. Järgnevalt vaatleme näidisrakenduse kontekstis, kuidas seda objekti rakendada.

Alustuseks vaatame Kubernetes'e manifesti Secret objektile (vt hello-secret-env/k8s/secret.yaml):

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

Selles näites on salajase võtme magicWord väärtus xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing)). Sõna xyzzy on arvutite maailmas tõeliselt kasulik. Sarnaselt ConfigMap'iga saab Secret objektis hoida palju võtmeid ja väärtusi. Siin kasutame lihtsuse huvides vaid ühte "võti - väärtus" paari.

Secret objektide kasutamine keskkonnamuutujatena

Nagu ConfigMap, saab ka Secret objekti teha konteineris kergesti kättesaadavaks keskkonnamuutujate või failina tema ketas. Järgmises näites määrame keskkonnamuutujale väärtuse Secret'ist:

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

Käivitage järgmine käsk demo hoidlas, et manustada manifestid:

kubectl apply -f hello-secret-env/k8s/
deployment.extensions "demo" konfigureeritud
secret "demo-secret" loodud

Nagu ennegi, suunake kohalik port rakendusele, et näha tulemust oma brauseris:

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

Avades aadressi localhost:9999/ peaksite nägema järgmist:

Salajane sõna on "xyzzy"

Salajaste objektide salvestamine failidesse

Selles näites ühendame salajase objekti konteineriga failina. Kood on demo hoidla hello-secret-file kaustas.

Salajase faili ühendamiseks kasutame järgmist rakendust:

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

Nagu jaotises „Konfiguratsioonifailide loomine ConfigMap objektidest” leheküljel 240, loome mahu (antud juhul demo-secret-volume) ja ühendame selle konteineriga mahtude määratlemise sektsioonis. mountPath väljale on määratud /secrets, seega loob Kubernetes selle kaustas ühe faili iga „võti- väärtus” paari kohta, mis on määratletud salajases objekti.

Meie näites oleme määranud ainult ühe „võti- väärtus” paari nimega magicWord, seega loob manifest konteineris ühe faili /secrets/magicWord salajaste andmetega, mis on saadaval ainult lugemiseks.

Kui manustada see manifest samamoodi nagu eelmises näites, peaks tulemus olema sama:

Salajane sõna on "xyzzy"

Salajaste objektide lugemine

Eelmisel leheküljel kasutasime käsku kubectl describe ConfigMap sisu kuvamiseks. Kas on võimalik sama teha salajase objektiga?

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

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

Data
====
magicWord: 5   bytes

Märkus: andmed endid ei kuvata. Salajased objektid Kuberneteses on tüübilt Opaque: see tähendab, et nende sisu ei kuvata kubectl describe väljundis, logides ja terminalis, takistades seega salajase teabe tahtlikku avalikustamist.

YAML-formaadis salajaste andmete kodeeritud versiooni vaatamiseks kasutage käsku kubectl get:

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

base64

Mis on eHl6enk=, mis ei näe välja nagu meie algne väärtus? Tegelikult on see Secret objekt, esitatud base64 kodeeringus. Base64 on skeem, mis kodeerib juhuslikke binaarandmeid sümbolite stringiks.

Kuna konfidentsiaalne teave võib olla binaarne ja ei pruugi olla väljundiks kergesti saadaval (nt TLS krüptimise võtme puhul), siis hoitakse Secret objekte alati base64 formaadis.

Tekst beHl6enk= on meie salajase sõna xyzzy base64 kodeeritud versioon. Seda saab kontrollida, kui terminalis käivitada käsk base64 —decode:

echo "eHl6enk=" | base64 --decode
xyzzy

Seega, kuigi Kubernetes kaitseb teid juhusliku konfidentsiaalsete andmete väljundist terminalis või logifailides, on olemasolevate õiguste korral võimalik neid base64 formaadis saada ja hiljem dekodeerida.

Kui peate kodeerima mõne teksti base64 (nt selle paigutamiseks Secretisse), kasutage käsku base64 ilma argumentideta:

echo xyzzy | base64
eHl6enkK

Pääs Secret objektidele

Kes saab lugeda ja redigeerida Secret objekte? See määratakse RBAC — juurdepääsu kontrolli mehhanismiga (mille üle arutame üksikasjalikult jaotises "Sissejuhatus rollipõhisesse juurdepääsu haldamisse" lk 258). Kui kasutate klastrit, kus RBAC süsteem puudub või ei ole lubatud, on kõik teie Secret objektid kõigile kasutajatele ja konteineritele kergesti kättesaadavad (hiljem selgitame, miks ei tohiks teil olla ühtegi tööstuslikku klastrit ilma RBAC-ta).

Passiivne andmete krüpteerimine

Aga kuidas on nende kohta, kes pääsevad juurde andmebaasile etcd, kus Kubernetes salvestab kogu oma teabe? Kas nad saavad lugeda konfidentsiaalseid andmeid, ilma et oleksid õigusi lugeda Secret objekte API kaudu?

Alates versioonist 1.7 toetab Kubernetes passiivset andmete krüpteerimist. See tähendab, et tundlik teave etcd-s hoitakse kettal krüpteeritud kujul ja seda ei saa lugeda isegi neil, kellel on otsene juurdepääs andmebaasile. Selle dekrüpteerimiseks on vajalik võti, mis on ainult Kubernetes API serveril. Õigesti konfigureeritud klastris peaks passiivne krüpteerimine olema lubatud.

Kontrollida, kas passiivne krüpteerimine teie klastris töötab, saab järgmiselt:

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

Kui te ei näe lippu experimental-encryption-provider-config, siis passiivne krüpteerimine ei ole lubatud. Google Kubernetes Engine'i või muude Kubernetes'i haldusteenuste kasutamisel on teie andmed krüpteeritud muude mehhanismide abil, seetõttu see lipp puudub. Küsige oma Kubernetes'i teenusepakkujalt, kas etcd sisu on krüpteeritud.

Tundlike andmete haldamine

On Kubernetes'i ressursse, mida ei tohiks kunagi klastrist kustutada: näiteks eriti olulised Secret objektid. Saate ressursi kustutamise eest kaitsta annotatsiooni abil, mida pakub Helm haldur:

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

Secret objektide haldamise strateegiad

Eelnevas jaotises kaitsti tundlikud andmed volitamata juurdepääsu eest kohe pärast klastrisse salvestamist. Kuid manifestifailides salvestati need tavalise tekstina.

Te ei tohi kunagi paigutada tundlikku teavet failidesse, mis on versioonihaldussüsteemis. Kuidas ohutult hallata ja hoida sellist teavet enne selle rakendamist Kubernetes klastrisse?

Saate valida mis tahes tööriistad või strateegiad tundlike andmete haldamiseks oma rakendustes, kuid peate siiski vähemalt neile küsimustele vastama.

• Kus hoida tundlikke andmeid, et need oleksid suure kättesaadavusega?
• Kuidas teha tundlikud andmed teie aktiivsetele rakendustele kättesaadavaks?
• Mis peaks juhtuma teie rakendustega, kui asendate või muudate tundlikke andmeid?

Autoritest

John Arundel on konsultant 30-aastase kogemusega arvutustööstuses. Ta on kirjutanud mitu raamatut ja teeb koostööd paljude ettevõtetega erinevatest maadest, nõustades neid pilvepõhiste infrastruktuuri ja Kubernetes'i küsimustes. Vabas osas naudib ta surfamist, on hea relvakasutaja ja mängib hobi korras klaverit. Elab muinasjutulises suvekohas Cornwallis, Inglismaal.

Justin Domingus on süsteemihalduse insener, kes töötab DevOps keskkonnas Kubernetes'i ja pilvetehnoloogiatega. Talle meeldib veeta aega värskes õhus, juua kohvi, kraabe püüda ja arvuti taga aega veeta. Elab Seattle'is, Washingtonis, koos oma imelise kassi ja veelgi imelisema naisega, kes on tema parim sõber, Adrienne.

» Raamatuga saab lähemalt tutvuda kirjastuse veebisaidil
» Sisukord
» Lõik

Habr kasutajatele on 25% allahindlus kupongi abil — Kubernetes

Paberkoopia eest maksmise korral saadetakse elektrooniline raamat e-posti teel.

Allikas: habr.com