Questa notte è stato pubblicato un nuovo rilascio di Kubernetes — . Come consuetudine nel nostro blog, vi raccontiamo i cambiamenti chiave nella nuova versione di questo straordinario prodotto Open Source.
Le informazioni utilizzate per preparare questo materiale provengono da , e dai rispettivi issue, pull request, Proposte di Miglioramento di Kubernetes (KEP).
Iniziamo con un'importante introduzione da SIG cluster-lifecycle: cluster dinamici e resilienti Kubernetes (o, per essere più precisi, deployment HA self-hosted) ora utilizzando i comandi familiari (nel contesto di cluster con un solo nodo) kubeadm (init e join). In breve, per questo:
- i certificati utilizzati dal cluster vengono trasferiti nei segreti;
- per abilitare l'utilizzo del cluster etcd all'interno del cluster K8s (cioè per eliminare la dipendenza esterna esistente) è stato introdotto ;
- vengono documentate le configurazioni raccomandate per un bilanciatore di carico esterno che assicura una configurazione resiliente (in futuro si prevede di eliminare anche questa dipendenza, ma non in questa fase).
Architettura del cluster HA di Kubernetes, creata con kubeadm
Puoi trovare i dettagli sull'implementazione in . Questa funzione era davvero attesa: la versione alfa era prevista già in K8s 1.9, ma è disponibile solo adesso.
API
Team applica e in generale gestione dichiarativa degli oggetti di kubectl in 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", motivo per cui questa funzionalità deve essere sistemata e trasferita nel control plane. Esempi semplici e chiari dei problemi attuali:
I dettagli sull'implementazione sono in . La disponibilità attuale è la versione alfa (il passaggio alla beta è previsto per la prossima release di Kubernetes).
Nella versione alfa è diventata disponibile l'uso dello schema OpenAPI v3 per la creazione e pubblicazione della documentazione OpenAPI per CustomResources (CR), utilizzati per la validazione (lato server) delle risorse K8s definite dall'utente (CustomResourceDefinition, CRD). La pubblicazione di OpenAPI per CRD consente ai client (ad esempio, kubectl) di eseguire la validazione sul proprio lato (nell'ambito di kubectl create e kubectl apply) e fornire documentazione secondo lo schema (kubectl spiega). Maggiori dettagli — in .
I log precedentemente esistenti con il flag O_APPEND (e non O_TRUNC) per evitare la perdita di log in alcune situazioni e per facilitare il truncamento dei log tramite strumenti esterni per la rotazione.
Inoltre, nel contesto dell'API di Kubernetes si può notare che in PodSandbox e PodSandboxStatus campo runtime_handler per tenere conto delle informazioni su RuntimeClass nel pod (leggi maggiori dettagli nel testo relativo a , dove questa classe è apparsa come versione alpha), e negli Admission Webhooks la possibilità di definire quali versioni AdmissionReview loro supportano. Infine, nelle regole degli Admission Webhooks ora l'ambito della loro applicazione ai namespace e alle forme del cluster.
I volumi
, precedentemente in stato di beta dal rilascio , stabili (GA): questo feature gate non può più essere disattivato e sarà rimosso in Kubernetes 1.17.
l'uso di variabili ambientali cosiddette (ad esempio, il nome del pod) per i nomi delle directory montate come , ha trovato uno sviluppo — sotto forma di un nuovo campo subPathExpr, grazie al quale ora viene definito il nome della directory necessaria. Questa funzionalità è stata introdotta in Kubernetes 1.11, ma è rimasta in fase alfa anche per la 1.14.
Come nel precedente rilascio di Kubernetes, sono state introdotte molte modifiche significative per il CSI (Container Storage Interface) in continua evoluzione:
CSI
È diventato disponibile (nell'ambito della fase alfa) la modifica delle dimensioni per i volumi CSI. Per utilizzare questa funzionalità, sarà necessario attivare la feature gate chiamata ExpandCSIVolumes, e assicurarsi che questa operazione sia supportata dal specifico driver CSI.
Un'altra funzionalità per CSI in fase alfa è la possibilità di riferirsi direttamente (ovvero senza utilizzare PV/PVC) ai volumi CSI all'interno delle specifiche dei pod. Questo rimuove la limitazione di utilizzare CSI come esclusivamente archivi di dati remoti, aprendo le porte a . Per l'utilizzo () è necessario attivare la feature gate CSIInlineVolume.
C'è stato progresso anche nelle «internals» di Kubernetes legate a CSI, che non sono così visibili agli utenti finali (amministratori di sistema)… Attualmente, gli sviluppatori sono costretti a mantenere due versioni di ogni plug-in di storage: una «alla vecchia maniera», all'interno del codice sorgente di K8s (in-tree), e l'altra all'interno del nuovo CSI. (per saperne di più, leggi ad esempio in ). Questo causa inconvenienti comprensibili che devono essere risolti man mano che il CSI si stabilizza come tale. Non è possibile semplicemente dichiarare obsoleti (deprecated) gli API dei plug-in interni (in-tree) a causa di .
Tutto ciò ha portato a raggiungere le versioni alfa del codice interno dei plug-in., implementate come in-tree, nei plugin CSI, il che ridurrà le preoccupazioni degli sviluppatori a mantenere una sola versione dei loro plugin, preservando la compatibilità con le API precedenti, che potranno essere dichiarate obsolete secondo lo scenario consueto. Si prevede che con la prossima release di Kubernetes (1.15) verrà effettuata la migrazione di tutti i plugin dei provider cloud, la realizzazione otterrà lo status di beta e sarà attivata nelle installazioni K8s per impostazione predefinita. Maggiori dettagli si trovano in . Una conseguenza di questa migrazione è stato di limitazioni per i volumi definiti da specifici provider cloud (AWS, Azure, GCE, Cinder).
Inoltre, il supporto per i dispositivi a blocchi con CSI (CSIBlockVolume) in versione beta.
Nodi / Kubelet
È stata introdotta una versione alpha in Kubelet, destinato a fornire metriche sulle risorse principali. In generale, mentre in precedenza Kubelet riceveva le statistiche sull'utilizzo dei container da cAdvisor, ora questi dati provengono dall'ambiente di esecuzione del container tramite CRI (Container Runtime Interface), mantenendo però la compatibilità con le vecchie versioni di Docker. In passato, le statistiche raccolte in Kubelet venivano fornite tramite API REST, mentre ora viene utilizzato un endpoint posizionato 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 non «core metrics», ma «resource metrics», e sono descritte come «first-class resources, such as cpu, and memory».
Un aspetto interessante: nonostante il chiaro vantaggio delle prestazioni dell'endpoint gRPC rispetto ai vari casi d'uso del formato Prometheus (il risultato di uno dei benchmark è riportato qui sotto), gli autori hanno preferito il formato testuale di Prometheus a causa del chiaro predominio di questo sistema di monitoraggio nella comunità.
gRPC non è compatibile con i principali pipeline di monitoraggio. 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 testuale di Prometheus sono abbastanza buone per noi da preferire a Prometheus piuttosto che a gRPC, dato il suo ampio utilizzo nella comunità. Quando il formato OpenMetrics diventerà più stabile, potremo avvicinarci alle prestazioni di gRPC utilizzando un formato basato su proto.
Uno dei test di prestazioni comparativi tra i formati gRPC e Prometheus nel nuovo endpoint di Kubelet per le metriche. Maggiori grafici e ulteriori dettagli possono essere trovati in .
Tra le altre modifiche:
- Kubelet ora (una sola volta) i contenitori in stato sconosciuto (unknown) prima delle operazioni di riavvio e eliminazione.
- Quando utilizzi ora l'init-container la stessa informazione che un normale contenitore.
- Kubelet
usageNanoCoresdal fornitore di statistiche CRI, e per i nodi e i contenitori in Windows statistiche di rete. - Le informazioni sul sistema operativo e sull'architettura vengono ora registrate nelle etichette
kubernetes.io/osekubernetes.io/archoggetti Node (trasferiti dalla beta a GA). - La possibilità di specificare un gruppo di utenti di sistema specifico per i container in un pod (
RunAsGroup, è stata introdotta in ) fino alla versione beta (attivata per impostazione predefinita). - du e find, utilizzati in cAdvisor, da implementazioni in Go.
CLI
In cli-runtime e kubectl il flag -k per l'integrazione con (tra l'altro, il suo sviluppo ora avviene in un repository separato), cioè per la gestione di file YAML aggiuntivi da directory di kustomization speciali (per dettagli su come usarli, vedere ):
Esempio di utilizzo semplice del file (è possibile anche un'applicazione più complessa di kustomize nell'ambito di )
Inoltre:
- è stato aggiunto un nuovo comando
kubectl create cronjob, il cui nome parla da solo. - In
kubectl logsora può con i flag-f(--followper lo streaming dei log) e-l(--selectorper la query delle etichette). - kubectl a copiare file selezionati usando i caratteri jolly.
- Nel comando
kubectl waitil flag--allper selezionare tutte le risorse nel namespace del tipo di risorse specificato.
Altre
Le seguenti funzionalità hanno ottenuto uno stato stabile (GA):
- , utilizzato nella specifica del pod per definire ulteriori condizioni considerate nella prontezza del pod;
- Supporto per pagine grandi (feature gate chiamato );
- ;
- API PriorityClass, .
Altre modifiche presentate in Kubernetes 1.14:
- La politica RBAC predefinita non fornisce più accesso all'API
discoveryeaccess-reviewutenti senza autenticazione (unauthenticated). - Il supporto ufficiale per CoreDNS solo per Linux, quindi quando si utilizza kubeadm per il suo (CoreDNS) deployment nel cluster, i nodi devono funzionare solo su Linux (per questa limitazione vengono utilizzati i nodeSelectors).
- La configurazione predefinita di CoreDNS ora il plugin forward anziché il proxy. Inoltre, in CoreDNS
- readinessProbe per prevenire il bilanciamento del carico verso i pod corrispondenti (non pronti per il servizio).
initoIn kubeadm, nelle fasi, è ora possibilecaricare i certificati necessari per collegare un nuovo control-plane al segreto kubeadm-certs (viene utilizzato il flag). - --experimental-upload-certs Per le installazioni Windows, è disponibile una versione alpha
- Per GCE crittografia mTLS tra etcd e kube-apiserver.
- Aggiornamenti nel software utilizzato/dipendente: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, supporto di Docker 18.09 in kubeadm, e la versione minima supportata dell'API Docker è diventata 1.26.
P.S.
Leggete anche nel nostro blog:
- «»;
- «»;
- «»;
- «».
Fonte: habr.com
