🥇Kubernetes 1.17: panoramica delle principali novità

Ieri, 9 dicembre, si è svolto è stato rilasciato un nuovo aggiornamento di Kubernetes — 1.17. Secondo la tradizione del nostro blog, parliamo delle modifiche più significative nella nuova versione.

Kubernetes 1.17: panoramica delle principali novità

Le informazioni utilizzate per redigere questo materiale provengono dal comunicato ufficiale, tabella di tracciamento dei miglioramenti di Kubernetes, CHANGELOG-1.17 e dai relativi issues, pull requests, così come dalle Kubernetes Enhancement Proposals (KEP). Quindi, cosa c'è di nuovo?..

Routing consapevole della topologia

Da tempo la comunità di Kubernetes attendeva questa funzionalità — Routing dei servizi consapevole della topologiaSe KEP la sua origine risale a ottobre 2018, e il miglioramento è stato introdotto due anni fa, quindi le normali issue (come di questo) — sono addirittura più vecchie di alcuni anni…

L'idea generale è quella di fornire la possibilità di implementare un routing "locale" per i servizi che si trovano in Kubernetes. La "località" in questo caso significa "stesso livello topologico" (topology level), che può essere:

nodo identico per i servizi,
stesso rack,
stessa regione,
stesso fornitore di cloud,
…

Esempi di utilizzo di questa funzionalità:

risparmi sui costi del traffico in installazioni cloud con più zone di disponibilità (multi-AZ) — vedi. una nuova illustrazione con il traffico di una regione, ma diverse AZ in AWS;
minori latenze nelle prestazioni/migliore larghezza di banda;
servizio suddiviso, che ha informazioni locali sul nodo in ogni shard;
disposizione di fluentd (o analoghi) su un nodo con le applicazioni di cui vengono raccolti i log;
…

Questo tipo di routing, che "conosce" la topologia, è anche chiamato affinità di rete — analogamente a affinità del nodo, affinità/anti-affinità del pod o l'emergere recente di Volume Scheduling Consapevole della Topologia Provisioning del Volume (e ). L'attuale livello di implementazioneServiceTopology in Kubernetes è in alpha. Puoi leggere i dettagli su come funziona questa funzionalità e come utilizzarla già in

in un articolo di uno degli autori. questo articolo Supporto per lo stack IPv4/IPv6 duale

Un notevole progresso

è stato registrato in un'altra funzionalità di rete: il supporto simultaneo di due stack IP, che è stato presentato per la prima volta in K8s 1.16 . In particolare, il nuovo rilascio ha portato le seguenti modifiche:in kube-proxy

la possibilità di operare contemporaneamente in entrambe le modalità (IPv4 e IPv6); è stata implementata Pod.Status.PodIPs
in supporto per l'API downward (intanto ora richiedono di aggiungere anche l'indirizzo IPv6 per l'host); è comparso supporto per due stack in /etc/hosts KIND
(Kubernetes IN Docker) e (Kubernetes IN Docker) e (Kubernetes IN Docker) e kubeadm;
test e2e aggiornati.

Kubernetes 1.17: panoramica delle principali novità
Illustrazione utilizzo di uno stack doppio IPV4/IPv6 in KIND

Progresso su CSI

Annunciato stabile supporto per topologie per memorie basate su CSI, presentato per la prima volta in K8s 1.12.

Iniziativa per la migrazione dei plug-in di volume su CSI — Migrazione CSI — ha raggiunto lo stato beta. Questa funzionalità è fondamentale per trasferire i plug-in di memorizzazione esistenti (in-tree) a un'interfaccia moderna (CSI, out-of-tree) senza alcun impatto sugli utenti finali di Kubernetes. Gli amministratori dei cluster dovranno semplicemente attivare la Migrazione CSI, dopo di che le risorse stateful esistenti e i carichi di lavoro continueranno a "funzionare" normalmente... ma già utilizzando i driver CSI aggiornati invece di quelli obsoleti integrati nel kernel di Kubernetes.

Attualmente, lo stato beta della migrazione è disponibile per i driver AWS EBS (kubernetes.io/aws-ebs) e GCE PD (kubernetes.io/gce-pd). Le previsioni per altre memorie sono le seguenti:

Kubernetes 1.17: panoramica delle principali novità

Riguardo a come il supporto "tradizionale" delle memorie in K8s sia arrivato a CSI, ne abbiamo parlato in questo articolo. Un articolo a parte è dedicato al passaggio della migrazione CSI allo stato beta nel blog del progetto. Inoltre, un'altra funzionalità significativa nel contesto di CSI, che ha raggiunto lo stato beta (cioè abilitato di default) nella rilascio di Kubernetes 1.17, con origine (realizzazione alpha) in K8s 1.12, è

la creazione di snapshot e il recupero da essi . Tra le modifiche apportate a Kubernetes Volume Snapshot nel percorso verso il rilascio beta:divisione del sidecar CSI external-snapshotter in due controller,

aggiunta di un segreto per eliminare
(deletion secret) come annotazione al contenuto dello snapshot del volume, nuovo finalizzatore
(finalizer) per prevenire la cancellazione dell'oggetto API dello snapshot in presenza di legami rimanenti. Al momento del rilascio 1.17, la funzionalità è supportata da tre driver CSI: GCE Persistent Disk CSI Driver, Portworx CSI Driver e NetApp Trident CSI Driver. Maggiori dettagli sulla sua realizzazione e utilizzo possono essere letti nel

blog. questa pubblicazione Etichette del fornitore di cloud

Le etichette, che vengono automaticamente

assegnate ai nodi e ai volumi creati in base al fornitore di cloud utilizzato , sono state disponibili in Kubernetes come beta già da molto tempo - a partire dalla rilascio K8s 1.2(aprile 2016!) . Dato il loro ampio utilizzo per così tanto tempo, gli sviluppatorihanno deciso , che era giunto il momento di dichiarare la funzionalità stabile (GA).Pertanto, tutte sono state ribattezzate di conseguenza (per topologie):

beta.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

… ma rimangono comunque disponibili con i loro vecchi nomi (per compatibilità retroattiva). Tuttavia, a tutti gli amministratori si consiglia di passare ai nomi di etichette aggiornati. Documentazione pertinente K8s è stata aggiornata.

Output strutturato di kubeadm

Presentato per la prima volta in formato alpha output strutturato per lo strumento kubeadm. Formati supportati: JSON, YAML, modello Go.

La motivazione per l'implementazione di questa funzionalità (secondo KEP) è la seguente:

Sebbene Kubernetes possa essere distribuito manualmente, lo standard de facto (se non de iure) per questa operazione è l'uso di kubeadm. Strumenti di gestione dei sistemi popolari come Terraform si basano su kubeadm per il deployment di Kubernetes. I miglioramenti pianificati in Cluster API includono un pacchetto componibile per il bootstrap di Kubernetes con kubeadm e cloud-init.
Senza output strutturato, anche le modifiche più innocue a prima vista possono interrompere Terraform, Cluster API e altri software che utilizzano i risultati del lavoro di kubeadm.

Nel prossimo futuro è prevista la supporto (sotto forma di output strutturato) per i seguenti comandi kubeadm:

alpha certs
config images list
join
token create
token list
upgrade plan
versione

Illustrazione della risposta JSON per il comando 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": "Il token bootstrap predefinito generato da 'kubeadm init'.",
    "extraGroups": [
      "system:bootstrappers:kubeadm:default-node-token"
    ]
  },
  "raw": "Rm9yIHRoZSBhY3R1YWwgb3V0cHV0IG9mIHRoZSAia3ViZWFkbSBpbml0IiBjb21tYW5kLCBwbGVhc2Ugc2VlIGh0dHBzOi8vZ2lzdC5naXRodWIuY29tL2FrdXR6LzdhNjg2ZGU1N2JmNDMzZjkyZjcxYjZmYjc3ZDRkOWJhI2ZpbGUta3ViZWFkbS1pbml0LW91dHB1dC1sb2c="
}

Stabilizzazione di altre novità

In generale, il rilascio di Kubernetes 1.17 è avvenuto sotto il motto "Stabilità". Questo è stato facilitato dal fatto che molte funzionalità in esso (il loro numero totale è 14) hanno ottenuto lo stato GA. Tra queste:

"etichettatura" dei nodi in base a determinate condizioni (TaintNodesByCondition), introdotta in K8s 1.8;
Watch Bookmarks — un nuovo tipo di evento, che segnala che tutti gli oggetti fino a una certa versione (resourceVersion) erano già stati elaborati dal watch;
valori predefiniti (defaulting) per Custom Resources;
spazi dei nomi dei processi condivisi tra contenitori in un pod;
ScheduleDaemonSetPods — programmazione di pod nel DaemonSet utilizzando kube-scheduler (invece del controller DaemonSet);
limiti dinamici sul numero di volumi a seconda del tipo di nodo;
supporto per variabili d'ambiente per i nomi delle directory montate come subPath;
trasferimento dei heartbeat del Kubelet in un API Lease specializzato;
«protezione del finalizzatore» (Protezione del Finalizzatore) per i bilanciatori di carico (controllo delle risorse del Servizio rilevanti prima di rimuovere le risorse del LoadBalancer);
ottimizzazione del kube-apiserver nelle prestazioni quando si interagisce con molti watch che osservano set identici di oggetti, raggiunta evitando la serializzazione ripetuta degli stessi oggetti per ogni watcher.

Le date YYYY-M-DD e YYYY-MM-D non sono

L'elenco completo delle novità di Kubernetes 1.17, naturalmente, non si limita a quanto elencato sopra. Ecco alcune altre di esse (per un elenco più completo, vedere CHANGELOG):

la funzionalità presentata nell'ultima versione è "cresciuta" verso la beta RunAsUserName per Windows.;
una modifica analoga ha raggiunto l'API EndpointSlice (anch'essa di K8s 1.16), tuttavia, questa soluzione per migliorare le prestazioni / la scalabilità dell'API Endpoint non è attivata di default;
i pod critici per il funzionamento del cluster ora possono essere creati non solo negli spazi dei nomi kube-system (per dettagli vedere la documentazione su Limit Priority Class consumption);
una nuova opzione per kubelet — --reserved-cpus — consente di specificare esplicitamente un elenco di CPU riservati per il sistema;
per kubectl logs presentato una nuova flag --prefix, che aggiunge il nome del pod e del contenitore sorgente a ciascuna riga del log;
in label.Selector hanno aggiunto RequiresExactMatch;
tutti i contenitori in kube-dns ora vengono eseguiti con minori privilegi;
hyperkube è stato spostato in un repository GitHub separato e non sarà più incluso nei rilasci di Kubernetes;
significativamente migliorata la prestazione kube-proxy per le porte non UDP.