🥇Kubernetes 1.16: panoramica delle principali novità

Oggi, mercoledì, si terrà è stato rilasciato un nuovo aggiornamento di Kubernetes — 1.16. Secondo la tradizione del nostro blog, per la decima volta raccontiamo le modifiche più significative della nuova versione.

Le informazioni utilizzate per preparare questo materiale provengono da tabella di monitoraggio dei miglioramenti di Kubernetes, CHANGELOG-1.16 e le relative issue, pull request e Kubernetes Enhancement Proposals (KEP). Quindi, cominciamo!..

Nodi

Un numero notevole di nuove funzionalità (in stato alpha) è stato introdotto per i nodi dei cluster K8s (Kubelet).

Innanzitutto, sono stati presentati i cosiddetti «contenitori effimeri» (Ephemeral Containers), progettati per semplificare i processi di debugging nei pod.Il nuovo meccanismo consente di avviare contenitori speciali, che si avviano nello spazio dei nomi dei pod esistenti e vivono per un breve periodo. Il loro scopo è interagire con altri pod e contenitori per risolvere eventuali problemi e per il debugging. Per questa funzionalità è stata implementata una nuova comando kubectl debug, simile a kubectl exec: solo che invece di avviare un processo nel contenitore (come nel caso exec) avvia un contenitore nel pod. Ad esempio, il seguente comando collegherà un nuovo contenitore al pod:

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

Puoi trovare dettagli sui container effimeri (e esempi del loro utilizzo) in KEP corrispondente. L'attuale implementazione (in K8s 1.16) è in versione alpha e tra i criteri per la sua transizione in versione beta c'è «testare l'API dei container effimeri per almeno 2 rilasci [Kubernetes]».

NB: Fondamentalmente, la funzionalità ricorda un plugin già esistente kubectl-debug, di cui noi abbiamo già parlato. Si prevede che con l'arrivo dei container effimeri lo sviluppo di un plugin esterno separato si interrompa.

Un'altra novità è PodOverhead — progettata per fornire un meccanismo per il calcolo dei costi sui pod, che possono variare notevolmente a seconda dell'ambiente di esecuzione utilizzato (runtime). Come esempio, gli autori di questo KEP citano Kata Containers, che richiedono l'avvio di un kernel guest, di un agente kata, di un sistema init, ecc. Quando il sovraccarico diventa così elevato, non può essere ignorato, il che significa che è necessario un modo per considerarlo per ulteriori quote, pianificazioni, ecc. Per la sua implementazione, in PodSpec è stato aggiunto il campo Overhead *ResourceList (corrispondente ai dati in RuntimeClass, se applicabile).

Un'altra innovazione significativa è manager della topologia del nodo (Node Topology Manager), progettato per unificare l'approccio alla configurazione fine della distribuzione delle risorse hardware per diversi componenti in Kubernetes. Questa iniziativa è stata motivata dalla crescente necessità di vari sistemi moderni (nel campo delle telecomunicazioni, dell'apprendimento automatico, dei servizi finanziari, ecc.) di calcoli paralleli ad alte prestazioni e di minimizzazione delle latenze durante l'esecuzione delle operazioni, per cui sfruttano le avanzate capacità della CPU e dell'accelerazione hardware. Tali ottimizzazioni in Kubernetes sono state finora raggiunte attraverso componenti disparati (CPU manager, Device manager, CNI), e ora verrà introdotto un'interfaccia interna unificata che standardizzerà l'approccio e semplificherà l'integrazione di nuovi componenti simili — i cosiddetti componenti sensibili alla topologia — sul lato di Kubelet. Maggiori dettagli — in KEP corrispondente.

Schema dei componenti del Topology Manager

La prossima funzionalità — controllo dei contenitori al momento del loro avvio (startup probe). Come è noto, ottenere lo stato attuale per i container che impiegano molto tempo a partire è difficile: vengono 'terminati' prima dell'effettivo avvio o possono rimanere a lungo in deadlock. Un nuovo controllo (attivato tramite un feature gate chiamato StartupProbeEnabled) annulla — o meglio, posticipa — l'azione di qualsiasi altro controllo fino a quando il pod ha completato il suo avvio. Per questo motivo, la funzione è stata inizialmente chiamata pod-startup liveness-probe holdoff. Per i pod che impiegano molto tempo a partire, è possibile effettuare controlli di stato a intervalli di tempo relativamente brevi.

Inoltre, è stata presentata immediatamente in stato beta un'ottimizzazione per RuntimeClass, che aggiunge supporto per 'cluster eterogenei'. Con RuntimeClass Scheduling non è più necessario che ogni nodo supporti ogni RuntimeClass: per i pod è possibile selezionare il RuntimeClass, senza preoccuparsi della topologia del cluster. In precedenza, per ottenere questo — affinché i pod fossero posizionati su nodi con il supporto necessario — era necessario impostare regole appropriate su NodeSelector e tolerations. In KEP si parla di esempi di utilizzo e, naturalmente, di dettagli di implementazione.

Rete

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

Supporto doppio stack di rete — IPv4/IPv6 — e la relativa "comprensione" a livello di pod, nodi e servizi. Questo include l'interazione IPv4-to-IPv4 e IPv6-to-IPv6 tra i pod, dai pod a servizi esterni, implementazioni di riferimento (nel contesto dei plugin Bridge CNI, PTP CNI e Host-Local IPAM), nonché la retrocompatibilità con cluster Kubernetes operanti solo su IPv4 o IPv6. Maggiori dettagli sull'implementazione sono disponibili in KEP.
Esempio di output degli indirizzi IP di due tipi (IPv4 e IPv6) nella lista 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#
```
Nuovo API per Endpoint — EndpointSlice API. Risolve i problemi dell'attuale Endpoint API in termini di prestazioni/scalabilità, che coinvolgono vari componenti nel control-plane (apiserver, etcd, endpoints-controller, kube-proxy). Il nuovo API sarà aggiunto al gruppo API Discovery e sarà in grado di gestire decine di migliaia di backend endpoint per ogni servizio in un cluster composto da migliaia di nodi. A tal fine, ogni servizio verrà visualizzato in N oggetti EndpointSlice, ognuno dei quali ha per impostazione predefinita un massimo di 100 endpoint (valore configurabile). L'API EndpointSlice prevede anche possibilità per il suo futuro sviluppo: supporto per più indirizzi IP per ogni pod, nuovi stati per gli endpoint (non solo Pronto e NonPronto), subsetting dinamico per gli endpoint.

Fino alla versione beta è avanzato quanto presentato nell'ultimo rilascio finalizer, chiamato service.kubernetes.io/load-balancer-cleanup e allegato a ogni servizio di tipo LoadBalancer. Durante l'eliminazione di tale servizio, impedisce l'effettiva eliminazione della risorsa fino al termine della "pulizia" di tutte le risorse associate al bilanciatore.

API Machinery

Questa "pietra miliare di stabilizzazione" è stata registrata nell'area del server API di Kubernetes e della sua interazione. Gran parte di ciò è avvenuto grazie alla conversione in stato stabile di risorse che non necessitano di una particolare presentazione CustomResourceDefinitions (CRD), che avevano lo stato di beta da quando Kubernetes 1.7 (giugno 2017!). La stessa stabilizzazione è arrivata anche alle funzionalità correlate:

"sotto-risorse" (subresources) e /status e /scale per CustomResources;
trasformazione versioni per CRD, basate su un webhook esterno;
recentemente presentati (in K8s 1.15) valori predefiniti (defaulting) e la rimozione automatica dei campi (potatura) per CustomResources;
possibilità l'adozione dello schema OpenAPI v3 per la creazione e pubblicazione della documentazione OpenAPI, utilizzata per la convalida delle risorse CRD lato server.

Un altro meccanismo, ormai familiare per gli amministratori di Kubernetes: admission webhook è rimasto per lungo tempo in stato beta (dalla versione K8s 1.9) ed è ora dichiarato stabile.

Due altre funzionalità hanno raggiunto la versione beta: server-side apply e watch bookmarks.

E l'unica novità significativa nell'alpha è stata il rifiuto da SelfLink è un URI speciale che rappresenta l'oggetto specificato ed è parte di ObjectMeta e ListMeta (cioè parte di qualsiasi oggetto in Kubernetes). Perché se ne fa a meno? La motivazione 'in modo semplice' è come l'assenza di vere (insormontabili) ragioni affinché questo campo continui a esistere. Motivi più formali includono l'ottimizzazione delle prestazioni (rimuovendo un campo non necessario) e semplificare il lavoro del generic-apiserver, che è costretto a gestire tale campo in modo speciale (è l'unico campo impostato proprio prima della serializzazione dell'oggetto). Il vero 'deprecamento' (nella versione beta) SelfLink avverrà con la versione Kubernetes 1.20, e definitivo — 1.21.

Archiviazione dei dati

Il lavoro principale nel settore dello storage, come nelle versioni precedenti, si osserva nell'ambito del supporto CSI. Le principali novità sono state:

per la prima volta (nella versione alpha) è stata introdotta supporto ai plugin CSI per i nodi di lavoro con Windows: il modo attuale di operare con gli archivi sostituirà i plugin in-tree nel kernel di Kubernetes e i plugin FlexVolume di Microsoft basati su Powershell;

Schema di implementazione dei plugin CSI in Kubernetes per Windows
possibilità ridimensionamento dei volumi CSI, presentato già in K8s 1.12, è arrivato alla versione beta;
un analogo 'passaggio' (da alpha a beta) è stato raggiunto dalla possibilità di utilizzare CSI per creare volumi effimeri locali (Supporto ai volumi inline CSI).

Introdotta nella versione precedente di Kubernetes la funzione di clonazione dei volumi (utilizzando PVC esistenti come DataSource per creare nuovi PVC) ha ora ricevuto anche lo stato di versione beta.

Pianificatore

Due importanti cambiamenti nella pianificazione (entrambi in versione alpha):

EvenPodsSpreading — la possibilità di utilizzare i pod al posto delle unità logiche dell'app per una 'distribuzione giusta' dei carichi (come Deployment e ReplicaSet) e le regolazioni di questa distribuzione (come requisiti rigidi o condizioni flessibili, ovvero priorità). La funzionalità amplierà le attuali capacità di distribuzione dei pod pianificati, attualmente limitate dalle opzioni PodAffinity e PodAntiAffinity, fornendo agli amministratori un controllo più fine su questo aspetto, il che significa una maggiore alta disponibilità e un consumo ottimizzato delle risorse. Maggiori dettagli sono disponibili in KEP.
L'utilizzo di BestFit Policy in RequestedToCapacityRatio Priority Function durante la pianificazione dei pod, il che consentirà applicare bin packing («imballaggio in contenitori») sia per le risorse principali (CPU, memoria) che per quelle avanzate (come GPU). Maggiori informazioni sono disponibili in KEP.

Pianificazione dei pod: prima dell'uso della best fit policy (direttamente attraverso il programmatore predefinito) e con il suo utilizzo (attraverso il programmatore extender)

Inoltre, è stata presentata la possibilità di creare i propri plugin per il programmatore al di fuori del principale albero di sviluppo di Kubernetes (out-of-tree).

Altre modifiche

Inoltre, nella versione Kubernetes 1.16, è possibile notare l'iniziativa per riordinare le metriche esistenti, per essere più precisi — in conformità con le normative ufficiali per l'instradamento di K8s. Si basano fondamentalmente sulla corrispondente documentazione di Prometheus. Le discrepanze sono emerse per vari motivi (ad esempio, alcune metriche sono state semplicemente create prima che le attuali istruzioni fossero disponibili), e gli sviluppatori hanno deciso che era giunto il momento di portare tutto a uno standard uniforme, "in linea con il resto dell'ecosistema Prometheus". L'attuale implementazione di questa iniziativa è in fase alfa, che verrà progressivamente elevata nelle versioni future di Kubernetes alla beta (1.17) e stabile (1.18).

Inoltre, si possono notare i seguenti cambiamenti:

Sviluppo del supporto per Windows con per l'introduzione utilità Kubeadm per questo SO (versione alfa), possibilità di RunAsUserName per i contenitori Windows (versione alfa), miglioramento del supporto per Group Managed Service Account (gMSA) fino alla versione beta, supporto mount/attach per i volumi vSphere.
Meccanismo rielaborato di compressione dei dati nelle risposte API. In precedenza, per questi scopi veniva utilizzato un filtro HTTP, che imponeva alcune limitazioni, impedendone l'attivazione di default. Ora funziona "compressione trasparente delle richieste": i client che inviano Accept-Encoding: gzip nell'intestazione, ottengono una risposta compressa in GZIP se la sua dimensione supera 128 KB. I clienti su Go supportano automaticamente la compressione (inviando l'intestazione necessaria), quindi noteranno immediatamente una riduzione del traffico. (Per altre lingue potrebbero essere necessarie piccole modifiche.)
È diventato possibile scalare HPA da/a zero pod in base a metriche esterne. Se la scalabilità avviene sulla base di oggetti/metriche esterne, quando i carichi di lavoro sono inattivi, è possibile scalare automaticamente a 0 repliche per risparmiare risorse. Questa funzione risulta particolarmente utile nei casi in cui i worker richiedono risorse GPU e il numero di diversi tipi di worker inattivi supera la quantità disponibile di GPU.
Nuovo client — k8s.io/client-go/metadata.Client — per l'accesso 'generalizzato' agli oggetti. È progettato per ottenere facilmente metadati (cioè elementi metadata) dalle risorse del cluster e svolgere operazioni come raccolta rifiuti e quotazione.
Raccogliere Kubernetes ora può senza provider cloud obsoleti ('integrati' in tree) (versione alfa).
Nell'utility kubeadm è stato aggiunto la possibilità sperimentale (versione alpha) di applicare patch kustomize durante le operazioni init, join e aggiornamento. Maggiori informazioni su come utilizzare il flag --experimental-kustomize, consultare KEP.
Il nuovo endpoint per apiserver — readyz, — che consente di esportare informazioni sulla sua prontezza (readiness). Inoltre, l'API server ha ora il flag --maximum-startup-sequence-duration, che consente di regolare i suoi riavvii.
Due funzionalità per Azure sono state dichiarate stabili: supporto per zone di disponibilità (Availability Zones) e cross resource group (RG). Inoltre, Azure ha aggiunto:
- supporto per l'autenticazione AAD e ADFS;
- annotazione service.beta.kubernetes.io/azure-pip-name per specificare l'IP pubblico del bilanciatore di carico;
- possibilità le impostazioni LoadBalancerName e LoadBalancerResourceGroup.
AWS ha aggiunto supporto per EBS in Windows e ottimizzati chiamate API EC2 DescribeInstances.
Kubeadm ora migra autonomamente la configurazione di CoreDNS durante l'aggiornamento della versione di CoreDNS. конфигурацию CoreDNS при обновлении версии CoreDNS.
I binari etcd nella corrispondente immagine Docker sono stati resi world-executable, il che consente di eseguire questa immagine senza necessità di privilegi di root. Inoltre, l'immagine di migrazione etcd cessato supporta la versione etcd2.
In Cluster Autoscaler 1.16.0 abbiamo adottato l'uso di immagini distroless come base, migliorato le prestazioni e aggiunto nuovi fornitori di cloud (DigitalOcean, Magnum, Packet).
Aggiornamenti nel software utilizzato / dipendente: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

P.S.

Leggete anche nel nostro blog:

Fonte: habr.com

Kubernetes 1.16: panoramica delle principali novità