Sveiki, Khabro iedzīvotāji! Kubernetes ir viens no galvenajiem mūsdienu mākoņu ekosistēmas elementiem. Šī tehnoloģija nodrošina konteineru virtualizācijas uzticamību, mērogojamību un noturību. Džons Arundels un Džastins Dominguss stāsta par Kubernetes ekosistēmu un iepazīstina ar pārbaudītiem ikdienas problēmu risinājumiem. Soli pa solim jūs izveidosit savu mākoņa lietojumprogrammu un izveidosit infrastruktūru tās atbalstam, izveidosit izstrādes vidi un nepārtrauktu izvietošanas konveijeru, kas jums palīdzēs, strādājot pie nākamajām lietojumprogrammām.
• Sāciet darbu ar konteineriem un Kubernetes no pamatiem: tēmas apguvei nav nepieciešama īpaša pieredze. • Palaidiet savus klasterus vai izvēlieties pārvaldītu Kubernetes pakalpojumu no Amazon, Google utt. • Izmantojiet Kubernetes, lai pārvaldītu konteinera dzīves ciklu un resursu patēriņu. • Optimizējiet klasterus, pamatojoties uz izmaksām, veiktspēju, noturību, jaudu un mērogojamību. • Apgūstiet labākos rīkus lietojumprogrammu izstrādei, testēšanai un izvietošanai. • Izmantojiet pašreizējo nozares praksi, lai nodrošinātu drošību un kontroli. • Ieviesiet DevOps principus visā uzņēmumā, lai izstrādes komandas varētu darboties elastīgāk, ātrāk un efektīvāk.
Kam grāmata ir paredzēta?
Grāmata visvairāk attiecas uz administrācijas nodaļu darbiniekiem, kas atbild par serveriem, lietojumprogrammām un pakalpojumiem, kā arī izstrādātājiem, kas iesaistīti jaunu mākoņpakalpojumu veidošanā vai esošo lietojumprogrammu migrēšanā uz Kubernetes un mākoni. Neuztraucieties, jums nav jāzina, kā strādāt ar Kubernetes vai konteineriem - mēs jums visu iemācīsim.
Pieredzējuši Kubernetes lietotāji arī atradīs daudz vērtības, padziļināti aptverot tādas tēmas kā RBAC, nepārtraukta izvietošana, sensitīvu datu pārvaldība un novērojamība. Mēs ceram, ka grāmatas lappusēs noteikti būs kaut kas interesants jums, neatkarīgi no jūsu prasmēm un pieredzes.
Uz kādiem jautājumiem grāmata sniedz atbildes?
Plānojot un rakstot grāmatu, mēs apspriedām mākoņtehnoloģiju un Kubernetes ar simtiem cilvēku, runājot ar nozares līderiem un ekspertiem, kā arī pilnīgiem iesācējiem. Tālāk ir atlasīti jautājumi, uz kuriem viņi vēlētos saņemt atbildes šajā publikācijā.
- “Mani interesē, kāpēc jums vajadzētu veltīt laiku šai tehnoloģijai. Kādas problēmas tas palīdzēs atrisināt man un manai komandai?
- “Kubernetes šķiet interesanta, taču tai ir diezgan augsta barjera ienākšanai. Vienkārša piemēra sagatavošana nav grūta, taču turpmāka administrēšana un atkļūdošana ir biedējoša. Mēs vēlamies saņemt uzticamus padomus par to, kā cilvēki pārvalda Kubernetes klasterus reālajā pasaulē un ar kādām problēmām mēs varētu saskarties."
- “Subjektīvs padoms noderētu. Kubernetes ekosistēma dod jaunām komandām pārāk daudz iespēju izvēlēties. Ja ir vairāki veidi, kā darīt vienu un to pašu, kā jūs zināt, kurš no tiem ir labākais? Kā izdarīt izvēli?
Un, iespējams, vissvarīgākais no visiem jautājumiem:
- "Kā es varu izmantot Kubernetes, netraucējot manam uzņēmumam?"
Izvilkums. Konfigurācijas un slepenie objekti
Ļoti noderīga ir iespēja nodalīt Kubernetes lietojumprogrammas loģiku no tās konfigurācijas (tas ir, no jebkādām vērtībām vai iestatījumiem, kas laika gaitā var mainīties). Konfigurācijas vērtības parasti ietver videi raksturīgus iestatījumus, trešās puses pakalpojumu DNS adreses un autentifikācijas akreditācijas datus.
Protams, to visu var ievietot tieši kodā, taču šī pieeja nav pietiekami elastīga. Piemēram, mainot konfigurācijas vērtību, kods būs jāizveido un jāizvieto vēlreiz. Daudz labāks risinājums būtu atdalīt konfigurāciju no koda un nolasīt to no faila vai vides mainīgajiem.
Kubernetes nodrošina vairākus dažādus konfigurācijas pārvaldības veidus. Pirmkārt, varat nodot vērtības lietojumprogrammai, izmantojot vides mainīgos, kas norādīti aptvērēja specifikācijā (skatiet “Vides mainīgie” 192. lpp.). Otrkārt, konfigurācijas datus var glabāt tieši Kubernetes, izmantojot ConfigMap un Secret objektus.
Šajā nodaļā mēs detalizēti izpētām šos objektus un aplūkosim dažas praktiskas pieejas konfigurācijas un sensitīvu datu pārvaldībai, izmantojot demonstrācijas lietojumprogrammu.
Notiek apvidu čaulu atjaunināšana, kad mainās konfigurācija
Iedomājieties, ka jūsu klasterī ir izvietošana un vēlaties mainīt dažas vērtības tās ConfigMap kartē. Ja izmantojat Helm diagrammu (skatiet sadaļu "Helm: Kubernetes pakotņu pārvaldnieks" 102. lpp.), varat automātiski noteikt konfigurācijas izmaiņas un atkārtoti ielādēt pod apvalkus, veicot vienu glītu triku. Pievienojiet savai izvietošanas specifikācijai šādu anotāciju:
checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") .
| sha256sum }}Izvietošanas veidnē tagad ir konfigurācijas parametru kontrolsumma: ja parametri tiek mainīti, summa tiks atjaunināta. Ja palaižat helm jaunināšanu, Helm noteiks, ka izvietošanas specifikācija ir mainījusies, un restartēs visus pod čaulas.
Sensitīvi dati pakalpojumā Kubernetes
Mēs jau zinām, ka ConfigMap objekts nodrošina elastīgu mehānismu konfigurācijas datu glabāšanai un piekļuvei klasterī. Tomēr lielākajai daļai lietojumprogrammu ir sensitīva informācija, piemēram, paroles vai API atslēgas. To var saglabāt arī ConfigMap, taču šis risinājums nav ideāls.
Tā vietā Kubernetes piedāvā īpašu objektu veidu, kas paredzēts sensitīvu datu glabāšanai: Secret. Tālāk apskatīsim piemēru, kā šo objektu var izmantot mūsu demonstrācijas lietojumprogrammā.
Lai sāktu, apskatiet objekta Secret Kubernetes manifestu (skatiet hello-secret-env/k8s/secret.yaml):
apiVersion: v1
kind: Secret
metadata:
name: demo-secret
stringData:
magicWord: xyzzy
Šajā piemērā magicWord privātā atslēga ir xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing)). Vārds xyzzy parasti ir ļoti noderīgs datoru pasaulē. Līdzīgi kā ConfigMap, slepenajā objektā varat saglabāt vairākas atslēgas un vērtības. Šeit vienkāršības labad mēs izmantojam tikai vienu atslēgas vērtību pāri.
Slepeno objektu izmantošana kā vides mainīgie
Tāpat kā ConfigMap, slepeno objektu var padarīt pieejamu konteinerā kā vides mainīgos vai kā failu tā diskā. Nākamajā piemērā vērtībai no Secret piešķirsim vides mainīgo:
spec:
containers:
- name: demo
image: cloudnatived/demo:hello-secret-env
ports:
- containerPort: 8888
env:
- name: GREETING
valueFrom:
secretKeyRef:
name: demo-secret
key: magicWordDemonstrācijas repozitorijā palaidiet šo komandu, lai lietotu manifestus:
kubectl apply -f hello-secret-env/k8s/
deployment.extensions "demo" configured
secret "demo-secret" createdTāpat kā iepriekš, pārsūtiet vietējo portu uz izvietošanu, lai pārlūkprogrammā redzētu rezultātu:
kubectl port-forward deploy/demo 9999:8888
Forwarding from 127.0.0.1:9999 -> 8888
Forwarding from [::1]:9999 -> 8888Atverot adresi :9999/ jums vajadzētu redzēt sekojošo:
The magic word is "xyzzy"
Slepeno objektu rakstīšana failos
Šajā piemērā mēs pievienosim objektu Secret konteineram kā failu. Kods atrodas demonstrācijas repozitorijas mapē hello-secret-file.
Lai savienotu Secret kā failu, mēs izmantosim šādu izvietošanu:
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-secretTāpat kā apakšsadaļā “Konfigurācijas failu izveide no ConfigMap objektiem” lpp. 240, mēs izveidojam sējumu (šajā gadījumā demo-secret-volume) un uzstādām to konteinerā specifikācijas sadaļā volumeMounts. mountPath lauks ir /secrets, tāpēc Kubernetes izveidos vienu failu šajā mapē katram atslēgas/vērtības pārim, kas definēts objektā Secret.
Mūsu piemērā mēs definējām tikai vienu atslēgu-vērtību pāri ar nosaukumu magicWord, tāpēc manifests izveidos vienu tikai lasāmu failu /secrets/magicWord ar sensitīviem datiem konteinerā.
Ja lietojat šo manifestu tāpat kā iepriekšējā piemērā, jums vajadzētu iegūt tādu pašu rezultātu:
The magic word is "xyzzy"
Slepeno objektu lasīšana
Iepriekšējā sadaļā mēs izmantojām komandu kubectl description, lai parādītu ConfigMap saturu. Vai to pašu var izdarīt ar Secret?
kubectl describe secret/demo-secret
Name: demo-secret
Namespace: default
Labels: <none>
Annotations:
Type: Opaque
Data
====
magicWord: 5 bytesLūdzu, ņemiet vērā, ka paši dati netiek parādīti. Kubernetes slepenie objekti ir necaurspīdīgi, kas nozīmē, ka to saturs netiek parādīts kubectl apraksta izvadē, žurnāla ierakstos vai terminālī, tādējādi nav iespējams nejauši atklāt sensitīvu informāciju.
Lai skatītu sensitīvo datu kodētu YAML versiju, izmantojiet komandu kubectl get:
kubectl get secret/demo-secret -o yaml
apiVersion: v1
data:
magicWord: eHl6enk=
kind: Secret
metadata:
...
type: Opaquebase64
Kas ir eHl6enk=, kas pilnīgi atšķiras no mūsu sākotnējās vērtības? Tas faktiski ir slepenais objekts, kas attēlots base64 kodējumā. Base64 ir shēma patvaļīgu bināro datu kodēšanai kā rakstzīmju virkne.
Tā kā sensitīva informācija var būt bināra un netiek izvadīta (kā tas ir TLS šifrēšanas atslēgas gadījumā), slepenie objekti vienmēr tiek glabāti base64 formātā.
Teksts beHl6enk= ir mūsu slepenā vārda xyzzy base64 kodētā versija. To var pārbaudīt, terminālī izpildot komandu base64 —decode:
echo "eHl6enk=" | base64 --decode
xyzzyTātad, lai gan Kubernetes aizsargā jūs no nejaušas sensitīvu datu izvadīšanas termināļa vai žurnālfailos, ja jums ir lasīšanas atļaujas slepenajiem objektiem noteiktā nosaukumvietā, šos datus var izmantot base64ed un pēc tam atkodēt.
Ja jums ir nepieciešams base64 iekodēt kādu tekstu (piemēram, lai to ievietotu noslēpumā), izmantojiet komandu base64 bez argumentiem:
echo xyzzy | base64
eHl6enkKPiekļuve slepenajiem objektiem
Kas var lasīt un rediģēt slepenos objektus? To nosaka piekļuves kontroles mehānisms RBAC (mēs to sīkāk apspriedīsim apakšsadaļā “Ievads uz lomu balstītā piekļuves kontrolē” 258. lpp.). Ja izmantojat klasteru, kuram nav RBAC vai tas nav iespējots, visi jūsu slepenie objekti ir pieejami visiem lietotājiem un konteineriem (mēs vēlāk paskaidrosim, ka bez RBAC jums nevajadzētu būt nevienai ražošanas klasterai).
Pasīvā datu šifrēšana
Kā ir ar tiem, kuriem ir piekļuve etcd datubāzei, kurā Kubernetes glabā visu savu informāciju? Vai viņi var lasīt sensitīvus datus, ja viņiem nav atļaujas lasīt slepenos objektus, izmantojot API?
Kopš versijas 1.7 Kubernetes atbalsta pasīvo datu šifrēšanu. Tas nozīmē, ka sensitīva informācija, kas atrodas etcd, tiek glabāta diskā šifrēta, un to nevar nolasīt pat tie, kuriem ir tieša piekļuve datubāzei. Lai to atšifrētu, ir nepieciešama atslēga, kas ir pieejama tikai Kubernetes API serverim. Pareizi konfigurētā klasterī ir jāiespējo pasīvā šifrēšana.
Varat pārbaudīt, vai pasīvā šifrēšana jūsu klasterī darbojas šādi:
kubectl describe pod -n kube-system -l component=kube-apiserver |grep encryption
--experimental-encryption-provider-config=...Ja neredzat eksperimentālā-šifrēšanas-provider-config karogu, pasīvā šifrēšana nav iespējota. Izmantojot Google Kubernetes Engine vai citus Kubernetes pārvaldības pakalpojumus, jūsu dati tiek šifrēti, izmantojot citu mehānismu, tāpēc karodziņš nebūs redzams. Sazinieties ar savu Kubernetes pārdevēju, lai noskaidrotu, vai etcd saturs ir šifrēts.
Konfidenciālu datu uzglabāšana
Ir daži Kubernetes resursi, kurus nekad nevajadzētu noņemt no klastera, piemēram, ļoti jutīgi slepenie objekti. Varat aizsargāt resursu no dzēšanas, izmantojot Helm pārvaldnieka sniegto anotāciju:
kind: Secret
metadata:
annotations:
"helm.sh/resource-policy": keepSlepeno objektu pārvaldības stratēģijas
Iepriekšējās sadaļas piemērā sensitīvie dati tika aizsargāti pret nesankcionētu piekļuvi tūlīt pēc to saglabāšanas klasterī. Taču manifesta failos tie tika saglabāti kā vienkāršs teksts.
Nekad nevajadzētu ievietot konfidenciālu informāciju failos, kuriem ir versijas kontrole. Kā jūs varat droši pārvaldīt un uzglabāt šo informāciju, pirms to lietojat savā Kubernetes klasterī?
Varat izvēlēties jebkurus rīkus vai stratēģijas sensitīvu datu apstrādei savās lietojumprogrammās, taču jums joprojām būs jāatbild vismaz uz tālāk norādītajiem jautājumiem.
- Kur jāglabā sensitīvie dati, lai tie būtu labi pieejami?
- Kā padarīt sensitīvus datus pieejamus jūsu aktīvajām lietojumprogrammām?
- Kam jānotiek ar jūsu lietojumprogrammām, aizstājot vai rediģējot sensitīvus datus?
Par autoriem
Džons Arundels ir konsultants ar 30 gadu pieredzi datoru industrijā. Viņš ir sarakstījis vairākas grāmatas un strādā ar daudziem uzņēmumiem no dažādām valstīm, konsultējot tos par mākoņdatošanas infrastruktūru un Kubernetes. Brīvajā laikā viņš aizraujas ar sērfošanu, ir labs pistoles šāvējs un spēlē klavieres kā amatieris. Dzīvo pasaku kotedžā Kornvolā, Anglijā.
Džastins Dominguss — sistēmu administrēšanas inženieris, kas strādā DevOps vidē ar Kubernetes un mākoņtehnoloģijām. Viņam patīk pavadīt laiku brīvā dabā, dzert kafiju, kraboties un sēdēt pie datora. Dzīvo Sietlā, Vašingtonā, kopā ar brīnišķīgu kaķi un vēl brīnišķīgāku sievu un labāko draudzeni Adriennu.
» Sīkāku informāciju par grāmatu var atrast vietnē
»
»
Par Khabrozhiteley 25% atlaide, izmantojot kuponu - Kubernetes
Apmaksājot grāmatas papīra versiju, pa e-pastu tiks nosūtīta elektroniskā grāmata.
Avots: www.habr.com
