Bună, Habrodită! Kubernetes este unul dintre elementele cheie ale ecosistemului cloud modern. Această tehnologie oferă fiabilitate, scalabilitate și reziliență în virtualizarea containerelor. John Arundel și Justin Domingus discută despre ecosistemul Kubernetes și oferă soluții dovedite pentru problemele cotidiene. Pas cu pas, veți construi propria aplicație orientată spre cloud și veți crea infrastructura necesară pentru a o susține, configurând medii de dezvoltare și un flux de desfășurare continuu, care vă va fi util în lucrul cu aplicațiile următoare.
• Veți începe lucrul cu containere și Kubernetes de la zero: nu este necesară experiență specializată pentru a învăța subiectul. • Rulați propriile clustere sau alegeți un serviciu gestionat Kubernetes de la Amazon, Google etc. • Aplicați Kubernetes pentru a gestiona ciclul de viață al containerului și consumul de resurse. • Optimizați clusterele în funcție de costuri, performanță, reziliență, putere și scalabilitate. • Studiați cele mai bune instrumente pentru dezvoltarea, testarea și desfășurarea aplicațiilor dumneavoastră. • Profitați de cele mai recente practici din industrie pentru a asigura securitatea și controlul. • Implementați principiile DevOps în companie pentru a face echipele de dezvoltare să acționeze mai flexibil, rapid și eficient.
Pentru cine este destinată cartea
Cartea este cel mai relevantă pentru angajații departamentelor de administrare, responsabili de servere, aplicații și servicii, precum și pentru dezvoltatorii care se ocupă fie cu construirea de noi servicii cloud, fie cu migrarea aplicațiilor existente în Kubernetes și în cloud. Nu vă faceți griji, nu este necesar să știți să lucrați cu Kubernetes și containere: vă vom învăța totul.
Utilizatorii experimentați de Kubernetes vor găsi de asemenea multe informații valoroase: aici sunt abordate în profunzime teme precum RBAC, desfășurarea continuă, gestionarea datelor confidențiale și observabilitatea. Sperăm că paginile cărții vor conține ceva interesant și pentru dumneavoastră, indiferent de abilitățile și experiența dumneavoastră.
La ce întrebări răspunde cartea
În timpul planificării și redactării cărții, am discutat despre tehnologiile cloud și Kubernetes cu sute de oameni, interacționând atât cu lideri și experți din industrie, cât și cu începători absoluti. Mai jos sunt câteva întrebări ale căror răspunsuri le-ar dori să le vadă în această publicație.
- „Mă interesează de ce ar trebui să investesc timp în această tehnologie. Ce probleme va ajuta să rezolv eu și echipa mea?”
- „Kubernetes pare interesant, dar are un prag de intrare destul de ridicat. E simplu să creezi un exemplu de bază, însă administrarea și depanarea ulterioară sunt descurajante. Am dori să primim sfaturi de încredere despre cum oamenii gestionează clusterele Kubernetes în condiții reale și cu ce probleme ne-am putea confrunta, cel mai probabil.”
- „Ar fi util un sfat subiectiv. Ecosistemul Kubernetes oferă echipelor începătoare prea multe opțiuni de alegere. Când același lucru poate fi realizat în mai multe moduri, cum putem înțelege care dintre ele este cel mai bun? Cum facem alegerea?”
Și, probabil, cea mai importantă întrebare dintre toate:
- „Cum pot folosi Kubernetes fără a perturba activitatea companiei mele?”
Extras. Configurarea și obiectele Secret
Capacitatea de a separa logica aplicatiei Kubernetes de configurația sa (adică de orice valori sau setări care se pot schimba în timp) este foarte utilă. Valorile de configurație includ de obicei parametrii destinați unui anumit mediu, adresele DNS ale serviciilor externe și acreditivele pentru autentificare.
Desigur, toate acestea pot fi incluse direct în cod, dar o astfel de abordare nu oferă suficientă flexibilitate. De exemplu, pentru a schimba o valoare de configurație, va trebui să recompilezi și să desfășori din nou codul tău. O soluție mult mai bună ar fi să separi configurația de cod și să o citești dintr-un fișier sau din variabile de mediu.
Kubernetes oferă mai multe modalități de a gestiona configurația. În primul rând, poți transmite valori aplicației prin variabile de mediu specificate în specificația pod-ului (vezi secțiunea „Variabile de mediu” la pagina 192). În al doilea rând, datele de configurație pot fi stocate direct în Kubernetes folosind obiecte ConfigMap și Secret.
În acest capitol, vom explora detaliat aceste obiecte și vom analiza câteva abordări practice pentru gestionarea configurației și a datelor sensibile, folosind un exemplu de aplicație demonstrativă.
Actualizarea pod-urilor la modificarea configurației
Imaginează-ți că în cluster-ul tău există o desfășurare și vrei să schimbi unele valori din ConfigMap-ul său. Dacă folosești un chart Helm (vezi secțiunea „Helm: manager de pachete pentru Kubernetes” la pagina 102), poți detecta automat schimbarea configurației și reporni pod-urile tale cu ajutorul unei tehnici elegante. Adaugă următoarea anotare în specificația desfășurării tale:
checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") .
| sha256sum }}Acum, șablonul desfășurării conține o sumă de control a parametrilor de configurație: atunci când parametrii se schimbă, suma se va actualiza. Dacă executezi comanda helm upgrade, Helm va detecta că specificația desfășurării s-a schimbat și va reporni toate pod-urile.
Date sensibile în Kubernetes
Deja știm că obiectul ConfigMap oferă un mecanism flexibil pentru stocarea și accesarea datelor de configurație în cluster. Totuși, majoritatea aplicațiilor au informații care sunt secrete și confidențiale: de exemplu, parole sau chei API. Acestea pot fi stocate și în ConfigMap, dar această soluție nu este ideală.
În schimb, Kubernetes oferă un obiect de un tip special, destinat stocării datelor confidențiale: Secret. Vom explora mai departe, folosind un exemplu, cum poate fi aplicat acest obiect în aplicația noastră demonstrativă.
Pentru început, aruncă o privire asupra manifestului Kubernetes pentru obiectul Secret (vezi hello-secret-env/k8s/secret.yaml):
apiVersion: v1
kind: Secret
metadata:
name: demo-secret
stringData:
magicWord: xyzzy
În acest exemplu, cheia secretă magicWord are valoarea xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing)). Cuvântul xyzzy este de fapt foarte util în lumea calculatoarelor. La fel ca în ConfigMap, în obiectul Secret se pot plasa numeroase chei și valori. Aici, pentru simplitate, folosim doar o pereche „cheie – valoare”.
Utilizarea obiectelor Secret ca variabile de mediu
Asemenea ConfigMap, obiectul Secret poate fi disponibil în container sub formă de variabile de mediu sau fișier pe disc. În următorul exemplu, vom atribui o variabilă de mediu o valoare din Secret:
spec:
containers:
- name: demo
image: cloudnatived/demo:hello-secret-env
ports:
- containerPort: 8888
env:
- name: GREETING
valueFrom:
secretKeyRef:
name: demo-secret
key: magicWordRulați următoarea comandă în depozitul demo pentru a aplica manifesturile:
kubectl apply -f hello-secret-env/k8s/
deployment.extensions "demo" configurat
secret "demo-secret" creatAșa cum a fost înainte, redirecționați portul local către implementare pentru a vedea rezultatul în browserul dvs.:
kubectl port-forward deploy/demo 9999:8888
Înaintare de la 127.0.0.1:9999 -> 8888
Înaintare de la [::1]:9999 -> 8888Când deschideți adresa :9999/ ar trebui să vedeți următoarele:
Cuvântul magic este "xyzzy"
Scrierea obiectelor Secret în fișiere
În acest exemplu, vom monta obiectul Secret în container ca fișier. Codul se află în folderul hello-secret-file din depozitul demo.
Pentru a monta Secret ca fișier, vom folosi următoarea implementare:
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-secretAșa cum s-a menționat în subsecțiunea „Crearea fișierelor de configurare din obiecte ConfigMap” de la pagina 240, creăm un volum (în acest caz, demo-secret-volume) și îl montăm în container în secțiunea volumeMounts. Câmpul mountPath specifică /secrets, astfel încât Kubernetes va crea în acest folder câte un fișier pentru fiecare pereche „cheie — valoare” definită în obiectul Secret.
În exemplul nostru, am definit doar o singură pereche „cheie — valoare” numită magicWord, astfel încât manifestul va crea în container un fișier /secrets/magicWord cu datele confidențiale, disponibil exclusiv în modul de citire.
Dacă aplicați acest manifest la fel ca în exemplul anterior, ar trebui să obțineți același rezultat:
Cuvântul magic este "xyzzy"
Citirea obiectelor Secret
În secțiunea anterioară, am folosit comanda kubectl describe pentru a afișa conținutul ConfigMap. Se poate face același lucru cu Secret?
kubectl describe secret/demo-secret
Nume: demo-secret
Spațiu de nume: default
Etichete:
Anotări:
Tip: Opaque
Date
====
magicWord: 5 bytesRețineți că datele în sine nu sunt afișate. Obiectele Secret din Kubernetes au tipul Opaque: acest lucru înseamnă că conținutul lor nu este arătat în ieșirea kubectl describe, în jurnale și în terminal, ceea ce împiedică în mod accidental divulgarea informațiilor confidențiale.
Pentru a vizualiza versiunea codificată a datelor confidențiale în format YAML, utilizați comanda kubectl get:
kubectl get secret/demo-secret -o yaml
apiVersion: v1
data:
magicWord: eHl6enk=
kind: Secret
metadata:
...
type: Opaquebase64
Ce este eHl6enk=, nu seamănă deloc cu valoarea noastră inițială? De fapt, acesta este un obiect Secret, reprezentat în codificarea base64. Base64 este o schemă de codificare a datelor binare arbitrare sub formă de șir de caractere.
Din moment ce informațiile confidențiale pot fi binare și inaccesibile pentru ieșire (precum în cazul unei chei de criptare TLS), obiectele Secret sunt întotdeauna stocate în format base64.
Textul beHl6enk= este versiunea cuvântului nostru secret xyzzy, codificat în base64. Acest lucru poate fi verificat dacă executați în terminal comanda base64 --decode:
echo "eHl6enk=" | base64 --decode
xyzzyAstfel, deși Kubernetes vă protejează de ieșirea accidentală a datelor confidențiale în terminal sau în fișierele de jurnal, dacă aveți drepturi de citire asupra obiectelor Secret dintr-un anumit spațiu de nume, aceste date pot fi obținute în format base64 și decodează ulterior.
Dacă trebuie să codificați un text în base64 (de exemplu, pentru a-l plasa într-un Secret), utilizați comanda base64 fără argumente:
echo xyzzy | base64
eHl6enkKAcces la obiectele Secret
Cine poate citi și edita obiectele Secret? Acest lucru este definit de RBAC — mecanismul de control al accesului (vom discuta acest lucru în detaliu în subcapitolul „Introducere în gestionarea accesului pe baza rolurilor” la pagina 258). Dacă utilizați un cluster în care sistemul RBAC nu este prezent sau nu este activat, toate obiectele dumneavoastră Secret sunt accesibile oricărui utilizator și container (mai târziu vă vom explica de ce nu ar trebui să aveți un cluster de producție fără RBAC).
Criptarea pasivă a datelor
Și ce se întâmplă cu cei care au acces la baza de date etcd, în care Kubernetes își stochează toate informațiile? Pot ei să citească datele confidențiale fără a avea drepturi de citire asupra obiectelor Secret prin API?
Începând cu versiunea 1.7, Kubernetes suportă criptarea pasivă a datelor. Aceasta înseamnă că informațiile confidențiale din etcd sunt stocate pe disc într-o formă criptată și nu pot fi citite nici măcar de cei care au acces direct la baza de date. Pentru decriptare este nevoie de o cheie, care se află doar pe serverul API Kubernetes. Într-un cluster configurat corect, criptarea pasivă ar trebui să fie activată.
Pentru a verifica dacă criptarea pasivă funcționează în clusterul dumneavoastră, puteți proceda astfel:
kubectl describe pod -n kube-system -l component=kube-apiserver | grep encryption
--experimental-encryption-provider-config=...Dacă nu vedeți flag-ul experimental-encryption-provider-config, criptarea pasivă nu este activată. Când folosiți Google Kubernetes Engine sau alte servicii de management Kubernetes, datele dumneavoastră sunt criptate printr-un mecanism diferit, astfel că flag-ul nu va fi prezent. Întrebați furnizorul dumneavoastră Kubernetes dacă conținutul etcd este criptat.
Stocarea datelor confidențiale
Există resurse Kubernetes care nu ar trebui niciodată șterse din cluster: de exemplu, obiecte de tip Secret deosebit de importante. Puteți proteja resursa de ștergere folosind o adnotare furnizată de managerul Helm:
kind: Secret
metadata:
annotations:
"helm.sh/resource-policy": keepStrategii de gestionare a obiectelor Secret
În exemplul din secțiunea precedentă, datele confidențiale erau protejate de accesul neautorizat imediat după salvarea acestora în cluster. Totuși, în fișierele manifest ele erau stocate în formă de text simplu.
Nu ar trebui niciodată să plasați informații confidențiale în fișiere care se află în sistemul de control al versiunilor. Cum ar trebui să administrați și să stocați în siguranță aceste informații înainte de a le aplica în clusterul Kubernetes?
Puteți alege orice instrumente sau strategii pentru a lucra cu date confidențiale în aplicațiile dumneavoastră, dar va trebui totuși să răspundeți la cel puțin următoarele întrebări.
- Unde ar trebui să stocați datele confidențiale pentru a fi disponibile la scară mare?
- Cum să faceți datele confidențiale disponibile pentru aplicațiile dumneavoastră active?
- Ce ar trebui să se întâmple cu aplicațiile dumneavoastră atunci când înlocuiți sau editați datele confidențiale?
Despre autori
John Arundel este consultant cu o experiență de 30 de ani în industria IT. A scris mai multe cărți și colaborează cu diverse companii din întreaga lume, oferindu-le consultanță în domeniul infrastructurii cloud și Kubernetes. În timpul liber, îi place să facă surf, trage bine cu pistolul și cântă la pian ca hobby. Locuiește într-o căsuță de poveste în Cornwall, Anglia.
Justin Domingus este inginer de sistem, lucrând în medii DevOps cu Kubernetes și tehnologii cloud. Îi place să petreacă timp în aer liber, să bea cafea, să prindă crabi și să stea la computer. Locuiește în Seattle, Washington, împreună cu un pisoi minunat și o soție și, în același timp, cea mai bună prietenă, Adrianne.
» Puteți găsi mai multe detalii despre carte pe
»
»
Pentru utilizatorii Habr, discount de 25% cu codul — Kubernetes
După plata versiunii tipărite a cărții, se va trimite o carte electronică pe e-mail.
Sursa: habr.com
