🥇Kubernetes 1.17: visió general de les principals innovacions

Ahir, 9 de desembre, tingué lloc propera versió de Kubernetes - 1.17. Segons la tradició que s'ha desenvolupat per al nostre blog, parlem dels canvis més significatius de la nova versió.

La informació utilitzada per preparar aquest material prové de l'anunci oficial, Taules de seguiment de millores de Kubernetes, REGISTRE DE CANVIS-1.17 i problemes relacionats, sol·licituds d'extracció i propostes de millora de Kubernetes (KEP). Què hi ha de nou?..

Encaminament conscient de la topologia

La comunitat de Kubernetes fa temps que espera aquesta funció: Encaminament de serveis conscients de la topologia. Si KEP té el seu origen a l'octubre de 2018, i l'oficial realç — Fa 2 anys, els problemes habituals (M'agrada el) - i uns quants anys més...

La idea general és oferir la possibilitat d'implementar l'encaminament "local" per als serveis que resideixen a Kubernetes. "Localitat" en aquest cas significa "el mateix nivell topològic" (nivell de topologia), que pot ser:

node idèntic per als serveis,
el mateix bastidor de servidors,
la mateixa regió
el mateix proveïdor de núvol,
...

Exemples d'ús d'aquesta funció:

estalvi de trànsit en instal·lacions al núvol amb zones de disponibilitat múltiples (multi-AZ) - vegeu. il·lustració fresca utilitzant l'exemple de trànsit de la mateixa regió, però diferents AZ a AWS;
menor latència de rendiment/millor rendiment;
un servei fragmentat que té informació local sobre el node de cada fragment;
col·locació de fluentd (o anàlegs) al mateix node amb les aplicacions els registres de les quals es recullen;
...

Aquest enrutament, que "coneix" la topologia, també s'anomena afinitat de xarxa, per analogia amb afinitat de nodes, afinitat/antiafinitat de la beina o va aparèixer no fa tant Programació de volums conscient de la topologia (i Aprovisionament de volum). Nivell actual d'implementació ServiceTopology a Kubernetes - versió alfa.

Per obtenir més informació sobre com funciona la funció i com ja la podeu utilitzar, llegiu aquest article d'un dels autors.

Suport de doble pila IPv4/IPv6

Progrés significatius fixat en una altra característica de xarxa: suport simultani per a dues piles IP, que es va introduir per primera vegada a K8s 1.16. En particular, la nova versió va comportar els canvis següents:

en kube-proxy implementat possibilitat de funcionament simultani en ambdues modalitats (IPv4 i IPv6);
в Pod.Status.PodIPs va aparèixer suport per a l'API descendent (al mateix temps que en /etc/hosts ara requereixen que l'amfitrió afegeixi una adreça IPv6);
suport de doble pila AMABLE (Kubernetes IN Docker) i kubeadm;
proves e2e actualitzades.

Il·lustració utilitzant IPV4/IPv6 de doble pila en CIND

Avenços en CSI

Declarat estable suport de topologia per a l'emmagatzematge basat en CSI, introduït per primera vegada a K8s 1.12.

Iniciativa per migració de connectors de volum a CSI - Migració CSI - S'ha arribat a la versió beta. Aquesta característica és fonamental per traduir els connectors d'emmagatzematge existents (dins l'arbre) a una interfície moderna (CSI, fora de l'arbre) invisible per als usuaris finals de Kubernetes. Els administradors de clúster només hauran d'habilitar la migració CSI, després de la qual els recursos i les càrregues de treball amb estat existents continuaran "funcionant"... però utilitzant els darrers controladors CSI en comptes dels obsolets inclosos al nucli de Kubernetes.

De moment, la migració per als controladors AWS EBS està preparada en versió beta (kubernetes.io/aws-ebs) i GCE PD (kubernetes.io/gce-pd). Les previsions per a altres instal·lacions d'emmagatzematge són les següents:

Hem parlat de com el suport d'emmagatzematge "tradicional" a K8 va arribar a CSI aquest article. I es dedica a la transició de la migració de CSI a l'estat beta publicació separada al blog del projecte.

A més, una altra funcionalitat significativa en el context de CSI, que s'origina (implementació alfa) a K1.17s 8, va arribar a l'estat beta (és a dir, habilitat per defecte) a la versió de Kubernetes 1.12 - creant instantànies i la recuperació d'ells. Entre els canvis fets a Kubernetes Volume Snapshot en el camí cap a la versió beta:

dividint el sidecar de la instantània externa CSI en dos controladors,
secret afegit per esborrar (secret d'eliminació) com a anotació del contingut d'una instantània de volum,
nou finalitzador (finalitzador) per evitar que l'objecte de l'API de la instantània se suprimeixi si hi ha connexions restants.

En el moment de la versió 1.17, la funció és compatible amb tres controladors CSI: el controlador CSI de disc persistent GCE, el controlador CSI Portworx i el controlador CSI Trident de NetApp. Podeu trobar més detalls sobre la seva implementació i ús a aquesta publicació al blog.

Etiquetes de proveïdors de núvol

Etiquetes que automàticament assignat als nodes i volums creats en funció del proveïdor de núvol utilitzat, han estat disponibles a Kubernetes com a versió beta durant molt de temps, des del llançament de K8s 1.2 (abril de 2016!). Donat el seu ús generalitzat durant tant de temps, els desenvolupadors decidit, que és hora de declarar la característica estable (GA).

Per tant, tots es van canviar de nom en conseqüència (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

... però encara estan disponibles amb els seus noms antics (per compatibilitat amb versions anteriors). Tanmateix, es recomana a tots els administradors que canviïn a les etiquetes actuals. Documentació relacionada K8s s'ha actualitzat.

Sortida estructurada de kubeadm

Presentat en versió alfa per primera vegada sortida estructurada per a la utilitat kubeadm. Formats compatibles: plantilla JSON, YAML, Go.

Motivació per implementar aquesta característica (segons KEP) és:

Tot i que Kubernetes es pot desplegar manualment, l'estàndard de facto (si no de jure) per a aquesta operació és utilitzar kubeadm. Les eines de gestió de sistemes populars com Terraform depenen de kubeadm per al desplegament de Kubernetes. Les millores previstes a l'API del clúster inclouen un paquet componible per a l'arrencada de Kubernetes amb kubeadm i cloud-init.

Sense una sortida estructurada, fins i tot els canvis més innòcus a primera vista poden trencar Terraform, Cluster API i altres programaris que utilitzin els resultats de kubeadm.

Els nostres plans immediats inclouen suport (en forma de sortida estructurada) per a les ordres kubeadm següents:

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

Il·lustració d'una resposta JSON a una ordre 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="
}

Estabilització d'altres innovacions

En general, el llançament de Kubernetes 1.17 va tenir lloc sota el lema "Estabilitat" Això es va veure facilitat pel fet que hi ha moltes funcions (el seu nombre total és 14) va rebre l'estat de GA. Entre ells:

"marcar" nodes segons determinades condicions (TaintNodesByCondition), va aparèixer a K8s 1.8;
Mira els marcadors - un nou tipus d'esdeveniments que tenen una etiqueta que indica que tots els objectes tenen una versió determinada (resourceVersion) ja s'han processat per rellotge;
valors per defecte (per defecte) per a Recursos personalitzats;
compartit entre contenidors als espais de noms del procés de pod;
ScheduleDaemonSetPods - pods de programació a DaemonSet utilitzant kube-scheduler (en lloc del controlador DaemonSet);
límits dinàmics sobre el nombre de volums en funció del tipus de node;
suport variable d'entorn per als noms de directoris muntats com a subPath;
Transferència de batecs del cor de Kubelet a una API d'arrendament especialitzada;
"protecció del finalitzador" (Protecció del finalitzador) per als equilibradors de càrrega (comprovant els recursos de servei corresponents abans de suprimir els recursos de LoadBalancer);
optimització de kube-apserver en rendiment quan es treballa amb diversos rellotges monitoritzant conjunts idèntics d'objectes; s'aconsegueix evitant la serialització repetida dels mateixos objectes per a cada observador.

Altres canvis

La llista completa d'innovacions de Kubernetes 1.17, per descomptat, no es limita a les enumerades anteriorment. Aquí hi ha alguns altres (i per a una llista més completa, vegeu REGISTRE DE CANVIS):

La funció presentada a la darrera versió ha arribat a la versió beta RunAsUserName per a finestres;
canvi similar va caure API EndpointSlice (també de K8s 1.16), però de moment aquesta solució per millorar el rendiment/escalabilitat de l'API Endpoint no està habilitada per defecte;
ara els pods són fonamentals per al funcionament del clúster es pot crear no només als espais de noms kube-system (per a més detalls, consulteu la documentació de Limitar el consum de classes prioritàries);
nova opció per a kubelet - --reserved-cpus — us permet definir explícitament la llista de CPU reservades per al sistema;
per kubectl logs presentat nova bandera --prefix, afegint el nom del pod i el contenidor d'origen a cada línia del registre;
в label.Selector afegit RequiresExactMatch;
tots els contenidors a kube-dns ara estan en funcionament amb menys privilegis;
hiperkube separat en un repositori GitHub separat i ja no s'inclourà a les versions de Kubernetes;
molt rendiment millorat kube-proxy per a ports que no són UDP.

Canvis de dependència:

La versió CoreDNS inclosa a kubeadm és la 1.6.5;
versió de crictl actualitzada a v1.16.1;
CSI 1.2.0;
etcd 3.4.3;
L'última versió de Docker provada s'ha actualitzat a 19.03;
La versió mínima de Go necessària per crear Kubernetes 1.17 és la 1.13.4.

PS

Llegeix també al nostre blog:

Font: www.habr.com

Kubernetes 1.17: aspectes destacats de les novetats