A principios de esta semana
, tuvo lugar el pr贸ximo lanzamiento de Kubernetes, que se denomin贸 "angelical",
1.13 . Este nombre est谩 asociado con el n煤mero 113, que
se considera "angelical" y, seg煤n los desarrolladores de Kubernetes, simboliza "nuevos comienzos, transformaci贸n y el final de un cap铆tulo antes de abrir nuevos". Sin profundizar en el an谩lisis del simbolismo de lo que est谩 sucediendo, de acuerdo con la tradici贸n ya establecida para nuestro blog, informaremos por s茅ptima vez sobre cambios clave en la nueva versi贸n de Kubernetes, que est谩n dise帽ados para complacer a los ingenieros de DevOps / SRE que trabajan con este producto.
Como fuentes de informaci贸n, operamos con datos del
seguimiento de mejoras de Kubernetes , la tabla
CHANGELOG-1.13 y cuestiones relacionadas, solicitudes de extracci贸n, propuestas de mejora de Kubernetes (KEP).
GA para kubeadm
Uno de los principales eventos del lanzamiento de Kubernetes 1.13 fue el anuncio de un estado estable (Disponibilidad general, GA) para la utilidad de consola
kubeadm . El blog de K8s incluso ha dedicado una
publicaci贸n separada a esto . Como mucha gente sabe, kubeadm es una herramienta para crear cl煤steres de Kubernetes de acuerdo con las mejores pr谩cticas del proyecto, as铆 como su soporte m铆nimo adicional. Una caracter铆stica distintiva es que los desarrolladores se esfuerzan por mantenerlo compacto e independiente del proveedor / infraestructura, sin incluir soluciones a problemas tales como infraestructuras de aprovisionamiento, soluciones de red de terceros, complementos (monitoreo, registro, etc.), integraciones espec铆ficas con la nube proveedores.
El estado de GA marc贸 la madurez de kubeadm en las siguientes 谩reas:
- interfaz de consola estable que sigue la pol铆tica de obsolescencia de Kubernetes: los comandos y los indicadores presentados en la versi贸n de GA deben ser compatibles durante al menos un a帽o despu茅s de su obsolescencia;
- implementaci贸n estable "bajo el cap贸" debido al hecho de que el cl煤ster se crea mediante m茅todos que no cambiar谩n en el futuro cercano: el plano de control inicia la mayor cantidad de pods est谩ticos, se usan tokens bootstrap para
kubeadm join y ComponentConfig se usa para configurar kubelet; - esquema de configuraci贸n con una nueva API (v1beta1), que permite describir declarativamente casi todos los componentes del cl煤ster (GitOps es posible para los cl煤steres creados con kubeadm): se planifica una actualizaci贸n a la versi贸n v1 sin cambios o con cambios m铆nimos;
- las llamadas fases (o interfaz de la caja de herramientas ) en kubeadm (
kubeadm init phase ), lo que le permite elegir qu茅 procedimientos de inicializaci贸n se realizar谩n; - El equipo de
kubeadm upgrade garantiza actualizaciones de cl煤ster entre las versiones 1.10.x, 1.11.x, 1.12.xy 1.13.x (actualizaciones, etcd, API Server, Controller Manager y Scheduler); - instalaci贸n segura de etcd de forma predeterminada (usa TLS en todas partes) con la capacidad de expandirse al cl煤ster HA si es necesario.
Tambi茅n se puede notar que kubeadm ahora reconoce correctamente Docker 18.09.0 y sus versiones m谩s recientes. Finalmente, los desarrolladores solicitan a los usuarios de kubeadm que realicen una peque帽a
encuesta en
l铆nea en la que pueden expresar sus deseos sobre el uso y desarrollo del proyecto.
CoreDNS por defecto
CoreDNS, que recibi贸 un estado estable en la
versi贸n 1.11 de Kubernetes , fue a煤n m谩s lejos y se
convirti贸 en el servidor DNS predeterminado en K8 (en lugar de los kube-dns utilizados hasta ahora). Se planific贸 que esto suceder铆a ya en 1.12, pero los desarrolladores se enfrentaron a la necesidad de optimizaciones adicionales en la escalabilidad y el consumo de memoria, que se completaron solo con la versi贸n actual.
El soporte para kube-dns continuar谩 "durante al menos una pr贸xima versi贸n", pero los desarrolladores est谩n hablando sobre la necesidad
de comenzar a migrar a una soluci贸n actualizada ahora.
De los cambios relacionados con el tema CoreDNS en Kubernetes 1.13, tambi茅n se
puede observar el complemento
NodeLocal DNS Cache para mejorar el rendimiento de DNS. La mejora se logra ejecutando un agente en los nodos del cl煤ster para la cach茅 DNS, a la que acceder谩n directamente los pods de este nodo. Por defecto, la funci贸n est谩 deshabilitada, y para activarla, debe establecer
KUBE_ENABLE_NODELOCAL_DNS=true .
Instalaciones de almacenamiento
Se presta mucha atenci贸n en los 煤ltimos lanzamientos de Kubernetes para trabajar con la
Interfaz de almacenamiento de contenedores (CSI), que comenz贸 con la versi贸n alfa de CSI en
K8s 1.9 , continu贸 con la versi贸n beta en
1.10 ... Sin embargo, ya hemos
escrito sobre eso m谩s
de una vez . Se alcanz贸 un nuevo hito significativo en K8 1.13: el
soporte CSI se declara estable (GA).
(Diagrama del art铆culo " Descripci贸n de la interfaz de almacenamiento de contenedores ")Junto con esto, apareci贸 el soporte para la especificaci贸n CSI v1.0.0 y el soporte para versiones anteriores del est谩ndar (0.3 y anteriores) qued贸 en desuso. Esto significa que los controladores CSI m谩s antiguos requerir谩n actualizar a CSI 1.0 (y pasar al nuevo directorio de registro del complemento Kubelet) para funcionar en Kubernetes 1.15 y versiones anteriores. Por cierto, desde los propios controladores, vale la pena se帽alar la
aparici贸n de la versi贸n alfa de la interfaz CSI para administrar el ciclo de vida de los vol煤menes de AWS EBS (Elastic Block Store).
Una nueva adici贸n al administrador de complementos ahora instala autom谩ticamente CRI desde CSI si al menos una de las dos puertas de caracter铆sticas est谩 activada:
CSIDriverRegistry y
CSINodeInfo . Tiene el estado de la versi贸n alfa, pero de hecho es solo una soluci贸n temporal al problema, descrita en detalle como
un mecanismo de instalaci贸n de CRD .
La planificaci贸n de vol煤menes basada en topolog铆a (
Programaci贸n de vol煤menes consciente de topolog铆a ), de la que hablamos en el contexto de la
versi贸n Kubernetes 1.10 , se ha
vuelto estable . En resumen, el planificador en su trabajo tiene en cuenta las limitaciones de la topolog铆a del volumen del pod (por ejemplo, su zona y nodo).
La
oportunidad introducida en
Kubernetes 1.9 para usar
dispositivos crudos en bloque (no de red) como vol煤menes persistentes se
ha traducido a beta y ahora est谩 habilitada de forma predeterminada.
Concluimos el tema del almacenamiento con el hecho de que el soporte para GCERegionalPersistentDisk se
declara estable.
Nodos de cl煤ster
Se
ha introducido la versi贸n alfa de
soporte para complementos de monitoreo de dispositivos de terceros . La idea detr谩s de esta iniciativa es sacar el conocimiento espec铆fico del dispositivo
del 谩rbol de Kubelet. Los administradores del cl煤ster recibir谩n m茅tricas informadas por los complementos del dispositivo a nivel de contenedor, y los fabricantes podr谩n crear estas m茅tricas sin tener que hacer cambios en el n煤cleo de Kubernetes. Los detalles de la implementaci贸n se pueden encontrar en la propuesta, llamada
Kubelet Metadata API .
Declarado estable,
Kubelet Plugin Watcher (tambi茅n conocido como Kubelet Device Plugin Registration) permite que los complementos a nivel de nodo (complementos de dispositivo, CSI y CNI) se comuniquen con Kubelet sobre ellos mismos.
Una nueva caracter铆stica en estado alfa es
NodeLease . Si anteriormente el "latido" de un nodo fue determinado por NodeStatus, entonces con una nueva caracter铆stica, cada nodo tiene un objeto
Lease asociado (en el espacio de nombres
kube-node-lease ), que el nodo actualiza peri贸dicamente. El "pulso" ahora est谩 configurado por ambos par谩metros: el antiguo NodeStatus, que se informa al maestro solo en caso de cambios o por un tiempo de espera fijo (por defecto es una vez por minuto), y un nuevo objeto (se actualiza con frecuencia). Dado que este objeto es muy peque帽o, mejorar谩 en gran medida la escalabilidad y el rendimiento. Los autores se propusieron crear un nuevo "pulso" despu茅s de probar cl煤steres con un tama帽o de m谩s de 2000 nodos, que durante su trabajo podr铆an estar en contra de los l铆mites de etcd, para m谩s detalles ver
KEP-0009 .
type Lease struct { metav1.TypeMeta `json:",inline"` // Standard object's metadata. // More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata // +optional ObjectMeta metav1.ObjectMeta `json:"metadata,omitempty"` // Specification of the Lease. // More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status // +optional Spec LeaseSpec `json:"spec,omitempty"` } type LeaseSpec struct { HolderIdentity string `json:"holderIdentity"` LeaseDurationSeconds int32 `json:"leaseDurationSeconds"` AcquireTime metav1.MicroTime `json:"acquireTime"` RenewTime metav1.MicroTime `json:"renewTime"` LeaseTransitions int32 `json:"leaseTransitions"` }
(La especificaci贸n compacta del nuevo objeto para representar el "pulso" del nodo - Lease - es id茅ntico a LeaderElectionRecord )Seguridad
La versi贸n alfa de
Dynamic Audit Control sigue las ideas de Dynamic Admission Control y proporciona una configuraci贸n din谩mica de capacidades de auditor铆a avanzadas, para esto ahora puede registrar (din谩micamente) un webhook que recibir谩 una secuencia de eventos. La necesidad de esta funci贸n se explica por el hecho de que la auditor铆a de Kubernetes ofrece funciones muy potentes, pero son dif铆ciles de configurar y cada cambio de configuraci贸n a煤n requiere un reinicio del servidor.
El cifrado de datos en etcd (ver documentaci贸n oficial ) se ha transferido del estado experimental a beta.
kind: EncryptionConfiguration apiVersion: apiserver.config.k8s.io/v1 resources: - resources: - secrets providers: - identity: {} - aesgcm: keys: - name: key1 secret: c2VjcmV0IGlzIHNlY3VyZQ== - name: key2 secret: dGhpcyBpcyBwYXNzd29yZA== - aescbc: keys: - name: key1 secret: c2VjcmV0IGlzIHNlY3VyZQ== - name: key2 secret: dGhpcyBpcyBwYXNzd29yZA== - secretbox: keys: - name: key1 secret: YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXoxMjM0NTY=
(Se toma un ejemplo de configuraci贸n con datos cifrados de la documentaci贸n ).Entre las innovaciones menos significativas en esta categor铆a:
- Ahora se puede configurar un servidor para rechazar solicitudes que no pueden entrar en los registros de auditor铆a.
PodSecurityPolicy objetos PodSecurityPolicy agregaron con soporte para la regla MayRunAs para las opciones fsGroup y fsGroup , que permite definir el rango de identificadores de grupo (GID) permitidos para pods / contenedores sin forzar el GID predeterminado. Adem谩s, con PodSecurityPolicy , la estrategia RunAsGroup ahora es posible en la especificaci贸n de RunAsGroup , es decir. Puede controlar el GID principal para contenedores.- Para kube-Scheduler, reemplazamos el puerto inseguro anterior (10251) con el nuevo puerto seguro (10259) y lo activamos de manera predeterminada. Si no se especifican indicadores adicionales, al cargarlos, se crean certificados autofirmados en la memoria.
CLI
El
kubectl diff , que
muestra la diferencia entre la configuraci贸n local y la descripci贸n actual del objeto de trabajo (funciona y recursivamente para directorios con configuraciones), ha recibido el estado beta.
De hecho,
diff "predice" los cambios que se realizar谩n con el
kubectl apply , y se
utiliza otra nueva caracter铆stica:
APIServer DryRun . Su esencia, el inicio inactivo, debe ser clara a partir del nombre, y una descripci贸n m谩s detallada est谩 disponible en la
documentaci贸n de Kubernetes . Por cierto, en la versi贸n 1.13, la funci贸n DryRun tambi茅n se "actualiz贸" a la versi贸n beta y se activ贸 de forma predeterminada.
Y otro avance a la versi贸n beta en el mundo de la consola de Kubernetes ha afectado el
nuevo mecanismo de complemento . En el camino,
corrigieron el orden de salida de los complementos (
kubectl plugin list ), eliminando la clasificaci贸n adicional desde all铆.
Adem谩s, la salida de
los recursos de
almacenamiento ef铆mero utilizados se
agreg贸 al
kubectl describe node , y los vol煤menes de tipo
proyectados se agregaron al
kubectl describe pod .
Otros cambios
La funci贸n del planificador de
desalojo basado en Taint se ha convertido al estado beta y se habilita de forma predeterminada despu茅s de una
larga pausa en el desarrollo. Su prop贸sito es agregar autom谩ticamente
manchas a los nodos (a trav茅s de NodeController o kubelet) ante la aparici贸n de ciertas condiciones, como, por ejemplo,
node.kubernetes.io/not-ready , que corresponde al valor de
NodeCondition en
Ready=False .
Una anotaci贸n de pods cr铆ticos para el funcionamiento del cl煤ster (
critical-pod ) est谩 en desuso. En cambio, se propone utilizar
prioridades (en beta con Kubernetes 1.11) .
Para AWS, por primera vez (como parte de las versiones alfa), estuvo disponible lo siguiente:
- integraci贸n para AWS ALB (Application Load Balancer) con recursos de Kubernetes Ingress - aws-alb-ingress-controller (el proyecto fue creado originalmente por Ticketmaster y CoreOS para migrar el primero a la nube de AWS);
- CCM (Cloud Controller Manager) externo de AWS: cloud-provider-aws , responsable de lanzar controladores con la funcionalidad de proveedor espec铆fico de la nube (AWS).
SIG Azure implement贸 soporte adicional para Azure Disk (Ultra SSD, SSD est谩ndar y Premium Azure Files) y promovi贸 los
nodos del grupo de recursos cruzados a beta. Adem谩s, los complementos CNI para Windows ahora tienen
la capacidad de configurar DNS en un contenedor.
Compatibilidad
- La versi贸n etcd es 3.2.24 (no ha cambiado desde Kubernetes 1.12).
- Versiones verificadas de Docker : 1.11.1, 1.12.1, 1.13.1, 17.03, 17.06, 17.09, 18.06 (tampoco han cambiado).
- Go versi贸n - 1.11.2, coincide con el m铆nimo admitido.
- La versi贸n CNI es 0.6.0.
- La versi贸n CSI es 1.0.0.
- La versi贸n de CoreDNS es 1.2.6.
PS
Lea tambi茅n en nuestro blog: