🥇Kubernetes 1.16: visió general de les principals innovacions

Avui dimecres, tindrà lloc propera versió de Kubernetes - 1.16. Segons la tradició que s'ha desenvolupat per al nostre blog, aquest és el desè aniversari que parlem dels canvis més significatius de la nova versió.

S'ha extret la informació utilitzada per preparar aquest material Taules de seguiment de millores de Kubernetes, REGISTRE DE CANVIS-1.16 i problemes relacionats, sol·licituds d'extracció i propostes de millora de Kubernetes (KEP). Així doncs, anem!...

Nodes

Al costat dels nodes del clúster K8s (Kubelet) es presenten un nombre realment gran d'innovacions notables (en estat de versió alfa).

En primer lloc, l'anomenat «contenidors efímers» (Contenidors efímers), dissenyat per simplificar els processos de depuració en pods. El nou mecanisme permet llançar contenidors especials que s'inicien a l'espai de noms dels pods existents i viuen durant un temps curt. El seu propòsit és interactuar amb altres pods i contenidors per resoldre qualsevol problema i depurar. S'ha implementat una comanda nova per a aquesta funció kubectl debug, semblant en essència a kubectl exec: només en lloc d'executar un procés en un contenidor (com en exec) llança un contenidor en una beina. Per exemple, aquesta ordre connectarà un contenidor nou a un pod:

kubectl debug -c debug-shell --image=debian target-pod -- bash

Els detalls sobre els contenidors efímers (i exemples del seu ús) es poden trobar a KEP corresponent. La implementació actual (a K8s 1.16) és una versió alfa, i entre els criteris per a la seva transferència a una versió beta hi ha "provar l'API Ephemeral Containers per a almenys 2 versions de [Kubernetes]".

NB: En la seva essència i fins i tot el seu nom, la característica s'assembla a un connector ja existent kubectl-debugsobre el qual nosaltres ja va escriure. S'espera que amb l'arribada dels contenidors efímers s'aturarà el desenvolupament d'un complement extern separat.

Una altra innovació - PodOverhead - dissenyat per oferir mecanisme per calcular els costos generals de les beines, que pot variar molt segons el temps d'execució utilitzat. Com a exemple, els autors aquest KEP donar lloc a Kata Containers, que requereixen executar el nucli convidat, l'agent kata, el sistema d'inici, etc. Quan les despeses generals es fan tan grans, no es poden ignorar, la qual cosa significa que s'ha d'haver una manera de tenir-les en compte per a més quotes, planificació, etc. Per implementar-lo en PodSpec camp afegit Overhead *ResourceList (compara amb les dades a RuntimeClass, si s'utilitza).

Una altra innovació notable és gestor de topologia de nodes (Gestor de topologia de nodes), dissenyat per unificar l'enfocament per ajustar l'assignació de recursos de maquinari per a diversos components a Kubernetes. Aquesta iniciativa ve impulsada per la creixent necessitat de diversos sistemes moderns (de l'àmbit de les telecomunicacions, l'aprenentatge automàtic, els serveis financers, etc.) per a la computació paral·lela d'alt rendiment i minimitzar els retards en l'execució de les operacions, per a la qual cosa utilitzen CPU avançades i capacitats d'acceleració de maquinari. Aquestes optimitzacions a Kubernetes s'han aconseguit fins ara gràcies a components dispars (gestor de CPU, gestor de dispositius, CNI), i ara s'afegirà una única interfície interna que unifica l'enfocament i simplifica la connexió de nous similars -anomenada topologia-. conscients: components del costat de Kubelet. Detalls - a KEP corresponent.

Diagrama de components del gestor de topologia

Següent característica - revisar els contenidors mentre estan en funcionament (sonda d'arrencada). Com sabeu, per als contenidors que triguen molt de temps a llançar-se, és difícil obtenir un estat actualitzat: o bé són "assassinats" abans de començar a funcionar, o bé acaben en un punt mort durant molt de temps. Comprovació nova (activada mitjançant la porta de funció trucada StartupProbeEnabled) cancel·la -o millor dit, ajorna- l'efecte de qualsevol altra comprovació fins al moment en què el pod ha acabat de funcionar. Per aquest motiu, la funció es va anomenar originalment pod-startup liveness-probe holdoff. Per als pods que triguen molt a començar, podeu consultar l'estat en intervals de temps relativament curts.

A més, una millora per a RuntimeClass està disponible immediatament en estat beta, afegint suport per a "clústers heterogenis". C Programació RuntimeClass Ara no és gens necessari que cada node tingui suport per a cada RuntimeClass: per als pods podeu seleccionar una RuntimeClass sense pensar en la topologia del clúster. Anteriorment, per aconseguir-ho, perquè els pods acabin en nodes amb suport per a tot el que necessiten, era necessari assignar regles adequades a NodeSelector i toleracions. EN KEP Parla d'exemples d'ús i, per descomptat, de detalls d'implementació.

Xarxa

Dues funcions de xarxa importants que van aparèixer per primera vegada (en versió alfa) a Kubernetes 1.16 són:

suport pila de xarxa dual: IPv4/IPv6 - i la seva "comprensió" corresponent a nivell de pods, nodes, serveis. Inclou la interoperabilitat d'IPv4 a IPv4 i d'IPv6 a IPv6 entre pods, des de pods fins a serveis externs, implementacions de referència (dins dels connectors Bridge CNI, PTP CNI i Host-Local IPAM), així com la compatibilitat inversa amb els clústers de Kubernetes en execució. Només IPv4 o IPv6. Els detalls d'implementació es troben KEP.
Un exemple de mostrar adreces IP de dos tipus (IPv4 i IPv6) a la llista de pods:
```
kube-master# kubectl get pods -o wide
NAME               READY     STATUS    RESTARTS   AGE       IP                          NODE
nginx-controller   1/1       Running   0          20m       fd00:db8:1::2,192.168.1.3   kube-minion-1
kube-master#
```
Nova API per a Endpoint - API EndpointSlice. Soluciona els problemes de rendiment/escalabilitat de l'API Endpoint existent que afecten diversos components del pla de control (apiserver, etcd, endpoints-controller, kube-proxy). La nova API s'afegirà al grup d'API Discovery i podrà servir desenes de milers de punts finals de backend a cada servei en un clúster format per milers de nodes. Per fer-ho, cada servei s'assigna a N objectes EndpointSlice, cadascun dels quals per defecte no té més de 100 punts finals (el valor és configurable). L'API EndpointSlice també oferirà oportunitats per al seu desenvolupament futur: suport per a diverses adreces IP per a cada pod, nous estats per als punts finals (no només Ready и NotReady), subconjunt dinàmic per als punts finals.

El presentat en la darrera versió ha arribat a la versió beta finalitzador, nomenat service.kubernetes.io/load-balancer-cleanup i s'adjunta a cada servei amb tipus LoadBalancer. En el moment de suprimir aquest servei, impedeix la supressió real del recurs fins que s'hagi completat la "neteja" de tots els recursos d'equilibrador rellevants.

Maquinària API

La veritable "fita d'estabilització" es troba a l'àrea del servidor API de Kubernetes i la interacció amb ell. Això va passar en gran part gràcies a transferir a un estat estable aquells que no necessiten una introducció especial Definicions de recursos personalitzades (CRD), que tenen estat beta des dels dies llunyans de Kubernetes 1.7 (i això és juny de 2017!). La mateixa estabilització va arribar a les característiques relacionades:

"subrecursos" amb /status и /scale per a CustomResources;
conversió versions per a CRD, basades en webhook extern;
presentat recentment (a K8s 1.15) valors per defecte (per defecte) i eliminació automàtica del camp (poda) per a CustomResources;
oportunitat utilitzant l'esquema OpenAPI v3 per crear i publicar la documentació OpenAPI utilitzada per validar els recursos CRD al costat del servidor.

Un altre mecanisme que fa temps que s'ha familiaritzat amb els administradors de Kubernetes: webhook d'admissió - també va romandre en estat beta durant molt de temps (des de K8s 1.9) i ara es declara estable.

Altres dues funcions han arribat a la versió beta: s'aplica al costat del servidor и mira els marcadors.

I l'única innovació significativa en la versió alfa va ser fracàs d' SelfLink — un URI especial que representa l'objecte especificat i en forma part ObjectMeta и ListMeta (és a dir, part de qualsevol objecte a Kubernetes). Per què l'abandonen? Motivació d'una manera senzilla sona com l'absència de raons reals (aclaparadores) perquè aquest camp encara existeixi. Raons més formals són optimitzar el rendiment (eliminant un camp innecessari) i simplificar el treball del genèric-apiserver, que es veu obligat a gestionar aquest camp d'una manera especial (aquest és l'únic camp que s'estableix just abans de l'objecte). està serialitzat). Obsolescència real (dins de la versió beta) SelfLink passarà per la versió 1.20 de Kubernetes i la versió final - 1.21.

Emmagatzematge de dades

El treball principal a l'àrea d'emmagatzematge, com en versions anteriors, s'observa a la zona Suport CSI. Els principals canvis aquí van ser:

per primera vegada (en versió alfa) va aparèixer Compatibilitat del connector CSI per als nodes de treball de Windows: la forma actual de treballar amb l'emmagatzematge també substituirà els connectors de l'arbre al nucli de Kubernetes i els connectors FlexVolume de Microsoft basats en Powershell;

Esquema per implementar connectors CSI a Kubernetes per a Windows
oportunitat canviar la mida dels volums CSI, introduït de nou a K8s 1.12, ha crescut fins a ser una versió beta;
Una "promoció" similar (d'alfa a beta) es va aconseguir gràcies a la capacitat d'utilitzar CSI per crear volums efímers locals (Suport de volum en línia CSI).

Introduït a la versió anterior de Kubernetes funció de clonació de volum (utilitzant PVC existent com a DataSource per crear un nou PVC) també ha rebut l'estat beta.

Programador

Dos canvis notables a la programació (tots dos en alfa):

EvenPodsSpreading - oportunitat utilitzeu pods en lloc d'unitats d'aplicacions lògiques per a una "distribució justa" de les càrregues (com Deployment i ReplicaSet) i ajustant aquesta distribució (com a requisit dur o com a condició suau, és a dir, prioritat). La funció ampliarà les capacitats de distribució existents dels pods planificats, actualment limitades per opcions PodAffinity и PodAntiAffinity, donant als administradors un control més fi en aquesta matèria, la qual cosa significa una millor alta disponibilitat i un consum de recursos optimitzat. Detalls - a KEP.
Utilitzar Política de BestFit в Funció de prioritat RequestedToCapacityRatio durant la planificació del pod, que permetrà per aplicar embalatge de paperera ("empaquetat en contenidors") tant per als recursos bàsics (processador, memòria) com per als estès (com la GPU). Per a més detalls, vegeu KEP.

Programació de pods: abans d'utilitzar la política de millor ajust (directament mitjançant el programador predeterminat) i amb el seu ús (mitjançant l'extensor del programador)

A més, representat per la possibilitat de crear els vostres propis complements de planificador fora de l'arbre de desenvolupament principal de Kubernetes (fora de l'arbre).

Altres canvis

També es pot assenyalar a la versió 1.16 de Kubernetes iniciativa per portant mètriques disponibles en tot ordre, o més precisament, d'acord amb normativa oficial a la instrumentació K8s. Es basen en gran mesura en el corresponent Documentació Prometeu. Les inconsistències van sorgir per diversos motius (per exemple, algunes mètriques simplement es van crear abans que apareguessin les instruccions actuals), i els desenvolupadors van decidir que era hora de portar-ho tot a un únic estàndard, "en línia amb la resta de l'ecosistema de Prometheus". La implementació actual d'aquesta iniciativa es troba en estat alfa, que anirà promocionant progressivament en versions posteriors de Kubernetes a beta (1.17) i estable (1.18).

A més, es poden observar els següents canvis:

Desenvolupament de suport de Windows с aparença Utilitats Kubeadm per a aquest sistema operatiu (versió alfa), oportunitat RunAsUserName per a contenidors de Windows (versió alfa), millora Compte de servei gestionat de grup (gMSA) suport fins a la versió beta, suport muntar/connectar per a volums vSphere.
Reciclat mecanisme de compressió de dades a les respostes de l'API. Anteriorment, s'utilitzava un filtre HTTP per a aquests propòsits, que imposava una sèrie de restriccions que impedien que s'habiliten per defecte. "Compressió de sol·licitud transparent" ara funciona: enviament de clients Accept-Encoding: gzip a la capçalera, reben una resposta comprimida amb GZIP si la seva mida supera els 128 KB. Els clients Go admeten automàticament la compressió (enviant la capçalera necessària), de manera que notaran immediatament una reducció del trànsit. (Potser calen petites modificacions per a altres idiomes.)
Es va fer possible escalar HPA de/a zero pods en funció de mètriques externes. Si escaleu en funció d'objectes/mètriques externes, quan les càrregues de treball estiguin inactives, podeu escalar automàticament a 0 rèpliques per estalviar recursos. Aquesta funció hauria de ser especialment útil per als casos en què els treballadors sol·liciten recursos de GPU i el nombre de diferents tipus de treballadors inactius supera el nombre de GPU disponibles.
client nou - k8s.io/client-go/metadata.Client — per a l'accés "generalitzat" als objectes. Està dissenyat per recuperar fàcilment metadades (és a dir, subsecció metadata) dels recursos del clúster i realitzar operacions de recollida d'escombraries i quotes amb ells.
Construeix Kubernetes ara pots sense proveïdors de núvol heretats (versió alfa).
A la utilitat kubeadm afegit capacitat experimental (versió alfa) d'aplicar pedaços personalitzats durant les operacions init, join и upgrade. Més informació sobre com utilitzar la bandera --experimental-kustomize, veure a KEP.
Nou punt final per a apiserver - readyz, - us permet exportar informació sobre la seva preparació. El servidor de l'API també té ara un indicador --maximum-startup-sequence-duration, que us permet regular els seus reinicis.
Dos funcions per a Azure declarat estable: suport zones de disponibilitat (Zones de disponibilitat) i grup de recursos creuats (RG). A més, Azure ha afegit:
- suport d'autenticació AAD i ADFS;
- resum service.beta.kubernetes.io/azure-pip-name per especificar la IP pública de l'equilibrador de càrrega;
- oportunitat настройки LoadBalancerName и LoadBalancerResourceGroup.
AWS ara ho té donar suport per a EBS a Windows i optimitzat Trucades a l'API EC2 DescribeInstances.
Kubeadm ara és independent migra Configuració de CoreDNS en actualitzar la versió de CoreDNS.
Binaris etc. a la imatge de Docker corresponent han fet executable mundialment, que us permet executar aquesta imatge sense necessitat de drets d'arrel. També, imatge de migració etcd ha cessat Compatibilitat amb la versió etcd2.
В Clúster Autoscaler 1.16.0 es va canviar a utilitzar distroless com a imatge base, millora el rendiment, s'han afegit nous proveïdors de núvol (DigitalOcean, Magnum, Packet).
Actualitzacions del programari utilitzat/depenent: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

PS

Llegeix també al nostre blog:

Font: www.habr.com

Kubernetes 1.16: aspectes destacats de les novetats