Se suponía que el lunes tendría lugar oficialmente
( pero hasta ahora esto no ha sucedido ... ACTUALIZADO 20/06 : el anuncio apareció en el blog de K8) El próximo lanzamiento de
Kubernetes es
1.15 . Según la tradición que se ha desarrollado para nuestro blog, hablamos de los cambios más significativos en la nueva versión.
La información utilizada para preparar este material se toma de
la tabla de seguimiento de mejoras de Kubernetes ,
CHANGELOG-1.15 y cuestiones relacionadas, solicitudes de extracción, así como las Propuestas de mejora de Kubernetes (KEP). Dado que la conferencia KubeCon en Shanghai se llevará a cabo la próxima semana, este lanzamiento tuvo un ciclo acortado de 11 semanas (en lugar de 12 semanas), que, sin embargo, no afectó significativamente la cantidad de cambios significativos. ¡Entonces vamos! ..
Almacenes de datos
Introdujo un
nuevo API ExecutionHook , que le permite ejecutar dinámicamente comandos de usuario en un pod / contenedor o grupo de pods / contenedores, y con él el controlador correspondiente (
ExecutionHookController ) que implementa la gestión del ciclo de vida del gancho. La motivación para la aparición de esta función fue el deseo de proporcionar a los usuarios la capacidad de crear / eliminar instantáneas de acuerdo con la lógica de la aplicación, es decir. ejecute cualquier comando específico de la aplicación antes y después de crear la instantánea. Se supone que dichos enlaces también pueden ser útiles en otras situaciones, por ejemplo, realizar actualizaciones, depurar, actualizar archivos de configuración, reiniciar el contenedor, prepararse para otros eventos como la migración de la base de datos. Estado actual - versión alfa (se espera que se traduzca a beta para la próxima versión), detalles - en
KEP .
En el almacenamiento efímero , que le permite diferenciar para contenedores / contenedores específicos el volumen de espacio compartido compartido
(almacenamiento compartido) ,
se ha agregado soporte para las cuotas del sistema de archivos. Este nuevo mecanismo utiliza
cuotas de proyectos disponibles en XFS y ext4, que proporcionan monitoreo del consumo de recursos y la imposición opcional de límites sobre ellos. Estado actual - versión alfa; aún no se han especificado planes para lanzamientos futuros.
Otra nueva característica introducida por sig-storage es el uso de PVC existentes como
DataSource para crear nuevos PVC. En otras palabras, esta es una
implementación de la función de clonación de volumen . Los clones deben distinguirse de las instantáneas, ya que cada clon es un volumen nuevo y "completo": se crea como una copia de uno existente, pero sigue completamente el ciclo de vida de los volúmenes ordinarios (a diferencia de las instantáneas, aunque son copias de volúmenes en un determinado momento, pero no independientes volúmenes). Ilustración de oportunidad:
kind: PersistentVolumeClaim apiVersion: v1 metadata: name: pvc-2 namespace: myns spec: capacity: storage: 10Gi dataSource: kind: PersistentVolumeClaim name: pvc-1
En este caso, se creará un nuevo PV / PVC independiente ( pvc-2 ) que contenga los mismos datos que en pvc-1 . Se indica que el nuevo PVC debe tener el mismo espacio de nombres que el original.Las limitaciones existentes son compatibles solo con el aprovisionador dinámico y solo los complementos CSI (deben tener la capacidad
CLONE_VOLUME ). Lea más en
KEP .
Las siguientes características han "crecido" al estado de la versión beta (y, por lo tanto, a la activación en las instalaciones predeterminadas de Kubernetes):
- Función de expansión de tamaño de volumen persistente `` en línea '', es decir sin la necesidad de reiniciar el pod usando el PVC apropiado. Por primera vez (en estado alfa), apareció en K8s 1.11.
- Soporte para variables de entorno para nombres de directorio montados como
subPath , que se introdujo por primera vez en K8s 1.11 y se desarrolló en el pasado 1.14.
Pero el proceso de migración de los componentes internos de los antiguos complementos para repositorios implementados dentro de la base de código de Kubernetes (en el árbol) se ha prolongado a favor de los complementos para la nueva interfaz CSI. Se esperaba que el lanzamiento de 1.15 completara la migración de todos los complementos de los proveedores de la nube, sin embargo, se
decidió mantener el estado de la versión alfa, ya que la función depende de las API introducidas en K8s 1.15 y hasta ahora solo se implementa en la versión alfa (en particular, estamos hablando de mejoras en soporte de Azure: complementos de
Azure File y
Azure Disk en csi-translation-lib).
Planificador
Dos innovaciones notables, ambas en forma alfa hasta ahora, están disponibles en el Programador de Kubernetes.
El primero es el
marco de programación (
Kubernetes Scheduling Framework ), que es un nuevo conjunto de API para complementos que amplían las capacidades de un programador existente. Los complementos se crean fuera del repositorio principal (fuera del árbol), pero se incluyen en el planificador durante la compilación. Por lo tanto, el núcleo funcional del planificador sigue siendo tan simple y conveniente como sea posible, y las características adicionales se implementan por separado, sin las muchas restricciones que la
forma actual de expandir las características del planificador "sufrió" con la ayuda de webhooks.
En el nuevo marco, cada intento de programación de pod se divide en dos etapas:
- ciclo de programación : donde se selecciona el nodo para el pod,
- y enlace (ciclo de enlace) : donde la solución seleccionada se implementa dentro del clúster.
En cada una de estas etapas (juntas también se denominan
contexto de programación ), hay muchos
puntos de extensión , en cada uno de los cuales se pueden llamar los complementos del marco.
(Ciclo de vida para llamar a complementos en Scheduling Framework).Como parte de la versión alfa del framework, solo
se implementan los puntos Reserve ,
Unreserve y
Prebind . Lea más sobre esta innovación masiva en
KEP .
La segunda es la
opción de No Preliminar para PriorityClasses .
Las clases de prioridad recibieron un estado estable (GA) en la última versión de Kubernetes, lo que afectó la planificación y selección de pods: los pods se planifican según la prioridad, y si el pod no se puede crear debido a la falta de recursos, entonces los pods Se puede desplazar una prioridad más baja para liberar el espacio necesario.
La nueva opción:
Preempting , definida como un booleano en la estructura
PriorityClass , significa: si un pod está esperando su planificación y tiene
Preempting=false , crearlo
no prevalecerá sobre otros pods. Este campo aparece en
PodSpec durante el proceso de
admisión de pod (similar al valor de
PriorityClass ). Los detalles de la implementación se encuentran en
KEP .
Maquinaria API
Para
CustomResources , se presentan mejoras diseñadas para implementar para los datos almacenados de esta manera (en el marco de JSON en CRD) un comportamiento que se corresponde mejor con el generalmente aceptado en la API de Kubernetes (para objetos K8 "nativos"):
- eliminación automática de campos no especificados en los esquemas de validación de OpenAPI; para obtener más información, consulte KEP " Poda para recursos personalizados ";
- la capacidad de establecer valores predeterminados para los campos en los esquemas de validación de OpenAPI v3, que es especialmente importante para mantener la compatibilidad de la API al agregar nuevos campos a los objetos; para obtener más información, consulte KEP "Configuración predeterminada de recursos personalizados ".
Originalmente se planeó que ambas características se incluyeran en el lanzamiento de K8s 1.12, pero solo ahora se presentan en versiones alfa.
Los cambios en CRD no se limitaron a esto:
- Publicar la función CRD OpenAPI , es decir validación CustomResources del lado del servidor (usando el esquema OpenAPI v3) introducida en la última versión de Kubernetes - alcanzó la versión beta y ahora está habilitada de manera predeterminada;
- El mecanismo de conversión de versión para recursos CRD basado en webhooks externos también se ha convertido a beta.
Otra innovación interesante se llama
Watch bookmark . Su esencia se reduce a agregar un nuevo tipo de evento a
Watch API -
Bookmark . Este tipo significa una etiqueta que el reloj ya ha procesado todos los objetos hasta un cierto
resourceVersion . Dicho mecanismo reducirá la carga en kube-apiserver, reduciendo la cantidad de eventos que deben procesarse cada vez que se reinicia el reloj, así como la cantidad de errores no deseados como
"versión de recursos demasiado antigua" . En Kubernetes 1.15, la función tiene el estado de la versión alfa, y se espera su aumento a beta para la próxima versión.
Added EventType = "ADDED" Modified EventType = "MODIFIED" Deleted EventType = "DELETED" Error EventType = "ERROR" Bookmark EventType = "BOOKMARK"
(Posibles tipos de eventos en la API Watch).En Admisión Webhooks:
- Se agregó soporte para un selector de objetos además de los selectores de espacio de nombres existentes
- implementó la capacidad de registrar una versión específica de un recurso y llamar cuando se modifica cualquier versión anterior de este recurso;
- El campo
Option se ha agregado a la API AdmissionReview, que informa las opciones para la operación que se realiza.
Red
Una innovación importante en la parte de la red de Kubernetes es la llamada "
Protección del finalizador" para equilibradores de carga. Ahora, antes de eliminar los recursos de LoadBalancer, se verifica que el recurso del Servicio correspondiente no se haya eliminado por completo. Para hacer esto, se adjunta un llamado finalizador a cada servicio con
type=LoadBalancer : cuando se elimina dicho servicio, la eliminación real del recurso se bloquea hasta que se elimina el finalizador, y el finalizador no se elimina hasta que se completa la "eliminación" de los recursos del equilibrador de carga correspondiente (
service.kubernetes.io/load-balancer-cleanup ). La versión actual de la implementación es la versión alfa, y los detalles al respecto se pueden encontrar en
KEP .
Además
- El complemento NodeLocal DNS Cache introducido en Kubernetes 1.13 y que mejora el rendimiento de DNS ha llegado a beta.
- Kube-proxy ya no elimina automáticamente las reglas de red creadas como resultado de su funcionamiento en otros modos (esto requiere el lanzamiento explícito de
kube-proxy --cleanup ).
CLI
Como siempre, hubo algunos pequeños detalles agradables en los comandos de consola para trabajar con clústeres de Kubernetes:
Otros
Entre otros cambios notables en Kubernetes 1.15:
- Se ha agregado compatibilidad con el Presupuesto de interrupción de pod (PDB) para recursos / controladores basados en CRD de terceros (por ejemplo: EtcdCluster, MySQLReplicaSet ...) utilizando el subrecurso Scale . Hasta ahora, esta es una versión beta que se estabilizará en la próxima versión. Los detalles están en el KEP .
- Dos características para los nodos / Kubelet llegaron a la versión beta: soporte para complementos de monitoreo de dispositivos de terceros (para eliminar todo el conocimiento específico del dispositivo de Kubelet, es decir, fuera del árbol) y
SupportNodePidsLimit (aislamiento de PID del nodo al vainas). - La compatibilidad con los módulos Go se ha agregado y habilitado de forma predeterminada para la base de código de Kubernetes (en lugar de Godep y el modo GOPATH, que está en desuso).
- El soporte para AWS NLB (Network Load Balancer), introducido por primera vez en K8s 1.9, ha alcanzado el nivel beta. En particular, obtuvo la capacidad de configurar
accessLogs , terminar TLS y LoadBalancerSourceRanges . - Se implementó la capacidad de configurar el proveedor de la nube de Azure a partir de los secretos de Kubernetes (para esto, se ha
cloudConfigType una nueva opción cloudConfigType , una de las cuales puede ser secret ). Además, Kubelet en Azure ahora puede funcionar sin identidad de Azure ( useInstanceMetadata debe estar habilitado para esto). - En el ciclo de vida del clúster, la posibilidad de crear clústeres HA usando kubeadm se llevó a beta, y también completaron el siguiente paso (v1beta2) para reorganizar el formato del archivo de configuración de kubeadm.
- El número de pods en el estado pendiente en diferentes colas se agrega a las métricas del planificador, y se agregan estadísticas sobre volúmenes a través de métricas de volumen de kubelet de CSI.
- Actualizaciones en el software usado / dependiente: Go 1.12.5, cri-tools 1.14.0, etcd 3.3.10 (la versión no ha cambiado para el servidor, pero se ha actualizado para el cliente) . Las versiones de CNI, CSI, CoreDNS no han cambiado (en una de las versiones alfa de Kubernetes 1.15 se actualizó a 1.5.0, pero luego volvió a 1.3.1) , versiones compatibles de Docker.
PS
Lea también en nuestro blog: