Kubernetes 1.12: panoramica delle principali novità

Questa notte si svolgerà un altro rilascio di Kubernetes — 1.14. Secondo la tradizione del nostro blog, raccontiamo i cambiamenti chiave nella nuova versione di questo fantastico prodotto Open Source.

Le informazioni utilizzate per preparare questo materiale provengono da tabella di tracciamento dei miglioramenti di Kubernetes, CHANGELOG-1.14 e le relative issue, pull request, Kubernetes Enhancement Proposals (KEP).

Iniziamo con un'introduzione importante da parte di SIG cluster-lifecycle: cluster dinamici a prova di guasto Kubernetes (o, per essere più precisi, deploy self-hosted HA) ora può essere creato utilizzando i comandi familiari (nel contesto di cluster con un solo nodo) kubeadm (join e upgrade). In sintesi, per questo:

• i certificati utilizzati dal cluster vengono trasferiti in segreti;
• per consentire l'uso del cluster etcd all'interno del cluster K8s (cioè eliminando la dipendenza esterna esistente) è stato coinvolto etcd-operator;
• si documentano le configurazioni consigliate per un bilanciatore di carico esterno che fornisce una configurazione a prova di guasto (in futuro è prevista possibilità di liberarsi anche da questa dipendenza, ma non in questa fase).

Architettura del cluster HA di Kubernetes, creato con kubeadm

Puoi consultare i dettagli sull'implementazione nel design proposal. Questa funzione era veramente attesa: la versione alpha era attesa già in K8s 1.9, ma è apparsa solo ora.

API

Team apply e in generale gestione dichiarativa degli oggetti in un pacchetto " da kubectl nell'apiserver. Gli stessi sviluppatori spiegano brevemente la loro decisione dicendo che kubectl apply è una parte fondamentale del lavoro con le configurazioni in Kubernetes, tuttavia è "piena di bug e difficile da correggere", per cui è necessario portare questa funzionalità a uno stato normale e trasferirla nel control plane. Ecco alcuni esempi semplici e evidenti dei problemi esistenti oggi:

I dettagli sull'implementazione sono nel KEP. L'attuale prontezza è la versione alpha (il passaggio alla beta è previsto per il prossimo rilascio di Kubernetes).

Nella versione alpha è diventato disponibile la possibilità l'uso dello schema OpenAPI v3 per la creazione e pubblicazione della documentazione OpenAPI per le CustomResources (CR), utilizzate per la validazione (lato server) delle risorse K8s definite dall'utente (CustomResourceDefinition, CRD). La pubblicazione di OpenAPI per CRD consente ai clienti (ad esempio, kubectl) di eseguire la validazione sul lato loro (nell'ambito di kubectl create e kubectl apply) e fornire la documentazione dello schema (kubectl explain). I dettagli sono nel KEP.

I log esistenti ora si aprono con il flag O_APPEND (e non O_TRUNC) per evitare la perdita di log in alcune situazioni e per la comodità del truncate dei log tramite utilità esterne per la rotazione.

Inoltre, nel contesto dell'API di Kubernetes, si può notare che PodSandbox e PodSandboxStatus aggiunto il campo runtime_handler per considerare le informazioni su RuntimeClass nel pod (per ulteriori dettagli, leggi il testo relativo a rilascio di Kubernetes 1.12, dove questa classe è emersa come versione alfa), e nei Webhook di ammissione è stata implementata la possibilità di determinare quali versioni AdmissionReview sono supportate. Infine, nelle regole dei Webhook di ammissione ora è possibile limitare l'ambito della loro applicazione ai namespace e ai limiti del cluster.

I volumi di storage

PersistentLocalVolumes, che avevano lo stato di beta dalla versione K8s 1.10, sono stati dichiarati stabili (GA): questo feature gate non può più essere disattivato e sarà rimosso in Kubernetes 1.17.

Capacità utilizzando variabili d'ambiente del cosiddetto Downward API (ad esempio, il nome del pod) per i nomi delle directory montate come subPath, ha ricevuto sviluppo — sotto forma di un nuovo campo subPathExpr, tramite il quale ora viene determinato il nome della directory necessaria. Inizialmente, questa funzionalità è apparsa in Kubernetes 1.11, ma è rimasta in stato di versione alfa anche per 1.14.

Come nel precedente rilascio di Kubernetes, sono state presentate molte modifiche significative per il CSI (Container Storage Interface) in continua evoluzione:

CSI

È diventata disponibile (nel contesto della versione alfa) highlightsFromPoint() il ridimensionamento dei volumi CSI. Per utilizzarla, sarà necessario abilitare il feature gate chiamato ExpandCSIVolumes, oltre a garantire il supporto di questa operazione in un determinato driver CSI.

Un'altra funzionalità per il CSI in versione alfa — la possibilità fare riferimento direttamente (ossia senza utilizzare PV/PVC) ai volumi CSI all'interno delle specifiche dei pod. Questo elimina la limitazione sull'uso del CSI come esclusivamente archiviazione remota, aprendo per loro le porte nel mondo dei volumi effimeri locali.Per utilizzarlo (CASE) è necessario abilitare il feature gate CSIInlineVolume. C'è stato un progresso anche nelle 'interno' di Kubernetes, relativo al CSI, che non è così evidente per gli utenti finali (amministratori di sistema)… Attualmente, gli sviluppatori sono costretti a mantenere due versioni di ciascun plugin di storage: una 'alla vecchia maniera', all'interno della base di codice K8s (in-tree), e l'altra all'interno del nuovo CSI

(per ulteriori dettagli, leggi ad esempio in . Questo comporta inconvenienti comprensibili che devono essere risolti man mano che il CSI si stabilizza. Semplicemente dichiarare obsoleti (deprecated) le API dei plugin interni (in-tree) non è possibile a causa di qui)Questo comporta inconvenienti comprensibili che devono essere risolti man mano che il CSI si stabilizza. È semplicemente impossibile dichiarare obsoleti (deprecated) le API dei plugin interni (in-tree) per il semplice fatto che politiche corrispondenti di Kubernetes.

Tutto ciò ha portato al raggiungimento delle versioni alpha processo di migrazione codice interno dei plugin, implementati come in-tree, nei plugin CSI, il che significa che le preoccupazioni degli sviluppatori saranno ridotte a supportare una sola versione dei loro plugin, mentre la compatibilità con le API vecchie sarà mantenuta e potranno essere dichiarate deprecate secondo lo scenario abituale. Si prevede che entro il prossimo rilascio di Kubernetes (1.15) verrà completata la migrazione di tutti i plugin dei provider cloud, e l'implementazione otterrà lo stato di versione beta e sarà attivata nelle installazioni K8s per impostazione predefinita. Per ulteriori dettagli, vedere design proposal. Una conseguenza di questa migrazione è stata la rimozione la rimozione delle limitazioni per i volumi definiti da specifici provider cloud (AWS, Azure, GCE, Cinder).

Inoltre, il supporto per i dispositivi di blocco con CSI (CSIBlockVolume) è stato portato in versione beta.

Nodi / Kubelet

È stata introdotta la versione alpha di un nuovo endpoint in Kubelet, destinato a fornire metriche sui principali risorse. In generale, prima Kubelet riceveva statistiche sull'uso dei contenitori da cAdvisor, mentre ora questi dati provengono dall'ambiente di esecuzione del contenitore tramite CRI (Container Runtime Interface), ma è mantenuta la compatibilità con le vecchie versioni di Docker. In precedenza, le statistiche raccolte in Kubelet venivano fornite tramite API REST, mentre ora si utilizza un endpoint situato all'indirizzo /metrics/resource/v1alpha1. La strategia a lungo termine degli sviluppatori è quella di ridurre al minimo il set di metriche fornite da Kubelet. A proposito, queste metriche stesse sono ora chiamate non “metriche core”, ma “metriche delle risorse”, e descrivono come “risorse di prima classe, come CPU e memoria”.

Un aspetto interessante: nonostante il chiaro vantaggio in termini di prestazioni dell'endpoint gRPC rispetto a vari casi d'uso del formato Prometheus (il risultato di uno dei benchmark è riportato di seguito), gli autori hanno preferito il formato di testo di Prometheus a causa del chiaro predominio di questo sistema di monitoraggio nella comunità.

“gRPC non è compatibile con i principali pipeline di monitoraggio. Tuttavia, l'endpoint sarà utile solo per fornire metriche al Metrics Server o ai componenti di monitoraggio che si integrano direttamente con esso. Utilizzando la cache nel Metrics Server, le prestazioni del formato di testo di Prometheus sono abbastanza buone. per noi, per preferire Prometheus invece di gRPC, considerando la sua ampia diffusione nella comunità. Quando il formato OpenMetrics diventerà più stabile, potremo avvicinarci alle prestazioni di gRPC utilizzando un formato basato su proto.

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

Tra le altre modifiche:

• Kubelet ora (una sola volta) cerca di fermare i container in stato sconosciuto (unknown) prima delle operazioni di riavvio e cancellazione.
• Quando utilizzi PodPresets ora viene aggiunta al container init la stessa informazione che al container normale. ha iniziato a utilizzare
• Kubelet usageNanoCores dal provider di statistiche CRI, e per i nodi e i container in Windows statistiche di rete. è stata aggiunta Le informazioni sul sistema operativo e sull'architettura ora vengono registrate nelle etichette
• kubernetes.io/os kubernetes.io/arch e degli oggetti Node (tradotto da beta a GA). La possibilità di specificare un gruppo specifico di utenti del sistema per i container nel pod (
• RunAsGroup) è stata introdotta inK8s 1.11 ha progredito) alla versione beta (attivata per impostazione predefinita). du e find, utilizzati in cAdvisor,
• sono stati sostituiti da implementazioni in Go. Nel cli-runtime e kubectl

CLI

il flag -k per l'integrazione con è stata aggiunta (tra l'altro, il suo sviluppo ora si svolge in un repository separato), cioè per gestire file YAML aggiuntivi da directory speciali di kustomization (dettagli sul loro utilizzo possono essere found in kustomize Esempio di utilizzo semplice di un file KEP):

kustomization (possibile anche applicazione più complessa di kustomize nell'ambito di nuova comando overlay)

Inoltre:

• È stata aggiunta kubectl create cronjob , il cui nome parla da sé.unire
• In kubectl logs senza fornitori di cloud obsolete («integrati» in albero) (versione alfa). i flag flag -f (per il flusso dei log) e --selector -l (per la query delle etichette). hanno imparato
• kubectl a copiare file selezionati tramite wild card. kubectl wait
• Nel team --all hanno aggiunto flag per selezionare tutte le risorse nello spazio dei nomi di un determinato tipo di risorse. Le seguenti funzionalità hanno ricevuto uno stato stabile (GA):

Altri

ReadinessGate

• , utilizzato nella specifica del pod per definire condizioni aggiuntive considerate nella prontezza del pod;Supporto per le grandi pagine (feature gate chiamato
• HugePages CustomPodDNS);
• PriorityClass API,;
• Pod Priority & Preemption Altre modifiche presentate in Kubernetes 1.14:.

La politica RBAC predefinita non concede più accesso all'API

• discovery access-review e agli utenti non autenticati (unauthenticated) Il supporto ufficiale per CoreDNS.
• è garantito è garantito solo per Linux, quindi quando si utilizza kubeadm per il suo (CoreDNS) deployment nel cluster, i nodi devono funzionare solo in Linux (per questo si utilizzano i nodeSelectors).
• La configurazione di CoreDNS predefinita ora utilizza plugin forward invece di proxy. Inoltre, in CoreDNS è stata aggiunta readinessProbe, che impedisce il bilanciamento del carico sui pod corrispondenti (non pronti per il servizio).
• In kubeadm, nelle fasi join o upload-certs, è diventato possibile caricare i certificati necessari per connettere un nuovo control-plane al segreto kubeadm-certs (si usa il flag --experimental-upload-certs).
• Per le installazioni Windows è disponibile una versione alpha supporto gMSA (Group Managed Service Account) - conti speciali in Active Directory, che possono essere utilizzati anche dai container.
• Per GCE è stato attivato la crittografia mTLS tra etcd e kube-apiserver.
• Aggiornamenti nei software utilizzati/dipendenti: 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 è diventata 1.26.

P.S.

Leggi anche nel nostro blog:

• «Introduzione a Kustomize»;
• «🥇Kubernetes 1.16: panoramica delle principali novità | ProHoster»;
• «Kubernetes 1.11: panoramica delle principali novità»;
• «Kubernetes 1.10: panoramica delle principali novità».

Fonte: habr.com