Nota perev. : Hemos escrito más de una vez sobre contenedores y otros tiempos de ejecución para Kubernetes. La nueva publicación es una traducción del reciente anuncio de un hito importante en el desarrollo de containerd, publicado en el blog oficial del proyecto Kubernetes. El texto fue escrito por empleados de Google e IBM, que (por supuesto, junto con Docker Inc) contribuyen significativamente a la mejora de los contenedores.Anteriormente en el blog, en la nota
Containerd trae más opciones de tiempo de ejecución de contenedor para Kubernetes , presentamos una versión alfa de la integración de containerd con Kubernetes. ¡Los siguientes 6 meses de desarrollo llevaron al hecho de que la integración se ha hecho públicamente disponible! Esto significa que ahora puede usar
containerd 1.1 como el tiempo de ejecución para contenedores en clústeres de Kubernetes en producción.
Containerd 1.1 funciona con Kubernetes versión 1.10 y superior, admite todas las características de Kubernetes. En la infraestructura de prueba de Kubernetes, la cobertura de las pruebas de integración de contenedores en Google Cloud Platform se ha convertido en la misma que la integración con Docker (ver
panel de prueba ).
“Estamos encantados de ver que los contenedores lleguen rápidamente a este hito significativo. En Alibaba Cloud, comenzamos a utilizar activamente los contenedores desde sus primeros días y, gracias a su énfasis en la simplicidad y confiabilidad, convertimos el contenedor en el motor de contenedores predeterminado en su producto Serveruber Kubernetes, que impone altas demandas de rendimiento y estabilidad. Containerd será, sin duda, el motor principal de la era de los contenedores y conducirá al desarrollo de la innovación ". - Xinwei, ingeniero a tiempo completo de Alibaba Cloud
Mejoras arquitectónicas
La arquitectura para integrar containerd con Kubernetes ha cambiado dos veces. Cada uno de sus pasos evolutivos estabilizó y mejoró la eficiencia de la pila.
Containerd 1.0 - CRI-Containerd (dejó de existir)
En containerd 1.0, se requería el demonio cri-containerd para la interacción entre
Kubelet y containerd
(escribimos sobre esto al final de este artículo - aprox. Transl. ) . Este demonio atendió solicitudes a la
Interfaz de tiempo de ejecución de contenedor (CRI) de
Kubelet y se utilizó containerd para administrar adecuadamente contenedores e imágenes de contenedores. Este enfoque eliminó un enlace adicional en la pila en comparación con la implementación de Docker CRI (
dockershim );
consulte la ilustración anterior .
Sin embargo, cri-containerd y containerd 1.0 fueron dos demonios separados que interactúan sobre GRPC. Un demonio adicional en este paquete dificultó la vida de los usuarios tanto para comprender el dispositivo como durante la implementación, y también generó una sobrecarga innecesaria para la interacción.
Containerd 1.1 - Complemento CRI (versión actual)
En containerd 1.1, el demonio cri-containerd se rehizo en el complemento CRI de containerd. Este complemento está integrado en containerd 1.1 y está habilitado de forma predeterminada. A diferencia de cri-containerd, el complemento interactúa con containerd invocando directamente las funciones necesarias. La nueva arquitectura ha hecho que la integración sea más estable y productiva, eliminando otro enlace (GRPC) de la pila. Ahora containerd 1.1 se puede usar directamente en Kubernetes, y el demonio cri-containerd ya no es necesario.
Rendimiento
Uno de los objetivos principales de containerd 1.1 era mejorar el rendimiento. Las optimizaciones se llevaron a cabo en el área del tiempo de inicio y los recursos utilizados por el demonio.
Los siguientes resultados son una comparación de containerd 1.1 y Docker 18.03 CE. Integration containerd 1.1 utiliza el complemento CRI incorporado, y la integración para Docker 18.03 CE funciona con dockershim. Los resultados se generaron utilizando el punto de referencia de rendimiento del nodo Kubernetes, que forma parte de las
pruebas e2e para los nodos K8 . La mayoría de los datos de comparación están disponibles públicamente en el
panel de rendimiento del
nodo .
Retraso de inicio de hogar
Los resultados del
punto de referencia de inicio de lote de 105 pod muestran que la integración de contenedor 1.1 tiene menos retraso en el inicio de un pod que Docker 18.03 CE con dockershim (cuanto más pequeño, mejor).
CPU y memoria
En un estado inactivo, la integración de contenedor 1.1 con 105 hogares consume menos procesador y memoria que la integración de Docker 18.03 CE con dockershim. Los resultados pueden variar según el número de hogares iniciados en el nodo; se selecciona el número de 105 hogares, porque el valor predeterminado ahora es el valor máximo para hogares personalizados en el nodo.
Como se puede ver en los gráficos a continuación, la integración de contenedor 1.1 con
Kubelet consume 30.89% menos de CPU y 11.30% menos memoria RSS (tamaño de conjunto residente), así como 12.78% menos memoria RSS consumida por el tiempo de ejecución del contenedor .
Adición del traductor
Vale la pena prestar atención a que otra solución alternativa, CRI-O , continúa desarrollándose. En particular, en una Open Source Summit Japan 2018 en estos días, un empleado de NTT presentó un informe con una extensa comparación de los entornos ejecutables existentes para contenedores. Y aquí está una de sus diapositivas que compara su desempeño:
crictl
La Interfaz de consola de contenedor (CLI) es una herramienta útil para identificar problemas en el sistema y la aplicación. Al usar Docker como un entorno contenedor en Kubernetes, los administradores del sistema a veces van al sitio de Kubernetes para ejecutar comandos de Docker y recopilar información sobre el sistema y / o la aplicación. Por ejemplo, pueden usar
docker ps y
docker inspect para verificar el estado del proceso,
docker images para obtener una lista de imágenes en el nodo,
docker info para obtener la configuración del tiempo de ejecución de los contenedores, etc.
Para contenedores y todos los demás entornos compatibles con CRI, como dockershim, recomendamos usar
crictl como una alternativa CLI a los comandos de la consola Docker para analizar problemas en pods, contenedores e imágenes de contenedores alojados en nodos de Kubernetes.
crictl es una utilidad que ofrece características similares a la Docker CLI y funciona igual de bien para todos los entornos de tiempo de ejecución para contenedores compatibles con CRI. Se puede encontrar en el
repositorio kubernetes-incubator / cri-tools ; la versión actual es
cri-tools v1.11.0 (la versión se ha corregido para la versión actual hace 3 días en lugar de v1.0.0-beta.1 , indicada en el artículo original, aprox. transl. ) . Aunque la utilidad
crictl está diseñada para ser similar a la Docker CLI, ofreciendo una transición simple para los usuarios, no es una copia completa de la misma. Algunas diferencias importantes se describen a continuación.
Uso limitado: crictl es una herramienta de solución de problemas
crictl no reemplaza los
kubectl docker o
kubectl : su uso se limita al alcance de la identificación y análisis de problemas. La interfaz de la consola Docker ofrece un amplio conjunto de comandos, por lo que es una herramienta de desarrollo muy útil. Sin embargo, esta no es la mejor opción para solucionar problemas en los nodos de Kubernetes. Algunos comandos de Docker (por ejemplo, Docker
docker network y Docker Build) son inútiles para Kubernetes, y algunos (por ejemplo,
docker rename ) pueden romperlo todo. El propósito de
crictl es proporcionar suficientes comandos para identificar problemas en los nodos que son seguros de usar en entornos de producción.
Enfoque Kubernetes
crictl ofrece una vista de contenedores más comprensible en el mundo de Kubernetes. La interfaz de la consola Docker no funciona con los conceptos básicos de Kubernetes, como under (pod) y namespace (
namespace ), lo que impide la representación visual de contenedores y hogares
(la importancia de este problema es cierta, ya en el contexto de monitoreo, recientemente hablamos en este informe - nota perev. ) Un ejemplo de ello es
docker ps muestra nombres largos y oscuros para contenedores Docker y una lista de contenedores de pausa junto con contenedores de aplicaciones:
Sin embargo, los
contenedores de pausa son parte de la implementación del hogar, donde se utiliza uno de estos contenedores para cada hogar; no deben mostrarse cuando se muestran contenedores que son parte del hogar.
crictl , por el contrario, fue creado para Kubernetes. La utilidad proporciona diferentes conjuntos de comandos para hogares y contenedores. Por ejemplo,
crictl pods muestra información sobre
crictl pods , y
crictl ps solo muestra información sobre contenedores de aplicaciones. Todos los datos están formateados en una vista de tabla:
Otro ejemplo: en los
crictl pods hay un argumento:
--namespace , que permite filtrar pods por espacios de nombres definidos en Kubernetes:
Para obtener más información sobre cómo usar crictl con containerd, consulte aquí:
¿Pero qué pasa con el motor Docker?
A menudo escuchamos la siguiente pregunta: "¿Cambiar a contenedor significa que ya no puedo usar el motor Docker?", Y la respuesta corta es "NO".
Docker Engine está construido en contenedor. La próxima versión de Docker Community Edition (Docker CE) utilizará la versión 1.1 del contenedor. En consecuencia, tendrá un complemento CRI incorporado y habilitado por defecto. Esto significa que los usuarios tendrán la oportunidad de continuar trabajando con Docker Engine para otros escenarios típicos, así como la capacidad de configurar Kubernetes para usar el contenedor subyacente que viene con Docker Engine y que Docker Engine usa simultáneamente en el mismo host. Eche un vistazo al siguiente diagrama arquitectónico que muestra cómo Docker Engine y
Kubelet usan el mismo contenedor:
Dado que
Kubelet y Docker Engine usan
containerd , los usuarios que eligen integrarse con containerd no solo obtendrán todas las nuevas características para Kubernetes, mejoras en el rendimiento y la estabilidad, sino también la opción de usar Docker Engine, como antes, para otras necesidades.
El mecanismo de
espacio de nombres en containerd asegura que
Kubelet y Docker Engine no tendrán acceso a contenedores e imágenes no creados por ellos. Esto significa que no interferirán entre sí, así como:
- Los usuarios que ingresen el
docker ps no verán los contenedores creados en Kubernetes. Use crictl ps para esto. Por el contrario, los usuarios no verán contenedores creados en Docker CLI en Kubernetes o el comando crictl ps . Los crictl create y crictl run son solo para solucionar problemas. No se recomienda la ejecución manual de hogares o contenedores con crictl en los nodos de producción. - Los usuarios que ingresen al
docker images no verán las imágenes de Kubernetes. Para hacer esto, use el comando crictl images . Por el contrario, Kubernetes no verá las imágenes creadas por los comandos docker pull , docker load y docker build . Para hacer esto, use el comando crictl pull , así como ctr cri load , si desea cargar la imagen.
Resumen
- Containerd 1.1 tiene soporte nativo de CRI. Puede ser utilizado directamente por Kubernetes.
- Containerd 1.1 está listo para la producción.
- Containerd 1.1 tiene un buen rendimiento en términos de tiempo de inicio de pod y utilización de recursos del sistema.
- crictl es una utilidad de consola (CLI) para comunicarse con containerd 1.1 y otros entornos de tiempo de ejecución para contenedores que cumplen con CRI para identificar problemas en el nodo.
- Containerd 1.1 se incluirá en la próxima versión estable de Docker CE. Los usuarios tendrán la opción de continuar trabajando con Docker en casos que no sean de Kubernetes y configurar Kubernetes para usar el contenedor subyacente que forma parte de Docker.
¡Queremos agradecer a todos los desarrolladores de Google, IBM, Docker, ZTE, ZJU e individuales que han contribuido e hicieron posible todo esto!
Para obtener una lista detallada de los cambios en containerd 1.1, consulte las
Notas de la versión .
Como intentar
Instrucciones para configurar un clúster de Kubernetes para usar containerd como el tiempo de ejecución predeterminado:
- para un clúster en GCE, generado usando
kube-up.sh , - aquí ; - instalar un clúster de muchos nodos usando Ansible y kubeadm, aquí ;
- para crear un clúster desde cero en Google Cloud: consulte " Kubernetes the Hard Way ";
- para instalación manual desde el archivo tarball - aquí ;
- para la instalación usando LinuxKit en una máquina virtual local, aquí .
Cómo contribuir
Complemento Containerd CRI: un proyecto de código abierto en GitHub, que forma parte de containerd:
https://github.com/containerd/cri . Todos los cambios propuestos son bienvenidos en forma de ideas, boletos, correcciones. Esta
guía de inicio para desarrolladores es un buen punto de partida para realizar cambios.
PD del traductor
Lea también en nuestro blog: