🥇Kubernetes 1.16: Panoramica di e innovazioni principali

Oghje, mercuri, duverà prossima versione di Kubernetes - 1.16. Sicondu a tradizione chì hà sviluppatu per u nostru blog, questu hè u decimu anniversariu chì parlemu di i cambiamenti più significati in a nova versione.

L'infurmazione utilizata per preparà stu materiale hè stata presa da Kubernetes migliora i tabelle di tracciamentu, CHANGELOG-1.16 è prublemi cunnessi, richieste di pull, è Proposte di miglioramentu di Kubernetes (KEP). Allora, andemu!...

Nodi

Un veru gran numaru di innovazioni notevuli (in u statutu di versione alfa) sò presentati à u latu di i nodi di cluster K8s (Kubelet).

Prima, u cusì chjamatu «contenitori effimeri» (Contenitori effimeri), cuncepitu per simplificà i prucessi di debugging in pods. U novu mecanismu permette di lancià cuntenituri speciali chì cumincianu in u namespace di pods esistenti è campanu per un pocu tempu. U so scopu hè di interagisce cù altri pods è cuntenituri per risolve ogni prublema è debug. Un novu cumandamentu hè statu implementatu per sta funzione kubectl debug, simile in essenza à kubectl exec: solu invece di eseguisce un prucessu in un containeru (cum'è in exec) lancia un containeru in un pod. Per esempiu, stu cumandimu cunnette un novu containeru à un pod:

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

I dettagli nantu à i cuntenituri effimeri (è esempi di u so usu) ponu esse truvati in KEP corrispondente. L'implementazione attuale (in K8s 1.16) hè una versione alfa, è trà i criterii per u so trasferimentu à una versione beta hè "prova l'API Ephemeral Containers per almenu 2 versioni di [Kubernetes]".

NB: In a so essenza è ancu u so nome, a funzione s'assumiglia à un plugin digià esistente kubectl-debugcirca chì noi digià scrittu. Hè previstu chì cù l'avventu di cuntenituri effimeri, u sviluppu di un plugin esternu separatu cesserà.

Un'altra innovazione - PodOverhead - cuncepitu per furnisce mecanismu per u calculu di i costi generali per i pods, chì pò varià assai sicondu u runtime utilizatu. Per esempiu, l'autori questu KEP risultatu in Kata Containers, chì necessitanu di eseguisce u kernel d'ospiti, l'agente kata, u sistema init, etc. Quandu l'overhead diventa cusì grande, ùn pò micca esse ignoratu, chì significa chì deve esse un modu per piglià in contu per più quote, pianificazione, etc. Per implementà in PodSpec campu aghjuntu Overhead *ResourceList (paragunate cù i dati in RuntimeClass, se unu hè utilizatu).

Un'altra novità notevole hè gestore di topologia di nodi (Gestione di topologia di nodi), cuncepitu per unificà l'approcciu di fine-tuning l'assignazione di risorse hardware per diversi cumpunenti in Kubernetes. Questa iniziativa hè guidata da a crescente necessità di diversi sistemi muderni (da u campu di telecomunicazioni, apprendimentu di machine, servizii finanziarii, etc.) per un computing parallelu d'alta prestazione è minimizzà i ritardi in l'esekzione di l'operazioni, per quale utilizanu CPU avanzati è capacità di accelerazione hardware. Tali ottimisazioni in Kubernetes sò stati ottenuti finu à avà grazia à cumpunenti disparati (CPU manager, Device manager, CNI), è avà seranu aghjuntu una sola interfaccia interna chì unifica l'approcciu è simplificà a cunnessione di novi simili - cusì-chiamatu topologia - cuscenti - cumpunenti nant'à u latu Kubelet. Dettagli - in KEP corrispondente.

Diagramma di cumpunenti di Topology Manager

Funzione dopu - cuntrollà i cuntenituri mentre sò in esecuzione (sonda di startup). Comu sapete, per i cuntenituri chì piglianu assai tempu per lancià, hè difficiule d'ottene un statutu aghjurnatu: sò o "ammazzati" prima di principià veramente à funziunà, o finiscinu in bloccu per un bellu pezzu. Novu cuntrollu (attivatu attraversu a porta di funzione chjamata StartupProbeEnabled) annulla - o piuttostu, diferisce - l'effettu di qualsiasi altri cuntrolli finu à u mumentu chì u pod hè finitu di funziona. Per quessa, a funzione hè stata chjamata urigginariamente pod-startup liveness-probe holdoff. Per i baccelli chì piglianu assai tempu per inizià, pudete sondaghju u statu in intervalli di tempu relativamente brevi.

Inoltre, una mellura per RuntimeClass hè immediatamente dispunibule in u statutu beta, aghjunghjendu supportu per "clusters eterogenei". C RuntimeClass Scheduling Avà ùn hè micca necessariu per ogni node per avè supportu per ogni RuntimeClass: per pods pudete selezziunate una RuntimeClass senza pensà à a topologia di cluster. Nanzu, per ottene questu - per chì i pods finiscinu nantu à i nodi cù supportu per tuttu ciò chì anu bisognu - era necessariu d'assignà regule appropritate à NodeSelector è tollerazioni. IN CAP Parla di esempi d'usu è, sicuru, dettagli di implementazione.

Network

Dui funzioni di rete impurtanti chì apparsu per a prima volta (in versione alfa) in Kubernetes 1.16 sò:

sustegnu stack dual network - IPv4/IPv6 - è a so "comprensione" currispundente à u livellu di pods, nodes, servizii. Include l'interoperabilità IPv4-à-IPv4 è IPv6-à-IPv6 trà pods, da pods à servizii esterni, implementazioni di riferimentu (dentru i plugins Bridge CNI, PTP CNI è Host-Local IPAM), è ancu inversu Compatibile cù i cluster Kubernetes in esecuzione. Solu IPv4 o IPv6. I dettagli di implementazione sò in CAP.
Un esempiu di vede indirizzi IP di dui tipi (IPv4 è IPv6) in a lista di pods:
```
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#
```
Nova API per Endpoint - API EndpointSlice. Risolve i prublemi di rendiment / scalabilità di l'API Endpoint esistenti chì affettanu diversi cumpunenti in u pianu di cuntrollu (apiserver, etcd, endpoints-controller, kube-proxy). A nova API serà aghjuntu à u gruppu Discovery API è serà capace di serve decine di millaie di backend endpoints in ogni serviziu in un cluster custituitu da millaie di nodi. Per fà questu, ogni Serviziu hè mappatu à N oggetti EndpointSlice, ognuna di quali per difettu ùn hà micca più di 100 endpoints (u valore hè configurabile). L'API EndpointSlice furnisce ancu opportunità per u so sviluppu futuru: supportu per parechje indirizzi IP per ogni pod, stati novi per i punti finali (micca solu Ready и NotReady), subsetting dinamicu per i punti finali.

Quellu prisentatu in l'ultima versione hè ghjuntu à a versione beta finalizzatore, chjamatu service.kubernetes.io/load-balancer-cleanup è attaccatu à ogni serviziu cù tipu LoadBalancer. À u mumentu di sguassà un tali serviziu, impedisce l'eliminazione attuale di a risorsa finu à chì a "pulizia" di tutte e risorse di bilanciu pertinenti hè finita.

Macchinari API

U veru "pietra di stabilizazione" hè in l'area di u servitore API Kubernetes è l'interazzione cun ellu. Questu hè accadutu in gran parte grazia à trasferendu à un statutu stabile quelli chì ùn anu micca bisognu di introduzione speciale Definizioni di risorse persunalizate (CRD), chì anu avutu u status beta da i ghjorni distanti di Kubernetes 1.7 (è questu hè ghjugnu 2017!). A listessa stabilizazione hè ghjunta à e caratteristiche cunnesse:

"sottorisorse" cù /status и /scale per CustomResources;
cunversione versioni per CRD, basatu annantu à webhook esternu;
presentatu recentemente (in K8s 1.15) valori predeterminati (par défaut) è eliminazione automatica di u campu (potatura) per CustomResources;
uppurtunità utilizendu u schema OpenAPI v3 per creà è publicà a documentazione OpenAPI utilizata per validà e risorse CRD in u latu di u servitore.

Un altru mecanismu chì hè diventatu longu familiarizatu à l'amministratori di Kubernetes: webhook di ammissione - hè statu ancu in u status beta per un bellu pezzu (dapoi K8s 1.9) è hè avà dichjaratu stabile.

Dui altri funziunalità sò ghjunti in beta: applicà à u latu di u servitore и fighjate i marcatori.

È l'unica innovazione significativa in a versione alfa era отказ от SelfLink - un URI speciale chì rapprisenta l'ughjettu specificatu è chì face parte ObjectMeta и ListMeta (vale à dì parte di qualsiasi ughjettu in Kubernetes). Perchè l'abbandunanu ? A motivazione in modu simplice sona cum'è l'absenza di mutivi veri (enorme) per chì stu campu esista sempre. Motivi più furmali sò per ottimisà u rendiment (sguassendu un campu innecessariu) è simplificà u travagliu di u genericu-apiserver, chì hè obligatu à trattà un tali campu in una manera speciale (questu hè l'unicu campu chì hè stallatu ghjustu davanti à l'ughjettu). hè serializatu). Vera obsolescenza (in u beta) SelfLink succederà da Kubernetes versione 1.20, è finale - 1.21.

Storage di dati

U travagliu principale in l'area di almacenamentu, cum'è in e versioni precedenti, hè osservatu in a zona Supportu CSI. I cambiamenti principali quì sò stati:

per a prima volta (in versione alfa) apparsu Supportu di plugin CSI per i nodi di u travagliu di Windows: u modu attuale di travaglià cù l'almacenamiento rimpiazzarà ancu i plugins in-tree in u core Kubernetes è i plugins FlexVolume da Microsoft basatu in Powershell;

Schema per l'implementazione di plugins CSI in Kubernetes per Windows
uppurtunità ridimensionà i volumi CSI, introduttu torna in K8s 1.12, hè cresciutu à una versione beta;
Una "prumozione" simili (da l'alfa à beta) hè stata ottenuta da a capacità di utilizà CSI per creà volumi effimeri lucali (Supportu di Volume Inline CSI).

Intruduttu in a versione precedente di Kubernetes funzione di clonazione di volumi (aduprendu PVC esistenti cum'è DataSource per creà un novu PVC) hà ancu avà ricevutu status beta.

Scheduler

Dui cambiamenti notevuli à a pianificazione (i dui in alfa):

EvenPodsSpreading - opportunità utilizate pods invece di unità di applicazione logica per a "distribuzione ghjusta" di carichi (cum'è Deployment and ReplicaSet) è aghjustendu sta distribuzione (cum'è un requisitu duru o cum'è una cundizione suave, vale à dì priorità). A funzione ampliarà e capacità di distribuzione esistenti di pods pianificati, attualmente limitati da opzioni PodAffinity и PodAntiAffinity, dendu à l'amministratori un cuntrollu più fine in questa materia, chì significa una megliu alta dispunibilità è u cunsumu di risorse ottimizzati. Dettagli - in CAP.
Usu Pulitica BestFit в Funzione di priorità RequestedToCapacityRatio durante a pianificazione di pod, chì permetterà per appiicà imballaggio bin ("packing in containers") sia per e risorse basi (processore, memoria) sia estese (cum'è GPU). Per più dettagli, vede CAP.

Scheduling pods: prima di utilizà a pulitica di u megliu adattatu (direttamente via u pianificatore predeterminatu) è cù u so usu (via l'estensione di pianificazione)

Inoltre, rapprisintatu da l'abilità di creà i vostri plugins di pianificazione fora di l'arburu di sviluppu principale di Kubernetes (fora di l'arbre).

Altri cambiamenti

Ancu in a versione Kubernetes 1.16 pò esse nutatu iniziativa per purtendu metriche dispunibili in ordine cumpletu, o più precisamente, in cunfurmità cù regulamenti ufficiali à l'instrumentazione K8s. Si basanu largamente nantu à u currispundente Documentazione Prometheus. L'incongruenze sò ghjunte per parechji motivi (per esempiu, alcune metriche sò stati simpliciamente creati prima chì l'istruzzioni attuali apparsu), è i sviluppatori anu decisu chì era ora di portà tuttu à un standard unicu, "in linea cù u restu di l'ecosistema Prometheus". L'implementazione attuale di sta iniziativa hè in statu alfa, chì serà prugressivamenti prumuvutu in versioni successive di Kubernetes à beta (1.17) è stabile (1.18).

Inoltre, i seguenti cambiamenti ponu esse nutati:

Windows supportu u sviluppu с apparenza Utilità Kubeadm per questu OS (versione alfa), opportunità RunAsUserName per i cuntenituri Windows (versione alfa), migliuramentu Cuntu di serviziu amministratu di gruppu (gMSA) supportu finu à a versione beta, sustegnu mount/attach for vSphere volumes.
Riciclata mecanismu di cumpressione di dati in risposti API. Nanzu, un filtru HTTP era utilizatu per questi scopi, chì impone una quantità di restrizioni chì impediscenu di esse attivatu per automaticamente. "A cumpressione di richieste trasparenti" funziona avà: i clienti mandanu Accept-Encoding: gzip in l'intestazione, ricevenu una risposta cumpressa GZIP se a so dimensione supera 128 KB. I clienti Go supportanu automaticamente a compressione (inviendu l'intestazione necessaria), perch'elli notaranu immediatamente una riduzione di u trafficu. (Picculi mudificazioni ponu esse necessarie per altre lingue.)
Hè diventatu pussibule scala HPA da / à zero pods basatu nantu à metriche esterne. Se scalate basatu annantu à l'uggetti / metriche esterne, allora quandu i carichi di travagliu sò inattivi, pudete scalà automaticamente à 0 repliche per salvà risorse. Questa funzione deve esse particularmente utile per i casi induve i travagliadori dumandanu risorse GPU, è u nùmeru di diversi tipi di travagliadori inattivi supera u numeru di GPU dispunibili.
novu cliente - k8s.io/client-go/metadata.Client - per l'accessu "generalizatu" à l'uggetti. Hè pensatu per ricuperà facilmente i metadati (vale à dì subsection metadata) da e risorse di cluster è eseguisce cullizzioni di basura è operazioni di quota cun elli.
Custruisce Kubernetes avà pudete senza legatu ("custruitu" in-tree) fornitori di nuvola (versione alfa).
À l'utilità kubeadm aghjuntu capacità sperimentale (versione alfa) di applicà patches persunalizate durante l'operazioni init, join и upgrade. Sapete più nantu à cumu utilizà a bandiera --experimental-kustomize, vede in CAP.
Novu endpoint per apiserver - readyz, - permette di exportà infurmazioni nantu à a so prontezza. U servitore API hà ancu avà una bandiera --maximum-startup-sequence-duration, chì vi permette di regulà u so riavvia.
Dui funzioni per Azure dichjaratu stabile : supportu zoni di dispunibilità (Zone di Disponibilità) è gruppu di risorse incruciate (RG). Inoltre, Azure hà aghjustatu:
- supportu di autentificazione AAD è ADFS;
- annotazione service.beta.kubernetes.io/azure-pip-name per specificà l'IP publicu di u balancer di carica;
- uppurtunità messageria LoadBalancerName и LoadBalancerResourceGroup.
AWS hà avà supportu per EBS in Windows è ottimizzati Chjama EC2 API DescribeInstances.
Kubeadm hè avà indipendente migra Cunfigurazione CoreDNS quandu aghjurnà a versione CoreDNS.
Binari eccd in l'imaghjini currispundenti di Docker fattu world-executable, chì vi permette di eseguisce sta maghjina senza bisognu di diritti di root. Inoltre, l'immagine di migrazione etcd cessatu supportu di versione etcd2.
В Cluster Autoscaler 1.16.0 hà cambiatu à aduprà distroless cum'è l'imaghjini di basa, un rendimentu migliuratu, aghjustatu novi fornitori di nuvola (DigitalOcean, Magnum, Packet).
Aghjurnamenti in u software utilizatu / dipendente: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

PS

Leghjite puru nant'à u nostru blog:

Source: www.habr.com

Kubernetes 1.16: Highlights di ciò chì hè novu