🥇Kubernetes 1.16: resumen de las principales novedades

Hoy miércoles, состоитися próxima versión de Kubernetes: 1.16. Según la tradición que se ha desarrollado en nuestro blog, este es el décimo aniversario en el que hablamos de los cambios más significativos en la nueva versión.

La información utilizada para preparar este material está extraída de Tablas de seguimiento de mejoras de Kubernetes, REGISTRO DE CAMBIOS-1.16 y problemas relacionados, solicitudes de extracción y propuestas de mejora de Kubernetes (KEP). ¡Entonces vamos!..

Nodos

Una cantidad verdaderamente grande de innovaciones notables (en estado de versión alfa) se presentan en el lado de los nodos del clúster K8 (Kubelet).

En primer lugar, el llamado «contenedores efímeros» (Contenedores efímeros), diseñado para simplificar los procesos de depuración en pods. El nuevo mecanismo le permite lanzar contenedores especiales que comienzan en el espacio de nombres de los pods existentes y viven por un corto tiempo. Su propósito es interactuar con otros pods y contenedores para resolver cualquier problema y depurar. Se ha implementado un nuevo comando para esta característica. kubectl debug, similar en esencia a kubectl exec: solo en lugar de ejecutar un proceso en un contenedor (como en exec) lanza un contenedor en un pod. Por ejemplo, este comando conectará un nuevo contenedor a un pod:

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

Los detalles sobre los contenedores efímeros (y ejemplos de su uso) se pueden encontrar en KEP correspondiente. La implementación actual (en K8s 1.16) es una versión alfa, y entre los criterios para su transferencia a una versión beta está "probar la API de contenedores efímeros para al menos 2 versiones de [Kubernetes]".

NB: En su esencia e incluso en su nombre, la función se parece a un complemento ya existente kubectl-depuraciónsobre el cual nosotros ya escribí. Se espera que con la llegada de los contenedores efímeros cese el desarrollo de un complemento externo independiente.

Otra innovación - PodOverhead - diseñado para proporcionar mecanismo para calcular los costos generales de las vainas, que puede variar mucho según el tiempo de ejecución utilizado. Como ejemplo, los autores este KEP dan como resultado contenedores Kata, que requieren ejecutar el kernel invitado, el agente kata, el sistema de inicio, etc. Cuando los gastos generales se vuelven tan grandes, no se pueden ignorar, lo que significa que debe haber una manera de tenerlos en cuenta para futuras cuotas, planificación, etc. Para implementarlo en PodSpec campo agregado Overhead *ResourceList (se compara con los datos en RuntimeClass, si se utiliza alguno).

Otra innovación notable es administrador de topología de nodo (Administrador de topología de nodo), diseñado para unificar el enfoque para ajustar la asignación de recursos de hardware para varios componentes en Kubernetes. Esta iniciativa viene impulsada por la creciente necesidad que tienen diversos sistemas modernos (del campo de las telecomunicaciones, el aprendizaje automático, los servicios financieros, etc.) de una computación paralela de alto rendimiento y minimizando los retrasos en la ejecución de las operaciones, para lo que utilizan CPU avanzadas y capacidades de aceleración de hardware. Estas optimizaciones en Kubernetes hasta ahora se han logrado gracias a componentes dispares (administrador de CPU, administrador de dispositivos, CNI), y ahora se les agregará una única interfaz interna que unifica el enfoque y simplifica la conexión de nuevos similares -la llamada topología-. consciente: componentes en el lado de Kubelet. Detalles - en KEP correspondiente.

Diagrama de componentes del Administrador de topología

Siguiente característica - comprobar los contenedores mientras están en funcionamiento (sonda de inicio). Como usted sabe, para los contenedores que tardan mucho en lanzarse, es difícil obtener un estado actualizado: o son "muertos" antes de que realmente comiencen a funcionar, o terminan estancados durante mucho tiempo. Nuevo cheque (habilitado a través de la puerta de función llamada StartupProbeEnabled) cancela, o mejor dicho, difiere, el efecto de cualquier otra verificación hasta el momento en que el pod haya terminado de ejecutarse. Por esta razón, la función se llamó originalmente Retraso de la sonda de vida del inicio del pod. Para los pods que tardan mucho en iniciarse, puede sondear el estado en intervalos de tiempo relativamente cortos.

Además, una mejora para RuntimeClass está disponible de inmediato en estado beta, agregando soporte para “clústeres heterogéneos”. C Programación de clases en tiempo de ejecución Ahora no es en absoluto necesario que cada nodo tenga soporte para cada RuntimeClass: para los pods puedes seleccionar un RuntimeClass sin pensar en la topología del clúster. Anteriormente, para lograr esto (para que los pods terminen en nodos con soporte para todo lo que necesitan), era necesario asignar reglas apropiadas a NodeSelector y tolerancias. EN KEP Habla de ejemplos de uso y, por supuesto, detalles de implementación.

Red

Dos características de red importantes que aparecieron por primera vez (en la versión alfa) en Kubernetes 1.16 son:

Apoyar pila de red dual: IPv4/IPv6 - y su correspondiente “comprensión” a nivel de pods, nodos y servicios. Incluye interoperabilidad de IPv4 a IPv4 e IPv6 a IPv6 entre pods, desde pods hasta servicios externos, implementaciones de referencia (dentro de los complementos Bridge CNI, PTP CNI y Host-Local IPAM), así como compatibilidad inversa con clústeres de Kubernetes en ejecución. Sólo IPv4 o IPv6. Los detalles de implementación están en KEP.
Un ejemplo de visualización de direcciones IP de dos tipos (IPv4 e IPv6) en la lista 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#
```
Nueva API para endpoints - API de EndpointSlice. Resuelve los problemas de rendimiento/escalabilidad de la API Endpoint existente que afectan a varios componentes en el plano de control (apiserver, etcd, endpoints-controller, kube-proxy). La nueva API se agregará al grupo Discovery API y podrá servir a decenas de miles de puntos finales de backend en cada servicio en un clúster que consta de miles de nodos. Para hacer esto, cada Servicio se asigna a N objetos. EndpointSlice, cada uno de los cuales de forma predeterminada no tiene más de 100 puntos finales (el valor es configurable). La API EndpointSlice también brindará oportunidades para su desarrollo futuro: soporte para múltiples direcciones IP para cada pod, nuevos estados para puntos finales (no solo Ready и NotReady), subconjunto dinámico para puntos finales.

El presentado en la última versión ha llegado a la versión beta. finalizadorllamado service.kubernetes.io/load-balancer-cleanup y adjunto a cada servicio con tipo LoadBalancer. En el momento de eliminar dicho servicio, evita la eliminación real del recurso hasta que se complete la "limpieza" de todos los recursos del balanceador relevantes.

Maquinaria API

El verdadero "hito de estabilización" está en el área del servidor API de Kubernetes y la interacción con él. Esto sucedió en gran medida gracias a transferir al estatus estable a aquellos que no necesitan una presentación especial Definiciones de recursos personalizados (CRD), que han tenido estado beta desde los lejanos días de Kubernetes 1.7 (¡y esto es junio de 2017!). La misma estabilización llegó a las características relacionadas:

"subrecursos" con /status и /scale para recursos personalizados;
transformación versiones para CRD, basadas en webhook externo;
presentado recientemente (en K8s 1.15) valores predeterminados (predeterminado) y eliminación automática de campos (poda) para recursos personalizados;
oportunidad usar el esquema OpenAPI v3 para crear y publicar documentación de OpenAPI utilizada para validar los recursos CRD en el lado del servidor.

Otro mecanismo que los administradores de Kubernetes conocen desde hace mucho tiempo: webhook de admisión - También permaneció en estado beta durante mucho tiempo (desde K8s 1.9) y ahora está declarado estable.

Otras dos funciones han llegado a la versión beta: aplicar del lado del servidor и ver marcadores.

Y la única innovación significativa en la versión alfa fue renuncia de SelfLink — un URI especial que representa el objeto especificado y que forma parte de ObjectMeta и ListMeta (es decir, parte de cualquier objeto en Kubernetes). ¿Por qué lo abandonan? Motivación de forma sencilla sonidos como la ausencia de razones reales (abrumadoras) para que este campo siga existiendo. Razones más formales son optimizar el rendimiento (eliminando un campo innecesario) y simplificar el trabajo del apiserver genérico, que se ve obligado a manejar dicho campo de una manera especial (este es el único campo que se establece justo antes del objeto está serializado). Obsolescencia verdadera (dentro de la versión beta) SelfLink Sucederá con la versión 1.20 de Kubernetes y la versión 1.21 final.

Almacenamiento de datos

El principal trabajo en el área de almacenamiento, al igual que en entregas anteriores, se observa en el área Soporte CSI. Los principales cambios aquí fueron:

por primera vez (en versión alfa) apareció Compatibilidad con el complemento CSI para nodos trabajadores de Windows: la forma actual de trabajar con el almacenamiento también reemplazará los complementos en el árbol en el núcleo de Kubernetes y los complementos FlexVolume de Microsoft basados en Powershell;

Esquema para implementar complementos CSI en Kubernetes para Windows
oportunidad cambiar el tamaño de los volúmenes CSI, introducido en K8s 1.12, ha crecido hasta convertirse en una versión beta;
Se logró una "promoción" similar (de alfa a beta) mediante la capacidad de utilizar CSI para crear volúmenes efímeros locales (Soporte de volumen en línea CSI).

Introducido en la versión anterior de Kubernetes. función de clonación de volumen (utilizando PVC existente como DataSource para crear nuevo PVC) también ha recibido ahora el estado beta.

Planificador

Dos cambios notables en la programación (ambos en alfa):

EvenPodsSpreading - oportunidad Utilice pods en lugar de unidades de aplicación lógicas para una "distribución justa" de las cargas. (como Deployment y ReplicaSet) y ajustando esta distribución (como un requisito estricto o como una condición suave, es decir, prioridad). La función ampliará las capacidades de distribución existentes de los grupos planificados, actualmente limitadas por opciones. PodAffinity и PodAntiAffinity, brindando a los administradores un control más preciso en este asunto, lo que significa una mayor disponibilidad y un consumo optimizado de recursos. Detalles - en KEP.
el uso de Política de mejor ajuste в Función de prioridad RequestedToCapacityRatio durante la planificación del pod, lo que permitirá применять embalaje de basura (“empaquetado en contenedores”) tanto para recursos básicos (procesador, memoria) como extendidos (como GPU). Para más detalles, ver KEP.

Programación de pods: antes de usar la política de mejor ajuste (directamente a través del programador predeterminado) y con su uso (a través del extensor del programador)

Además, representado la capacidad de crear sus propios complementos de programación fuera del árbol de desarrollo principal de Kubernetes (fuera del árbol).

Otros cambios

También en la versión Kubernetes 1.16 puede observar iniciativa para trayendo métricas disponibles en orden completo, o más precisamente, de acuerdo con regulaciones oficiales a la instrumentación del K8. Se basan en gran medida en las correspondientes Documentación de Prometeo. Surgieron inconsistencias por varias razones (por ejemplo, algunas métricas simplemente se crearon antes de que aparecieran las instrucciones actuales), y los desarrolladores decidieron que era hora de llevar todo a un estándar único, "en línea con el resto del ecosistema de Prometheus". La implementación actual de esta iniciativa se encuentra en estado alfa, que será promovida progresivamente en versiones posteriores de Kubernetes a beta (1.17) y estable (1.18).

Además, se pueden observar los siguientes cambios:

Desarrollo de soporte de Windows. с el advenimiento de Utilidades de Kubeadm para este sistema operativo (versión alfa), la oportunidad RunAsUserName para contenedores de Windows (versión alfa), mejora Soporte de cuenta de servicio administrada por grupo (gMSA) hasta la versión beta, apoyo montar/adjuntar para volúmenes de vSphere.
reciclado Mecanismo de compresión de datos en respuestas API.. Anteriormente se utilizaba un filtro HTTP para estos fines, lo que imponía una serie de restricciones que impedían habilitarlo por defecto. La "compresión de solicitud transparente" ahora funciona: los clientes envían Accept-Encoding: gzip en el encabezado, reciben una respuesta comprimida con GZIP si su tamaño supera los 128 KB. Los clientes de Go admiten automáticamente la compresión (envío del encabezado requerido), por lo que notarán inmediatamente una reducción en el tráfico. (Es posible que se necesiten ligeras modificaciones para otros idiomas).
se hizo posible escalar HPA desde/hasta pods cero en función de métricas externas. Si escala en función de objetos/métricas externas, cuando las cargas de trabajo estén inactivas, puede escalar automáticamente a 0 réplicas para ahorrar recursos. Esta característica debería ser especialmente útil para los casos en los que los trabajadores solicitan recursos de GPU y la cantidad de diferentes tipos de trabajadores inactivos excede la cantidad de GPU disponibles.
Cliente nuevo - k8s.io/client-go/metadata.Client - para el acceso "generalizado" a los objetos. Está diseñado para recuperar fácilmente metadatos (es decir, subsección metadata) de los recursos del clúster y realizar operaciones de cuota y recolección de basura con ellos.
Construir Kubernetes ahora puedes sin proveedores de nube heredados (“integrados” en el árbol) (versión alfa).
A la utilidad kubeadm adicional capacidad experimental (versión alfa) para aplicar parches personalizados durante las operaciones init, join и upgrade. Obtenga más información sobre cómo usar la bandera. --experimental-kustomize, ver en KEP.
Nuevo punto final para apiserver - readyz, - le permite exportar información sobre su preparación. El servidor API ahora también tiene una bandera --maximum-startup-sequence-duration, permitiéndole regular sus reinicios.
dos características para Azure declarado estable: soporte zonas de disponibilidad (Zonas de disponibilidad) y grupo de recursos cruzados (RG). Además, Azure ha agregado:
- soporte de autenticación DAA y ADFS;
- anotación service.beta.kubernetes.io/azure-pip-name para especificar la IP pública del balanceador de carga;
- oportunidad настройки LoadBalancerName и LoadBalancerResourceGroup.
AWS ahora tiene apoyar para EBS en Windows y optimizado Llamadas a la API de EC2 DescribeInstances.
Kubeadm ahora es independiente migra Configuración de CoreDNS al actualizar la versión de CoreDNS.
binarios etcd en la imagen de Docker correspondiente haber hecho ejecutable mundial, que le permite ejecutar esta imagen sin la necesidad de derechos de root. Además, imagen de migración de etcd. cesó Soporte de versión etcd2.
В Escalador automático de clúster 1.16.0 Se cambió al uso de distroless como imagen base, se mejoró el rendimiento y se agregaron nuevos proveedores de nube (DigitalOcean, Magnum, Packet).
Actualizaciones de software usado/dependiente: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.