Kubernetes 1.17: o privire de ansamblu asupra principalelor noutăți

Ieri, 9 decembrie, a avut loc a avut loc un nou release Kubernetes — 1.17. Conform tradiției pentru blogul nostru, vă vom prezenta cele mai semnificative modificări din noua versiune.

Informațiile utilizate pentru pregătirea acestui material sunt preluate din anunțul oficial, tabelul de urmărire a îmbunătățirilor Kubernetes, CHANGELOG-1.17 și problemele, cererile de integrare, precum și Propunerile de Îmbunătățire Kubernetes (KEP). Așadar, ce noutăți avem?..

Rutare în funcție de topologie

Comunitatea Kubernetes a așteptat de mult această caracteristică — Rutare a serviciilor conștiente de topologie. Dacă KEP care își are începutul în octombrie 2018, iar oficial îmbunătățirea — acum 2 ani, iar problemele obişnuite (de exemplu, aceasta) — sunt cu câțiva ani mai vechi…

Idea generală este de a oferi posibilitatea de a implementa o rutare „locală” pentru serviciile aflate în Kubernetes. „Localitatea” în acest context înseamnă „același nivel topologic” (nivel de topologie), care poate fi:

• același nod pentru servicii,
• aceeași unitate de server,
• același region,
• același furnizor de cloud,
• …

Exemple de utilizare a acestei caracteristici:

• reducerea traficului în instalările cloud cu mai multe zone de disponibilitate (multi-AZ) — vezi ilustrația recentă cu traficul dintr-un singur region, dar din AZ-uri diferite în AWS;
• teroari mai mici de latență/performanță mai bună;
• un serviciu shardat, având informații locale despre nod în fiecare shard;
• plasarea fluentd (sau echivalente) pe un singur nod cu aplicațiile ale căror log-uri sunt colectate;
• …

Această rutare, „conștientă” de topologie, se mai numește și similară cu network affinity — similar cu node affinity, pod affinity/anti-affinity sau cu apariția recentă Topology-Aware Volume Scheduling (și Volume Provisioning ). Nivelul actual de implementareServiceTopology în Kubernetes — versiune alfa. Detalii despre cum funcționează caracteristica și cum o puteți utiliza deja, citiți în

articolul unuia dintre autori. această articole Suport pentru stiva dublă IPv4/IPv6

Progrese semnificative

au fost înregistrate într-o altă caracteristică de rețea: suport simultan pentru două stive IP, care a fost prezentat pentru prima dată în K8s 1.16 . În special, noul release a adus următoarele modificări:în kube-proxy

• posibilitatea de a funcționa simultan în ambele moduri (IPv4 și IPv6); a fost implementată Pod.Status.PodIPs
• în suport pentru API-ul descendent (în același timp, acestea acum cer pentru gazdă să adauge și adresa IPv6); a apărut suport pentru două stive în /etc/hosts KIND
• (Kubernetes IN Docker) și teste e2e actualizate. actualizate. kubeadm;
• actualizate.

Ilustrație a utilizării stivei duale IPv4/IPv6 în KIND

Progres în CSI

Anunțat ca stabil sprijin pentru topologii pentru stocări bazate pe CSI, prezentată pentru prima dată în K8s 1.12.

Inițiativa pentru migrarea plugin-urilor de stocare pe CSI — Migrarea CSI a ajuns la versiunea beta. Această caracteristică este critică pentru a transfera plugin-urile de stocare existente (in-tree) la interfața modernă (CSI, out-of-tree) invizibil pentru utilizatorii finali Kubernetes. Administratorii de clustere vor trebui doar să activeze Migrarea CSI, după care resursele stateful existente și sarcinile de lucru vor continua să „funcționeze pur și simplu”… dar acum cu driverele CSI actualizate în locul celor învechite, incluse în nucleul Kubernetes.

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

Despre cum a ajuns suportul „tradițional” pentru stocare în K8s la CSI am relatat în această articole. O publicație separată se dedică trecerii Migrației CSI în statut beta în blogul proiectului. De asemenea, o altă funcționalitate semnificativă în contextul CSI, care a ajuns la statut beta (adică activare implicită) în versiunea Kubernetes 1.17, a avut originea (implementarea alfa) în K8s 1.12, —

crearea de snapshot-uri și recuperarea din ele . Printre modificările efectuate în Kubernetes Volume Snapshot pe drumul către versiunea beta:fragmentarea sidecar-ului CSI external-snapshotter în doi controlori,

• s-a adăugat un secret pentru ștergere
• (deletion secret) ca o notă la conținutul snapshot-ului volumului, un nou finalizator
• (finalizer) pentru a împiedica ștergerea obiectului API al snapshot-ului în cazul existenței unor relații rămase. În momentul lansării 1.17, caracteristica este suportată de trei drivere CSI: GCE Persistent Disk CSI Driver, Portworx CSI Driver și NetApp Trident CSI Driver. Mai multe detalii despre implementarea și utilizarea acesteia pot fi citite în

această publicație din blog. Etichete Cloud Provider

Etichete, care sunt atribuite automat

nodurilor și volumelor create în funcție de furnizorul de cloud utilizat , au fost disponibile în Kubernetes ca versiune beta de mult timp — încă de la lansarea K8s 1.2(aprilie 2016!) . Având în vedere utilizarea lor pe scară largă de atât de multă vreme, dezvoltatoriiau decis , că a sosit timpul să anunțe caracteristica ca fiind stabilă (GA).Astfel, toate acestea au fost redenumite în mod corespunzător (pe topologii):

beta.kubernetes.io/instance-type

• node.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 și cu vechile lor denumiri (pentru compatibilitate). Totuși, tuturor administratorilor li se recomandă să migreze la etichetele actuale. Documentația corespunzătoare K8s a fost actualizat.

Ieşirea structurată kubeadm

A fost prezentată pentru prima dată în format alpha ieșirea structurată pentru utilitarul kubeadm. Formatele acceptate sunt: JSON, YAML, Go-template.

Motivul implementării acestei caracteristici (conform KEP) este:

Deși Kubernetes poate fi desfășurat manual, standardul de facto (dacă nu chiar de jure) pentru această operațiune este utilizarea kubeadm. Instrumentele populare de gestionare a sistemelor, precum Terraform, se bazează pe kubeadm pentru desfășurarea Kubernetes. Îmbunătățirile planificate pentru Cluster API includ un pachet compus pentru bootstrap-ing Kubernetes cu kubeadm și cloud-init.

Fără ieșirea structurată, chiar și cele mai inofensive modificări pot sparge Terraform, Cluster API și alte softuri care utilizează rezultatul kubeadm.

În planurile de viitor se află suportul (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ția răspunsului JSON pentru comanda 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": "Tokenul de bootstrap implicit generat de 'kubeadm init'.",
    "extraGroups": [
      "system:bootstrappers:kubeadm:default-node-token"
    ]
  },
  "raw": "Rm9yIHRoZSBhY3R1YWwgb3V0cHV0IG9mIHRoZSAia3ViZWFkbSBpbml0IiBjb21tYW5kLCBwbGVhc2Ugc2VlIGh0dHBzOi8vZ2lzdC5naXRodWIuY29tL2FrdXR6LzdhNjg2ZGU1N2JmNDMzZjkyZjcxYjZmYjc3ZDRkOWJhI2ZpbGUta3ViZWFkbS1pbml0LW91dHB1dC1sb2c="
}

Stabilizarea altor inovații

În general, lansarea Kubernetes 1.17 s-a desfășurat sub deviza „Stabilitate”. Acest lucru a fost facilitat de faptul că multe caracteristici din el (în total) 14) au primit statut GA. Printre acestea se numără:

• „eticheta” nodurilor în funcție de anumite condiții (TaintNodesByCondition), apărută în K8s 1.8;
• Watch Bookmarks — un nou tip de evenimente care marchează că toate obiectele până la o anumită versiune (resourceVersion) au fost deja procesate de watch;
• valori implicite (defaulting) pentru resursele personalizate;
• namespace-urile proceselor partajate între containere în pod;
• ScheduleDaemonSetPods — planificarea podurilor în DaemonSet cu ajutorul kube-scheduler (în locul controlerului DaemonSet);
• limite dinamice în funcție de tipul nodului;
• suport pentru variabile de mediu pentru denumirile directorilor montate ca subPath;
• transferul bătăilor de inimă Kubelet în API-ul specializat Lease;
• «protecția finalizatorului» (Finalizer Protection) pentru echilibratoarele de sarcină (verificarea resurselor corespunzătoare serviciului înainte de a șterge resursele LoadBalancer);
• optimizarea kube-apiserver în performanță atunci când lucrează cu numeroase watches, observând seturi identice de obiecte, - realizată prin evitarea serializării repetate a acelorași obiecte pentru fiecare watcher.

Alte modificări

Lista completă a noutăților din Kubernetes 1.17, desigur, nu se limitează la cele enumerate mai sus. Iată câteva altele (pentru o listă mai completă, consultați CHANGELOG):

• funcționalitatea introdusă în ultima versiune a ajuns la versiunea beta RunAsUserName pentru Windows;
• o modificare similară a ajuns EndpointSlice API (de asemenea, din K8s 1.16), totuși, această soluție pentru îmbunătățirea performanței/scalabilității API-ului Endpoint nu este activată implicit;
• podurile critice pentru funcționarea clusterului pot fi create nu doar în spațiile de nume kube-system (detalii în documentația despre Limit Priority Class consumption);
• o nouă opțiune pentru kubelet - --reserved-cpus - permite definirea explicită a listei de CPU-uri rezervate pentru sistem;
• pentru kubectl logs la sfârșitul anului 2019. Pe lângă protocoalele ActivityPub și diaspora, Hubzilla se federează în cadrul rețelei prin propriul său protocol o nouă flag --prefix, adăugând numele pod-ului și al containerului sursă la fiecare linie de log;
• în label.Selector a fost adăugată RequiresExactMatch;
• toate containerele din kube-dns acum sunt rulate cu privilegii reduse;
• hyperkube a fost dedicat într-un repository GitHub separat și nu va mai fi inclus în versiunile Kubernetes;
• semnificativ a fost îmbunătățită performanța kube-proxy pentru porturi non-UDP.

Modificări în dependențe:

• versiunea CoreDNS în kubeadm - 1.6.5;
• versiunea crictl a fost actualizată la v1.16.1;
• CSI 1.2.0;
• etcd 3.4.3;
• cea mai recentă versiune verificată a Docker a fost ridicată la 19.03;
• versiunea minimă Go necesară pentru construirea Kubernetes 1.17 este 1.13.4.

P.S.

Citiți și în blogul nostru:

• «Kubernetes 1.16: o privire asupra principalelor noutăți»;
• «Kubernetes 1.15: o privire asupra principalelor noutăți»;
• «Kubernetes 1.14: o privire asupra principalelor noutăți»;
• «Kubernetes 1.13: o privire asupra principalelor noutăți».

Sursa: habr.com