🥇Kubernetes 1.17: resumen de las principales innovaciones

Ayer 9 de diciembre tuvo lugar próxima versión de Kubernetes: 1.17. Siguiendo la tradición que se ha desarrollado en nuestro blog, hablamos de los cambios más significativos de la nueva versión.

La información utilizada para elaborar este material está extraída del anuncio oficial, Tablas de seguimiento de mejoras de Kubernetes, REGISTRO DE CAMBIOS-1.17 y problemas relacionados, solicitudes de extracción y propuestas de mejora de Kubernetes (KEP). ¿Qué hay de nuevo?..

Enrutamiento consciente de la topología

La comunidad de Kubernetes ha estado esperando esta característica durante mucho tiempo. Enrutamiento de servicios consciente de la topología. Si KEP se origina en octubre de 2018, y el oficial Estrategias orientadas — Hace 2 años, los problemas habituales. (como lo) - y unos años más mayor...

La idea general es brindar la capacidad de implementar enrutamiento "local" para servicios que residen en Kubernetes. "Localidad" en este caso significa "el mismo nivel topológico" (nivel de topología), que puede ser:

nodo idéntico para servicios,
el mismo rack de servidores,
la misma región
el mismo proveedor de nube,
...

Ejemplos de uso de esta característica:

ahorros en tráfico en instalaciones en la nube con múltiples zonas de disponibilidad (multi-AZ) - ver. ilustración fresca usando el ejemplo del tráfico de la misma región, pero diferentes AZ en AWS;
menor latencia de rendimiento/mejor rendimiento;
un servicio fragmentado que tiene información local sobre el nodo en cada fragmento;
colocación de fluentd (o análogos) en el mismo nodo con las aplicaciones cuyos registros se recopilan;
...

Este enrutamiento, que "conoce" la topología, también se denomina afinidad de red, por analogía con afinidad de nodo, afinidad/antiafinidad de pods o apareció no hace mucho tiempo Programación de volúmenes basada en topología (y Aprovisionamiento de volumen). Nivel actual de implementación ServiceTopology en Kubernetes - versión alfa.

Para obtener detalles sobre cómo funciona la función y cómo ya puedes usarla, lee este artículo de uno de los autores.

Compatibilidad con doble pila IPv4/IPv6

Progreso significativo reparado en otra característica de la red: soporte simultáneo para dos pilas de IP, que se introdujo por primera vez en K8 1.16. En particular, la nueva versión trajo los siguientes cambios:

en kube-proxy implementado posibilidad de funcionamiento simultáneo en ambos modos (IPv4 e IPv6);
в Pod.Status.PodIPs apareció soporte para API descendente (al mismo tiempo que en /etc/hosts ahora requieren que el host agregue una dirección IPv6);
soporte de doble pila TIPO (Kubernetes EN Docker) y kubeadm;
Pruebas e2e actualizadas.

Ilustración usando IPV4/IPv6 de doble pila en KIND

Progreso en CSI

Declarado estable soporte de topología para almacenamiento basado en CSI, introducido por primera vez en K8 1.12.

Iniciativa para migración de complementos de volumen a CSI - Migración CSI - alcanzó la versión beta. Esta característica es fundamental para traducir complementos de almacenamiento existentes. (en el árbol) a una interfaz moderna (CSI, fuera del árbol) invisible para los usuarios finales de Kubernetes. Los administradores de clústeres solo necesitarán habilitar la migración CSI, después de lo cual los recursos con estado y las cargas de trabajo existentes continuarán "simplemente funcionando"... pero utilizando los controladores CSI más recientes en lugar de los obsoletos incluidos en el núcleo de Kubernetes.

Por el momento, la migración de los controladores de AWS EBS está lista en versión beta (kubernetes.io/aws-ebs) y GCE PD (kubernetes.io/gce-pd). Las previsiones para el resto de instalaciones de almacenamiento son las siguientes:

Hablamos sobre cómo el soporte de almacenamiento "tradicional" en K8 llegó a CSI en este artículo. Y la transición de la migración de CSI al estado beta está dedicada a publicación separada en el blog del proyecto.

Además, otra funcionalidad importante en el contexto de CSI, que se origina (implementación alfa) en K1.17s 8, alcanzó el estado beta (es decir, habilitada de forma predeterminada) en la versión Kubernetes 1.12: creando instantáneas y recuperación de ellos. Entre los cambios realizados en Kubernetes Volume Snapshot en camino a la versión beta:

dividir el sidecar de instantánea externa CSI en dos controladores,
secreto agregado para eliminación (secreto de eliminación) como una anotación al contenido de una instantánea de volumen,
nuevo finalizador (finalizador) para evitar que el objeto API de instantánea se elimine si quedan conexiones.

En el momento de la versión 1.17, la función es compatible con tres controladores CSI: controlador CSI de disco persistente GCE, controlador CSI Portworx y controlador CSI Trident de NetApp. Más detalles sobre su implementación y uso se pueden encontrar en esta publicacion en el blog.

Etiquetas de proveedor de nube

Etiquetas que automáticamente asignado a nodos y volúmenes creados según el proveedor de nube utilizado, están disponibles en Kubernetes como versión beta desde hace mucho tiempo, desde el lanzamiento de K8s 1.2 (¡Abril de 2016!). Dado su uso generalizado durante tanto tiempo, los desarrolladores decidió, que es hora de declarar la característica estable (GA).

Por lo tanto, se les cambió el nombre a todos en consecuencia (por topologí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 todavía están disponibles con sus nombres antiguos (para compatibilidad con versiones anteriores). Sin embargo, se recomienda a todos los administradores que cambien a las etiquetas actuales. Documentación relacionada K8s ha sido actualizado.

Salida estructurada de kubeadm

Presentado en versión alfa por primera vez. salida estructurada para la utilidad kubeadm. Formatos admitidos: JSON, YAML, plantilla Go.

Motivación para implementar esta característica (según KEP) es:

Si bien Kubernetes se puede implementar manualmente, el estándar de facto (si no de jure) para esta operación es utilizar kubeadm. Herramientas populares de administración de sistemas como Terraform dependen de kubeadm para la implementación de Kubernetes. Las mejoras planificadas para la API del clúster incluyen un paquete componible para el arranque de Kubernetes con kubeadm y cloud-init.

Sin una salida estructurada, incluso los cambios más inofensivos a primera vista pueden dañar Terraform, Cluster API y otro software que utiliza los resultados de kubeadm.

Nuestros planes inmediatos incluyen soporte (en forma de salida estructurada) para los siguientes comandos de kubeadm:

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

Ilustración de una respuesta 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 de otras innovaciones.

En general, el lanzamiento de Kubernetes 1.17 se produjo bajo el lema “Estabilidad" Esto se vio facilitado por el hecho de que muchas de sus funciones (su número total es 14) recibió el estatus GA. Entre ellos:

“marcar” nodos según ciertas condiciones (TaintNodesByCondition), apareció en K8 1.8;
Ver marcadores - un nuevo tipo de eventos que tienen una etiqueta que indica que todos los objetos tienen una versión determinada (resourceVersion) ya han sido procesados por reloj;
valores predeterminados (predeterminado) para recursos personalizados;
compartido entre contenedores en los espacios de nombres del proceso del pod;
ScheduleDaemonSetPods - programación de pods en DaemonSet usando kube-scheduler (en lugar del controlador DaemonSet);
límites dinámicos del número de volúmenes según el tipo de nodo;
soporte de variables de entorno para nombres de directorio montados como subPath;
Transferencia de latidos del corazón de Kubelet a una API de arrendamiento especializada;
"protección del finalizador" (Protección del finalizador) para balanceadores de carga (verificando los recursos de Servicio correspondientes antes de eliminar los recursos de LoadBalancer);
optimización de kube-apiserver en el rendimiento cuando se trabaja con múltiples relojes que monitorean conjuntos idénticos de objetos, lo que se logra evitando la serialización repetida de los mismos objetos para cada observador.

Otros cambios

La lista completa de innovaciones en Kubernetes 1.17, por supuesto, no se limita a las enumeradas anteriormente. A continuación se muestran algunos otros (y para obtener una lista más completa, consulte CAMBIO):

La función presentada en la última versión ha llegado a la versión beta. RunAsUserName para ventanas;
cambio similar sucedió EndpointSlice API (también de K8s 1.16), sin embargo, por ahora esta solución para mejorar el rendimiento/escalabilidad de Endpoint API no está habilitada de forma predeterminada;
Los pods ahora son críticos para la operación del cluster se puede crear no solo en espacios de nombres kube-system (para más detalles, consulte la documentación de Limitar el consumo de Clase Prioritaria);
nueva opción para kubelet - --reserved-cpus — le permite definir explícitamente la lista de CPU reservadas para el sistema;
para kubectl logs presentado nueva bandera --prefix, agregando el nombre del pod y el contenedor de origen a cada línea del registro;
в label.Selector adicional RequiresExactMatch;
todos los contenedores en kube-dns ahora están corriendo con menos privilegios;
hiperkube separado en un repositorio de GitHub separado y ya no se incluirá en las versiones de Kubernetes;
mucho desempeño mejorado kube-proxy para puertos que no son UDP.

Cambios de dependencia:

La versión de CoreDNS incluida en kubeadm es 1.6.5;
versión crictl actualizada a v1.16.1;
CSI 1.2.0;
etcétera 3.4.3;
La última versión probada de Docker se actualizó a 19.03;
La versión mínima de Go requerida para compilar Kubernetes 1.17 es 1.13.4.

PS

Lea también en nuestro blog:

Fuente: habr.com

Kubernetes 1.17: Aspectos destacados de las novedades