🥇Kubernetes 1.17: Punti salienti delle novità

Ieri, 9 dicembre, ha avuto luogo prossima versione di Kubernetes - 1.17. Secondo la tradizione che si è sviluppata per il nostro blog, parliamo dei cambiamenti più significativi della nuova versione.

Le informazioni utilizzate per la preparazione di questo materiale sono tratte dal bando ufficiale, Tabelle di monitoraggio dei miglioramenti di Kubernetes, CAMBIAMENTI-1.17 e problemi correlati, richieste pull e proposte di miglioramento Kubernetes (KEP). Allora che c'è di nuovo?..

Routing con riconoscimento della topologia

La comunità Kubernetes aspettava questa funzionalità da molto tempo - Routing del servizio con riconoscimento della topologia. Se KEP ha origine nell'ottobre 2018 e è ufficiale aumento — 2 anni fa, i soliti problemi (Piace esso) - e qualche anno in più...

L'idea generale è quella di fornire la possibilità di implementare il routing “locale” per i servizi che risiedono in Kubernetes. “Località” in questo caso significa “lo stesso livello topologico” (livello di topologia), che può essere:

nodo identico per i servizi,
lo stesso server rack,
la stessa regione
lo stesso fornitore di servizi cloud,
...

Esempi di utilizzo di questa funzionalità:

risparmio sul traffico in installazioni cloud con più zone di disponibilità (multi-AZ) - cfr. illustrazione fresca utilizzando l'esempio del traffico dalla stessa regione, ma AZ diverse in AWS;
minore latenza delle prestazioni/migliore throughput;
un servizio partizionato che contiene informazioni locali sul nodo in ogni partizione;
posizionamento di fluentd (o analoghi) sullo stesso nodo con le applicazioni di cui vengono raccolti i log;
...

Tale routing, che "conosce" la topologia, è anche chiamato affinità di rete - per analogia con affinità del nodo, affinità/anti-affinità pod o è apparso non molto tempo fa Pianificazione del volume in base alla topologia (e Provisioning del volume). Livello attuale di implementazione ServiceTopology in Kubernetes - versione alpha.

Per i dettagli su come funziona la funzionalità e come puoi già utilizzarla, leggi questo articolo da uno degli autori.

Supporto doppio stack IPv4/IPv6

Progresso significativo fisso in un'altra funzionalità di rete: il supporto simultaneo per due stack IP, introdotto per la prima volta in K8 1.16. In particolare la nuova release ha apportato le seguenti modifiche:

nel proxy kube implementato possibilità di funzionamento simultaneo in entrambe le modalità (IPv4 e IPv6);
в Pod.Status.PodIPs apparso supporto per API verso il basso (contemporaneamente a in /etc/hosts ora richiedono all'host di aggiungere un indirizzo IPv6);
supporto per doppio stack GENERE (Kubernetes IN Docker) e kubeadm;
test e2e aggiornati.

illustrazione utilizzando il doppio stack IPV4/IPv6 in KIND

Progressi sul CSI

Dichiarato stabile supporto della topologia per lo storage basato su CSI, introdotto per la prima volta in K8 1.12.

Iniziativa per migrazione dei plug-in del volume su CSI - Migrazione CSI - raggiunta la versione beta. Questa funzionalità è fondamentale per tradurre i plug-in di archiviazione esistenti (nell'albero) a un'interfaccia moderna (CSI, fuori dall'albero) invisibile agli utenti finali Kubernetes. Gli amministratori del cluster dovranno solo abilitare la migrazione CSI, dopodiché le risorse stateful e i carichi di lavoro esistenti continueranno a "funzionare"... ma utilizzando i driver CSI più recenti invece di quelli obsoleti inclusi nel core Kubernetes.

Al momento la migrazione per i driver AWS EBS è pronta in versione beta (kubernetes.io/aws-ebs) e GCE PD (kubernetes.io/gce-pd). Le previsioni per gli altri impianti di stoccaggio sono le seguenti:

Abbiamo parlato di come il supporto di archiviazione "tradizionale" nei K8 sia arrivato a CSI questo articolo. E a cui è dedicata la transizione della migrazione di CSI allo stato beta pubblicazione separata sul blog del progetto.

Inoltre, un'altra funzionalità significativa nel contesto di CSI, che ha origine (implementazione alpha) in K1.17s 8, ha raggiunto lo stato beta (cioè abilitata per impostazione predefinita) nella versione Kubernetes 1.12 - creazione di istantanee e il recupero da essi. Tra le modifiche apportate a Kubernetes Volume Snapshot in vista del rilascio beta:

dividendo il sidecar dello snapshot esterno CSI in due controller,
aggiunto segreto per l'eliminazione (segreto di cancellazione) come annotazione al contenuto di uno snapshot del volume,
nuovo finalizzatore (finalizzatore) per impedire che l'oggetto API snapshot venga eliminato se sono presenti connessioni rimanenti.

Al momento della versione 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 implementazione e utilizzo possono essere trovati in questa pubblicazione sul blog.

Etichette dei fornitori di servizi cloud

Etichettalo automaticamente assegnati ai nodi e ai volumi creati a seconda del provider cloud utilizzato, sono disponibili in Kubernetes come versione beta da molto tempo, dal rilascio di K8s 1.2 (Aprile 2016!). Dato il loro uso diffuso per così tanto tempo, gli sviluppatori решили, che è giunto il momento di dichiarare la funzionalità stabile (GA).

Pertanto, sono stati tutti rinominati di conseguenza (per topologia):

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 sono ancora disponibili con i vecchi nomi (per compatibilità con le versioni precedenti). Tuttavia, si consiglia a tutti gli amministratori di passare alle etichette correnti. Documentazione correlata K8 è stato aggiornato.

Output strutturato di kubeadm

Presentato per la prima volta in versione alpha output strutturato per l'utilità kubeadm. Formati supportati: JSON, YAML, modello Go.

Motivazione per l'implementazione di questa funzionalità (secondo KEP) È:

Sebbene Kubernetes possa essere distribuito manualmente, lo standard de facto (se non de jure) per questa operazione prevede l'utilizzo di kubeadm. Gli strumenti di gestione dei sistemi più diffusi come Terraform si affidano a kubeadm per la distribuzione di Kubernetes. I miglioramenti pianificati all'API Cluster includono un pacchetto componibile per il bootstrap di Kubernetes con kubeadm e cloud-init.

Senza un output strutturato, anche le modifiche più innocue a prima vista possono danneggiare Terraform, Cluster API e altri software che utilizzano i risultati di kubeadm.

I nostri piani immediati includono il supporto (sotto forma di output strutturato) per i seguenti comandi kubeadm:

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

Illustrazione di una risposta JSON a un 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": "The default bootstrap token generated by 'kubeadm init'.",
    "extraGroups": [
      "system:bootstrappers:kubeadm:default-node-token"
    ]
  },
  "raw": "Rm9yIHRoZSBhY3R1YWwgb3V0cHV0IG9mIHRoZSAia3ViZWFkbSBpbml0IiBjb21tYW5kLCBwbGVhc2Ugc2VlIGh0dHBzOi8vZ2lzdC5naXRodWIuY29tL2FrdXR6LzdhNjg2ZGU1N2JmNDMzZjkyZjcxYjZmYjc3ZDRkOWJhI2ZpbGUta3ViZWFkbS1pbml0LW91dHB1dC1sb2c="
}

Stabilizzazione di altre innovazioni

In generale, il rilascio di Kubernetes 1.17 è avvenuto all'insegna del motto “stabilità" Ciò è stato facilitato dal fatto che molte funzionalità in esso contenute (il loro numero totale è 14) ha ricevuto lo stato GA. Tra loro:

“marcatura” dei nodi in base a determinate condizioni (TaintNodesByCondition), apparso in K8 1.8;
Guarda Segnalibri - un nuovo tipo di eventi che hanno un'etichetta che indica che tutti gli oggetti sono fino a una determinata versione (resourceVersion) sono già stati elaborati da watch;
valori standard (predefinito) per le risorse personalizzate;
condiviso tra contenitori negli spazi dei nomi del processo pod;
ScheduleDaemonSetPods - pod di pianificazione in DaemonSet utilizzando kube-scheduler (invece del controller DaemonSet);
limiti dinamici dal numero di volumi a seconda del tipo di nodo;
supporto variabile d'ambiente per i nomi di directory montati come subPath;
Trasferimento dei battiti cardiaci Kubelet ad un'API Lease specializzata;
"protezione finalizzatore" (Protezione del finalizzatore) per i bilanciatori di carico (controllando le risorse del servizio corrispondenti prima di eliminare le risorse LoadBalancer);
Ottimizzazione kube-apiserver in termini di prestazioni quando si lavora con più orologi che monitorano insiemi identici di oggetti, ottenuto evitando la serializzazione ripetuta degli stessi oggetti per ciascun osservatore.

Altre modifiche

L'elenco completo delle innovazioni di Kubernetes 1.17, ovviamente, non si limita a quelle sopra elencate. Eccone alcuni altri (e per un elenco più completo, vedere CHANGELOG):

La funzionalità presentata nell'ultima release ha raggiunto la versione beta RunAsUserName per finestre;
cambiamento simile è successo API EndpointSlice (anche da K8s 1.16), tuttavia per ora questa soluzione per migliorare le prestazioni/scalabilità dell'API Endpoint non è abilitata per impostazione predefinita;
i pod sono ora fondamentali per il funzionamento del cluster può essere creato non solo negli spazi dei nomi kube-system (per i dettagli, consultare la documentazione di Limita il consumo della classe prioritaria);
nuova opzione per kubelet - --reserved-cpus — permette di definire esplicitamente la lista delle CPU riservate al sistema;
per kubectl logs presentata nuova bandiera --prefix, aggiungendo il nome del pod e del contenitore di origine a ogni riga del log;
в label.Selector aggiunto RequiresExactMatch;
tutti i contenitori in kube-dns ora stanno correndo con meno privilegi;
iperkubo separato in un repository GitHub separato e non sarà più incluso nelle versioni Kubernetes;
molto ottimizzazione della fornitura kube-proxy per porte non UDP.

Modifiche alla dipendenza:

La versione CoreDNS inclusa in kubeadm è la 1.6.5;
versione crictl aggiornata alla v1.16.1;
CSI 1.2.0;
eccd 3.4.3;
Ultima versione Docker testata aggiornata alla 19.03;
La versione Go minima richiesta per creare Kubernetes 1.17 è 1.13.4.

Kubernetes 1.17: punti salienti delle novità