🥇Kubernetes 1.16: Punti salienti delle novità

Oggi mercoledì состоится la prossima versione di Kubernetes è la 1.16. Secondo la tradizione che si è sviluppata per il nostro blog, per il decimo anniversario stiamo parlando dei cambiamenti più significativi nella nuova versione.

Le informazioni utilizzate per preparare questo materiale sono tratte da Tabelle di monitoraggio dei miglioramenti di Kubernetes, CAMBIAMENTI-1.16 e problemi correlati, richieste pull e Kubernetes Enhancement Proposals (KEP). Quindi andiamo! ..

Nodi

Un numero davvero elevato di innovazioni degne di nota (in stato di versione alpha) sono presentate sul lato dei nodi dei cluster K8s (Kubelet).

Innanzitutto, ci sono i cosiddetti «contenitori effimeri» (Contenitori effimeri), progettato per semplificare i processi di debug nei pod. Il nuovo meccanismo consente di eseguire contenitori speciali che iniziano nello spazio dei nomi dei pod esistenti e restano attivi per un breve periodo. Il loro scopo è quello di interagire con altri pod e container al fine di risolvere eventuali problemi ed eseguire il debug. È stato implementato un nuovo comando per questa funzione kubectl debug, simile in sostanza a kubectl exec: solo invece di eseguire un processo in un contenitore (come nel caso exec) avvia il contenitore nel pod. Ad esempio, questo comando collegherà un nuovo contenitore a un pod:

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

I dettagli sui contenitori temporanei (ed esempi su come utilizzarli) sono disponibili in KPE corrispondente. L'attuale implementazione (in K8s 1.16) è una versione alpha e tra i criteri per la sua transizione a una versione beta c'è "testare l'API Ephemeral Containers per almeno 2 versioni [Kubernetes]".

NB: Nella sua essenza e anche il nome della funzione ricorda un plugin esistente kubectl-debugdi cui noi già scritto. Si presume che con l'avvento dei contenitori temporanei, lo sviluppo di un plug-in esterno separato si interromperà.

Un'altra innovazione - PodOverhead - destinato a fornire meccanismo di calcolo dell'overhead del pod, che può essere molto diverso a seconda dell'ambiente eseguibile (runtime) utilizzato. Ad esempio, gli autori questo kep citare i contenitori Kata, che richiedono che il kernel guest, l'agente kata, il sistema init, ecc. siano in esecuzione. Quando l'overhead diventa così grande, non può essere ignorato, il che significa che deve esserci un modo per tenerne conto per ulteriori quotazioni, programmazione, ecc. Per la sua implementazione in PodSpec campo aggiunto Overhead *ResourceList (confrontare con i dati in RuntimeClass, se ne viene utilizzato uno).

Un'altra notevole innovazione è gestore della topologia dei nodi (Gestore della topologia dei nodi), progettato per unificare l'approccio alla messa a punto della distribuzione delle risorse hardware per vari componenti in Kubernetes. Questa iniziativa è causata dalla crescente necessità di vari sistemi moderni (dal campo delle telecomunicazioni, dell'apprendimento automatico, dei servizi finanziari, ecc.) per il calcolo parallelo ad alte prestazioni e la riduzione al minimo dei ritardi nell'esecuzione delle operazioni, per le quali utilizzano CPU avanzate e funzionalità di accelerazione hardware. Tali ottimizzazioni in Kubernetes sono state finora ottenute grazie a componenti disparati (CPU manager, Device manager, CNI), e ora aggiungeranno un'unica interfaccia interna che unifica l'approccio e semplifica la connessione di nuovi simili - i cosiddetti topology-aware - componenti lato Kubelet. Dettagli - dentro KPE corrispondente.

Diagramma dei componenti di Topology Manager

La caratteristica successiva è controllare i contenitori mentre sono in funzione (sonda di avvio). Come sapete, per i container che impiegano molto tempo per essere lanciati, è difficile ottenere uno stato aggiornato: o vengono "uccisi" anche prima che inizino effettivamente a funzionare, oppure rimangono in una situazione di stallo per molto tempo . Nuovo controllo (abilitato tramite un feature gate chiamato StartupProbeEnabled) annulla, o meglio, ritarda, qualsiasi altro controllo finché il pod non ha terminato l'esecuzione. Per questo motivo, la funzionalità è stata originariamente chiamata holdoff della sonda di attività del pod-startup. Per i pod che richiedono molto tempo per l'avvio, puoi eseguire il polling dello stato a intervalli di tempo relativamente brevi.

Inoltre, viene introdotto immediatamente un miglioramento per RuntimeClass in stato beta, aggiungendo il supporto per "cluster eterogenei". C Pianificazione RuntimeClass ora non è affatto necessario che ogni nodo abbia il supporto per ogni RuntimeClass: per i pod, puoi scegliere RuntimeClass senza pensare alla topologia del cluster. In precedenza, per raggiungere questo obiettivo, in modo che i pod finissero su nodi con supporto per tutto ciò di cui avevano bisogno, dovevi assegnare le regole appropriate a NodeSelector e alle tolleranze. IN KEP parla di esempi di utilizzo e, naturalmente, dettagli di implementazione.

Rete

Due funzionalità di rete significative che sono apparse per la prima volta (in versione alpha) in Kubernetes 1.16 sono:

Sostegno doppio stack di rete - IPv4/IPv6 - e la sua corrispondente "comprensione" a livello di pod, nodi, servizi. Include l'interazione da IPv4 a IPv4 e da IPv6 a IPv6 tra i pod, dai pod ai servizi esterni, le implementazioni di riferimento (all'interno dei plug-in Bridge CNI, PTP CNI e Host-Local IPAM), nonché la compatibilità inversa con i cluster Kubernetes in esecuzione solo su IPv4 o IPv6. I dettagli di implementazione sono disponibili KEP.
Un esempio di visualizzazione di due tipi di indirizzi IP (IPv4 e IPv6) nell'elenco dei pod:
```
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#
```
Nuova API per endpoint - API EndpointSlice. Risolve i problemi di prestazioni/scalabilità dell'API Endpoint esistente che interessano vari componenti nel piano di controllo (apiserver, etcd, endpoint-controller, kube-proxy). La nuova API verrà aggiunta al gruppo Discovery API e sarà in grado di servire decine di migliaia di endpoint back-end su ciascun servizio in un cluster composto da un migliaio di nodi. Per fare ciò, ogni Servizio è mappato su N oggetti EndpointSlice, ognuno dei quali non ha più di 100 endpoint per impostazione predefinita (il valore è configurabile). L'API EndpointSlice fornirà anche opportunità per il suo sviluppo futuro: supporto per più indirizzi IP per ogni pod, nuovi stati per gli endpoint (non solo Ready и NotReady), sottoinsiemi dinamici per gli endpoint.

Quello presentato nell'ultima release è avanzato alla versione beta finalizzatore, di nome service.kubernetes.io/load-balancer-cleanup e allegato a ciascun servizio con tipo LoadBalancer. Al momento della rimozione di tale servizio, impedisce l'effettiva rimozione della risorsa fino al completamento della "pulizia" di tutte le risorse rilevanti del bilanciatore.

Macchinari API

La vera "pietra miliare della stabilizzazione" è nell'area del server API Kubernetes e nell'interazione con esso. Ciò era in gran parte dovuto a passaggio allo stato di stabile che non necessita di particolari presentazioni CustomResourceDefinitions (CRD), che hanno avuto lo stato beta dal lontano Kubernetes 1.7 (e questo è giugno 2017!). La stessa stabilizzazione è arrivata alle funzionalità correlate:

"sottorisorse" (sottorisorse) con /status и /scale per Risorse personalizzate;
преобразование versioni per CRD basate su un webhook esterno;
recentemente introdotto (in K8s 1.15) valori predefiniti (inadempiente) e cancellazione automatica dei campi (potatura) per Risorse personalizzate;
opportunità utilizzando lo schema OpenAPI v3 per creare e pubblicare la documentazione OpenAPI utilizzata per convalidare le risorse CRD sul lato server.

Un altro meccanismo che è diventato familiare da tempo agli amministratori di Kubernetes: webhook di ammissione - è stato anche in stato beta per molto tempo (da K8s 1.9) ed è ora dichiarato stabile.

Altre due funzionalità hanno raggiunto la versione beta: si applicano lato server и guarda i segnalibri.

E l'unica innovazione significativa nella versione alfa era fallimento от SelfLink — un URI speciale che rappresenta l'oggetto specificato e ne fa parte ObjectMeta и ListMeta (ovvero parte di qualsiasi oggetto in Kubernetes). Perché lo rifiutano? Motivazione "in modo semplice" suoni come l'assenza di ragioni reali (irresistibili) per cui questo campo esiste ancora. Le ragioni più formali sono per ottimizzare le prestazioni (rimuovendo un campo non necessario) e per semplificare il lavoro di generic-apiserver, che è costretto a gestire tale campo in un modo speciale (questo è l'unico campo che viene impostato subito prima che l'oggetto sia serializzato). Vera "obsolescenza" (sotto beta) SelfLink avverrà entro Kubernetes 1.20 e quello finale sarà 1.21.

Archiviazione dei dati

Il lavoro principale nell'area di stoccaggio, come nelle versioni precedenti, è osservato nell'area Supporto CSI. Le principali modifiche qui sono:

per la prima volta (in versione alpha) apparso supporto per i plug-in CSI per i nodi di lavoro Windows: l'attuale modo di lavorare con gli archivi sostituirà anche i plug-in in-tree nel core Kubernetes e i plug-in FlexVolume di Microsoft basati su Powershell;

Implementazione Kubernetes per Windows dei plug-in CSI
opportunità ridimensionamento dei volumi CSI, introdotto in K8s 1.12, è diventato beta;
una simile "elevazione" (da alfa a beta) è stata raggiunta dalla capacità di utilizzare CSI per creare volumi effimeri locali (Supporto volume in linea CSI).

Introdotto nella versione precedente di Kubernetes funzione di clonazione del volume (utilizzando PVC esistenti come DataSource per creare nuovi PVC) è ora in stato beta.

Pianificatore

Due importanti modifiche alla pianificazione (entrambe in versione alpha):

EvenPodsSpreading - opportunità utilizzare i pod invece delle unità logiche dell'applicazione per una "equa distribuzione" dei carichi (come Deployment e ReplicaSet) e regolando questa distribuzione (come requisito rigido o come condizione flessibile, ovvero priorità). La funzione espanderà le opzioni di distribuzione esistenti per i pod pianificati, attualmente limitate alle opzioni PodAffinity и PodAntiAffinity, offrendo agli amministratori un controllo più granulare in questa materia, il che significa una migliore disponibilità elevata e un consumo di risorse ottimizzato. Dettagli - dentro KEP.
l'uso di Politica BestFit в Funzione di priorità RequestedToCapacityRatio durante la programmazione del pod, che consentirà applicare imballaggio del bidone ("impacchettamento in contenitori") sia per le risorse di base (processore, memoria) che per quelle estese (come la GPU). Per i dettagli vedere KEP.

Pianificazione pod: prima di utilizzare la policy best fit (direttamente tramite lo scheduler predefinito) e di utilizzarla (tramite l'estensione dello scheduler)

Inoltre, представлена la possibilità di creare i propri plug-in per lo scheduler al di fuori dell'albero di sviluppo principale di Kubernetes (out-of-tree).

Altre modifiche

Anche nel rilascio di Kubernetes 1.16, puoi notare iniziativa su portando metriche disponibili in ordine completo, o più precisamente, in accordo con regolamenti ufficiali alla strumentazione del K8. Si basano in gran parte sui rispettivi Documentazione Prometeo. Le incoerenze sono sorte per vari motivi (ad esempio, alcune metriche sono state semplicemente create anche prima che apparissero le istruzioni attuali) e gli sviluppatori hanno deciso che era ora di portare tutto a un unico standard, "in linea con il resto dell'ecosistema Prometheus". L'attuale implementazione di questa iniziativa è alfa e verrà progressivamente aggiornata a beta (1.17) e stabile (1.18) nelle future versioni di Kubernetes.

Inoltre, si possono notare le seguenti modifiche:

Sviluppo del supporto di Windows с l'avvento di Utilità Kubeadm per questo sistema operativo (versione alpha), l'opportunità RunAsUserName per i contenitori Windows (versione alpha), miglioramento Supporto dell'account di servizio gestito di gruppo (gMSA) fino alla versione beta, supporto montaggio/collegamento per volumi vSphere.
riciclato meccanismo di compressione dei dati nelle risposte API. In precedenza, per questi scopi veniva utilizzato un filtro HTTP, che imponeva una serie di restrizioni che ne impedivano l'inclusione per impostazione predefinita. Ora la "compressione delle richieste trasparenti" funziona: i client inviano Accept-Encoding: gzip nell'intestazione riceve una risposta compressa GZIP se la sua dimensione supera i 128 KB. I client Go supportano automaticamente la compressione (invia l'intestazione corretta), quindi noteranno immediatamente una diminuzione del traffico. (Potrebbero essere necessarie lievi modifiche per altre lingue.)
È diventato possibile scalare l'HPA da/a zero pod in base a metriche esterne. Se il ridimensionamento è basato su oggetti/metriche esterne, quando i carichi di lavoro sono inattivi, puoi ridimensionare automaticamente a 0 repliche per risparmiare risorse. Questa funzione dovrebbe essere particolarmente utile nei casi in cui i lavoratori richiedono risorse GPU e il numero di diversi tipi di lavoratori inattivi supera il numero di GPU disponibili.
Nuovo cliente - k8s.io/client-go/metadata.Client - per l'accesso "generalizzato" agli oggetti. È progettato per recuperare facilmente i metadati (ad esempio subsection metadata) dalle risorse del cluster ed eseguire operazioni con esse dalla categoria Garbage Collection e quota.
Crea Kubernetes ora possibile senza provider cloud obsoleti ("incorporati" nell'albero) (versione alpha).
All'utilità kubeadm aggiunto capacità sperimentale (alfa) di applicare patch personalizzate durante le operazioni init, join и upgrade. Ulteriori informazioni su come utilizzare la bandiera --experimental-kustomize, vedi dentro KEP.
Nuovo endpoint per apiserver - readyz, - consente di esportare informazioni sulla sua prontezza (prontezza). Inoltre, il server API ha un flag --maximum-startup-sequence-duration, permettendoti di controllarne i riavvii.
due funzionalità per Azure dichiarato stabile: supporto zone di disponibilità (Zone di disponibilità) e gruppo di risorse incrociate (RG). Inoltre, Azure ha aggiunto:
- supporto per l'autenticazione AAD e ADFS;
- astratto service.beta.kubernetes.io/azure-pip-name per specificare l'IP pubblico del bilanciamento del carico;
- opportunità настройки LoadBalancerName и LoadBalancerResourceGroup.
AWS ha sostegno per EBS su Windows e ottimizzato Chiamate API EC2 DescribeInstances.
Kubeadm ora è da solo migra Configurazione CoreDNS durante l'aggiornamento della versione CoreDNS.
Binari etcd nell'immagine Docker corrispondente ho fatto world-executable, che consente di eseguire questa immagine senza la necessità dei privilegi di root. Inoltre, l'immagine di migrazione etcd cessato supporto per la versione etcd2.
В Scalatore automatico di cluster 1.16.0 passato all'utilizzo distroless come immagine di base, prestazioni migliorate, aggiunta di nuovi fornitori di servizi cloud (DigitalOcean, Magnum, Packet).
Aggiornamenti nel software utilizzato/dipendente: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

Kubernetes 1.16: punti salienti delle novità