În noaptea aceasta o nouă lansare Kubernetes — . Conform tradiției blogului nostru, vă spunem despre schimbările cheie din noua versiune a acestui minunat produs Open Source.
Informațiile folosite pentru redactarea acestui material provin din , și din problemele, cererile de tragere, Propunerile de Îmbunătățire Kubernetes (KEP) relevante.
Să începem cu o introducere importantă din partea SIG cluster-lifecycle: clustere dinamice rezistente la defecțiuni Kubernetes (sau, mai exact, implementări HA auto-găzduite) pot fi acum folosind comenzile obișnuite (în contextul clusterelor cu un singur nod) kubeadm (init și join). Pe scurt, pentru aceasta:
- certificatele utilizate de cluster sunt mutate în secrete;
- pentru a permite utilizarea clusterului etcd în interiorul clusterului K8s (adică eliminarea dependenței externe existente), este activat ;
- sunt documentate configurațiile recomandate pentru un echilibrator de sarcină extern, care asigură o configurație rezistentă la defecțiuni (pe viitor se preconizează posibilitatea eliminării acestei dependențe, dar nu în această etapă).
Arhitectura clusterului HA Kubernetes, creată cu kubeadm
Detalii despre implementare pot fi găsite în . Această caracteristică a fost foarte așteptată: versiunea alfa a fost anticipată încă din K8s 1.9, dar a apărut abia acum.
API
Comanda aplicare și în general gestionarea declarativă a obiectelor din kubectl în apiserver. Dezvoltatorii înșiși explică pe scurt decizia lor astfel: kubectl apply — o parte fundamentală a muncii cu configurațiile în Kubernetes, dar este „plină de bug-uri și greu de reparat”, motiv pentru care această funcționalitate trebuie readusă la un standard normal și mutată în control plane. Exemple simple și clare ale problemelor existente astăzi:
Detalii despre implementare — în . Starea actuală — versiune alfa (promovarea la beta este planificată pentru următoarea lansare Kubernetes).
În versiunea alfa a devenit disponibil utilizarea schemei OpenAPI v3 pentru crearea și publicarea documentației OpenAPI pentru CustomResources (CR), utilizate pentru validarea (pe partea serverului) a resurselor K8s definite de utilizator (CustomResourceDefinition, CRD). Publicarea OpenAPI pentru CRD permite clienților (de exemplu, kubectl) să efectueze validări pe partea lor (în cadrul kubectl create și kubectl apply) și să emită documentație schema (kubectl explain). Detalii — în .
Log-urile existente anterior cu flag-ul O_APPEND (nu O_TRUNC) pentru a evita pierderea jurnalelor în anumite situații și pentru a facilita trunchierea jurnalelor cu utilitare externe pentru rotație.
De asemenea, în contextul API-ului Kubernetes se poate menționa că în PodSandbox și PodSandboxStatus câmpul runtime_handler pentru a înregistra informații despre RuntimeClass în pod (despre acesta citiți mai multe în textul despre , unde această clasă a apărut ca versiune alfa), iar în Admission Webhooks posibilitatea de a determina ce versiuni AdmissionReview ele suportă. În cele din urmă, în regulile Admission Webhooks acum domeniile de aplicare la namespace-uri și limitele clusterului.
Stocările
, care au avut statut de versiune beta de la lansarea , stabile (GA): această funcție nu mai poate fi dezactivată și va fi eliminată în Kubernetes 1.17.
utilizarea variabilelor de mediu numite (de exemplu, numele pod-ului) pentru numele directorilor montați ca , a evoluat — sub forma unui nou câmp subPathExpr, prin care acum se determină numele directorului necesar. Inițial, funcția a apărut în Kubernetes 1.11, dar pentru 1.14 a rămas în statut de versiune alfa.
Ca și în lansarea anterioară a Kubernetes, multe schimbări semnificative au fost prezentate pentru CSI (Container Storage Interface) în continuă dezvoltare:
CSI
A devenit disponibil (în cadrul versiunii alfa) extinderea dimensiunilor pentru volumele CSI. Pentru utilizarea ei, va fi necesară activarea funcției cu denumirea ExpandCSIVolumes, precum și suportul acestei operații în driverul CSI specific.
O altă funcție pentru CSI în versiune alfa — a face referire direct (adică fără a utiliza PV/PVC) la volumele CSI în cadrul specificației pod-urilor. Acest lucru îndepărtează restricția utilizării CSI ca fiind exclusiv stocări de date externe, deschizând pentru ele porțile în lumea Pentru utilizare () trebuie activat CSIInlineVolume feature gate.
A apărut un progres și în «interiorul» Kubernetes, legat de CSI, care nu este atât de vizibil utilizatorilor finali (administratorilor de sistem)... În prezent, dezvoltatorii sunt nevoiți să mențină două versiuni ale fiecărui plugin de stocare: una — «pe vechi», în interiorul bazei de cod K8s (in-tree), iar a doua — în cadrul noului CSI (despre acesta citiți mai multe, de exemplu, în ). Aceasta generează disconforturi evidente, care trebuie eliminate pe măsură ce CSI se stabilizează ca atare. Pur și simplu declararea ca fiind învechite (deprecated) a API-urilor interne (in-tree) ale plugin-urilor nu este posibilă din cauza .
Tot acest lucru a dus la faptul că versiunile alpha au atins codului intern al plugin-urilor, implementate ca in-tree, în plugin-urile CSI, ceea ce va reduce preocupările dezvoltatorilor la suportul pentru o singură versiune a plugin-urilor lor, iar compatibilitatea cu API-urile vechi va fi menținută, permițându-le să fie declarate învechite conform scenariului obișnuit. Se așteaptă ca, până la următoarea versiune Kubernetes (1.15), migrarea tuturor plugin-urilor furnizorilor de cloud să fie realizată, implementarea va obține statutul de versiune beta și va fi activată în instalațiile K8s implicit. Detalii pot fi găsite în . Ca urmare a acestei migrații, de asemenea, a avut loc la restricțiile pentru volumele definite de anumiți furnizori de cloud (AWS, Azure, GCE, Cinder).
În plus, suportul pentru dispozitivele de blocare cu CSI (CSIBlockVolume) în versiune beta.
Noduri / Kubelet
A fost prezentată versiunea alpha în Kubelet, destinat pentru oferirea de metrici pentru resursele de bază. În general, dacă anterior Kubelet primea statistici despre utilizarea containerelor din cAdvisor, acum aceste date sunt obținute din mediul de execuție al containerului prin CRI (Container Runtime Interface), totuși compatibilitatea cu versiunile vechi de Docker a fost păstrată. Statistica anterior colectată în Kubelet era expusă prin REST API, iar acum acest lucru se face printr-un endpoint situat la adresa /metrics/resource/v1alpha1. Strategia pe termen lung a dezvoltatorilor în minimizarea setului de metrici oferite de Kubelet. Apropo, aceste metrici nu «core metrics», ci «resource metrics», descriindu-le ca «resurse de primă clasă, cum ar fi cpu și memorie».
Un detaliu foarte interesant: în ciuda avantajului evident de performanță al endpoint-ului gRPC în comparație cu diferitele utilizări ale formatului Prometheus (rezultatul uneia din benchmark-uri se găsește mai jos), autorii au preferat formatul text Prometheus datorită poziției predominante a acestui sistem de monitorizare în comunitate.
«gRPC nu este compatibil cu principalele fluxuri de monitorizare. Endpoint-ul va fi util doar pentru livrarea metricilor în Metrics Server sau în componentele de monitorizare care se integrează direct cu acesta. Atunci când se folosește caching în Metrics Server, performanța formatului text Prometheus este suficient de bună pentru noi, pentru a prefera Prometheus în loc de gRPC, având în vedere popularitatea largă a Prometheus în comunitate. Când formatul OpenMetrics va deveni mai stabil, vom putea să ne apropiem de performanța gRPC folosind un format bazat pe proto».
Una dintre testele comparative de performanță utilizând formatele gRPC și Prometheus în noul endpoint Kubelet pentru metrici. Mai multe grafice și alte detalii pot fi găsite în .
Printre alte modificări:
- Kubelet acum (o singură dată) containerele în stare necunoscută (unknown) înainte de operațiile de restart și ștergere.
- Când folosești acum controlează inițializarea containerului aceleași informații ca un container obișnuit.
- Kubelet
usageNanoCoresdin furnizorul de statistici CRI, iar pentru noduri și containere în Windows statistici de rețea. - Informațiile despre sistemul de operare și arhitectură sunt acum înregistrate în etichete
kubernetes.io/osșikubernetes.io/archale obiectelor Node (traduse din beta în GA). - Posibilitatea de a specifica un grup sistemic specific de utilizatori pentru containerele din pod (
RunAsGroup, a apărut în ) la versiunea beta (activată implicit). - du și find, utilizate în cAdvisor, cu implementări Go.
CLI
În cli-runtime și kubectl flagul -k pentru integrarea cu (de altfel, dezvoltarea sa se desfășoară acum într-un repository separat), adică pentru tratarea fișierelor YAML suplimentare din directoare speciale de kustomization (detalii despre utilizarea acestora poate fi găsită în ):
Exemplu de utilizare simplă a fișierului (posibil și aplicarea mai complexă a kustomize în cadrul )
În plus:
- noua comandă
kubectl create cronjob, numele său vorbește de la sine. - În
kubectl logsacum se poate flagg-f(--followpentru streaming-ul jurnalelor) și-l(--selectorpentru interogarea etichetelor). - kubectl să copiem fișiere, selectate folosind wildcard.
- În comanda
kubectl waitsteag--allpentru a selecta toate resursele din spațiul de nume de tipul specificat de resurse.
Altele
Următoarele funcționalități au obținut statut stabil (GA):
- , utilizat în specificația pod-ului pentru a determina condiții suplimentare care sunt luate în considerare în pregătirea pod-ului;
- Suport pentru pagini mari (feature gate numit );
- ;
- PriorityClass API, .
Alte schimbări introduse în Kubernetes 1.14:
- Politica RBAC implicită nu mai oferă acces la API
descoperireșirevizuire de accesutilizatorilor fără autentificare (neautentificat). - Suport oficial pentru CoreDNS doar pentru Linux, așadar, atunci când folosiți kubeadm pentru implementarea sa (CoreDNS) în cluster, nodurile trebuie să funcționeze doar în Linux (pentru această restricție se folosesc nodeSelectors).
- Configurarea implicită a CoreDNS acum în loc de proxy. De asemenea, în CoreDNS readinessProbe, care previne echilibrarea încărcăturii pe pod-urile corespunzătoare (care nu sunt pregătite pentru a fi utilizate).
- În kubeadm, în fazele
initsauupload-certs, să încărcați certificatele necesare pentru conectarea noului control-plane la secretul kubeadm-certs (se folosește opțiunea--experimental-upload-certs). - Pentru instalațiile Windows a fost lansată o versiune alpha gMSA (Group Managed Service Account) — conturi speciale în Active Directory, care pot fi folosite și de containere.
- Pentru GCE criptarea mTLS între etcd și kube-apiserver.
- Actualizări în software-ul utilizat/dependențelor: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, suport pentru Docker 18.09 în kubeadm, iar versiunea minim suportată a API-ului Docker a devenit 1.26.
P.S.
Citiți și în blogul nostru:
- «»;
- «»;
- «»;
- «».
Sursa: habr.com
