Această noapte următoarea lansare a Kubernetes - . Conform tradiției care s-a dezvoltat pentru blogul nostru, vorbim despre schimbările cheie în noua versiune a acestui minunat produs Open Source.
Informațiile utilizate pentru pregătirea acestui material sunt preluate din , și probleme conexe, solicitări de extragere, propuneri de îmbunătățire Kubernetes (KEP).
Să începem cu o introducere importantă din ciclul de viață al clusterului SIG: clustere dinamice de failover Kubernetes (sau, pentru a fi mai precis, implementările HA auto-găzduite) este acum folosind comenzi familiare (în contextul clusterelor cu un singur nod). kubeadm (init и join). Pe scurt, pentru asta:
- certificatele utilizate de cluster sunt transferate în secrete;
- pentru posibilitatea de a utiliza clusterul etcd în interiorul clusterului K8s (adică scăparea de dependența externă existentă anterior) ;
- Documentează setările recomandate pentru un echilibrator de încărcare extern care oferă o configurație tolerantă la erori (în viitor este planificată eliminarea acestei dependențe, dar nu în această etapă).
Arhitectura unui cluster Kubernetes HA creat cu kubeadm
Detalii despre implementare pot fi găsite în . Această caracteristică a fost cu adevărat mult așteptată: versiunea alfa era așteptată în K8s 1.9, dar a apărut abia acum.
API
Echipă apply și în general vorbind managementul obiectelor declarative de kubectl în apiserver. Dezvoltatorii înșiși își explică pe scurt decizia spunând asta kubectl apply - o parte fundamentală a lucrului cu configurațiile în Kubernetes, totuși, „este plin de erori și greu de remediat” și, prin urmare, această funcționalitate trebuie readusă la normal și transferată în planul de control. Exemple simple și clare de probleme care există astăzi:
Detalii despre implementare sunt în . Pregătirea actuală este alfa (promovarea la versiunea beta este planificată pentru următoarea lansare Kubernetes).
Disponibil în versiunea alfa folosind schema OpenAPI v3 pentru crearea și publicarea documentației OpenAPI pentru CustomResources (CR) utilizat pentru validarea resurselor K8 definite de utilizator (CustomResourceDefinition, CRD). Publicarea OpenAPI pentru CRD permite clienților (de ex. kubectl) efectuați validarea de partea dvs. (în cadrul kubectl create и kubectl apply) și emite documentația conform schemei (kubectl explain). Detalii - in .
Jurnalele preexistente cu steag O_APPEND (dar nu O_TRUNC) pentru a evita pierderea buștenilor în unele situații și pentru comoditatea trunchierii buștenilor cu utilități externe pentru rotație.
De asemenea, în contextul API-ului Kubernetes, se poate observa că în PodSandbox и PodSandboxStatus câmp runtime_handler pentru a înregistra informații despre RuntimeClass în pod (citiți mai multe despre el în textul despre , unde această clasă a apărut ca o versiune alfa) și în Admission Webhooks capacitatea de a determina care versiuni AdmissionReview ei suporta. În sfârșit, regulile Admission Webhooks sunt acum gradul de utilizare a acestora de către spațiile de nume și cadrele de cluster.
Bolti
, care a avut statut beta de la lansare , stabil (GA): această poartă de caracteristici nu mai este dezactivată și va fi eliminată în Kubernetes 1.17.
folosind variabile de mediu numite (de exemplu, numele podului) pentru numele directoarelor montate ca , a fost dezvoltat - sub forma unui nou domeniu subPathExpr, care este acum folosit pentru a determina numele directorului dorit. Caracteristica a apărut inițial în Kubernetes 1.11, dar pentru 1.14 a rămas în starea de versiune alfa.
Ca și în versiunea anterioară Kubernetes, sunt introduse multe modificări semnificative pentru CSI (Interfață de stocare containere) în curs de dezvoltare:
CSI
A devenit disponibil (ca parte a versiunii alfa) redimensionare pentru volume CSI. Pentru a-l utiliza, va trebui să activați poarta de funcții numită ExpandCSIVolumes, precum și prezența suportului pentru această operațiune într-un anumit driver CSI.
O altă caracteristică pentru CSI în versiunea alfa - se referă direct (adică fără a utiliza PV/PVC) la volumele CSI din specificațiile podului. Acest elimină restricția privind utilizarea CSI ca stocare exclusivă a datelor la distanță, deschizându-le uși către lume . Pentru utilizare () trebuie să fie activat CSIInlineVolume poarta caracteristica.
S-au înregistrat progrese și în „internele” Kubernetes legate de CSI, care nu sunt atât de vizibile pentru utilizatorii finali (administratorii de sistem)... În prezent, dezvoltatorii sunt nevoiți să accepte două versiuni ale fiecărui plugin de stocare: una - „în mod vechi”, în interiorul bazei de cod K8s (în -tree), iar al doilea - ca parte a noului CSI (citiți mai multe despre asta, de exemplu, în ). Acest lucru provoacă inconveniente de înțeles care trebuie abordate pe măsură ce CSI se stabilizează. Nu este posibil să se deprecieze pur și simplu API-ul pluginurilor interne (în arbore) din cauza .
Toate acestea au dus la faptul că versiunea alfa a ajuns codul pluginului intern, implementat ca in-tree, în plugin-uri CSI, datorită cărora grijile dezvoltatorilor se vor reduce la suportarea unei singure versiuni a pluginurilor lor, iar compatibilitatea cu vechile API-uri va rămâne și acestea pot fi declarate învechite în scenariul obișnuit. Este de așteptat ca până la următoarea ediție a Kubernetes (1.15) toate pluginurile furnizorilor de cloud să fie migrate, implementarea să primească starea beta și să fie activată în instalările K8s în mod implicit. Pentru detalii, vezi . Această migrare a rezultat și în din limitele de volum definite de furnizori specifici de cloud (AWS, Azure, GCE, Cinder).
În plus, suport pentru dispozitivele bloc cu CSI (CSIBlockVolume) la versiunea beta.
Noduri/Kubelet
Versiunea alfa prezentată în Kubelet, conceput pentru returnează valori pentru resursele cheie. În general, dacă anterior Kubelet a primit statistici privind utilizarea containerului de la cAdvisor, acum aceste date provin din mediul de rulare al containerului prin CRI (Container Runtime Interface), dar se păstrează și compatibilitatea pentru lucrul cu versiuni mai vechi de Docker. Anterior, statisticile colectate în Kubelet erau trimise prin API-ul REST, dar acum un punct final situat la /metrics/resource/v1alpha1. Strategia pe termen lung a dezvoltatorilor este de a minimiza setul de valori furnizate de Kubelet. Apropo, aceste valori în sine nu „valori de bază”, ci „metrici de resurse” și sunt descrise ca „resurse de primă clasă, cum ar fi CPU și memoria”.
O nuanță foarte interesantă: în ciuda avantajului clar de performanță al punctului final gRPC în comparație cu diferite cazuri de utilizare a formatului Prometheus (vezi rezultatul unuia dintre benchmark-urile de mai jos), autorii au preferat formatul text al lui Prometheus datorită conducerii clare a acestui sistem de monitorizare în comunitate.
„gRPC nu este compatibil cu conductele majore de monitorizare. Endpoint-ul va fi util doar pentru furnizarea de valori către Metrics Server sau pentru monitorizarea componentelor care se integrează direct cu acesta. Performanța formatului text Prometheus atunci când utilizați memorarea în cache în Metrics Server suficient de bun pentru ca noi să preferăm Prometheus față de gRPC, având în vedere adoptarea pe scară largă a lui Prometheus în comunitate. Odată ce formatul OpenMetrics devine mai stabil, vom putea aborda performanța gRPC cu un format bazat pe proto.”
Unul dintre testele comparative de performanță ale utilizării formatelor gRPC și Prometheus în noul punct final Kubelet pentru valori. Mai multe grafice și alte detalii pot fi găsite în .
Printre alte modificări:
- Kubelet acum (o dată) containerele într-o stare necunoscută înainte de repornirea și ștergerea operațiunilor.
- Când utilizați acum la containerul init aceleași informații ca pentru un container obișnuit.
- kubelet
usageNanoCoresde la furnizorul de statistici CRI și pentru noduri și containere pe Windows statistici de rețea. - Informațiile despre sistemul de operare și arhitectura sunt acum înregistrate în etichete
kubernetes.io/osиkubernetes.io/archObiecte nod (transferate de la beta la GA). - Abilitatea de a specifica un anumit grup de utilizatori de sistem pentru containerele dintr-un pod (
RunAsGroup, aparut in ) înainte de beta (activat implicit). - du și găsiți utilizate în cAdvisor, implementare on Go.
CLI
În cli-runtime și kubectl -k steag pentru integrare cu (apropo, dezvoltarea sa se realizează acum într-un depozit separat), adică pentru a procesa fișiere YAML suplimentare din directoare speciale de personalizare (pentru detalii despre utilizarea lor, consultați ):
Exemplu de utilizare simplă a fișierelor (o aplicație mai complexă a lui kustomize este posibilă în )
În plus:
- echipa noua
kubectl create cronjob, al cărui nume vorbește de la sine. - В
kubectl logsacum poti steaguri-f(--followpentru jurnalele de streaming) și-l(--selectorpentru interogarea etichetei). - kubectl copiați fișierele selectate prin wild card.
- Echipei
kubectl waitpavilion--allpentru a selecta toate resursele din spațiul de nume al tipului de resursă specificat.
Alții
Următoarele capabilități au primit starea stabilă (GA):
- , utilizat în specificația podului pentru a defini condiții suplimentare luate în considerare în pregătirea podului;
- Suport pentru pagini mari (poarta de funcții numită );
- ;
- API-ul PriorityClass .
Alte modificări introduse în Kubernetes 1.14:
- Politica RBAC implicită nu mai permite accesul la API
discoveryиaccess-reviewutilizatori fără autentificare (neautentificat). - Suport oficial CoreDNS Numai Linux, deci atunci când utilizați kubeadm pentru a-l implementa (CoreDNS) într-un cluster, nodurile trebuie să ruleze numai pe Linux (nodeSelectors sunt utilizați pentru această limitare).
- Configurația CoreDNS implicită este acum în loc de proxy. De asemenea, în CoreDNS ReadinessProbe, care previne echilibrarea sarcinii pe poduri adecvate (nu sunt pregătite pentru service).
- În kubeadm, pe faze
initsauupload-certs, încărcați certificatele necesare pentru a conecta noul plan de control la secretul kubeadm-certs (utilizați steag--experimental-upload-certs). - A apărut o versiune alfa pentru instalările Windows gMSA (Group Managed Service Account) - conturi speciale în Active Directory care pot fi folosite și de containere.
- Pentru G.C.E. Criptare mTLS între etcd și kube-apiserver.
- Actualizări ale software-ului utilizat/dependent: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, suport pentru Docker 18.09 în kubeadm, iar versiunea minimă acceptată de API Docker este acum 1.26.
PS
Citește și pe blogul nostru:
- «»;
- «»;
- «»;
- «".
Sursa: www.habr.com