🥇Kubernetes 1.17: resumen de las principales novedades

Ayer, 9 de diciembre, se llevó a cabo se lanzó otra versión de Kubernetes — 1.17. Siguiendo la tradición de nuestro blog, compartimos los cambios más significativos en esta nueva versión.

Kubernetes 1.17: revisión de las principales novedades

La información utilizada para preparar este material proviene del anuncio oficial, la tabla de seguimiento de mejoras de Kubernetes, CHANGELOG-1.17 y de los issues, pull requests y Kubernetes Enhancement Proposals (KEP) correspondientes. Entonces, ¿qué hay de nuevo?..

Enrutamiento consciente de la topología

La comunidad de Kubernetes ha estado esperando esta característica durante mucho tiempo — Topology-aware service routing. Si KEP que comenzó en octubre de 2018, y el enhancement hace 2 años; los issues comunes (como esto) — e incluso algunos de hace varios años…

La idea general es permitir implementar enrutamiento 'local' para servicios que residen en Kubernetes. La 'localidad' en este caso significa 'el mismo nivel topológico' (topology level), que puede ser:

el mismo nodo para los servicios,
el mismo rack servidor,
la misma región,
el mismo proveedor de nube,
…

Ejemplos de uso de esta característica:

ahorro en el tráfico en instalaciones en la nube con múltiples zonas de disponibilidad (multi-AZ) — véase una nueva ilustración del tráfico de una región, pero de diferentes AZ en AWS;
menores latencias en el rendimiento/mejor capacidad de ancho de banda;
un servicio fragmentado que tiene información local del nodo en cada fragmento;
colocando fluentd (o similares) en el mismo nodo que las aplicaciones cuyos logs se recolectan;
…

Este enrutamiento, 'consciente' de la topología, también se conoce como una forma de network affinity — similar a node affinity, pod affinity/anti-affinity o la recientemente introducida Topology-Aware Volume Scheduling Volume Provisioning (y ). El nivel actual de implementación deServiceTopology en Kubernetes es una versión alfa. Para más detalles sobre cómo funciona esta característica y cómo se puede utilizar, lea en

un artículo de uno de los autores. este artículo Soporte de doble pila IPv4/IPv6

Se ha registrado un progreso significativo

en otra característica de red: el soporte simultáneo de dos pilas IP, que se presentó por primera vez en K8s 1.16. En particular, la nueva versión trajo los siguientes cambios: en kube-proxyla capacidad de operar simultáneamente en ambos modos (IPv4 e IPv6);

Pod.Status.PodIPs se ha implementado soporte downward API (al mismo tiempo, ahora se requiere que el host también agregue una dirección IPv6);
en soporte de ambas pilas en se ha añadido (Kubernetes IN Docker) y /etc/hosts pruebas e2e actualizadas.
soporte de dos pilas en KIND (Kubernetes EN Docker) y kubeadm;
pruebas e2e actualizadas.

Kubernetes 1.17: revisión de las principales novedades
Ilustración uso de la pila doble IPV4/IPv6 en KIND

Progreso en CSI

Anunciada como estable soporte para topologías de almacenamiento basado en CSI, presentado por primera vez en K8s 1.12.

Iniciativa de migración de plugins de volúmenes a CSI — Migración CSI — ha alcanzado la versión beta. Esta característica es crítica para trasladar los plugins de almacenamiento existentes (in-tree) a una interfaz moderna (CSI, out-of-tree) sin que los usuarios finales de Kubernetes lo noten. Los administradores de clústeres solo necesitan activar la Migración CSI, después de lo cual los recursos y cargas de trabajo stateful existentes seguirán "simplemente funcionando"... pero ahora utilizando los controladores CSI actualizados en lugar de los antiguos, incluidos en el núcleo de Kubernetes.

En este momento, la migración está en beta para los controladores AWS EBS (kubernetes.io/aws-ebs) y GCE PD (kubernetes.io/gce-pd). Las proyecciones para otros almacenamientos son las siguientes:

Kubernetes 1.17: revisión de las principales novedades

Sobre cómo el soporte "tradicional" de almacenamiento en K8s llegó a CSI, hablamos en este artículo. La migración de CSI a estado beta se detalla en una publicación separada en el blog del proyecto.

Además, otra funcionalidad significativa en el contexto de CSI, que alcanzó el estado beta (es decir, habilitada por defecto) en la versión de Kubernetes 1.17, que tuvo su inicio (implementación alfa) en K8s 1.12, es la creación de instantáneas y la recuperación de ellas. Entre los cambios realizados en Kubernetes Volume Snapshot en su camino hacia el lanzamiento beta:

división del sidecar CSI external-snapshotter en dos controladores,
se agregó un secreto para eliminación (deletion secret) como anotación al contenido de la instantánea del volumen,
nuevo finalizador (finalizer) para evitar la eliminación del objeto API de la instantánea si hay vínculos restantes.

En el momento del lanzamiento 1.17, la característica es soportada por tres controladores CSI: GCE Persistent Disk CSI Driver, Portworx CSI Driver y NetApp Trident CSI Driver. Más detalles sobre su implementación y uso se pueden encontrar en esta publicación el blog.

Etiquetas del Proveedor de Nube

Las etiquetas que se asignan automáticamente a los nodos y volúmenes creados en función del proveedor de nube utilizado , han estado disponibles en Kubernetes como versión beta desde hace mucho tiempo — comenzando con el lanzamiento de K8s 1.2(abril de 2016!) . Dado su amplio uso durante tanto tiempo, los desarrolladoresdecidieron , que era hora de declarar la funcionalidad estable (GA).Por lo tanto, todos fueron renombrados en consecuencia (por topologías):

beta.kubernetes.io/instance-type

node.kubernetes.io/instance-type → failure-domain.beta.kubernetes.io/zone
topology.kubernetes.io/zone → topology.kubernetes.io/zone
failure-domain.beta.kubernetes.io/region → topology.kubernetes.io/region

… pero aún están disponibles con sus nombres antiguos (por compatibilidad). Sin embargo, se recomienda a todos los administradores que migren a las etiquetas actuales. Documentación correspondiente K8s se ha actualizado.

Salida estructurada de kubeadm

Se presenta por primera vez en formato alfa salida estructurada para la herramienta kubeadm. Formatos soportados: JSON, YAML, plantilla Go.

La motivación para implementar esta función (de acuerdo con KEP) es la siguiente:

Aunque Kubernetes se puede implementar manualmente, el estándar de facto (si no de jure) para esta operación es el uso de kubeadm. Herramientas populares de gestión de sistemas como Terraform se basan en kubeadm para desplegar Kubernetes. Las mejoras planificadas en Cluster API incluyen un paquete componible para el arranque de Kubernetes con kubeadm y cloud-init.
Sin salida estructurada, incluso los cambios más inofensivos a primera vista pueden romper Terraform, Cluster API y otro software que utiliza los resultados de kubeadm.

Los próximos planes incluyen soporte (en formato 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 la respuesta JSON del 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": "El token de arranque predeterminado generado por 'kubeadm init'.",
    "extraGroups": [
      "system:bootstrappers:kubeadm:default-node-token"
    ]
  },
  "raw": "Rm9yIHRoZSBhY3R1YWwgb3V0cHV0IG9mIHRoZSAia3ViZWFkbSBpbml0IiBjb21tYW5kLCBwbGVhc2Ugc2VlIGh0dHBzOi8vZ2lzdC5naXRodWIuY29tL2FrdXR6LzdhNjg2ZGU1N2JmNDMzZjkyZjcxYjZmYjc3ZDRkOWJhI2ZpbGUta3ViZWFkbS1pbml0LW91dHB1dC1sb2c="
}

Estabilización de otras innovaciones

En general, la versión Kubernetes 1.17 se lanzó bajo el lema "Estabilidad". Esto se debió al hecho de que muchas características en ella (su número total — 14) obtuvieron el estatus GA. Entre ellas se encuentran:

etiquetar nodos según ciertas condiciones (TaintNodesByCondition), que apareció en K8s 1.8;
Watch Bookmarks — un nuevo tipo de eventos que tienen una marca, indicando que todos los objetos hasta cierta versión (resourceVersion) ya han sido procesados por watch;
valores predeterminados (defaulting) para Recursos Personalizados;
espacios de nombres de proceso compartidos entre contenedores en el pod;
ScheduleDaemonSetPods — programación de pods en DaemonSet utilizando kube-scheduler (en lugar del controlador DaemonSet);
límites dinámicos en la cantidad de volúmenes según el tipo de nodo;
soporte para variables de entorno para los nombres de los directorios que se montan como subPath;
transferencia de los latidos de Kubelet en una API de Lease especializada;
"protección del finalizador" (Protección de Finalizador) para balances de carga (verificación de recursos relevantes del servicio antes de eliminar recursos de LoadBalancer);
optimización del kube-apiserver en el rendimiento al trabajar con muchas watches que observan conjuntos idénticos de objetos, logrando esto mediante la evitación de la reserialización de los mismos objetos para cada watcher.

Las fechas YYYY-M-DD y YYYY-MM-D ya no se interpretan

La lista completa de novedades en Kubernetes 1.17, por supuesto, no se limita a las mencionadas anteriormente. Aquí hay algunas otras (para una lista más completa, consulte CHANGELOG):

la característica presentada en el lanzamiento anterior ha alcanzado la versión beta RunAsUserName para Windows.;
un cambio similar ha llegado a API de EndpointSlice (también de K8s 1.16), sin embargo, esta solución para mejorar el rendimiento/escalabilidad de la API de Endpoint no está activada por defecto;
los pods críticos para el funcionamiento del clúster ahora pueden ser creados no solo en espacios de nombres kube-system (para más detalles, consulte la documentación sobre Limit Priority Class consumption);
nueva opción para kubelet — --reserved-cpus — permite definir explícitamente una lista de CPU reservadas para el sistema;
para combina presentado nueva bandera --prefix, que añade el nombre del pod y del contenedor de origen a cada línea del registro;
en label.Selector se ha añadido RequiresExactMatch;
todos los contenedores en kube-dns ahora se ejecutan con menos privilegios;
hyperkube se ha separado en un repositorio de GitHub y ya no se incluirá en los lanzamientos de Kubernetes;
significativamente mejorada la rendimiento de kube-proxy para puertos no UDP.

Cambios en las dependencias:

la versión de CoreDNS en kubeadm es — 1.6.5;
la versión de crictl se ha actualizado a v1.16.1;
CSI 1.2.0;
etcd 3.4.3;
la última versión verificada de Docker se ha elevado a 19.03;
la versión mínima de Go requerida para compilar Kubernetes 1.17 es — 1.13.4.

P.D.

También puedes leer en nuestro blog:

Fuente: habr.com