Ayer, 25 de marzo, el próximo lanzamiento de Kubernetes - 1.18. Según la tradición de nuestro blog, hablamos sobre los cambios más significativos en la nueva versión.
La información utilizada para preparar este material se toma del anuncio oficial, la tabla de seguimiento de mejoras de Kubernetes , CHANGELOG-1.18 , revisiones de SUSE y Sysdig , así como cuestiones relacionadas, solicitudes de extracción, propuestas de mejora de Kubernetes (KEP) ...El lanzamiento de Kubernetes 1.18 recibió su logotipo oficial, cuya esencia se reduce a comparar el proyecto con el Gran Colisionador de Hadrones. Al igual que el LHC, que fue el resultado del trabajo de miles de científicos de todo el mundo, Kubernetes reunió a miles de desarrolladores de cientos de organizaciones, y todos ellos están trabajando en una causa común: "mejorar la computación en la nube en todos los aspectos".
Mientras tanto, los entusiastas del equipo de SUSE prepararon una nube de palabras basada en las notas de la versión de las confirmaciones 3412 hechas para K8 1.18. Y resultó así:
ahora, sobre lo que hay detrás de estas palabras, en una forma más comprensible para los usuarios.Programador
La principal innovación aquí: perfila la planificación (programación de los perfiles) . Está relacionado con el hecho de que cuanto más heterogéneas son las cargas de trabajo en el clúster, más pronto surge la necesidad de diferentes enfoques para su planificación.Para resolver este problema, los autores proponen que el planificador use diferentes configuraciones asignadas al planificador y llamadas perfiles. Al comenzar, kube-Scheduler escanea todos los perfiles disponibles y los guarda en el registro. Si no hay perfiles en la configuración, se selecciona la opción predeterminada ( default-scheduler). Una vez que los pods están en la cola, kube-Scheduler realiza su planificación teniendo en cuenta el planificador seleccionado.Sami planificación de políticas basado en un predicado ( PodFitsResources, PodMatchNodeSelector,PodToleratesNodeTaintsetc.) y prioridades ( SelectorSpreadPriority, InterPodAffinityPriority, MostRequestedPriority, EvenPodsSpreadPriorityetc.). La implementación proporciona inmediatamente un sistema de complementos para que todos los perfiles se agreguen a través de un marco especial.Estructura de configuración actual (se cambiará pronto):type KubeSchedulerConfiguration struct {
...
SchedulerName string
AlgorithmSource SchedulerAlgorithmSource
HardPodAffinitySymmetricWeight
Plugins *Plugins
PluginConfig []PluginConfig
...
}
... y una configuración de ejemplo:profiles:
- schedulerName: 'default-scheduler'
pluginConfig:
- name: 'InterPodAffinity'
- args:
hadPodAffinityWeight: <value>
Para la próxima versión de K8, se espera que la función se traduzca a beta y luego de dos más: estabilización. Para obtener más información sobre los perfiles para el planificador, consulte el KEP apropiado .Otra innovación que apareció en el estado de la versión alfa es la regla predeterminada para la distribución uniforme de pods (Even Pod Spreading) . Actualmente, las reglas se definen PodSpecy se adjuntan a los pods, y ahora es posible establecer la configuración global a nivel de clúster. Los detalles están en KEP .Al mismo tiempo, la función de extensión de topología de pod en sí misma (su puerta de características EvenPodsSpread), que permite distribuir igualmente pods en un clúster multizona, se ha traducido al estado beta.Además, se ha anunciado la estabilización del desalojo basado en manchas, diseñado para agregar manchas a los nodos cuando ocurren ciertas condiciones. Por primera vez, la función apareció en el lanzamiento ya distante de K8s 1.8 , y recibió el estado beta en 1.13 .Velocidad de escala personalizada HPA
Durante más de un año, una característica interesante llamada Velocidad de escala configurable para HPA ha languidecido en el horno de mejoras de Kubernetes , es decir. Velocidad de zoom horizontal personalizable. (Por cierto, nuestro compatriota inició su desarrollo ). En la nueva versión, fue llevada a la primera etapa de uso masivo: estuvo disponible en la versión alfa.Como usted sabe, Horizontal Pod Autoscaler (HPA) en Kubernetes escala el número de pods para cualquier recurso que admita un subrecursoscalebasado en el consumo de CPU u otras métricas. Una nueva característica le permite controlar la velocidad con la que ocurre esta escala, y en ambas direcciones. Hasta ahora, ha sido posible regularlo en un grado muy limitado (ver, por ejemplo, el parámetro global para el clúster --horizontal-pod-autoscaler-downscale-stabilization-window).La principal motivación para introducir una velocidad de escala personalizada es la capacidad de separar las cargas de trabajo del clúster de acuerdo con su importancia para el negocio, lo que permite que una aplicación (que procesa el tráfico más crítico) tenga una velocidad de aumento máxima en tamaño y una velocidad de acumulación baja (ya que puede ocurrir una nueva explosión de carga), y para otros: escalar de acuerdo con otros criterios (para ahorrar dinero, etc.).Solución propuesta - Objeto agregado para configuraciones HPAbehavior, lo que le permite definir reglas para controlar el escalado en ambas direcciones ( scaleUpy scaleDown). Por ejemplo, la configuración:behavior:
scaleUp:
policies:
- type: percent
value: 900%
... conducirá al hecho de que el número de pods actualmente en ejecución aumentará en un 900%. Es decir, si la aplicación comienza como un solo pod, si es necesario escalar, comenzará a crecer como 1 → 10 → 100 → 1000. Paraotros ejemplos y detalles de implementación, vea KEP .Nudos
Progreso en el soporte de páginas enormes ( KEP total para fichas ): la versión alfa implementó el soporte para estas páginas en el nivel de contenedor y la capacidad de solicitar páginas de diferentes tamaños.El nodo del Administrador de topología ( el Administrador de topología de nodo ) , diseñado para unificar el enfoque para ajustar la asignación de recursos de hardware a diferentes componentes en Kubernetes, transferido al estado beta.El estado de la versión beta para tener una idea en una función K8s 1.16 PodOverhead , el mecanismo propuesto para calcular los gastos generales pod'y.kubectl
Se ha agregado una versión alfa del comando de depuración kubectl ( su KEP ), que desarrolló el concepto de " contenedores efímeros ". Se introdujeron por primera vez en K8 1.16 con el objetivo de simplificar la depuración en pods. Para hacer esto, en el pod derecho, se lanza un contenedor temporal (es decir, que vive por un corto tiempo) que contiene las herramientas necesarias para la depuración. Como ya escribimos, este comando es esencialmente idéntico al complemento kubectl-debug que existía hasta ahora ( su revisión ).Ilustración de trabajo kubectl debug:% kubectl help debug
Execute a container in a pod.
Examples:
kubectl debug mypod --image=debian
kubectl debug mypod --target=myapp
Options:
-a, --attach=true: Automatically attach to container once created
-c, --container='': Container name.
-i, --stdin=true: Pass stdin to the container
--image='': Required. Container image to use for debug container.
--target='': Target processes in this container name.
-t, --tty=true: Stdin is a TTY
Usage:
kubectl debug (POD | TYPE/NAME) [-c CONTAINER] [flags] -- COMMAND [args...] [options]
Use "kubectl options" for a list of global command-line options (applies to all commands).
Otro equipo, kubectl diff , que apareció por primera vez en K8s 1.9 y recibió el estado beta en 1.13, finalmente se declara estable. Como su nombre lo indica, le permite comparar configuraciones de clúster. Con motivo de las características de estabilización, apareció KEP y se actualizó con toda la documentación relevante del sitio de Kubernetes.Además, la bandera kubectl --dry a ejecutar añadido soporte para diferentes valores de ( client, server, none), que le permite intentar ejecutar el comando sólo en el lado del cliente o servidor. Para su implementación en el lado del servidor, se implementó el soporte para los principales equipos create, incluidos ,apply, patchY otros.Redes
El recurso Ingress comenzó a moverse del grupo API ( extensions.v1beta1) actual networking.v1beta1a, seguido de estabilización en la vista v1. Se planea una serie de cambios ( KEP ) para esto . Por el momento, como parte de la versión beta en K8s 1.18, Ingress ha recibido dos innovaciones significativas :- un nuevo campo
pathTypeque le permite determinar por qué principio se comparará el camino ( Exact, Prefixo ImplementationSpecific; el último comportamiento es determinado en IngressClass); - un nuevo recurso
IngressClassy un nuevo campo (inmutable) Classen la definición IngressSpecque indica qué controlador implementa el recurso Ingress. Estos cambios reemplazan la anotación kubernetes.io/ingress.class, cuyo uso quedará en desuso.
Para muchas funciones de red, se ha aumentado el estado de disponibilidad:- el complemento NodeLocal DNS Cache se ha estabilizado , lo que mejora el rendimiento de DNS mediante el uso de un agente para la caché DNS en los nodos del clúster;
- estable y declaró un campo
AppProtocolque define el protocolo de aplicación para cada puerto de servicio (recursos ServicePorty EndpointPort); - El soporte de IPv6 es reconocido como lo suficientemente estable como para traducirlo a una versión beta;
- Por defecto, la API EndpointSlices ahora está activada (como parte de la versión beta) , actuando como un reemplazo más escalable y expandible para los Endpoints habituales.
Instalaciones de almacenamiento
La versión alfa proporciona la base para crear volúmenes con datos precargados en ellos: Generic Data Populators ( KEP ). Como implementación, se propone debilitar la validación de campo DataSourcepara que los objetos de tipos arbitrarios puedan ser fuentes de datos.Antes de montar el volumen en el contenedor, los derechos de todos sus archivos se cambian según el valor fsGroup. Esta operación puede interrumpir el trabajo de algunas aplicaciones (por ejemplo, DBMS populares) y también tomar mucho tiempo (para grandes volúmenes, más de 1 TB). El nuevo campoPermissionChangePolicy para le PersistentVolumeClaimVolumeSource permite determinar si desea cambiar el propietario del contenido del volumen. La implementación actual es una versión alfa, los detalles están enKEP .Para los objetos Secrets, se ha ConfigMaps agregado un nuevo campoimmutable , haciéndolos inmutables. Como regla general, estos objetos se usan en pods como archivos. Cualquier cambio en estos archivos rápidamente (después de aproximadamente un minuto) se aplica a todos los pods que montaron los archivos. Por lo tanto, una actualización fallida de un secreto o ConfigMap puede provocar el fallo de toda la aplicación.Los autores de la función dicen que incluso en el caso de actualizar las aplicaciones con el método recomendado, a través de actualizaciones continuas, puede haber fallas causadas por actualizaciones fallidas de secretos existentes / ConfigMaps. Además, el proceso de actualización de estos objetos en pods en ejecución es complicado en términos de rendimiento y escalabilidad (cada kubelet se ve obligado a monitorear constantemente cada secreto / CM único).En la implementación actual, se realiza de modo que después de que el recurso se marque como inmutable, este cambio no se pueda revertir. Necesitará no solo eliminar el objeto y crearlo nuevamente, sino también recrear pods que usen el secreto remoto. Versión - alfa, detalles - KEP .Estable declarado:Otros cambios
Entre otras innovaciones en Kubernetes 1.18 (para obtener una lista más completa, consulte CHANGELOG ) :Cambios de dependencia:- Versión CoreDNS en kubeadm - 1.6.7;
- cri-tools 1.17.0;
- CNI (Interfaz de red de contenedores) 0.8.5, Calico 3.8.4;
- La versión de Go utilizada es 1.13.8.
¿Qué está desactualizado?
- API del servidor no está dando servicio API obsoleta: todos los recursos
apps/v1beta1y la extensions/v1beta1necesidad de seguir adelante apps/v1, y prestar atención a la recurso en particular daemonsets, deployments, replicasets, networkpolicies, podsecuritypolicies, - el punto final para las métricas
/metrics/resource/v1alpha1 no recibe servicio , ahora en su lugar /metrics/resource; - Se
kubectl run eliminaron todos los generadores del equipo, excepto el responsable de la generación de pod.
PD
Lea también en nuestro blog: