Tere, Khabro elanikud! Kubernetes on kaasaegse pilveökosüsteemi üks võtmeelemente. See tehnoloogia tagab konteinerite virtualiseerimise töökindluse, mastaapsuse ja vastupidavuse. John Arundel ja Justin Domingus räägivad Kubernetese ökosüsteemist ja tutvustavad end tõestanud lahendusi igapäevastele probleemidele. Samm-sammult loote omaenda pilvepõhise rakenduse ja loote seda toetava infrastruktuuri, loote arenduskeskkonna ja pideva juurutustorustiku, mis on abiks järgmiste rakenduste kallal töötades.
• Alustage konteinerite ja Kubernetetega põhitõdedest: teema õppimiseks pole vaja erilisi kogemusi. • Käivitage oma klastreid või valige Amazon, Google jne hallatav Kubernetese teenus. • Kasutage Kubernetesi konteineri elutsükli ja ressursside tarbimise haldamiseks. • Optimeerige klastreid kulu, jõudluse, vastupidavuse, võimsuse ja mastaapsuse alusel. • Õppige parimaid tööriistu rakenduste arendamiseks, testimiseks ja juurutamiseks. • Kasutage turvalisuse ja kontrolli tagamiseks tööstusharu praegusi tavasid. • Rakendage DevOpsi põhimõtteid kogu oma ettevõttes, et arendusmeeskonnad saaksid tegutseda paindlikumalt, kiiremini ja tõhusamalt.
Kellele raamat on mõeldud?
Raamat on kõige olulisem serverite, rakenduste ja teenuste eest vastutavate haldusosakondade töötajatele, aga ka arendajatele, kes tegelevad uute pilveteenuste loomise või olemasolevate rakenduste Kubernetesesse ja pilve migreerimisega. Ärge muretsege, te ei pea teadma, kuidas Kubernetese või konteineritega töötada – me õpetame teile kõike.
Kogenud Kubernetese kasutajad leiavad samuti palju väärtust, kuna need käsitlevad põhjalikult selliseid teemasid nagu RBAC, pidev juurutamine, tundlike andmete haldamine ja jälgitavus. Loodame, et raamatu lehekülgedel leidub Sulle kindlasti midagi huvitavat, olenemata Sinu oskustest ja kogemustest.
Millistele küsimustele raamat vastab?
Raamatut kavandades ja kirjutades arutasime pilvetehnoloogia ja Kubernetese üle sadade inimestega, vesteldes nii valdkonna juhtide ja ekspertidega kui ka täiesti algajatega. Allpool on valitud küsimused, millele nad sooviksid selles väljaandes vastuseid saada.
- "Mind huvitab, miks peaksite sellele tehnoloogiale aega kulutama. Milliseid probleeme see aitab mul ja mu meeskonnal lahendada?
- "Kubernetes tundub huvitav, kuid sellel on üsna kõrge sisenemisbarjäär. Lihtsa näite ettevalmistamine pole keeruline, kuid edasine haldamine ja silumine on hirmuäratav. Soovime saada usaldusväärset nõu selle kohta, kuidas inimesed reaalses maailmas Kubernetese klastreid haldavad ja milliste probleemidega me tõenäoliselt kokku puutume.
- “Subjektiivne nõuanne oleks abiks. Kubernetese ökosüsteem annab uutele meeskondadele liiga palju valikuvõimalusi. Kui sama asja tegemiseks on mitu võimalust, kuidas teada saada, milline neist on parim? Kuidas teha valikut?
Ja võib-olla kõige olulisem kõigist küsimustest:
- "Kuidas saan Kubernetest kasutada ilma oma ettevõtet häirimata?"
Väljavõte. Konfiguratsioon ja salajased objektid
Võimalus eraldada Kubernetese rakenduse loogika selle konfiguratsioonist (st mis tahes väärtustest või sätetest, mis võivad aja jooksul muutuda) on väga kasulik. Konfiguratsiooniväärtused hõlmavad tavaliselt keskkonnaspetsiifilisi sätteid, kolmanda osapoole teenuse DNS-aadresse ja autentimismandaate.
Loomulikult saab seda kõike otse koodi panna, kuid selline lähenemine pole piisavalt paindlik. Näiteks konfiguratsiooniväärtuse muutmine nõuab seejärel koodi uuesti koostamist ja juurutamist. Palju parem lahendus oleks eraldada konfiguratsioon koodist ja lugeda see failist või keskkonnamuutujatest.
Kubernetes pakub konfiguratsiooni haldamiseks mitmeid erinevaid viise. Esiteks saate edastada väärtused rakendusele keskkonnamuutujate kaudu, mis on määratud kausta ümbrise spetsifikatsioonis (vt "Keskkonnamuutujad" lk 192). Teiseks saab konfiguratsiooniandmeid salvestada otse Kubernetes, kasutades ConfigMap ja Secret objekte.
Selles peatükis uurime neid objekte üksikasjalikult ja vaatleme mõningaid praktilisi lähenemisviise konfiguratsiooni ja tundlike andmete haldamiseks demorakenduse abil.
Pod-kestade värskendamine konfiguratsiooni muutumisel
Kujutage ette, et teie klastris on juurutus ja soovite selle ConfigMapis mõnda väärtust muuta. Kui kasutate Helmi diagrammi (vt jaotist "Helm: Kubernetese paketihaldur" lk 102), saate automaatselt tuvastada konfiguratsioonimuudatuse ja laadida oma pod-kestad ühe korraliku nipiga uuesti. Lisage oma juurutusspetsifikatsioonile järgmine märkus.
checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") .
| sha256sum }}Juurutusmall sisaldab nüüd konfiguratsiooniparameetrite kontrollsummat: kui parameetreid muudetakse, värskendatakse summat. Kui käivitate tüüri versiooniuuenduse, tuvastab Helm, et juurutamise spetsifikatsioon on muutunud, ja taaskäivitab kõik pod-kestad.
Tundlikud andmed Kubernetesis
Teame juba, et ConfigMap objekt pakub paindlikku mehhanismi konfiguratsiooniandmete salvestamiseks ja neile juurdepääsuks klastris. Enamikul rakendustel on aga tundlik teave, näiteks paroolid või API võtmed. Seda saab salvestada ka ConfigMapi, kuid see lahendus pole ideaalne.
Selle asemel pakub Kubernetes spetsiaalset tüüpi objekte, mis on loodud tundlike andmete salvestamiseks: Secret. Järgmisena vaatame näidet, kuidas seda objekti saab meie demorakenduses kasutada.
Alustuseks vaadake salaobjekti Kubernetese manifesti (vt hello-secret-env/k8s/secret.yaml):
apiVersion: v1
kind: Secret
metadata:
name: demo-secret
stringData:
magicWord: xyzzy
Selles näites on magicWordi privaatvõti xyzzy (en.wikipedia.org/wiki/Xyzzy_(arvuti)). Sõna xyzzy on arvutimaailmas üldiselt väga kasulik. Sarnaselt ConfigMapiga saate salajasse objekti salvestada mitu võtit ja väärtust. Siin kasutame lihtsuse huvides ainult ühte võtme-väärtuste paari.
Salaobjektide kasutamine keskkonnamuutujatena
Nagu ConfigMap, saab ka salaobjekti teha konteineris kättesaadavaks keskkonnamuutujatena või failina selle kettal. Järgmises näites määrame saladuse väärtusele keskkonnamuutuja:
spec:
containers:
- name: demo
image: cloudnatived/demo:hello-secret-env
ports:
- containerPort: 8888
env:
- name: GREETING
valueFrom:
secretKeyRef:
name: demo-secret
key: magicWordManifestide rakendamiseks käivitage demohoidlas järgmine käsk:
kubectl apply -f hello-secret-env/k8s/
deployment.extensions "demo" configured
secret "demo-secret" createdNagu varemgi, edastage kohalik port juurutusse, et näha tulemust oma brauseris:
kubectl port-forward deploy/demo 9999:8888
Forwarding from 127.0.0.1:9999 -> 8888
Forwarding from [::1]:9999 -> 8888Aadressi avamisel :9999/ peaksite nägema järgmist:
The magic word is "xyzzy"
Salajaste objektide kirjutamine failidesse
Selles näites lisame objekti Salajane objekt failina konteinerisse. Kood asub demohoidla kaustas hello-secret-file.
Saladuse failina ühendamiseks kasutame järgmist juurutust:
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-secretNagu alajaotises "Konfiguratsioonifailide loomine ConfigMapi objektidest" lk. 240, loome köite (antud juhul demo-salajane köide) ja paigaldame selle spetsifikatsiooni jaotises VolumeMounts olevasse konteinerisse. MountPath väli on /secrets, seega loob Kubernetes sellesse kausta ühe faili iga salajase objektis määratletud võtme/väärtuse paari kohta.
Meie näites määratlesime ainult ühe võtme-väärtuste paari nimega magicWord, nii et manifest loob ühe kirjutuskaitstud faili /saladused/magicWord, mille konteineris on tundlikud andmed.
Kui rakendate seda manifesti samamoodi nagu eelmist näidet, peaksite saama sama tulemuse:
The magic word is "xyzzy"
Salajaste objektide lugemine
Eelmises jaotises kasutasime ConfigMapi sisu kuvamiseks käsku kubectl description. Kas Secretiga saab sama teha?
kubectl describe secret/demo-secret
Name: demo-secret
Namespace: default
Labels: <none>
Annotations:
Type: Opaque
Data
====
magicWord: 5 bytesPange tähele, et andmeid ise ei kuvata. Kubernetese salaobjektid on läbipaistmatut tüüpi, mis tähendab, et nende sisu ei kuvata kubectli kirjelduses, logikirjetes ega terminalis, mistõttu on tundliku teabe kogemata avaldamine võimatu.
Tundlike andmete kodeeritud YAML-versiooni vaatamiseks kasutage käsku kubectl get:
kubectl get secret/demo-secret -o yaml
apiVersion: v1
data:
magicWord: eHl6enk=
kind: Secret
metadata:
...
type: Opaquebase64
Mis on eHl6enk=, täiesti erinev meie algsest väärtusest? See on tegelikult salaobjekt, mis on esindatud base64 kodeeringus. Base64 on skeem suvaliste binaarandmete kodeerimiseks märgistringina.
Kuna tundlik teave võib olla binaarne ja seda ei väljastata (nagu TLS-i krüpteerimisvõtme puhul), salvestatakse salajased objektid alati base64-vormingus.
Tekst beHl6enk= on meie salasõna xyzzy base64 kodeeritud versioon. Saate seda kontrollida, käivitades terminalis käsu base64 —decode:
echo "eHl6enk=" | base64 --decode
xyzzyEhkki Kubernetes kaitseb teid tundlike andmete kogemata väljastamise eest terminalis või logifailides, siis kui teil on konkreetses nimeruumis salaobjektide lugemisõigused, saab neid andmeid base64-da ja seejärel dekodeerida.
Kui teil on vaja mõnda teksti base64 kodeerida (näiteks panna see salajasse), kasutage käsku base64 ilma argumentideta:
echo xyzzy | base64
eHl6enkKJuurdepääs salajastele objektidele
Kes saab salajasi objekte lugeda ja redigeerida? Selle määrab juurdepääsukontrolli mehhanism RBAC (me käsitleme seda üksikasjalikult alajaotises „Sissejuhatus rollipõhisesse juurdepääsukontrolli” lk 258). Kui kasutate klastrit, millel pole RBAC-i või mis pole lubatud, on kõik teie salaobjektid saadaval kõigile kasutajatele ja konteineritele (selgitame hiljem, et ilma RBAC-ita ei tohiks teil olla tootmisklastreid).
Passiivne andmete krüpteerimine
Kuidas on lood nendega, kellel on juurdepääs etcd andmebaasile, kuhu Kubernetes kogu oma teabe salvestab? Kas nad saavad lugeda tundlikke andmeid ilma, et neil oleks API kaudu salaobjektide lugemiseks luba?
Alates versioonist 1.7 toetab Kubernetes passiivset andmete krüptimist. See tähendab, et etcd sees olev tundlik teave salvestatakse krüpteeritult kettale ja seda ei saa lugeda isegi need, kellel on otsene juurdepääs andmebaasile. Selle dekrüpteerimiseks vajate võtit, mis on ainult Kubernetes API serveril. Õigesti konfigureeritud klastris peaks passiivne krüptimine olema lubatud.
Saate kontrollida, kas passiivne krüptimine teie klastris töötab, järgmiselt.
kubectl describe pod -n kube-system -l component=kube-apiserver |grep encryption
--experimental-encryption-provider-config=...Kui te eksperimentaalse krüptimise pakkuja konfiguratsiooni lippu ei näe, pole passiivne krüptimine lubatud. Google Kubernetes Engine'i või muude Kubernetes'i haldusteenuste kasutamisel krüpteeritakse teie andmed erineva mehhanismi abil, nii et lippu ei kuvata. Küsige oma Kubernetese müüjalt, kas etcd sisu on krüptitud.
Konfidentsiaalsete andmete säilitamine
Mõned Kubernetese ressursid, mida ei tohiks kunagi klastrist eemaldada, näiteks väga tundlikud salaobjektid. Saate kaitsta ressurssi kustutamise eest, kasutades Helmi halduri antud märkust.
kind: Secret
metadata:
annotations:
"helm.sh/resource-policy": keepSalajased objektide haldamise strateegiad
Eelmise jaotise näites kaitsti tundlikke andmeid volitamata juurdepääsu eest kohe pärast nende klastris salvestamist. Kuid manifestifailides salvestati need lihttekstina.
Te ei tohiks kunagi asetada konfidentsiaalset teavet failidesse, mis on versioonihalduses. Kuidas saate seda teavet turvaliselt hallata ja salvestada enne selle rakendamist oma Kubernetese klastris?
Saate oma rakendustes tundlike andmete käsitlemiseks valida mis tahes tööriistad või strateegiad, kuid siiski peate vastama vähemalt järgmistele küsimustele.
- Kus tuleks tundlikke andmeid hoida, et need oleksid hästi kättesaadavad?
- Kuidas muuta tundlikud andmed aktiivsetele rakendustele kättesaadavaks?
- Mis peaks juhtuma teie rakendustega, kui asendate või muudate tundlikke andmeid?
Autorite kohta
John Arundel on konsultant, kellel on 30-aastane kogemus arvutitööstuses. Ta on kirjutanud mitmeid raamatuid ja teeb koostööd paljude ettevõtetega erinevatest riikidest, nõustades neid pilvepõhise infrastruktuuri ja Kubernetese alal. Vabal ajal harrastab ta surfamist, on hea püstolilaskja ja mängib amatöörina klaverit. Elab Inglismaal Cornwallis muinasjutulises majakeses.
Justin Domingus — süsteemihalduse insener, kes töötab Kubernetese ja pilvetehnoloogiaga DevOpsi keskkonnas. Talle meeldib õues aega veeta, kohvi juua, krabistada ja arvuti taga istuda. Elab Seattle'is Washingtonis koos imelise kassi ja veelgi imelisema naise ja parima sõbra Adrienne'iga.
» Lisateavet raamatu kohta leiate aadressilt
»
»
Khabrozhiteley jaoks 25% allahindlus kupongi abil - Kubernetes
Raamatu paberversiooni eest tasumisel saadetakse e-postiga elektrooniline raamat.
Allikas: www.habr.com