🥇Kubernetes 1.17: visión xeral das principais novidades

Onte, 9 de decembro, tivo lugar próxima versión de Kubernetes - 1.17. Segundo a tradición que se desenvolveu para o noso blog, falamos dos cambios máis significativos da nova versión.

A información utilizada para preparar este material está tomada do anuncio oficial, Táboas de seguimento de melloras de Kubernetes, CAMBIOS-1.17 e problemas relacionados, solicitudes de extracción e propostas de mellora de Kubernetes (KEP). Entón, que hai de novo?...

Enrutamento consciente da topoloxía

A comunidade de Kubernetes estivo esperando por esta función durante moito tempo. Enrutamento de servizos con coñecemento de topoloxía. Se CAP ten a súa orixe en outubro de 2018, e o oficial valoración — Hai 2 anos, os problemas habituais (como el) - e uns anos máis...

A idea xeral é proporcionar a capacidade de implementar o enrutamento "local" para os servizos que residen en Kubernetes. "Localidade" neste caso significa "o mesmo nivel topolóxico" (nivel de topoloxía), que pode ser:

nodo idéntico para servizos,
o mesmo rack de servidor,
a mesma rexión
o mesmo provedor de nube,
...

Exemplos de uso desta función:

aforro no tráfico en instalacións na nube con varias zonas de dispoñibilidade (multi-AZ) - ver. ilustración fresca usando o exemplo de tráfico da mesma rexión, pero diferentes AZ en AWS;
menor latencia de rendemento/mellor rendemento;
un servizo fragmentado que ten información local sobre o nodo en cada fragmento;
colocación de fluentd (ou análogos) no mesmo nodo coas aplicacións cuxos rexistros se recollen;
...

Este enrutamento, que "coñece" a topoloxía, tamén se denomina afinidade de rede, por analoxía con afinidade de nodos, afinidade de vaina/antiafinidade ou apareceu non hai moito tempo Programación de volumes consciente da topoloxía (e Aprovisionamento de volume). Nivel actual de implantación ServiceTopology en Kubernetes - versión alfa.

Para obter máis información sobre como funciona a función e como xa podes usala, le Este artigo dun dos autores.

Soporte de pila dual IPv4/IPv6

Progreso significativo fixo noutra función de rede: soporte simultáneo para dúas pilas IP, que se introduciu por primeira vez en K8s 1.16. En particular, a nova versión trouxo os seguintes cambios:

en kube-proxy implementado posibilidade de funcionamento simultáneo en ambos os modos (IPv4 e IPv6);
в Pod.Status.PodIPs apareceu soporte para API descendente (ao mesmo tempo que en /etc/hosts agora esixen que o host engada un enderezo IPv6);
soporte de pila dual TIPO (Kubernetes IN Docker) e kubeadm;
probas e2e actualizadas.

Ilustración usando IPV4/IPv6 de pila dual en especie

Avances en CSI

Declarado estable soporte de topoloxía para o almacenamento baseado en CSI, introducido por primeira vez en K8s 1.12.

Iniciativa para migración de complementos de volume a CSI - Migración CSI - versión beta alcanzada. Esta función é fundamental para traducir os complementos de almacenamento existentes (en árbore) a unha interface moderna (CSI, fóra da árbore) invisible para os usuarios finais de Kubernetes. Os administradores do clúster só terán que activar a migración CSI, despois de que os recursos e cargas de traballo con estado existentes seguirán "só funcionando"... pero utilizando os controladores CSI máis recentes en lugar dos obsoletos incluídos no núcleo de Kubernetes.

Polo momento, a migración para os controladores de AWS EBS está lista na versión beta (kubernetes.io/aws-ebs) e GCE PD (kubernetes.io/gce-pd). As previsións para outras instalacións de almacenamento son as seguintes:

Falamos sobre como chegou a CSI a compatibilidade de almacenamento "tradicional" nos K8 Este artigo. E a transición da migración CSI ao estado beta está dedicada publicación separada no blog do proxecto.

Ademais, outra funcionalidade significativa no contexto de CSI, que se orixina (implementación alfa) en K1.17s 8, alcanzou o estado beta (é dicir, activada por defecto) na versión de Kubernetes 1.12. creando instantáneas e recuperación deles. Entre os cambios realizados en Kubernetes Volume Snapshot no camiño da versión beta:

dividindo o sidecar de instantáneas externas CSI en dous controladores,
segredo engadido para eliminalo (segredo de eliminación) como anotación ao contido dunha instantánea de volume,
novo finalizador (finalizador) para evitar que se elimine o obxecto da API de instantánea se quedan conexións restantes.

No momento da versión 1.17, a función é compatible con tres controladores CSI: GCE Persistent Disk CSI Driver, Portworx CSI Driver e NetApp Trident CSI Driver. Pódense atopar máis detalles sobre a súa implementación e uso en esta publicación no blog.

Etiquetas de provedores de nube

Etiquetas que automaticamente asignado aos nodos e volumes creados dependendo do provedor de nube utilizado, estiveron dispoñibles en Kubernetes como versión beta durante moito tempo, desde o lanzamento de K8s 1.2 (Abril 2016!). Dado o seu uso xeneralizado durante tanto tempo, os desenvolvedores decidiu, que é hora de declarar a característica estable (GA).

Polo tanto, todos eles foron renomeados en consecuencia (por topoloxía):

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

... pero aínda están dispoñibles cos seus antigos nomes (para compatibilidade con versións anteriores). Non obstante, recoméndase a todos os administradores que cambien ás etiquetas actuais. Documentación relacionada K8s actualizouse.

Saída estruturada de kubeadm

Presentado en versión alfa por primeira vez saída estruturada para a utilidade kubeadm. Formatos compatibles: JSON, YAML, modelo Go.

Motivación para implementar esta función (segundo CAP) é:

Aínda que Kubernetes se pode despregar manualmente, o estándar de feito (se non de iure) para esta operación é usar kubeadm. As ferramentas populares de xestión de sistemas como Terraform confían en kubeadm para a implantación de Kubernetes. As melloras previstas na API do clúster inclúen un paquete compoñente para o arranque de Kubernetes con kubeadm e cloud-init.

Sen saída estruturada, incluso os cambios máis inocuos a primeira vista poden romper Terraform, Cluster API e outro software que utiliza os resultados de kubeadm.

Os nosos plans inmediatos inclúen soporte (en forma de saída estruturada) para os seguintes comandos kubeadm:

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

Ilustración dunha resposta JSON a un comando 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="
}

Estabilización doutras innovacións

En xeral, o lanzamento de Kubernetes 1.17 tivo lugar baixo o lema "Estabilidade" Isto foi facilitado polo feito de que moitas características nel (o seu número total é 14) recibiu o estado de GA. Entre eles:

“marcar” os nodos segundo determinadas condicións (TaintNodesByCondition), apareceu en K8s 1.8;
Ver Marcadores - un novo tipo de eventos que teñen unha etiqueta que indica que todos os obxectos están ata unha determinada versión (resourceVersion) xa foron procesados por reloxo;
valores predeterminados (por defecto) para Recursos personalizados;
compartida entre contedores nos espazos de nomes do proceso pod;
ScheduleDaemonSetPods - pods de programación en DaemonSet usando kube-scheduler (en lugar do controlador DaemonSet);
límites dinámicos sobre o número de volumes dependendo do tipo de nodo;
soporte de variables de ambiente para os nomes de directorio montados como subPath;
Transferencia de latidos do corazón de Kubelet a unha API de arrendamento especializada;
"protección do finalizador" (Protección do finalizador) para equilibradores de carga (comprobando os recursos do servizo correspondentes antes de eliminar os recursos de LoadBalancer);
optimización de kube-apserver no rendemento cando se traballa con varios reloxos monitorizando conxuntos idénticos de obxectos - conseguido evitando a serialización repetida dos mesmos obxectos para cada observador.

Outros cambios

A lista completa de innovacións en Kubernetes 1.17, por suposto, non se limita ás listadas anteriormente. Aquí tes algúns outros (e para unha lista máis completa, vexa REGISTRO DE CAMBIOS):

A función presentada na última versión chegou á versión beta RunAsUserName para windows;
cambio similar caeu API de EndpointSlice (tamén de K8s 1.16), porén, polo momento, esta solución para mellorar o rendemento/escalabilidade da API de Endpoint non está activada por defecto;
Os pods son agora críticos para o funcionamento do clúster pódese crear non só nos espazos de nomes kube-system (para máis detalles, consulte a documentación de Limitar o consumo da clase prioritaria);
nova opción para kubelet - --reserved-cpus — permite definir explícitamente a lista de CPU reservadas para o sistema;
para kubectl logs presentado nova bandeira --prefix, engadindo o nome do recipiente e do recipiente de orixe a cada liña do rexistro;
в label.Selector engadido RequiresExactMatch;
todos os contedores en kube-dns agora están en execución con menos privilexios;
hipercubo separado nun repositorio GitHub separado e xa non se incluirá nas versións de Kubernetes;
moi rendemento mellorado kube-proxy para portos non UDP.

Cambios de dependencia:

A versión de CoreDNS incluída en kubeadm é 1.6.5;
versión crictl actualizada á v1.16.1;
CSI 1.2.0;
etcd 3.4.3;
A última versión probada de Docker actualizouse á 19.03;
A versión mínima de Go necesaria para crear Kubernetes 1.17 é 1.13.4.

PS

Lea tamén no noso blog:

Fonte: www.habr.com

Kubernetes 1.17: visión xeral das principais novidades