🥇Kubernetes 1.16: panoramica delle principali novità

Oggi, mercoledì, si svolgerà un altro rilascio di Kubernetes — 1.16. Seguendo la tradizione del nostro blog, per la decima volta parliamo delle modifiche più significative della nuova versione.

Le informazioni utilizzate per preparare questo materiale provengono da tabella di tracciamento dei miglioramenti di Kubernetes, CHANGELOG-1.16 e dalle relative issue, pull request, così come dalle proposte di miglioramento di Kubernetes (KEP). Quindi, cominciamo!..

Nodi

Un numero davvero considerevole di nuove funzionalità (in stato di alpha) è stato presentato sul lato dei nodi dei cluster K8s (Kubelet).

Innanzitutto, sono stati introdotti i cosiddetti «container effimeri» (Ephemeral Containers), progettati per semplificare i processi di debug nei pod. Il nuovo meccanismo consente di avviare container speciali che si avviano nello spazio dei nomi dei pod esistenti e vivono per un breve periodo di tempo. La loro funzione è quella di interagire con altri pod e container per risolvere problemi e fare debugging. Per questa funzionalità è stato implementato un nuovo comando kubectl debug, simile nel suo funzionamento a kubectl exec: solo che invece di avviare un processo all'interno del container (come nel caso di exec) avvia un container nel pod. Ad esempio, questo comando collegherà un nuovo container al pod:

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

I dettagli sui container effimeri (e gli esempi del loro utilizzo) possono essere trovati nel Kep corrispondente. L'attuale implementazione (in K8s 1.16) è in alpha, e tra i criteri per il suo passaggio in beta c'è "il collaudo dell'API dei container effimeri per almeno 2 rilasci [Kubernetes]".

NB: Per sua natura e anche nel nome, la funzione ricorda già un plugin esistente kubectl-debug, di cui abbiamo già parlato. Si prevede che con l'introduzione dei container effimeri lo sviluppo del plugin esterno separato cesserà.

Un'altra novità — PodOverhead — è progettata per fornire un meccanismo di calcolo dei costi per i pod, che possono variare notevolmente a seconda dell'ambiente di esecuzione utilizzato (runtime). Come esempio, gli autori di questo KEP citano i Kata Containers, che richiedono l'esecuzione di un kernel guest, dell'agente kata, di un sistema init, ecc. Quando l'overhead diventa così elevato, non può essere ignorato, e ciò significa che è necessario un modo per tenerlo in considerazione per il successivo quota, pianificazione, ecc. Per la sua implementazione, nel PodSpec è stato aggiunto un campo Overhead *ResourceList (corrisponde ai dati in RuntimeClass, se presente).

Un'altra innovazione notevole è il gestore della topologia dei nodi (Node Topology Manager), concepito per unificare l'approccio alla fine-tuning della distribuzione delle risorse hardware per i diversi componenti in Kubernetes. Questa iniziativa è stata avviata dalla crescente richiesta di sistemi moderni (nei settori delle telecomunicazioni, dell'apprendimento automatico, dei servizi finanziari, ecc.) per calcoli paralleli ad alte prestazioni e per minimizzare i ritardi nell'esecuzione delle operazioni, utilizzando le capacità avanzate delle CPU e l'accelerazione hardware. Tali ottimizzazioni in Kubernetes sono state raggiunte fino ad ora grazie a componenti disparati (CPU manager, Device manager, CNI), e ora verrà aggiunto un'interfaccia interna unica che unificherà l'approccio e semplificherà l'integrazione di nuovi componenti simili - così detti topology-aware - dal lato di Kubelet. Maggiori dettagli sono disponibili in Kep corrispondente.

Schema dei componenti del Topology Manager

La prossima funzionalità è il controllo dei contenitori durante il loro avvio (startup probe). Come noto, per i contenitori che richiedono molto tempo per avviarsi, è difficile ottenere uno stato aggiornato: o vengono 'terminati' prima di iniziare a funzionare realmente, oppure rimangono a lungo in deadlock. La nuova verifica (attivata tramite il feature gate chiamato StartupProbeEnabled) annulla - più precisamente, rinvia - l'attivazione di qualsiasi altro controllo fino a quando il pod ha terminato il suo avvio. Per questa ragione, la funzionalità è stata inizialmente chiamata pod-startup liveness-probe holdoff. Per i pod che richiedono molto tempo per avviarsi, è possibile effettuare verifiche di stato a intervalli temporali relativamente brevi.

Inoltre, è stata introdotta in fase beta un miglioramento per RuntimeClass, che aggiunge supporto per 'cluster eterogenei'. Con RuntimeClass Scheduling ora non è più necessario che ogni nodo supporti ogni RuntimeClass: per i pod è possibile scegliere RuntimeClass senza preoccuparsi della topologia del cluster. In precedenza, per raggiungere questo obiettivo - affinché i pod venissero eseguiti su nodi che supportano tutto ciò di cui hanno bisogno - era necessario impostare regole corrispondenti su NodeSelector e tolerations. Nel KEP viene discusso esempi di utilizzo e, ovviamente, dettagli di implementazione.

Rete

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

Supporto il doppio stack di rete - IPv4/IPv6 e la sua corrispondente "comprensione" a livello di pod, nodi e servizi. Essa comprende l'interazione da IPv4 a IPv4 e da IPv6 a IPv6 tra pod, dai pod ai servizi esterni, implementazioni di riferimento (nell'ambito dei plugin Bridge CNI, PTP CNI e Host-Local IPAM), così come la retrocompatibilità con i cluster Kubernetes che funzionano solo su IPv4 o IPv6. I dettagli dell'implementazione sono 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
NOME               PRONTO     STATO    RIAVVI FONTI   ETÀ       IP                          NODO
nginx-controller   1/1       In esecuzione   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 API Endpoint con prestazioni/scalabilità che interessano 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 endpoint backend per ogni servizio nel cluster, composto da migliaia di nodi. Per questo, ogni Servizio verrà mappato in N oggetti EndpointSlice, ognuno dei quali per impostazione predefinita ha al massimo 100 endpoint (il valore è configurabile). Nell'API EndpointSlice saranno previste anche possibilità per il 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'ultima versione finalizer, denominato service.kubernetes.io/load-balancer-cleanup e allegato a ogni servizio di tipo LoadBalancer. Al momento della rimozione di tale servizio, impedisce la reale rimozione della risorsa, finché non è completata la "pulizia" di tutte le risorse correlate del bilanciatore.

API Machinery

Una vera e propria "pietra miliare di stabilizzazione" è stata registrata nell'area dell'API server di Kubernetes e della sua interazione. Gran parte di questo è avvenuto grazie al passaggio allo stato stabile di risorse che non necessitano di rappresentazione particolare CustomResourceDefinitions (CRD), che avevano lo stato beta fin dai tempi remoti di Kubernetes 1.7 (giugno 2017!). La stessa stabilizzazione è avvenuta anche per le funzionalità collegate:

"sotto-risorse" (subresources) per /status e /scale CustomResources;
conversione di versioni per CRD, basata su un webhook esterno;
recentemente presentati (in K8s 1.15) valori predefiniti (defaulting) e rimozione automatica di campi (pruning) CustomResources;
la possibilità applicazione dello schema OpenAPI v3 per la creazione e pubblicazione della documentazione OpenAPI utilizzata per la validazione delle risorse CRD lato server.

Un altro meccanismo, che è diventato familiare per gli amministratori di Kubernetes: admission webhook è rimasto a lungo in fase beta (con K8s 1.9) ed è ora stato dichiarato stabile.

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

E l'unica significativa innovazione nella versione alpha è stata la rimozione di SelfLink un URI speciale che rappresenta l'oggetto specificato ed è parte di ObjectMeta e ListMeta (cioè parte di qualsiasi oggetto in Kubernetes). Perché viene rimosso? La motivazione "in parole semplici" suona come l'assenza di motivi reali (irresistibili) affinché questo campo continui a esistere. Motivi più formali — ottimizzare le prestazioni (rimuovendo campi non necessari) e semplificare il lavoro del generic-apiserver, che deve gestire tale campo in modo particolare (è l'unico campo che viene impostato proprio prima della serializzazione dell'oggetto). La vera "obsolescenza" (all'interno della versione beta) SelfLink si verificherà con la versione Kubernetes 1.20, e quella definitiva — 1.21.

Archiviazione dati

Il lavoro principale nel campo dello storage, come nelle versioni precedenti, si osserva nell'area supporto CSI. Le principali modifiche qui sono state:

per la prima volta (nella versione alpha) è comparso supporto ai plugin CSI per i nodi di lavoro su Windows: un modo attuale di lavorare con gli storage e qui soppianta 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
la possibilità ridimensionamento dei volumi CSI, presentato già in K8s 1.12, ha raggiunto la versione beta;
una simile "promozione" (da alpha a beta) ha raggiunto la possibilità di utilizzare CSI per creare volumi ephemeral locali (CSI Inline Volume Support).

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

Pianificatore

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

EvenPodsSpreading la possibilità di utilizzare i pod al posto delle unità logiche delle applicazioni per una "distribuzione equa" dei carichi (come Deployment e ReplicaSet) e regolare questa distribuzione (come una condizione rigida o come una condizione morbida, cioè una priorità). Questa funzione allargherà le capacità esistenti per la 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 migliore alta disponibilità e un consumo ottimizzato delle risorse. Maggiori dettagli - in KEP.
Utilizzo Politica BestFit in Funzione di priorità RequestedToCapacityRatio durante la pianificazione dei pod, permettendo di applicare bin packing («imballaggio in contenitori») sia per le risorse principali (processore, memoria) che per quelle avanzate (come le GPU). Maggiori dettagli in KEP.

Pianificazione dei pod: prima dell'uso della best fit policy (direttamente tramite il default scheduler) e con il suo utilizzo (tramite lo scheduler extender)

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

Altre modifiche

Si segnala inoltre nella release di Kubernetes 1.16 l'iniziativa per mettere in ordine le metriche esistenti, per essere più precisi - in conformità con le normative ufficiali per l' instrumentazione di K8s. Fondamentalmente si basano sulla corrispondente documentazione di Prometheus. Le incongruenze si sono verificate per vari motivi (ad esempio, alcune metriche erano state create prima che apparissero le attuali istruzioni), e gli sviluppatori hanno deciso che era giunto il momento di uniformare tutto allo stesso standard, «in conformità con il resto dell'ecosistema Prometheus». L'attuale implementazione di questa iniziativa è in stato alfa, che sarà progressivamente elevato nelle versioni successive di Kubernetes fino alla beta (1.17) e alla stabilità (1.18).

Inoltre, si possono notare le seguenti modifiche:

Sviluppo del supporto per Windows con con l'arrivo dell'utilità Kubeadm per questo OS (versione alfa), la possibilità di RunAsUserName per i contenitori Windows (versione alfa), il miglioramento del supporto per Group Managed Service Account (gMSA) fino alla beta-versione, il supporto per mount/attach per i volumi vSphere.
Meccanismo rivisitato per la compressione dei dati nelle risposte API. In precedenza per questi scopi veniva utilizzato un filtro HTTP, che imponeva alcune limitazioni, impedendone l'attivazione per impostazione predefinita. Ora funziona la «compressione trasparente delle richieste»: i client che inviano Accept-Encoding: gzip nell'intestazione ricevono una risposta compressa in GZIP, se la sua dimensione supera 128 Kb. I client in Go supportano automaticamente la compressione (inviando l'intestazione necessaria), quindi noteranno immediatamente una riduzione del traffico. (Per altri linguaggi possono essere necessarie piccole modifiche).
È ora possibile scalare HPA da/a zero pod in base a metriche esterne. Se il ridimensionamento avviene sulla base di oggetti / metriche esterne, quando i carichi di lavoro sono inattivi, è possibile scalare automaticamente a 0 repliche per risparmiare risorse. Questa funzionalità dovrebbe risultare particolarmente utile nei casi in cui i worker richiedono risorse GPU e il numero di diversi tipi di worker inattivi supera il numero di GPU disponibili.
Nuovo cliente — k8s.io/client-go/metadata.Client — per l'accesso «generale» agli oggetti. È progettato per ottenere facilmente i metadati (cioè le sezioni metadati) dalle risorse del cluster e per eseguire operazioni come la raccolta dei rifiuti e il monitoraggio delle quote.
Ora è possibile raccogliere Kubernetes senza fornitori di cloud obsolete («integrati» in albero) (versione alfa). Nell'utilità kubeadm
c'è una funzionalità sperimentale (versione alfa) per applicare patch kustomize durante le operazioni hanno aggiunto init join, upgrade e . Per ulteriori informazioni su come utilizzare il flag--experimental-kustomize , vedereNuovo endpoint per apiserver — KEP.
readyz , — che permette di esportare informazioni sulla sua prontezza (readiness). Inoltre, l'API server ha ora un 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, in Azure sono stati aggiunti: supporto per l'autenticazione
- AAD e ADFS; annotazione
- service.beta.kubernetes.io/azure-pip-name per specificare l'IP pubblico del bilanciatore di carico; LoadBalancerName
- la possibilità impostazioni LoadBalancerResourceGroup e AWS ha introdotto.
per EBS su Windows e highlightsFromPoint() ottimizzato API chiamate EC2 DescribeInstances Kubeadm ora migra autonomamente.
la configurazione CoreDNS durante l'aggiornamento della versione di CoreDNS. I binari etcd
nel corrispondente Docker image sono stati resi world-executable, permettendo di eseguire quest'immagine senza necessità di privilegi root. Inoltre, l'immagine di migrazione etcd ha smesso di il supporto per la versione etcd2. Cluster Autoscaler 1.16.0 ha adottato distroless come base per l'immagine, migliorando le prestazioni e aggiungendo nuovi fornitori di cloud (DigitalOcean, Magnum, Packet).
In Aggiornamenti nel software utilizzato / dipendente: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2. Kubernetes 1.15: panoramica delle principali novità
Kubernetes 1.14: panoramica delle principali novità

Kubernetes 1.16: panoramica delle principali novità