Kubernetes, el orquestador de contenedores favorito de todos, en su última versión, Kubernetes 1.24 Stargazer, realizó dos cambios importantes: los desarrolladores eliminaron el soporte para el tiempo de ejecución del contenedor Docker Engine y agregaron seguridad en la cadena de suministro a través de Sigstore.
Primero, no empiece a hiperventilar porque Dockershim ha quedado obsoleto. Si bien Dockershim le permitió usar el tiempo de ejecución del contenedor de Docker dentro de Kubernetes, nunca fue diseñado para integrarse dentro de Kubernetes. Además, es incompatible con la interfaz de tiempo de ejecución del contenedor (CRI) de Kubernetes. La solución fue que dockershim cerrara la brecha entre el contenedor de Docker y el CRI.
Sin embargo, mantener dockershim fue una molestia, por lo que Kubernetes comenzó a desaprobarlo. Como explicó Kat Cosgrove, defensora de desarrolladores de Pulumi y embajadora de Cloud Native Computing Foundation (CNCF), en los primeros días de Kubernetes, «Solo admitíamos un tiempo de ejecución de contenedor. Ese tiempo de ejecución era Docker Engine. En ese entonces, no había muchos de otras opciones disponibles y Docker era la herramienta dominante para trabajar con contenedores, por lo que esta no fue una elección controvertida».
Pero los usuarios de Kubernetes querían más opciones de tiempo de ejecución. Lo consiguieron con CRI, pero Docker Engine no era compatible con CRI. La solución, Dockershim, llenó los espacios entre Docker Engine y CRI. «Sin embargo», continuó Cosgrove, «este pequeño software shim nunca tuvo la intención de ser una solución permanente. A lo largo de los años, su existencia ha introducido mucha complejidad innecesaria en el kubelet en sí. Algunas integraciones se implementan de manera inconsistente para Docker debido a esta corrección, lo que resulta en una mayor carga para los mantenedores, y mantener el código específico del proveedor no está en línea con nuestra filosofía de código abierto».
Desafortunadamente, admite Cosgrove, la comunidad de desarrolladores de Kubernetes hizo un mal trabajo al comunicar lo que estaban haciendo al eliminar Dockerhsim. Tampoco ayuda que cuando decimos «Docker», nos referimos a la imagen del contenedor; Docker, la empresa o el tiempo de ejecución de Docker. Al eliminar Dockershim, nos referimos solo al tiempo de ejecución. Los contenedores Docker todavía funcionan bien en Kubernetes. Como concluyó Cosgrove, «Docker no va a desaparecer, ni como herramienta ni como empresa». Aún así, «eliminar dockershim de kubelet es, en última instancia, bueno para la comunidad, el ecosistema, el proyecto y el código abierto en general.
Pero si realmente desea seguir con Docker Engine, puede hacerlo incluso si Kubernetes ya no lo admite de forma nativa. Mirantis, que ahora posee el programa Docker, seguirá admitiendo Dockershim en Docker Engine y Mirantis Container Runtime con Kubernetes. Este nuevo programa de Dockershim, cri-dockerd, proporciona una corrección para Docker Engine, que le permite controlar Docker a través de Kubernetes CRI.
Por supuesto, también puede cambiar a uno de los tiempos de ejecución de Kubernetes admitidos, como containerd v1.6.4 y posterior, v1.5.11 y posterior, o CRI-O 1.24 y posterior.
Para obtener más información sobre cómo asegurarse de que su clúster de Kubernetes esté listo para el cambio, consulte ¿Está listo su clúster para v1.24?
En otro desarrollo importante, Kubernetes ahora admite la firma de artefactos de software encriptados para mejorar la seguridad de su cadena de suministro de software. Según el desarrollador fundador de Sigstore, Dan Lorenc, los certificados de Sigstore permiten a los usuarios de Kubernetes verificar la autenticidad y la integridad de la distribución que están utilizando «dando a los usuarios la capacidad de verificar las firmas y tener una mayor confianza en el origen de todos y cada uno de los binarios de Kubernetes implementados». paquete de código fuente e imagen de contenedor».
Los programadores de Kubernetes comenzaron a trabajar en el cumplimiento de los niveles de la cadena de suministro para artefactos de software (SLSA, pronunciado salsa) para mejorar la seguridad de la cadena de suministro del software de Kubernetes en 2021. SLSA es un marco de seguridad que incluye una lista de verificación de estándares y controles para evitar la manipulación, mejorar la integridad y asegurar los paquetes y la infraestructura de los proyectos de software.
El programa Sigstore, que cumple con el nivel 2 de SLSA, es un gran paso adelante para la seguridad de Kubernetes. Mejora la seguridad de la cadena de suministro de software al facilitar la firma criptográfica de archivos de lanzamiento, imágenes de contenedores y archivos binarios. Una vez firmado, el registro de firma se mantiene en un registro público a prueba de manipulaciones. Esto le da a los artefactos de software una cadena de custodia más segura que se puede rastrear hasta su origen.
Kubernetes 1.24 también trae otras mejoras. Por ejemplo, las nuevas interfaces de programación de aplicaciones (API) beta ya no estarán habilitadas en los clústeres de forma predeterminada. Sin embargo, las API beta existentes y las nuevas versiones seguirán habilitadas de forma predeterminada. En otro cambio de API, Kubernetes 1.24 ofrece soporte beta para publicar sus API en el formato OpenAPI v3.
También ha habido cambios de almacenamiento y volumen. El seguimiento de la capacidad de almacenamiento ahora admite la exposición de la capacidad de almacenamiento disponible actualmente a través de objetos CSIStorageCapacity y mejora la programación de pods que utilizan volúmenes de interfaz de almacenamiento de contenedores (CSI) con enlace tardío. Mientras tanto, puede cambiar el tamaño del volumen persistente existente con la expansión de volumen. También se está trabajando para migrar las partes internas de los complementos de almacenamiento en árbol para llamar a los complementos CSI mientras se mantiene la API original. Hasta ahora, se han migrado los complementos Azure Disk y OpenStack Cinder.
Finalmente, si bien hay muchos otros cambios y mejoras, llamo especialmente su atención sobre la nueva función de red opcional de Kubernetes 1.24, que le permite reservar un rango para asignaciones de direcciones IP estáticas a Servicios. Con la habilitación manual de esta función, el clúster preferirá la asignación automática desde el conjunto de direcciones IP del servicio, lo que reduce el riesgo de colisión. Me gusta mucho esta función.
Se puede asignar un Service ClusterIP:
-
dinámicamente, lo que significa que el clúster elegirá automáticamente una IP libre dentro del rango de IP de servicio configurado.
-
estáticamente, lo que significa que el usuario configurará una IP dentro del rango de IP del servicio configurado.
Estos ClusterIP de servicio son únicos; por lo tanto, intentar crear un Servicio con un ClusterIP que ya se ha asignado devolverá un error. Esto hace que evitar errores de red que de otro modo serían fáciles de cometer sea mucho más sencillo.
Por lo general, las empresas se toman su tiempo para pasar a una nueva versión de Kubernetes. Para Stargazer, sin embargo, le sugiero que considere hacer una excepción. Es un lanzamiento excepcional.
Historias relacionadas:
