Raamat „Kubernetes õpetus DevOps'ile“

Tere, Habrikate! Kubernetes on üks kaasaegse pilveökosüsteemi võtmeelemente. 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 loote oma pilvepõhise rakenduse ja loote selle toetamiseks infrastruktuuri, seadistate arenduskeskkonna ja pideva juurutamise torujuhtme, mis tuleb teile kasuks järgmiste rakenduste arendamisel.

• Alustage konteinerite ja Kubernetesega tutvumist algusest: teema õppimiseks ei ole vajalikke erilisi teadmisi. • Käitage oma klastreid või valige Amazonilt, Google'ilt jt hallatav Kubernetes teenus. • Kasutage Kubernetes'i konteinerite elutsükli ja ressursikasutuse haldamiseks. • Optimeerige klastreid kulude, jõudluse, stabiilsuse, võimsuse ja skaleeritavuse näitajate järgi. • Uurige parimaid tööriistu oma rakenduste arendamiseks, testimiseks ja juurutamiseks. • Kasutage praeguseid tööstusstandardeid turvalisuse ja kontrolli tagamiseks. • Rakendage ettevõttes DevOps põhimõtteid, et arendustiimid saaksid töötada paindlikumalt, kiiremini ja tõhusamalt.

Kellele raamat on mõeldud

Raamat on kõige asjakohasem serverite, rakenduste ja teenuste haldamise osakondade töötajatele ning arendajatele, kes tegelevad kas uute pilveteenuste loomise või olemasolevate rakenduste migratsiooniga Kubernetesisse ja pilve. Ärge muretsege, et Kubernetesega ja konteineritega töötamine on vajalik — me õpetame teile kõike.

Kubernetes'i kogen kasutajad leiavad siit ka palju kasulikku: käsitleme süvitsi selliseid teemasid nagu RBAC, pidev juurutamine, tundlike andmete haldamine ja jälgimine. Loodame, et raamatu lehtedel on midagi huvitavat ka teile, sõltumata teie oskustest ja kogemustest.

Millistele küsimustele raamat vastab

Raamatu planeerimise ja kirjutamise käigus arutasime pilvetehnoloogiaid ja Kubernetes'i sadade inimestega, rääkides nii juhtide ja valdkonna ekspertidega kui ka absoluutselt algajatega. Allpool on eraldi küsimused, millele nad sooviksid näha vastuseid selles väljaandes.

• «Mind huvitab, miks peaks investeerima aega sellesse tehnoloogiasse. Milliseid probleeme see aitab mul ja mu meeskonnal lahendada?»
• «Kubernetes tundub huvitav, kuid sellel on üsna kõrge sisenemiskünnis. Lihtsa näite koostamine pole keeruline, kuid edasine haldamine ja tõrkeotsing hirmutavad. Soovime saada usaldusväärseid nõuandeid selle kohta, kuidas inimesed haldavad Kubernetes'i klastreid reaalsetes tingimustes ning millega me tõenäoliselt silmitsi seisame.»
• „Subjektiivne nõuanne oleks kindlasti kasulik. Kubernetes'e ökosüsteem pakub alustavate meeskondade jaoks liiga palju valikuvõimalusi. Kui sama asja saab teha mitmel moel, kuidas mõista, milline on parem? Kuidas valida?”

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

• „Kuidas kasutada Kubernetes'e, ilma et see rikuks minu ettevõtte toimimist?”

Lõik. Konfiguratsioon ja Secret objektid

Võime eraldada Kubernetes'e rakenduse loogika selle konfiguratsioonist (st igasugustest väärtustest või seadetest, mis aja jooksul võivad muutuda) on väga kasulik. Konfiguratsiooni väärtuste alla kuuluvad tavaliselt keskkonnapõhised parameetrid, kolmandate osapoole teenuste DNS-aadressid ja autentimiseks vajalikud mandaadid.

Muidugi, kõik need saab otse koodi sisse panna, kuid selline lähenemine pole piisavalt paindlik. Näiteks konfiguratsiooni väärtuse muutmiseks tuleb teie kood uuesti kokku panna ja juurutada. Palju parem lahendus oleks eraldada konfiguratsioon koodist ja lugeda see failist või keskkonnamuutujatest.

Kubernetes pakub mitmeid erinevaid viise konfiguratsiooni haldamiseks. Esiteks saate väärtusi rakendusele edastada keskkonnamuutujate kaudu, mis on määratletud pod-i spetsifikatsioonis (vt jaotist "Keskkonnamuutujad" lk 192). Teiseks saab konfiguratsioonikandmeid salvestada otse Kubernetesesse, kasutades ConfigMap ja Secret objekte.

Selles peatükis uurime neid objekte süvitsi ja arutame mõningaid praktilisi lähenemisviise konfiguratsiooni ja konfidentsiaalsete andmete haldamiseks näidiserakenduse näitel.

Pod-ümbrikute värskendamine konfiguratsiooni muutumisel

Kujutage ette, et teie klastris on juurutamine ja soovite muuta mõningaid väärtusi selle ConfigMap-is. Kui kasutate Helm'i chart'i (vt jaotist "Helm: Kubernetes'e pakihaldur" lk 102), saate konfiguratsiooni muutuse avastada ja oma pod-ümbrikutesse automaatselt taaskäivitada, kasutades ühte elegantset nippi. Lisage järgmine annotatsioon oma juurutamise spetsifikatsiooni:

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

Nüüd sisaldab juurutuse mall konfiguratsiooni parameetrite kontrollsummat: parameetrite muutmisel uuendatakse summat. Kui käitada käsk helm upgrade, tuvastab Helm, et juurutuse spetsifikatsioon on muutunud, ja taaskäivitab kõik pod-kestad.

Kuberneetes konfidentsiaalsed andmed

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

Selle asemel pakub Kuberneetes erilist tüüpi objekti, mis on mõeldud konfidentsiaalsete andmete salvestamiseks: Secret. Järgmises vaatame näidet, kuidas seda objekti meie demonstreerimisrakenduses kasutada.

Alustuseks vaadake Kuberneetes'i manifesti Secret objekti jaoks (vt hello-secret-env/k8s/secret.yaml):

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

Selles näites on magicWord privaatvõti, mille väärtus on xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing)). Sõna xyzzy on arvutite maailmas äärmiselt kasulik. Nagu ConfigMapis, võib ka Secret-objektis olla mitu võtme-väärtuse paari. Siin kasutame lihtsuse huvides vaid ühte "võti — väärtus" paari.

Secret-objektide kasutamine keskkonnamuutujatena

Nagu ConfigMap, saab ka Secret-objekti kergesti konteineris kättesaadavaks teha keskkonnamuutujatena või failina selle kettale. 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äivita järgmine käsk demo hoidlas, et rakendada manifestid:

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

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

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

Aadressi avamisel localhost:9999/ peaksite nägema järgmist:

Salajane sõna on "xyzzy"

Secret-objektide salvestamine failidesse

Selles näites ühendame objekti Secret konteineriga faili kujul. Kood asub demo repi hello-secret-file kaustas.

Selleks, et ühendada Secret faili kujul, kasutame järgmisi juurutusi:

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 alajaotises "Konfiguratsioonifailide loomine ConfigMapi objektidest" lk 240, loome mahu (antud juhul demo-secret-volume) ja ühendame selle konteineriga volumeMounts spetsifikatsiooni osas. MountPath väljas on määratud "/secrets", mistõttu Kubernetes loob selles kaustas iga "võti - väärtus" paari jaoks, mis on määratud objekti Secret.

Meie näites oleme määranud ainult ühe "võti - väärtus" paari nimega magicWord, seega loob manifakt konteineris ühe faili "/secrets/magicWord" konfidentsiaalsete andmetega, mis on ainult lugemise jaoks kättesaadavad.

Kui käitada seda manifeeti samamoodi nagu eelnevas näites, peaks olema sama tulemus:

Salajane sõna on "xyzzy"

Secret objektide lugemine

Eelmises jaotises kasutasime käsku kubectl describe ConfigMap'i sisu kuvamiseks. Kas sama saab teha Secret'iga?

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

Namespace:      default
Labels:             
Annotations:
Type:               Opaque

Data
====
magicWord: 5   bytes

Pange tähele, et andmeid ennast ei kuvata. Kubernetes'is on Secret objektid tüüpi Opaque: see tähendab, et nende sisu ei kuvata kubectl describe väljundis, logides ega terminalis, mis takistab konfidentsiaalse teabe juhuslikku avalikustamist.

Salajaoleva teabe kodeeritud versiooni YAML formaadis 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=, see ei sarnane meie algväärtusega? Tegelikult esindab see Secret objekti base64 kodeeringus. Base64 on üldiste binaarandmete kodeerimise skeem, mis konverteerib need sümbolide stringiks.

Kuna konfidentsiaalne teave võib olla binaarne ja väljundiks kättesaamatu (näiteks TLS šifreerimisvõtme korral), hoitakse Secret objekte alati base64 formaadis.

Tekst beHl6enk= on meie salajase sõna xyzzy versioon, mis on kodeeritud base64 vormingus. Seda saab kinnitada, kui käitada terminalis käsku base64 —decode:

echo "eHl6enk=" | base64 --decode
xyzzy

Seega, kuigi Kubernetes kaitseb teid tundlike andmete juhusliku väljatrüki eest terminalis või logifailides, on võimalus neid andmeid saada base64 formaadis, kui on lugemisõigused Secret objektidele teatud nimede ruumis ja hiljem dekrüpteerida.

Kui peate kodeerima mõne teksti base64 formaati (näiteks et paigutada see Secret'i), kasutage käsku base64 argumentideta:

echo xyzzy | base64
eHl6enkK

Juurdepääs Secret objektidele

Kes võib lugeda ja redigeerida Secret objekte? Seda määrab RBAC — juurdepääsukontrolli mehhanism (arutame seda põhjalikumalt peatükis „Sissejuhatus rollipõhisesse juurdepääsu haldamisse“ lk 258). Kui kasutate klastrit, kus RBAC süsteem puudub või ei ole sisse lülitatud, on kõik teie Secret objektid kõikide kasutajate ja konteinerite jaoks kergesti ligipääsetavad (hiljem selgitame, et teil ei peaks olema ühtegi tööstuslikku klastrit ilma RBAC-ta).

Passiivne andmete krüptimine

Aga mis saab olema nende inimeste puhul, kes pääsevad etcd andmebaasi, kus Kubernetes salvestab kogu oma teabe? Kas nad saavad lugeda konfidentsiaalseid andmeid, kui neil ei ole API kaudu Object Secret lugemisõigust?

Alates versioonist 1.7 toetab Kubernetes passiivset andmete krüpteerimist. See tähendab, et konfidentsiaalne teave etcd sees salvestatakse kettale krüptitud kujul ja ei saa olla isegi nende poolt loetav, kes pääsevad andmebaasile otse ligi. Selle dekrüpteerimiseks on vajalik võti, mis on ainult Kubernetes API serveril. Õigesti konfigureeritud klastris peaks passiivne krüpteerimine olema sisse lülitatud.

Kontrollimiseks, kas passiivne krüpteerimine töötab teie klastris, saate teha järgmist:

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 sisse lülitatud. Google Kubernetes Engine'i või muude Kubernetes-i haldusteenuste kasutamisel krüpteeritakse teie andmed teistsuguse mehhanismi abil, seega lipp puudub. Uurige oma Kubernetes'i teenusepakkujalt, kas etcd sisu on krüptitud.

Konfidentsiaalsete andmete hoidmine

Kuberneteses on ressursse, mida ei tohiks kunagi klastrist kustutada: näiteks eriti olulised objektid, nagu Secret. Saate ressursi kustutamise vältimiseks kasutada annotatsiooni, mida pakub Helm'i haldaja:

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

Secret objektide haldamise strateegiad

Eelmise osa näites kaitsti konfidentsiaalsed andmed volitamata ligipääsu eest kohe pärast klastrisse salvestamist. Kuid manifestifailides olid need salvestatud tavatekstina.

Te ei tohi kunagi säilitada konfidentsiaalset teavet failides, mis on versioonihalduses. Kuidas siis turvaliselt hallata ja säilitada sellist teavet enne, kui see rakendatakse Kuberneteses klastrisse?

Saate valida mistahes tööriistad või strateegiad konfidentsiaalsete andmete haldamiseks oma rakendustes, kuid peate siiski vastama vähemalt järgmistele küsimustele.

• Kus hoida konfidentsiaalseid andmeid, et need oleksid kõrge kättesaadavusega?
• Kuidas muuta konfidentsiaalsed andmed teie aktiivsetele rakendustele kergesti ligipääsetavaks?
• Mis peab teie rakendustega juhtuma, kui te asendate või redigeerite tundlikke andmeid?

Autoritest

John Arundell on nõustaja, kellel on 30-aastane kogemus arvutitehnika valdkonnas. Ta on kirjutanud mitmeid raamatuid ja teeb koostööd paljude erinevatest riikidest pärit ettevõtetega, pakkudes neile nõu pilvepõhiste infrastruktuuride ja Kubernetes'e küsimustes. Vabal ajal armastab ta surfata, oskab hästi lasta püstolist ja mängib hobina klaverit. Elab muinasjutulises suvila Cornwalis, Inglismaal.

Justin Domingus on süsteemiadministreerimise insener, kes töötab DevOpsi keskkonnas, keskendudes Kubernetes'ele ja pilvetehnoloogiatele. Talle meeldib veeta aega värskes õhus, juua kohvi, krabisid püüda ja arvuti taga istuda. Elab Seattle'is, Washingtonis, koos oma imelise kassi ja veel imelisema abikaasa ning parima sõbra Edrianniga.

» Raamatu kohta on täiendavat teavet saadaval väljaandja veebisaidil
» Sisukord
» Lõik

Habr'i lugejatele 25% allahindlus kupongiga — Kubernetes

Paberraamatu eest tasumise korral saadetakse e-raamat e-kirjaga.

Allikas: habr.com