🥇Kubernetes 1.17: panoramica delle principali novità

Ieri, 9 dicembre, si è tenuto è uscita una nuova versione di Kubernetes — 1.17. Come da tradizione per il nostro blog, vi presentiamo le modifiche più significative nella nuova versione.

Kubernetes 1.17: panoramica delle principali novità

Le informazioni utilizzate per la preparazione di questo materiale provengono dall'annuncio ufficiale, tabella di monitoraggio dei miglioramenti di Kubernetes, CHANGELOG-1.17 e dai relativi issues, pull request e Kubernetes Enhancement Proposals (KEP). Quindi, cosa c'è di nuovo?

Routing consapevole della topologia

Da tempo, la comunità Kubernetes attendeva questa funzionalità — Topologie-aware service routing. Se KEP è nata nell'ottobre 2018, e l' enhancement è stato ufficializzato 2 anni fa, così come gli usuali issues (come ad esempio questo) — e persino più vecchi di qualche anno…

L'idea principale è quella di fornire l'opportunità di implementare un routing "locale" per i servizi che si trovano in Kubernetes. Con "località" si intende "lo stesso livello topologico" (topology level),che può essere:

il nodo uguale per i servizi,
la stessa rack server,
la stessa regione,
lo stesso provider cloud.
…

Esempi di utilizzo di questa funzionalità:

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

Un tale routing, che "conosce" la topologia, è anche chiamato affinità di rete — per analogia con affinità del nodo, affinità/anti-affinità del pod o recentemente introdotto non molto tempo fa Topology-Aware Volume Scheduling (e Volume Provisioning). Il livello attuale di implementazione ServiceTopology in Kubernetes — versione alpha.

Per dettagli su come è strutturata la funzionalità e come è già possibile utilizzarla, leggi in questo articolo da uno degli autori.

Supporto per lo stack doppio IPv4/IPv6

Significativo progresso è stato registrato in un'altra funzionalità di rete: il supporto simultaneo di due stack IP, presentato per la prima volta in K8s 1.16. In particolare, la nuova versione ha portato i seguenti cambiamenti:

in kube-proxy è stata realizzata capacità di funzionare simultaneamente in entrambe le modalità (IPv4 e IPv6);
in Pod.Status.PodIPs è stata introdotta supporto per il downward API (contemporaneamente ora è necessario per l'host aggiungere anche l'indirizzo IPv6); /etc/hosts supporto per due stack in
supporto di due stack in KIND (Kubernetes IN Docker) e kubeadm;
test e2e aggiornati.

Kubernetes 1.17: panoramica delle principali novità
Illustrazione utilizzo della doppia stack IPV4/IPv6 in KIND

Progresso di CSI

Annunciata stabile supporto per topologie per i depositi basati su CSI, presentato per la prima volta in K8s 1.12.

Iniziativa per la migrazione dei plugin dei volumi a CSI — Migrazione CSI — ha raggiunto la fase beta. Questa funzionalità è critica per migrare i plugin di archiviazione esistenti (in-tree) a un'interfaccia moderna (CSI, out-of-tree) senza interruzioni per gli utenti finali di Kubernetes. Gli amministratori del cluster dovranno semplicemente attivare la Migrazione CSI, dopo di che le risorse stateful esistenti e i carichi di lavoro continueranno a ‘funzionare normalmente’... ma ora utilizzando i driver CSI aggiornati invece dei vetusti, inclusi nel kernel di Kubernetes.

Attualmente, è pronta la migrazione per i driver AWS EBS (kubernetes.io/aws-ebs) e GCE PD (kubernetes.io/gce-pd). Le previsioni per altri archivi sono:

Kubernetes 1.17: panoramica delle principali novità

Riguardo a come il supporto ‘tradizionale’ degli archivi in K8s è arrivato a CSI, abbiamo parlato in questo articolo. A questa transizione della migrazione CSI in fase beta è dedicata una pubblicazione separata sul blog del progetto.

Inoltre, con il rilascio di Kubernetes 1.17 ha raggiunto lo stato di beta (cioè abilitato di default) anche un'altra funzionalità significativa per CSI, la cui origine risale all'implementazione alpha in K8s 1.12 — creazione di snapshot e ripristino da essi. Tra le modifiche apportate a Kubernetes Volume Snapshot verso il rilascio in beta:

scomposizione del sidecar CSI external-snapshotter in due controller,
aggiunto un segreto per la cancellazione (deletion secret) come annotazione al contenuto dello snapshot del volume,
nuovo finalizzatore (finalizer) per impedire la cancellazione dell'oggetto API dello snapshot in presenza di riferimenti rimanenti.

Al momento del rilascio 1.17, la feature è supportata da tre driver CSI: GCE Persistent Disk CSI Driver, Portworx CSI Driver e NetApp Trident CSI Driver. Maggiori informazioni sulla sua implementazione e utilizzo possono essere trovate nel questa pubblicazione blog.

Cloud Provider Labels

Etichette che vengono automaticamente assegnate ai nodi e ai volumi creati a seconda del provider cloud utilizzato, erano disponibili in Kubernetes come beta già da molto tempo — sin dal rilascio di K8s 1.2 (aprile 2016!). Considerando il loro ampio utilizzo per tanto tempo, gli sviluppatori hanno deciso, che era giunto il momento di dichiarare la feature stabile (GA).

Pertanto, tutti sono stati rinominati di conseguenza (secondo le 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 anche con i loro vecchi nomi (per motivi di retrocompatibilità). Tuttavia, si consiglia a tutti gli amministratori di passare ai label aggiornati. Documentazione pertinente K8s è stata aggiornata.

Output strutturato di kubeadm

Introdotto per la prima volta nel 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 jure) per questa operazione è l’utilizzo di kubeadm. Strumenti di gestione delle configurazioni popolari come Terraform si basano su kubeadm per il deployment di Kubernetes. I miglioramenti previsti nell'API Cluster includono un pacchetto componibile per il bootstrap di Kubernetes con kubeadm e cloud-init.
Senza output strutturato, anche le modifiche che sembrano innocue a prima vista possono rompere Terraform, Cluster API e altri software che utilizzano i risultati di kubeadm.

Nei prossimi piani è prevista la supporto (in forma di output strutturato) per i seguenti comandi kubeadm:

alpha certs
config images list
init
token create
token list
upgrade plan
version

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 possibile anche perché molte funzionalità in esso (il loro numero totale è 14) hanno ottenuto lo stato GA. Tra di esse:

«targhettatura» dei nodi in base a determinate condizioni (TaintNodesByCondition), introdotta in K8s 1.8;
Watch Bookmarks — un nuovo tipo di eventi contrassegnati, che indicano 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 di processo condivisi tra i contenitori nel pod;
ScheduleDaemonSetPods — pianificazione dei pod in DaemonSet utilizzando kube-scheduler (invece del controller DaemonSet);
limiti dinamici sul numero di volumi in base al tipo di nodo;
supporto per variabili d'ambiente per i nomi delle directory montate come subPath;
trasmissione dei heartbeat di Kubelet nel Lease API specializzato;
«protezione del finalizzatore» (Protezione del Finalizzatore) per i bilanciatori di carico (verifica delle risorse del Service prima di rimuovere le risorse del LoadBalancer);
ottimizzazione di kube-apiserver nella performance quando si lavora con numerosi watch che osservano set identici di oggetti, ottenuta evitando la ri-serializzazione degli stessi oggetti per ciascun watcher.

Altre modifiche

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

la funzionalità presentata nel rilascio precedente che è 'arrivata' alla beta RunAsUserName per Windows;
una modifica analoga ha raggiunto l'API EndpointSlice (anch'essa da K8s 1.16), tuttavia questa soluzione per migliorare le performance/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 kubectl -n kube-system edit cm kubelet-config-1.16 (dettagli vedi nella documentazione su Limitare il consumo della classe di priorità);
nuova opzione per kubelet — --reserved-cpus — consente di specificare esplicitamente l'elenco delle CPU riservate per il sistema;
per kubectl logs presentato nuovo flag --prefix, aggiungendo il nome del pod e del contenitore sorgente a ogni riga del log;
in label.Selector è stato aggiunto RequiresExactMatch;
tutti i contenitori in kube-dns ora vengono eseguiti con privilegi minori;
hyperkube separato in un repository GitHub e non sarà più incluso nelle versioni di Kubernetes;
notevolmente migliorata la performance kube-proxy per le porte non UDP.

Modifiche alle dipendenze:

versione CoreDNS inclusa in kubeadm — 1.6.5;
versione crictl aggiornata a v1.16.1;
CSI 1.2.0;
etcd 3.4.3;
l'ultima versione verificata di Docker è stata aggiornato a 19.03;
la versione minima di Go richiesta per compilare Kubernetes 1.17 è 1.13.4.

P.S.

Leggete anche nel nostro blog:

Fonte: habr.com