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 , 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), 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 -- bashLos detalles sobre los contenedores efímeros (y ejemplos de su uso) se pueden encontrar en . 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 sobre el cual nosotros . Se espera que con la llegada de los contenedores efímeros cese el desarrollo de un complemento externo independiente.
Otra innovación - - 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 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 .
Diagrama de componentes del Administrador de topología
Siguiente característica - comprobar los contenedores mientras están en funcionamiento (). 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 . 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 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 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:
- 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 .
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 - . 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 soloReadyиNotReady), subconjunto dinámico para puntos finales.
El presentado en la última versión ha llegado a la versión beta. llamado 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 (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:
- con
/statusи/scalepara recursos personalizados; - versiones para CRD, basadas en webhook externo;
- (en K8s 1.15) valores predeterminados (predeterminado) y eliminación automática de campos (poda) para recursos personalizados;
- 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: - 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: и .
Y la única innovación significativa en la versión alfa fue 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 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 . Los principales cambios aquí fueron:
- por primera vez (en versión alfa) 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 , 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 ().
Introducido en la versión anterior de Kubernetes. (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):
- - 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 . - el uso de Política de mejor ajuste в Función de prioridad RequestedToCapacityRatio durante la planificación del pod, lo que permitirá применять (“empaquetado en contenedores”) tanto para recursos básicos (procesador, memoria) como extendidos (como GPU). Para más detalles, ver .
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, 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 métricas disponibles en orden completo, o más precisamente, de acuerdo con a la instrumentación del K8. Se basan en gran medida en las correspondientes . 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. с Utilidades de Kubeadm para este sistema operativo (versión alfa),
RunAsUserNamepara contenedores de Windows (versión alfa), Soporte de cuenta de servicio administrada por grupo (gMSA) hasta la versión beta, montar/adjuntar para volúmenes de vSphere. - 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: gzipen 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). - 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 - - 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 sin proveedores de nube heredados (“integrados” en el árbol) (versión alfa).
- A la utilidad kubeadm 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 . - Nuevo punto final para apiserver - , - 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) y (RG). Además, Azure ha agregado:
- DAA y ADFS;
-
service.beta.kubernetes.io/azure-pip-namepara especificar la IP pública del balanceador de carga; - настройки
LoadBalancerNameиLoadBalancerResourceGroup.
- AWS ahora tiene para EBS en Windows y Llamadas a la API de EC2
DescribeInstances. - Kubeadm ahora es independiente Configuración de CoreDNS al actualizar la versión de CoreDNS.
- binarios etcd en la imagen de Docker correspondiente ejecutable mundial, que le permite ejecutar esta imagen sin la necesidad de derechos de root. Además, imagen de migración de etcd. Soporte de versión etcd2.
- В 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.
PS
Lea también en nuestro blog:
- «";
- «";
- «";
- «".
Fuente: habr.com