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

Ieri, 9 decembrie, a avut loc următoarea versiune a Kubernetes - 1.17. Conform tradiției care s-a dezvoltat pentru blogul nostru, vorbim despre cele mai semnificative schimbări în noua versiune.

Kubernetes 1.17: prezentare generală a principalelor inovații

Informațiile folosite la pregătirea acestui material sunt preluate din anunțul oficial, Tabelele de urmărire a îmbunătățirilor Kubernetes, CHANGELOG-1.17 și probleme conexe, solicitări de extragere și propuneri de îmbunătățire Kubernetes (KEP). Deci ce este nou?..

Rutare conștientă de topologie

Comunitatea Kubernetes așteaptă această funcție de mult timp - Rutarea serviciului conștient de topologie. dacă EBC își are originea în octombrie 2018, iar oficial sporire — Acum 2 ani, problemele obișnuite (ca ea) - și încă câțiva ani mai în vârstă...

Ideea generală este de a oferi posibilitatea de a implementa rutarea „locală” pentru serviciile care locuiesc în Kubernetes. „Localitatea” în acest caz înseamnă „același nivel topologic” (nivel de topologie), care poate fi:

nod identic pentru servicii,
același rack de server,
aceeași regiune
același furnizor de cloud,
...

Exemple de utilizare a acestei funcții:

economii de trafic în instalațiile cloud cu zone de disponibilitate multiple (multi-AZ) - vezi. ilustrație proaspătă folosind exemplul de trafic din aceeași regiune, dar AZ-uri diferite în AWS;
latență de performanță mai mică/performanță mai bună;
un serviciu sharded care are informații locale despre nodul din fiecare shard;
plasarea fluentd (sau analogilor) pe același nod cu aplicațiile ale căror loguri sunt colectate;
...

O astfel de rutare, care „știe” despre topologie, se mai numește și afinitate de rețea - prin analogie cu afinitatea nodului, afinitate de pod/anti-afinitate sau a apărut nu cu mult timp în urmă Programarea volumului în funcție de topologie (și Aprovizionarea volumului). Nivelul actual de implementare ServiceTopology în Kubernetes - versiunea alfa.

Pentru detalii despre cum funcționează funcția și despre cum o puteți utiliza deja, citiți acest articol de la unul dintre autori.

Suport IPv4/IPv6 dual stack

Progres semnificativ fix într-o altă caracteristică de rețea: suport simultan pentru două stive IP, care a fost introdus pentru prima dată în K8s 1.16. În special, noua versiune a adus următoarele modificări:

în kube-proxy implementate posibilitatea de funcționare simultană în ambele moduri (IPv4 și IPv6);
в Pod.Status.PodIPs a apărut suport pentru API descendent (în același timp cu în /etc/hosts acum solicită gazdei să adauge o adresă IPv6);
suport dual stack DRĂGUȚ (Kubernetes IN Docker) și kubeadm;
teste e2e actualizate.

Kubernetes 1.17: prezentare generală a principalelor inovații
Ilustrare folosind dual stack IPV4/IPv6 în NATUR

Progresul CSI

Declarat stabil suport de topologie pentru stocarea bazată pe CSI, introdus pentru prima dată în K8s 1.12.

Inițiativa pentru migrarea pluginurilor de volum la CSI - Migrare CSI - a ajuns la versiunea beta. Această caracteristică este critică pentru a traduce pluginurile de stocare existente (în copac) la o interfață modernă (CSI, în afara arborelui) invizibil pentru utilizatorii finali Kubernetes. Administratorii de clustere vor trebui doar să activeze migrarea CSI, după care resursele și încărcăturile de lucru existente vor continua să „funcționeze”... dar folosind cele mai recente drivere CSI în loc de cele învechite incluse în nucleul Kubernetes.

În acest moment, migrarea pentru driverele AWS EBS este gata în versiunea beta (kubernetes.io/aws-ebs) și GCE PD (kubernetes.io/gce-pd). Prognozele pentru alte spații de depozitare sunt următoarele:

Kubernetes 1.17: prezentare generală a principalelor inovații

Am vorbit despre modul în care suportul de stocare „tradițional” în K8 a ajuns la CSI acest articol. Iar tranziția migrației CSI la statutul beta este dedicată publicare separată pe blogul proiectului.

În plus, o altă funcționalitate semnificativă în contextul CSI, care își are originea (implementarea alfa) în K1.17s 8, a ajuns la starea beta (adică activată implicit) în versiunea Kubernetes 1.12 - crearea de instantanee și recuperarea de la ele. Printre modificările aduse Kubernetes Volume Snapshot în drumul spre lansarea beta:

împărțirea sidecar-ului cu instantaneu extern CSI în două controlere,
secret adăugat pentru ștergere (secretul de ștergere) ca adnotare la conținutul unui instantaneu de volum,
noul finalizator (finalizator) pentru a preveni ștergerea obiectului API instantaneu dacă mai există conexiuni.

La momentul lansării 1.17, caracteristica este acceptată de trei drivere CSI: driverul GCE Persistent Disk CSI, driverul Portworx CSI și driverul NetApp Trident CSI. Mai multe detalii despre implementarea și utilizarea sa pot fi găsite în această publicație pe blog.

Etichetele furnizorilor de cloud

Etichetează automat atribuite nodurilor și volumelor create în funcție de furnizorul de cloud utilizat, au fost disponibile în Kubernetes ca versiune beta de foarte mult timp - de la lansarea K8s 1.2 (aprilie 2016!). Având în vedere utilizarea lor pe scară largă pentru atât de mult timp, dezvoltatorii hotărât, că este timpul să declarăm caracteristica stabilă (GA).

Prin urmare, toate au fost redenumite în consecință (după topologie):

beta.kubernetes.io/instance-type → node.kubernetes.io/instance-type
failure-domain.beta.kubernetes.io/zone → topology.kubernetes.io/zone
failure-domain.beta.kubernetes.io/region → topology.kubernetes.io/region

... dar sunt încă disponibile sub numele lor vechi (pentru compatibilitate inversă). Cu toate acestea, tuturor administratorilor li se recomandă să treacă la etichetele actuale. Documentație aferentă K8s a fost actualizat.

Ieșire structurată a kubeadm

Prezentat în versiune alfa pentru prima dată ieșire structurată pentru utilitarul kubeadm. Formate acceptate: șablon JSON, YAML, Go.

Motivația pentru implementarea acestei caracteristici (conform EBC) este:

În timp ce Kubernetes poate fi implementat manual, standardul de facto (dacă nu de jure) pentru această operațiune este utilizarea kubeadm. Instrumentele populare de gestionare a sistemelor, cum ar fi Terraform, se bazează pe kubeadm pentru implementarea Kubernetes. Îmbunătățirile planificate ale API-ului Cluster includ un pachet composabil pentru bootstrapping Kubernetes cu kubeadm și cloud-init.
Fără rezultate structurate, chiar și cele mai inofensive modificări la prima vedere pot distruge Terraform, Cluster API și alte software-uri care utilizează rezultatele kubeadm.

Planurile noastre imediate includ suport (sub formă de ieșire structurată) pentru următoarele comenzi kubeadm:

alpha certs
config images list
init
token create
token list
upgrade plan
version

Ilustrație a unui răspuns JSON la o comandă kubeadm init -o json:

{
  "node0": "192.168.20.51:443",
  "caCrt": "sha256:1f40ff4bd1b854fb4a5cf5d2f38267a5ce5f89e34d34b0f62bf335d74eef91a3",
  "token": {
    "id":          "5ndzuu.ngie1sxkgielfpb1",
    "ttl":         "23h",
    "expires":     "2019-05-08T18:58:07Z",
    "usages":      [
      "authentication",
      "signing"
    ],
    "description": "The default bootstrap token generated by 'kubeadm init'.",
    "extraGroups": [
      "system:bootstrappers:kubeadm:default-node-token"
    ]
  },
  "raw": "Rm9yIHRoZSBhY3R1YWwgb3V0cHV0IG9mIHRoZSAia3ViZWFkbSBpbml0IiBjb21tYW5kLCBwbGVhc2Ugc2VlIGh0dHBzOi8vZ2lzdC5naXRodWIuY29tL2FrdXR6LzdhNjg2ZGU1N2JmNDMzZjkyZjcxYjZmYjc3ZDRkOWJhI2ZpbGUta3ViZWFkbS1pbml0LW91dHB1dC1sb2c="
}

Stabilizarea altor inovații

În general, lansarea Kubernetes 1.17 a avut loc sub motto-ul „stabilitate" Acest lucru a fost facilitat de faptul că multe caracteristici din acesta (numărul lor total este 14) a primit statutul GA. Printre ei:

„marcarea” nodurilor în funcție de anumite condiții (TaintNodesByCondition), aparut in K8s 1.8;
Urmăriți Marcaje - un nou tip de evenimente care au o etichetă că toate obiectele sunt până la o anumită versiune (resourceVersion) au fost deja procesate de ceas;
valori implicite (implicit) pentru Resurse personalizate;
împărțite între containere în spațiile de nume ale procesului pod;
ScheduleDaemonSetPods - pod-uri de programare în DaemonSet folosind kube-scheduler (în loc de controlerul DaemonSet);
limite dinamice asupra numărului de volume în funcție de tipul nodului;
suport pentru variabile de mediu pentru nume de directoare montate ca subPath;
Transferul bătăilor inimii Kubelet la un API de închiriere specializat;
„protecția finalizatorului” (Protecția Finalizatorului) pentru echilibratori de încărcare (verificarea resurselor Service corespunzătoare înainte de a șterge resursele LoadBalancer);
optimizare kube-apiserver în performanță atunci când se lucrează cu mai multe ceasuri monitorizarea seturi identice de obiecte - obținut prin evitarea serializării repetate a acelorași obiecte pentru fiecare observator.

Alte modificări

Lista completă a inovațiilor din Kubernetes 1.17, desigur, nu se limitează la cele enumerate mai sus. Iată câteva altele (și pentru o listă mai completă, vezi istoria schimbărilor):

Caracteristica prezentată în ultima versiune a ajuns în versiunea beta RunAsUserName pentru Windows;
schimbare similară s-a întâmplat API-ul EndpointSlice (tot din K8s 1.16), totuși, deocamdată, această soluție de îmbunătățire a performanței/scalabilității API-ului Endpoint nu este activată implicit;
Pod-urile sunt acum critice pentru funcționarea clusterului poate fi creat nu numai în spațiile de nume kube-system (pentru detalii, consultați documentația pentru Limitați consumul din clasa prioritară);
opțiune nouă pentru kubelet - --reserved-cpus — vă permite să definiți în mod explicit lista CPU-urilor rezervate pentru sistem;
pentru kubectl logs prezentat steag nou --prefix, adăugând numele podului și al containerului sursă la fiecare linie a jurnalului;
в label.Selector adăugat RequiresExactMatch;
toate containerele în kube-dns rulează acum cu mai puține privilegii;
hiperkube separat într-un depozit GitHub separat și nu va mai fi inclus în versiunile Kubernetes;
mult performanta imbunatatita kube-proxy pentru porturi non-UDP.

Modificări de dependență:

Versiunea CoreDNS inclusă în kubeadm este 1.6.5;
Versiunea crictl actualizată la v1.16.1;
CSI 1.2.0;
etcd 3.4.3;
Ultima versiune Docker testată, actualizată la 19.03;
Versiunea Go minimă necesară pentru a construi Kubernetes 1.17 este 1.13.4.

PS

Citește și pe blogul nostru:

Sursa: www.habr.com