🥇Kubernetes 1.16: prezentare generală a principalelor inovații

Astăzi, miercuri, va avea loc următoarea versiune a Kubernetes - 1.16. Conform tradiției care s-a dezvoltat pentru blogul nostru, este a zecea aniversare când vorbim despre cele mai semnificative schimbări în noua versiune.

Informațiile utilizate pentru pregătirea acestui material sunt preluate din Tabelele de urmărire a îmbunătățirilor Kubernetes, CHANGELOG-1.16 și probleme conexe, solicitări de extragere și propuneri de îmbunătățire Kubernetes (KEP). Deci să mergem!..

Noduri

Un număr cu adevărat mare de inovații notabile (în starea versiunii alfa) sunt prezentate pe partea nodurilor clusterului K8s (Kubelet).

În primul rând, așa-numitul «recipiente efemere» (Containere efemere), conceput pentru a simplifica procesele de depanare în poduri. Noul mecanism vă permite să lansați containere speciale care pornesc în spațiul de nume al podurilor existente și trăiesc pentru o perioadă scurtă de timp. Scopul lor este de a interacționa cu alte pod-uri și containere pentru a rezolva orice probleme și a depana. O nouă comandă a fost implementată pentru această caracteristică kubectl debug, asemănător în esență cu kubectl exec: numai în loc să ruleze un proces într-un container (ca în exec) lansează un container într-un pod. De exemplu, această comandă va conecta un nou container la un pod:

kubectl debug -c debug-shell --image=debian target-pod -- bash

Detalii despre recipientele efemere (și exemple de utilizare a acestora) pot fi găsite în KEP corespunzătoare. Implementarea actuală (în K8s 1.16) este o versiune alfa, iar printre criteriile pentru transferul acesteia la o versiune beta se numără „testarea API-ului Ephemeral Containers pentru cel puțin 2 versiuni de [Kubernetes]”.

NB: În esență și chiar numele său, caracteristica seamănă cu un plugin deja existent kubectl-debugdespre care noi a scris deja. Este de așteptat ca odată cu apariția containerelor efemere, dezvoltarea unui plugin extern separat să înceteze.

O altă inovație - PodOverhead - conceput pentru a oferi mecanism pentru calcularea costurilor generale pentru poduri, care poate varia foarte mult în funcție de timpul de rulare utilizat. De exemplu, autorii acest KEP rezultă în Kata Containers, care necesită rularea kernelului invitat, agentului kata, sistemului de inițiere etc. Când cheltuielile generale devin atât de mari, nu pot fi ignorate, ceea ce înseamnă că trebuie să existe o modalitate de a le lua în considerare pentru cote, planificare ulterioară etc. Pentru a o implementa în PodSpec câmp adăugat Overhead *ResourceList (se compară cu datele din RuntimeClass, dacă se folosește unul).

O altă inovație notabilă este manager de topologie de nod (Manager de topologie nod), conceput pentru a unifica abordarea de reglare fină a alocării resurselor hardware pentru diferite componente din Kubernetes. Această inițiativă este condusă de nevoia tot mai mare a diverselor sisteme moderne (din domeniul telecomunicațiilor, machine learning, servicii financiare etc.) pentru calcule paralele de înaltă performanță și minimizarea întârzierilor în execuția operațiunilor, pentru care folosesc procesoare avansate și capabilități de accelerare hardware. Astfel de optimizări în Kubernetes au fost realizate până acum datorită componentelor disparate (CPU manager, Device manager, CNI), iar acum li se va adăuga o singură interfață internă care unifică abordarea și simplifică conectarea unor noi similare - așa-numita topologie - conștient - componente de pe partea Kubelet. Detalii - in KEP corespunzătoare.

Diagrama componentelor Topology Manager

Următoarea caracteristică - verificarea containerelor în timpul funcționării acestora (sonda de pornire). După cum știți, pentru containerele care durează mult timp pentru a se lansa, este dificil să obțineți un statut actualizat: fie sunt „omorâți” înainte de a începe efectiv să funcționeze, fie ajung în impas pentru o lungă perioadă de timp. Verificare nouă (activată prin poarta de funcții numită StartupProbeEnabled) anulează - sau mai bine zis, amână - efectul oricăror alte verificări până în momentul în care podul a terminat de rulat. Din acest motiv, caracteristica a fost numită inițial pod-startup liveness-sonda reținere. Pentru podurile care durează mult timp să pornească, puteți interoga starea în intervale de timp relativ scurte.

În plus, o îmbunătățire pentru RuntimeClass este disponibilă imediat în starea beta, adăugând suport pentru „clustere eterogene”. C Programare RuntimeClass Acum nu este deloc necesar ca fiecare nod să aibă suport pentru fiecare RuntimeClass: pentru pod-uri puteți selecta o RuntimeClass fără să vă gândiți la topologia clusterului. Anterior, pentru a realiza acest lucru - astfel încât podurile să ajungă pe noduri cu suport pentru tot ce au nevoie - a fost necesar să se atribuie reguli adecvate NodeSelector și toleranțe. ÎN EBC Vorbește despre exemple de utilizare și, bineînțeles, despre detalii de implementare.

rețea

Două caracteristici semnificative de rețea care au apărut pentru prima dată (în versiunea alfa) în Kubernetes 1.16 sunt:

Sprijini stivă de rețea duală - IPv4/IPv6 - și „înțelegerea” corespunzătoare la nivel de poduri, noduri, servicii. Include interoperabilitatea IPv4-la-IPv4 și IPv6-la-IPv6 între poduri, de la pod-uri la servicii externe, implementări de referință (în cadrul pluginurilor Bridge CNI, PTP CNI și Host-Local IPAM), precum și compatibilitate inversă cu clusterele Kubernetes care rulează Numai IPv4 sau IPv6. Detaliile de implementare sunt în EBC.
Un exemplu de afișare a adreselor IP de două tipuri (IPv4 și IPv6) în lista de pod-uri:
```
kube-master# kubectl get pods -o wide
NAME               READY     STATUS    RESTARTS   AGE       IP                          NODE
nginx-controller   1/1       Running   0          20m       fd00:db8:1::2,192.168.1.3   kube-minion-1
kube-master#
```
Nou API pentru Endpoint - API-ul EndpointSlice. Rezolvă problemele de performanță/scalabilitate ale API-ului Endpoint existent care afectează diverse componente din planul de control (apiserver, etcd, endpoint-controller, kube-proxy). Noul API va fi adăugat la grupul Discovery API și va putea deservi zeci de mii de puncte finale backend pe fiecare serviciu într-un cluster format din mii de noduri. Pentru a face acest lucru, fiecare Serviciu este mapat la N obiecte EndpointSlice, fiecare dintre acestea în mod implicit nu are mai mult de 100 de puncte finale (valoarea este configurabilă). API-ul EndpointSlice va oferi, de asemenea, oportunități pentru dezvoltarea sa viitoare: suport pentru mai multe adrese IP pentru fiecare pod, noi stări pentru punctele finale (nu numai Ready и NotReady), subsetare dinamică pentru punctele finale.

Cel prezentat în ultima versiune a ajuns în versiunea beta finalizator, numit service.kubernetes.io/load-balancer-cleanup și atașat fiecărui serviciu cu tip LoadBalancer. În momentul ștergerii unui astfel de serviciu, acesta împiedică ștergerea efectivă a resursei până la finalizarea „curățării” tuturor resurselor de echilibrare relevante.

Mașini API

Adevărata „etapă de stabilizare” se află în zona serverului API Kubernetes și a interacțiunii cu acesta. Acest lucru s-a întâmplat în mare parte datorită transferarea în stare stabilă a celor care nu au nevoie de introducere specială CustomResourceDefinitions (CRD), care au statut beta încă din zilele îndepărtate ale Kubernetes 1.7 (și aici este iunie 2017!). Aceeași stabilizare a venit și la caracteristicile aferente:

"subresurse" cu /status и /scale pentru CustomResources;
transformare versiuni pentru CRD, bazate pe webhook extern;
prezentat recent (în K8s 1.15) valori implicite (implicit) și eliminarea automată a câmpului (taiere) pentru CustomResources;
oportunitate folosind schema OpenAPI v3 pentru a crea și publica documentația OpenAPI utilizată pentru validarea resurselor CRD pe partea serverului.

Un alt mecanism care a devenit de mult familiar administratorilor Kubernetes: webhook de admitere - a rămas, de asemenea, în stare beta mult timp (de la K8s 1.9) și este acum declarat stabil.

Alte două funcții au ajuns în versiune beta: se aplică partea serverului и ceas marcaje.

Și singura inovație semnificativă în versiunea alfa a fost eșec din SelfLink — un URI special care reprezintă obiectul specificat și care face parte din acesta ObjectMeta и ListMeta (adică o parte a oricărui obiect din Kubernetes). De ce îl abandonează? Motivația într-un mod simplu sunete ca absenţa unor motive reale (covârşitoare) pentru ca acest domeniu să mai existe. Motive mai formale sunt optimizarea performanței (prin eliminarea unui câmp inutil) și simplificarea muncii generic-apiserver, care este obligat să gestioneze un astfel de câmp într-un mod special (acesta este singurul câmp care este setat chiar înaintea obiectului). este serializat). Învechire adevărată (în cadrul beta) SelfLink se va întâmpla cu Kubernetes versiunea 1.20 și final - 1.21.

Stocare a datelor

Principala activitate în zona de depozitare, ca și în versiunile anterioare, se observă în zonă Suport CSI. Principalele modificări aici au fost:

pentru prima dată (în versiune alfa) a apărut Compatibilitate cu pluginul CSI pentru nodurile de lucru Windows: modul actual de lucru cu stocarea va înlocui, de asemenea, pluginurile din arborele din nucleul Kubernetes și pluginurile FlexVolume de la Microsoft bazate pe Powershell;

Schemă pentru implementarea pluginurilor CSI în Kubernetes pentru Windows
oportunitate redimensionarea volumelor CSI, introdus înapoi în K8s 1.12, a devenit o versiune beta;
O „promovare” similară (de la alfa la beta) a fost realizată prin capacitatea de a utiliza CSI pentru a crea volume efemere locale (Suport de volum inline CSI).

Introdus în versiunea anterioară de Kubernetes funcția de clonare a volumului (folosind PVC existent ca DataSource pentru a crea un nou PVC) a primit, de asemenea, statutul beta.

Programator

Două modificări notabile ale programării (ambele în alfa):

EvenPodsSpreading - oportunitate utilizați pod-uri în loc de unități logice de aplicație pentru „distribuirea corectă” a încărcăturilor (cum ar fi Deployment și ReplicaSet) și ajustarea acestei distribuții (ca o cerință grea sau ca o condiție soft, adică prioritate). Caracteristica va extinde capacitățile de distribuție existente ale podurilor planificate, limitate în prezent de opțiuni PodAffinity и PodAntiAffinity, oferind administratorilor un control mai fin în această problemă, ceea ce înseamnă o disponibilitate ridicată mai bună și un consum optimizat de resurse. Detalii - in EBC.
Folosi Politica BestFit в Funcția de prioritate RequestedToCapacityRatio în timpul planificării podului, ceea ce va permite aplica ambalarea coșului („ambalare în containere”) atât pentru resursele de bază (procesor, memorie), cât și pentru cele extinse (cum ar fi GPU). Pentru mai multe detalii, vezi EBC.

Planificarea podurilor: înainte de a utiliza politica cea mai bună potrivire (direct prin planificatorul implicit) și odată cu utilizarea acesteia (prin extensia de planificare)

Mai mult decât atât, este prezentat abilitatea de a crea propriile pluginuri de planificare în afara arborelui principal de dezvoltare Kubernetes (în afara arborelui).

Alte modificări

De asemenea, în versiunea Kubernetes 1.16 puteți observa initiativa pentru aducând valorile disponibile în ordine completă, sau mai precis, în conformitate cu regulamentele oficiale la instrumentarea K8s. Ei se bazează în mare măsură pe corespunzătoare Documentația Prometheus. Neconcordanțe au apărut din diverse motive (de exemplu, unele valori au fost create pur și simplu înainte de apariția instrucțiunilor actuale), iar dezvoltatorii au decis că este timpul să aducă totul la un singur standard, „în conformitate cu restul ecosistemului Prometheus”. Actuala implementare a acestei inițiative este în stare alfa, care va fi promovată progresiv în versiunile ulterioare de Kubernetes la beta (1.17) și stabil (1.18).

În plus, pot fi observate următoarele modificări:

Windows sprijină dezvoltarea с aspect Utilitare Kubeadm pentru acest sistem de operare (versiunea alfa), oportunitate RunAsUserName pentru containere Windows (versiunea alfa), îmbunătăţire Contul de servicii gestionat de grup (gMSA) acceptă până la versiunea beta, a sustine montare/atașare pentru volume vSphere.
Reciclat mecanism de comprimare a datelor în răspunsurile API. Anterior, în aceste scopuri era folosit un filtru HTTP, care impunea o serie de restricții care împiedicau activarea lui implicită. „Comprimarea cererii transparente” funcționează acum: trimiterea clienților Accept-Encoding: gzip în antet, ei primesc un răspuns comprimat GZIP dacă dimensiunea acestuia depășește 128 KB. Clienții Go acceptă automat compresia (trimiterea antetului necesar), astfel încât vor observa imediat o reducere a traficului. (Poate fi necesare mici modificări pentru alte limbi.)
A devenit posibil scalarea HPA de la/la zero poduri pe baza unor valori externe. Dacă scalați în funcție de obiecte/metrici externe, atunci când sarcinile de lucru sunt inactive, puteți scala automat la 0 replici pentru a economisi resurse. Această caracteristică ar trebui să fie utilă în special pentru cazurile în care lucrătorii solicită resurse GPU și numărul de tipuri diferite de lucrători inactivi depășește numărul de GPU-uri disponibile.
client nou - k8s.io/client-go/metadata.Client — pentru acces „general” la obiecte. Este conceput pentru a prelua cu ușurință metadatele (adică subsecțiunea metadata) din resursele clusterului și efectuează cu acestea operațiuni de colectare a gunoiului și de cotă.
Construiește Kubernetes acum poti fără furnizori de cloud moșteniți (încorporat în arbore) (versiunea alfa).
La utilitarul kubeadm adăugat capacitatea experimentală (versiunea alfa) de a aplica patch-uri personalizate în timpul operațiunilor init, join и upgrade. Aflați mai multe despre cum să utilizați steagul --experimental-kustomize, vezi in EBC.
Noul punct final pentru apiserver - readyz, - vă permite să exportați informații despre pregătirea acestuia. Serverul API are acum un steag --maximum-startup-sequence-duration, permițându-vă să-i reglați repornirile.
Două caracteristici pentru Azure declarat stabil: suport zone de disponibilitate (Zone de disponibilitate) și grup de resurse încrucișate (RG). În plus, Azure a adăugat:
- suport de autentificare AAD și ADFS;
- adnotare service.beta.kubernetes.io/azure-pip-name pentru a specifica IP-ul public al echilibratorului de încărcare;
- oportunitate настройки LoadBalancerName и LoadBalancerResourceGroup.
AWS are acum sprijini pentru EBS pe Windows și optimizat Apeluri EC2 API DescribeInstances.
Kubeadm este acum independent migrează Configurarea CoreDNS la actualizarea versiunii CoreDNS.
Binare etcd în imaginea Docker corespunzătoare Terminat World-executable, care vă permite să rulați această imagine fără a fi nevoie de drepturi de root. De asemenea, imaginea de migrare etcd a încetat suport pentru versiunea etcd2.
В Cluster Autoscaler 1.16.0 a trecut la utilizarea distroless ca imagine de bază, performanță îmbunătățită, au adăugat noi furnizori de cloud (DigitalOcean, Magnum, Packet).
Actualizări în software-ul folosit/dependent: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

PS

Citește și pe blogul nostru:

Sursa: www.habr.com

Kubernetes 1.16: prezentare generală a principalelor inovații