Hoy es el 27 de septiembre, lo que
significa que durante las horas de trabajo (según la zona horaria de EE. UU.) Podemos esperar el próximo lanzamiento de Kubernetes: 1.12 (sin embargo, su anuncio oficial a veces se retrasa). En general, es hora de continuar con la gloriosa tradición y contar sobre los cambios más significativos, lo que haremos en función de la información pública del proyecto:
Kubernetes presenta la tabla de seguimiento ,
CHANGELOG-1.12 , numerosos problemas, solicitudes de extracción y propuestas de diseño. Entonces, ¿qué hay de nuevo en K8s 1.12?
Instalaciones de almacenamiento
Si selecciona una cosa que se menciona con más frecuencia que cualquier otra entre todos los problemas relacionados con el lanzamiento de Kubernetes 1.12, tal vez sea la
Interfaz de almacenamiento de contenedores (CSI) , que
ya escribimos sobre el otro día. Por esta razón, comencemos con los cambios en el soporte de almacenamiento.
Como tal
, los complementos CSI han conservado el estado beta y se espera que sean estables para la próxima versión de Kubernetes (1.13). ¿Qué hay de nuevo en el soporte de CSI?
En febrero de este año
, el trabajo sobre
el concepto de topología comenzó en la propia especificación CSI. En resumen, la topología es información sobre la segmentación del clúster (por ejemplo, por "bastidores" para instalaciones locales o por "regiones" y "zonas" para entornos de nube), que los sistemas de orquestación deben conocer y tener en cuenta. Por qué Los volúmenes asignados por los proveedores de almacenamiento no serán necesariamente accesibles por igual en todo el clúster y, por lo tanto, el conocimiento de la topología es necesario para planificar recursos de manera eficiente y tomar decisiones de aprovisionamiento.
El resultado de la aparición de topologías en CSI (
adoptado en la especificación el 1 de junio) fue su apoyo en Kubernetes 1.12:
Pero esto no termina con las actualizaciones relacionadas con CSI. Otra innovación importante en la versión 1.12 de Kubernetes es la
compatibilidad con instantáneas para CSI (en estado alfa). Las instantáneas de los volúmenes como tales aparecieron en el
lanzamiento de K8s 1.8 . La implementación principal, que incluye el controlador y el aprovisionador (dos binarios separados), se decidió transferir a
un repositorio externo . Desde entonces, se ha agregado soporte para volúmenes de GCE PD, AWS EBS, OpenStack Cinder, GlusterFS y Kubernetes
hostPath .
La nueva
propuesta de diseño tiene como objetivo "continuar esta iniciativa agregando compatibilidad con instantáneas para controladores de volumen CSI" (
aquí se describe la compatibilidad con instantáneas en la especificación CSI). Dado que Kubernetes se adhiere al principio de incluir un conjunto mínimo de capacidades en la API principal, esta implementación (como para las instantáneas en el Controlador de instantáneas de volumen) usa CRD (
CustomResourceDefinitions ).
Y un par de nuevas características para los controladores CSI:
- La versión alfa de la capacidad del controlador para registrarse en la API de Kubernetes (para facilitar a los usuarios encontrar los controladores instalados en el clúster y permitir que los controladores influyan en los procesos de interacción de Kubernetes con ellos);
- La versión alfa de la capacidad del controlador para recibir información sobre la unidad que solicita el volumen a través de
NodePublish .
Introducido en la última versión de Kubernetes, el
mecanismo para limitar dinámicamente los volúmenes en los nodos movidos de alfa a beta,
recibiendo ... lo adivinó, soporte para CSI, así como Azure.
Finalmente, la característica de
propagación del espacio de nombres Mount , que le permite montar el volumen como
rshared (para que todos los directorios de contenedores montados sean visibles en el host) y tenga un estado beta en la
versión K8s 1.10 , se declara estable.
Planificador
En el planificador, Kubernetes 1.12 mejora el rendimiento gracias a la versión alfa del
mecanismo de restricción de búsqueda en un grupo de nodos adecuados para programar hogares
(nodos factibles) . Anteriormente, para cada intento de planificar cada pod,
kube-Scheduler verificaba la disponibilidad de todos los nodos y los pasaba para su evaluación, pero ahora el planificador encontrará solo un cierto número de ellos y luego detendrá su trabajo. Al mismo tiempo, el mecanismo proporciona la selección obligatoria de nodos de diferentes regiones y zonas, así como la necesidad de ver diferentes nodos en diferentes ciclos de planificación (no seleccione los primeros 100 nodos cada vez que comience). La decisión de implementar este mecanismo se tomó, guiada por los resultados del análisis de datos sobre el rendimiento del programador (si el percentil 90 mostraba un tiempo de 30 ms para un hogar, entonces el percentil 99 ya tenía 60 ms).
Además, las siguientes características del planificador han madurado hasta la versión beta:
- Taint node by Condition , que apareció en K8s 1.8 y permite marcar un nodo con un cierto estado (para acciones adicionales) cuando ocurren ciertos eventos: ahora el controlador del ciclo de vida del nodo crea manchas automáticamente y el programador las verifica (en lugar de las condiciones );
- Programación de hogar en
DaemonSet usando kube-Scheduler (en lugar del controlador DaemonSet ): también se activó por defecto; - especificando una clase de prioridad en
ResourceQuota .
Nodos de clúster
Una innovación interesante fue la aparición (en el estado de versión alfa) de
RuntimeClass , un nuevo recurso a nivel de clúster diseñado para servir los parámetros del
tiempo de ejecución del
contenedor (tiempo de ejecución del contenedor) .
RuntimeClasses se asignan a los pods a través del mismo campo en
PodSpec e implementan soporte para usar múltiples entornos ejecutables dentro de un clúster o nodo. Por qué
“El interés en usar diferentes tiempos de ejecución en un clúster está creciendo. Por el momento, el principal motivador para esto son las cajas de arena y el deseo de los contenedores Kata y gVisor de integrarse con Kubernetes. Otros modelos de tiempo de ejecución, como los contenedores de Windows o incluso los entornos de tiempo de ejecución remotos, también requerirán soporte en el futuro. RuntimeClass ofrece una forma de elegir entre diferentes tiempos de ejecución configurados en un clúster y cambiar sus propiedades (tanto por el clúster como por el usuario) ".
Para elegir entre las configuraciones predefinidas, el
RuntimeHandler pasa a la CRI (Container Runtime Interface), que está destinada a reemplazar las anotaciones actuales del hogar:
Y la configuración en containerd para kata-runtime se ve así:
[plugins.cri.containerd.kata-runtime] runtime_type = "io.containerd.runtime.v1.linux" runtime_engine = "/opt/kata/bin/kata-runtime" runtime_root = ""
El criterio
RuntimeClass para la versión alfa es una
validación CRI exitosa.
Además, el
mecanismo para registrar complementos locales (incluido CSI) en
Kubelet y
shareProcessNamespace (la función se ha habilitado de forma predeterminada) ha crecido al estado de una versión beta.
Redes
La principal noticia en la parte de la red de Kubernetes es la
versión alfa del soporte SCTP (Stream Control Transmission Protocol). Habiendo recibido soporte en
Pod ,
Service ,
Endpoint y
NetworkPolicy , este protocolo de telecomunicaciones se ha unido a las filas de TCP y UDP. Con la nueva característica "aplicaciones que requieren SCTP como protocolo L4 para sus interfaces, será más fácil de implementar en clústeres de Kubernetes; por ejemplo, podrán usar el descubrimiento de servicios basado en
kube-dns , y su interacción se controlará a través de
NetworkPolicy ". Los detalles de implementación están disponibles en
este documento .
Dos características de red introducidas en K8s 1.8 también lograron un estado estable:
soporte para políticas para el tráfico saliente de
EgressRules en la API de NetworkPolicy y
aplicación de reglas CIDR para origen / destino a través de
ipBlockRule .
Escalamiento
Las mejoras en el Autoscaler Horizontal Pod incluyen:
La
escala vertical de los hogares , que antes de llegar a la versión beta carecía de pruebas de usuario, no se detiene. Los autores lo consideraron suficiente para el lanzamiento de K8s 1.12 y
recuerdan que es más probable que esta característica sea una adición a Kubernetes (no incluida en el núcleo). Todo el desarrollo se lleva a cabo en un repositorio separado, en el que la versión beta se sincronizará con la versión de Kubernetes.
Flujo de trabajo Vertical Pod Autoscaler (VPA) para KubernetesFinalmente, K8s 1.12 incluye (en forma alfa) los resultados del
trabajo sobre "simplificar la instalación usando
ComponentConfig " (como parte del ciclo de vida sig-cluster-life), que ha estado sucediendo durante casi dos años. Desafortunadamente, por alguna razón (¿una simple supervisión?), El acceso al
documento de propuesta de diseño con detalles está cerrado para usuarios anónimos.
Otros cambios
API
Se implementan dos nuevas características en el grupo de api-machinery:
dry-run para apiserver (versión alfa), que imita la validación y el procesamiento de solicitudes;- API de cuota de recursos (inmediatamente beta) que define los recursos que están limitados por defecto (en lugar del comportamiento actual cuando el consumo de recursos es ilimitado si no se establece una cuota).
Azur
Estable declarado:
Se agregan las primeras implementaciones (versiones alfa):
Kubectl
- Se ha implementado una versión alfa del mecanismo de complemento actualizado , que le permite agregar nuevos comandos o reescribir subcomandos existentes de cualquier nivel de anidamiento. Está hecho de manera similar a Git y analiza los ejecutables que comienzan con
kubectl- en $PATH del usuario. Vea la propuesta de diseño para más detalles. - Se implementó una versión beta de la idea de aislar el
pkg/kubectl/genericclioptions de kubectl en un repositorio independiente. - La función de impresión del lado del servidor ha sido declarada estable.
Otros
- Se presenta la versión alfa del nuevo mecanismo TTL después del acabado , diseñado para limitar la vida útil de los trabajos y pods que han terminado de ejecutarse. Una vez que caduca el TTL especificado, los objetos se limpiarán automáticamente sin necesidad de intervención del usuario.
- La generación de una clave privada y CSR (TLS Bootstrap) para firmar un certificado a nivel de clúster en Kubelet se declara estable.
- La rotación del certificado TLS del servidor en Kubelet entró en estado beta.
PS
Lea también en nuestro blog: