Kubernetes 1.14: punti salienti delle novità

Questa notte состоится prossima versione di Kubernetes - 1.14. Secondo la tradizione che si è sviluppata per il nostro blog, stiamo parlando dei cambiamenti principali nella nuova versione di questo meraviglioso prodotto Open Source.

Le informazioni utilizzate per preparare questo materiale sono tratte da Tabelle di monitoraggio dei miglioramenti di Kubernetes, CAMBIAMENTI-1.14 e questioni correlate, richieste pull, proposte di miglioramento Kubernetes (KEP).

Iniziamo con un'importante introduzione dal ciclo di vita del cluster SIG: cluster di failover dinamico Kubernetes (o per essere più precisi, distribuzioni HA self-hosted) è ora può creare utilizzando comandi familiari (nel contesto dei cluster a nodo singolo). kubeadm (init и join). In breve, per questo:

• i certificati utilizzati dal cluster vengono trasferiti ai segreti;
• per la possibilità di utilizzare il cluster etcd all'interno del cluster K8s (ovvero eliminando la dipendenza esterna precedentemente esistente) etcd-operatore;
• Documenta le impostazioni consigliate per un bilanciatore del carico esterno che fornisce una configurazione con tolleranza agli errori (in futuro si prevede di eliminare questa dipendenza, ma non in questa fase).

Architettura di un cluster Kubernetes HA creato con kubeadm

I dettagli dell'implementazione possono essere trovati in proposta progettuale. Questa funzionalità era davvero attesa da tempo: la versione alpha era attesa già nel K8s 1.9, ma è apparsa solo ora.

API

Squadra apply e in generale gestione dichiarativa degli oggetti reso di kubectl nell'APIserver. Gli stessi sviluppatori spiegano brevemente la loro decisione dicendo questo kubectl apply - una parte fondamentale del lavoro con le configurazioni in Kubernetes, tuttavia, "è pieno di bug e difficile da risolvere", e quindi questa funzionalità deve essere riportata alla normalità e trasferita al piano di controllo. Esempi semplici e chiari di problemi che esistono oggi:

I dettagli sull'implementazione sono disponibili KEP. La disponibilità attuale è alpha (la promozione a beta è pianificata per la prossima versione di Kubernetes).

Reso disponibile nella versione alpha opportunità utilizzando lo schema OpenAPI v3 per creazione e pubblicazione della documentazione OpenAPI per CustomResources (CR) utilizzato per convalidare le risorse K8 definite dall'utente (lato server) (CustomResourceDefinition, CRD). La pubblicazione di OpenAPI per CRD consente ai client (ad es. kubectl) esegui la convalida dalla tua parte (entro kubectl create и kubectl apply) e rilasciare la documentazione secondo lo schema (kubectl explain). Dettagli - dentro KEP.

Registri preesistenti stanno ora aprendo con bandiera O_APPEND (e non O_TRUNC) per evitare la perdita di log in alcune situazioni e per comodità di troncare i log con utilità esterne per la rotazione.

Anche nel contesto delle API Kubernetes si può notare che in PodSandbox и PodSandboxStatus aggiunto campo runtime_handler per registrare informazioni su RuntimeClass nel pod (maggiori informazioni al riguardo nel testo about Versione Kubernetes 1.12, dove questa classe appariva come versione alpha) e in Admission Webhooks implementato capacità di determinare quali versioni AdmissionReview supportano. Infine, le regole dei webhook di ammissione sono ora può essere limitato la portata del loro utilizzo da parte degli spazi dei nomi e dei framework dei cluster.

Volte

PersistentLocalVolumes, che aveva lo stato beta sin dal rilascio K8 1.10, annunciato stabile (GA): questa funzionalità non è più disabilitata e verrà rimossa in Kubernetes 1.17.

Opportunità utilizzando variabili d'ambiente chiamate API verso il basso (ad esempio, il nome del pod) per i nomi delle directory montate come subPath, è stato sviluppato - sotto forma di un nuovo campo subPathExpr, che ora viene utilizzato per determinare il nome della directory desiderata. La funzionalità è apparsa inizialmente in Kubernetes 1.11, ma per la 1.14 è rimasta nello stato di versione alpha.

Come per la versione precedente di Kubernetes, vengono introdotte molte modifiche significative per la CSI (Container Storage Interface) in fase di sviluppo attivo:

CSI

È diventato disponibile (come parte della versione alpha) sostegno ridimensionamento per i volumi CSI. Per utilizzarlo sarà necessario abilitare la funzionalità gate denominata ExpandCSIVolumes, nonché la disponibilità del supporto per questa operazione in uno specifico driver CSI.

Un'altra caratteristica di CSI nella versione alpha: opportunità fare riferimento direttamente (ovvero senza utilizzare PV/PVC) ai volumi CSI all'interno delle specifiche del pod. Questo rimuove la restrizione all'utilizzo del CSI come archivio dati esclusivamente remoto, aprendo loro le porte del mondo volumi effimeri locali. Per uso (esempio dalla documentazione) deve essere abilitato CSIInlineVolume cancello caratteristico.

Ci sono stati progressi anche negli “interni” di Kubernetes legati a CSI, che non sono così visibili agli utenti finali (amministratori di sistema)... Attualmente, gli sviluppatori sono costretti a supportare due versioni di ciascun plugin di archiviazione: una - “nella old way”, all'interno del codice base di K8 (in -tree), e il secondo - come parte del nuovo CSI (maggiori informazioni a riguardo, ad esempio, in qui). Ciò provoca inconvenienti comprensibili che devono essere affrontati man mano che lo stesso CSI si stabilizza. Non è possibile semplicemente deprecare l'API dei plugin interni (in-tree) a causa di policy Kubernetes pertinente.

Tutto ciò ha portato al fatto che è stata raggiunta la versione alfa processo di migrazione codice del plugin interno, implementato come in-tree, nei plugin CSI, grazie al quale le preoccupazioni degli sviluppatori si ridurranno al supporto di una versione dei loro plugin, e rimarrà la compatibilità con le vecchie API e potranno essere dichiarate obsolete nel solito scenario. Si prevede che entro la prossima versione di Kubernetes (1.15) tutti i plugin del cloud provider verranno migrati, l'implementazione riceverà lo stato beta e sarà attivata nelle installazioni K8s per impostazione predefinita. Per i dettagli, vedere proposta progettuale. Anche questa migrazione ha avuto come conseguenza fallimento dai limiti di volume definiti da specifici cloud provider (AWS, Azure, GCE, Cinder).

Inoltre, supporto per dispositivi a blocchi con CSI (CSIBlockVolume) trasferito alla versione beta.

Nodi/Kubelet

Presentata la versione Alpha nuovo punto finale in Kubelet, progettato per restituire metriche sulle risorse chiave. In generale, se in precedenza Kubelet riceveva statistiche sull'utilizzo del contenitore da cAdvisor, ora questi dati provengono dall'ambiente di runtime del contenitore tramite CRI (Container Runtime Interface), ma viene preservata anche la compatibilità per lavorare con le versioni precedenti di Docker. In precedenza, le statistiche raccolte in Kubelet venivano inviate tramite l'API REST, ma ora un endpoint si trova su /metrics/resource/v1alpha1. Strategia a lungo termine degli sviluppatori consiste è ridurre al minimo l'insieme di metriche fornite da Kubelet. A proposito, questi stessi parametri adesso chiamano non "metriche fondamentali", ma "metriche delle risorse" e sono descritte come "risorse di prima classe, come CPU e memoria".

Una sfumatura molto interessante: nonostante il chiaro vantaggio prestazionale dell'endpoint gRPC rispetto a vari casi di utilizzo del formato Prometheus (vedi il risultato di uno dei benchmark di seguito), gli autori hanno preferito il formato testuale di Prometeo a causa della chiara leadership di questo sistema di monitoraggio nella comunità.

“gRPC non è compatibile con le principali pipeline di monitoraggio. L'endpoint sarà utile solo per fornire metriche a Metrics Server o per monitorare i componenti che si integrano direttamente con esso. Prestazioni del formato testo Prometheus quando si utilizza la memorizzazione nella cache in Metrics Server abbastanza buono per noi preferire Prometheus a gRPC data la diffusa adozione di Prometheus nella comunità. Una volta che il formato OpenMetrics diventerà più stabile, saremo in grado di avvicinarci alle prestazioni gRPC con un formato basato su prototipi”.

Uno dei test comparativi delle prestazioni sull'utilizzo dei formati gRPC e Prometheus nel nuovo endpoint Kubelet per le metriche. Ulteriori grafici e altri dettagli possono essere trovati in KEP.

Tra le altre modifiche:

• Kubelet ora (una volta) cercando di smettere contenitori in uno stato sconosciuto prima delle operazioni di riavvio ed eliminazione.
• Quando si utilizza la PodPresets ora al contenitore init è aggiunto le stesse informazioni di un normale contenitore.
• kubelet iniziato a usare usageNanoCores dal provider di statistiche CRI e per nodi e contenitori su Windows aggiunto statistiche di rete.
• Le informazioni sul sistema operativo e sull'architettura sono ora registrate nelle etichette kubernetes.io/os и kubernetes.io/arch Oggetti nodo (trasferiti da beta a GA).
• Possibilità di specificare un gruppo utenti di sistema specifico per i contenitori in un pod (RunAsGroup, apparso in K8 1.11) Avanzate prima della beta (abilitato per impostazione predefinita).
• du e trovare usato in cAdvisor, sostituito da implementazione in movimento.

CLI

In cli-runtime e kubectl aggiunto -k flag per l'integrazione con personalizza (a proposito, il suo sviluppo è ora effettuato in un repository separato), ad es. per elaborare file YAML aggiuntivi da directory speciali di kustomization (per i dettagli sul loro utilizzo, vedere KEP):

Esempio di utilizzo semplice dei file personalizzazione (un'applicazione più complessa di kustomize è possibile all'interno overlay)

Inoltre:

• Aggiunto da nuova squadra kubectl create cronjob, il cui nome parla da solo.
• В kubectl logs ora possibile combinare bandiere -f (--follow per i log di streaming) e -l (--selector per la query sull'etichetta).
• kubectl ha insegnato copiare i file selezionati con il carattere jolly.
• Alla squadra kubectl wait aggiunto bandiera --all per selezionare tutte le risorse nello spazio dei nomi del tipo di risorsa specificato.

Altrui

Le seguenti funzionalità hanno ricevuto lo stato stabile (GA):

• ReadinessGate, utilizzato nelle specifiche del pod per definire condizioni aggiuntive prese in considerazione nella preparazione del pod;
• Supporto per pagine di grandi dimensioni (gate di funzionalità chiamato HugePages);
• CustomPodDNS;
• API PriorityClass Priorità e prelazione dei pod.

Altre modifiche introdotte in Kubernetes 1.14:

• La policy RBAC predefinita non consente più l'accesso API discovery и access-review utenti senza autenticazione (non autenticato).
• Supporto ufficiale CoreDNS fornito Solo Linux, quindi quando si utilizza kubeadm per distribuirlo (CoreDNS) in un cluster, i nodi devono essere eseguiti solo su Linux (per questa limitazione vengono utilizzati i nodeSelector).
• La configurazione CoreDNS predefinita è ora usi plugin di inoltro invece che per procura. Inoltre, in CoreDNS aggiunto readinessProbe, che impedisce il bilanciamento del carico sui pod appropriati (non pronti per il servizio).
• In kubeadm, sulle fasi init o upload-certs, diventato possibile caricare i certificati richiesti per connettere il nuovo control-plane al segreto kubeadm-certs (utilizzare il flag --experimental-upload-certs).
• È apparsa una versione alpha per le installazioni Windows supporto gMSA (Account servizio gestito di gruppo): account speciali in Active Directory che possono essere utilizzati anche dai contenitori.
• Per G.C.E. attivato Crittografia mTLS tra etcd e kube-apiserver.
• Aggiornamenti nel software utilizzato/dipendente: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, supporto Docker 18.09 in kubeadm e la versione minima supportata dell'API Docker è ora 1.26.

PS

Leggi anche sul nostro blog:

• «Kubernetes 1.13: punti salienti delle novità";
• «Kubernetes 1.12: punti salienti delle novità";
• «Kubernetes 1.11: punti salienti delle novità";
• «Kubernetes 1.10: punti salienti delle novità'.

Fonte: habr.com