Ayer, 9 de diciembre,
el próximo lanzamiento de Kubernetes - 1.17. Según la tradición de nuestro blog, hablamos de 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.17 y cuestiones relacionadas, solicitudes de extracción, así como las Propuestas de mejora de Kubernetes (KEP). Entonces, ¿qué hay de nuevo? ..
Enrutamiento basado en topología
Durante mucho tiempo, la comunidad de Kubernetes ha estado esperando esta característica:
enrutamiento de servicio con reconocimiento de
topología . Si
KEP se basa en él en octubre de 2018, y la
mejora oficial es hace 2 años, entonces los problemas habituales
(como este ) son incluso unos años más antiguos ...
La idea general es proporcionar la capacidad de implementar enrutamiento "local" para los servicios ubicados en Kubernetes. "Localidad" en este caso significa "el mismo nivel topológico"
(nivel de topología) , que puede ser:
- mismo nodo para servicios,
- mismo rack de servidores
- la misma región
- el mismo proveedor de la nube
- ...
Ejemplos de uso de tal característica:
- ahorro de tráfico en instalaciones en la nube con muchas zonas de disponibilidad (multi-AZ): vea la última ilustración sobre el ejemplo del tráfico de una región, pero diferentes AZ en AWS;
- menor latencia en el rendimiento / mejor rendimiento;
- un servicio fragmentado que tiene información de nodo local en cada fragmento;
- colocar fluentd (o análogos) en un nodo con aplicaciones cuyos registros se recopilan;
- ...
Este enrutamiento, "conocer" sobre la topología, también se llama afinidad de afinidad de red, similar a la
afinidad de nodos ,
afinidad de pod / anti-afinidad o la
programación de volumen de topología recientemente introducida (y
aprovisionamiento de volumen ). El nivel de implementación actual de
ServiceTopology en Kubernetes es la versión alfa.
Para obtener detalles sobre cómo se organiza la función y cómo ya se puede usar, lea
este artículo de uno de los autores.
Soporte de doble pila IPv4 / IPv6
Se
registró un progreso significativo en otra función de red: el soporte simultáneo de dos pilas de IP, que se introdujo por primera vez en
K8 1.16 . En particular, la nueva versión trajo los siguientes cambios:
- kube-proxy implementa la posibilidad de operación simultánea en ambos modos (IPv4 e IPv6);
- el soporte para la API descendente ha aparecido en
Pod.Status.PodIPs (al mismo tiempo, /etc/hosts ahora requieren la adición de una dirección IPv6 para el host); - soporte para dos pilas en KIND (Kubernetes IN Docker) y kubeadm ;
- Pruebas actualizadas de e2e.
TIPO IPV4 / IPv6 Ilustración de doble pilaProgreso CSI
El
soporte de topología para repositorios basados en CSI, introducido por primera vez en
K8 1.12, se ha declarado estable .
Iniciativa de
complementos de volumen de migración CSI -
Migración CSI - Beta alcanzada. Esta característica es crítica para transferir los complementos existentes
en el árbol a una interfaz moderna
(CSI, fuera del árbol) que los usuarios finales de Kubernetes no notan. Será suficiente para que los administradores del clúster activen la migración CSI, después de lo cual los recursos con estado existentes y las cargas de trabajo seguirán "funcionando" ... pero usando los controladores CSI actuales en lugar de los obsoletos incluidos en el núcleo de Kubernetes.
Por el momento, el estado de migración para los controladores AWS EBS (
kubernetes.io/aws-ebs ) y GCE PD (
kubernetes.io/gce-pd ) está listo en estado beta. Las previsiones para otros repositorios son las siguientes:
De qué manera el soporte de almacenamiento "tradicional" en K8 llegó a CSI, hablamos en
este artículo . Una transición a la migración CSI al estado beta está dedicada a una
publicación separada en el blog del proyecto.
Además, el estado de la versión beta (es decir, la inclusión por defecto) en la versión de Kubernetes 1.17 fue alcanzado por otra funcionalidad significativa en el contexto de CSI, que se originó en (implementación alfa) en K8s 1.12,
creando instantáneas y restaurando a partir de ellas . Entre los cambios realizados en Kubernetes Volume Snapshot en el camino hacia la versión beta:
- dividir la instantánea externa CSI del sidecar en dos controladores,
- secreto de eliminación agregado como una anotación al contenido de la instantánea de volumen,
- Un nuevo finalizador para evitar la eliminación del objeto API de instantáneas si quedan conexiones restantes.
En el momento de la versión 1.17, la característica es compatible con tres controladores CSI: el controlador CSI de disco persistente GCE, el controlador CSI Portworx y el controlador CSI Trident de NetApp. Puede leer más sobre su implementación y uso en
esta publicación de blog.
Etiquetas de proveedor de la nube
Las etiquetas que se
asignan automáticamente
a los nodos y volúmenes creados según el proveedor de la nube utilizada han estado disponibles en Kubernetes como beta durante mucho tiempo, comenzando con el lanzamiento de K8s 1.2
(¡abril de 2016!) . Dado su uso generalizado durante tanto tiempo, los desarrolladores
decidieron que era hora de declarar la característica estable (GA).
Por lo tanto, todos fueron renombrados en consecuencia (por topología):
beta.kubernetes.io/instance-type → node.kubernetes.io/instance-typefailure-domain.beta.kubernetes.io/zone → topology.kubernetes.io/zonefailure-domain.beta.kubernetes.io/region → topology.kubernetes.io/region
... pero aún están disponibles por sus nombres antiguos (para compatibilidad con versiones anteriores). Sin embargo, se alienta a todos los administradores a cambiar a las etiquetas actuales. Se ha actualizado la
documentación relevante de K8s.
Salida estructurada kubeadm
En formato alfa, se presenta por primera vez una
salida estructurada para la utilidad kubeadm . Formatos admitidos: JSON, YAML, Go-template.
La motivación para implementar esta función (según
KEP ) es la siguiente:
Aunque Kubernetes se puede implementar manualmente, el estándar de facto (si no de jure) para esta operación es usar kubeadm. Las herramientas de administración de sistemas populares como Terraform dependen de kubeadm para la implementación de Kubernetes. Las mejoras programadas para la API de clúster incluyen un paquete componible para el arranque de Kubernetes con kubeadm y cloud-init.
Sin una salida estructurada, incluso los cambios más inocuos a primera vista pueden romper Terraform, la API de clúster y otro software que utiliza los resultados de kubeadm.
En un futuro próximo, aparece soporte (en forma de salida estructurada) para los siguientes comandos de kubeadm:
alpha certsconfig images listinittoken createtoken listupgrade planversion
Ilustración de la respuesta JSON al
kubeadm init -o json :
{ "node0": "192.168.20.51:443", "caCrt": "sha256:1f40ff4bd1b854fb4a5cf5d2f38267a5ce5f89e34d34b0f62bf335d74eef91a3", "token": { "id": "5ndzuu.ngie1sxkgielfpb1", "ttl": "23h", "expires": "2019-05-08T18:58:07Z", "usages": [ "authentication", "signing" ], "description": "The default bootstrap token generated by 'kubeadm init'.", "extraGroups": [ "system:bootstrappers:kubeadm:default-node-token" ] }, "raw": "Rm9yIHRoZSBhY3R1YWwgb3V0cHV0IG9mIHRoZSAia3ViZWFkbSBpbml0IiBjb21tYW5kLCBwbGVhc2Ugc2VlIGh0dHBzOi8vZ2lzdC5naXRodWIuY29tL2FrdXR6LzdhNjg2ZGU1N2JmNDMzZjkyZjcxYjZmYjc3ZDRkOWJhI2ZpbGUta3ViZWFkbS1pbml0LW91dHB1dC1sb2c=" }
Estabilización de otras innovaciones.
En general, el lanzamiento de Kubernetes 1.17 se realizó bajo el lema "
Estabilidad ". Esto fue facilitado por el hecho de que tantas características en él (su número total es
14 ) recibieron el estado de GA. Entre esos:
Otros cambios
La lista completa de innovaciones en Kubernetes 1.17, por supuesto, no se limita a las enumeradas anteriormente. Aquí hay algunos de ellos (y para una lista más completa, vea
CHANGELOG ):
- La versión beta de
RunAsUserName para Windows presentada en la versión anterior se ha convertido en la versión beta; - un cambio similar ocurrió en la API de EndpointSlice (también de K8s 1.16), pero hasta ahora esta solución para mejorar el rendimiento / escalabilidad de la API de Endpoint no se ha activado de manera predeterminada;
- los pods críticos para la operación del clúster ahora se pueden crear no solo en los espacios de nombres del
kube-system (consulte la documentación para el consumo de la Clase de prioridad de límite para más detalles) ; - una nueva opción para kubelet,
--reserved-cpus , le permite definir explícitamente una lista de CPU reservadas para el sistema; - para los
kubectl logs se presenta una nueva kubectl logs : prefijo, agregando el nombre del pod y el contenedor de origen a cada línea del registro; - en la
label.Selector agregado RequiresExactMatch ; - todos los contenedores en kube-dns ahora se ejecutan con menos privilegios;
- hyperkube se asigna a un repositorio GitHub separado y ya no se incluirá en las versiones de Kubernetes;
- Mejorado significativamente el rendimiento de kube-proxy para puertos no UDP.
Cambios de dependencia:
- Versión CoreDNS en kubeadm - 1.6.5;
- versión de crictl actualizada a v1.16.1;
- CSI 1.2.0;
- etcd 3.4.3;
- La última versión probada de Docker se ha actualizado a 19/03;
- la versión mínima de Go requerida para construir Kubernetes 1.17 es 1.13.4.
PS
Lea también en nuestro blog: