Cómo ejecutar cargas de trabajo de Kubernetes en systemd con Podman

Kubernetes es el estándar de la industria para orquestar cargas de trabajo de contenedores. Parte de su éxito se debe a que proporciona una manera fácil de declarar cargas de trabajo en YAML mientras oculta al usuario las complejidades de los sistemas distribuidos. Kubernetes YAML Expone varias perillas de control para ejecutar contenedores y pods, como imágenes de contenedores, comandos, puertos, volúmenes, secretos y más. Piense en ello como una opción de línea de comandos integrada en YAML.

Podman ha pasado desde los primeros días. podman-play-kube Ordenar. Este comando es muy útil para los desarrolladores, ya que permite desarrollar cargas de trabajo en la máquina local antes de implementarlas en el clúster. También es una función muy utilizada entre los administradores que ya están familiarizados con la especificación YAML de Kubernetes y desean ejecutar cargas de trabajo en nodos individuales en lugar de clústeres. Estamos viendo un gran interés en usar Kubernetes YAML en contextos distintos a los clústeres tradicionales, como los sistemas de servidor de un solo nodo, los dispositivos de Internet de las cosas (IoT) y, especialmente, la computación perimetral.

Tener una sola especificación para declarar cargas de trabajo en contenedores es un gran paso adelante.Las dos ventajas más importantes son portabilidad y fácil de adoptarPrimero, las cargas de trabajo pueden ser altamente portátiles en forma de Kubernetes YAML, que las organizaciones pueden implementar en una variedad de contextos dentro de su entorno de TI. En segundo lugar, es útil cuando los desarrolladores, usuarios y administradores solo necesitan estar familiarizados con una especificación: las organizaciones pueden capacitar a su personal en consecuencia. Si bien alternativas como Compose todavía se usan ampliamente, creo que Kubernetes YAML es el futuro de las cargas de trabajo de contenedores declarativos.

¿Por qué ejecutar Kubernetes YAML dentro de un servicio systemd en contenedores?

Una gran ventaja de Podman es su integración con systemd. Systemd administra muchas herramientas y sus dependencias, y las cargas de trabajo en contenedores no son una excepción.Como escribimos en el artículo anterior, Podman elimina la complejidad de ejecutar contenedores en systemd, permite usar podman-generate-systemd Ordenar. cuatrillizosPronto se integrará con el proyecto Podman para ayudar a simplificarlo aún más.

[ Download now: Podman basics cheat sheet .]

El conjunto de características de Podman ha crecido con el tiempo. Ahora puede ejecutar contenedores y pods como unidades systemd. La integración de Podman con systemd también permite actualizaciones y reversiones automáticas, en las que normalmente se basan IoT y la informática perimetral. A partir de la versión 4.2 de Podman, Kubernetes YAML se puede ejecutar con Podman y systemd.

Ejecutar Kubernetes YAML en systemd ha sido una solicitud popular de la comunidad. Esta solicitud resuena con la visión de nuestro equipo de proporcionar una especificación única para las cargas de trabajo en contenedores que se ejecutan en una variedad de entornos, incluido systemd.

Ejecución de cargas de trabajo de Kubernetes en systemd con Podman

El flujo de trabajo para ejecutar cargas de trabajo de Kubernetes en systemd usando Podman es simple.Todo lo que necesita hacer es ejecutar el nuevo [email protected] plantilla del sistema Utilice archivos YAML de Kubernetes. Podman y systemd se encargan del resto. Eche un vistazo más de cerca a cómo funciona a continuación.

Primero, cree un archivo YAML de Kubernetes. La siguiente carga de trabajo impulsa el libro de visitas utilizando la base de datos y dos contenedores en el front-end de PHP:

$ cat ~/guestbook.yaml
apiVersion: v1                              	
kind: Pod                                   	
metadata:                                   	
  name: guestbook                           	
spec:                                       	
  containers:                               	
	- name: backend                         	
  	image: "docker.io/redis:6"            	
  	ports:                                	
    	- containerPort: 6379               	
	- name: frontend                        	
  	image: gcr.io/google_samples/gb-frontend:v6
  	privileged: true                      	
  	ports:                                	
    	- containerPort: 80                 	
      	hostPort: 8080                    	
  	env:                                  	
    	- name: GET_HOSTS_FROM              	
      	value: "env"                      	      	
    	- name: REDIS_SLAVE_SERVICE_HOST    	
      	value: "guestbook-backend"

A continuación, coloque el archivo YAML de Kubernetes en la plantilla systemd. Las plantillas de systemd permiten gestionar varias unidades desde un único archivo de servicio. La idea es pasar la ruta al archivo YAML de Kubernetes a la plantilla y dejar que systemd y Podman se encarguen de iniciar las unidades, los pods y los contenedores de systemd.Tenga en cuenta que debe utilizar systemd-escape:

$ escaped=$(systemd-escape ~/guestbook.yaml)

$ systemctl --user start podman-kube@$escaped.service

Asegúrese de que el servicio esté activo y que el pod se esté ejecutando:

$ systemctl --user is-active podman-kube@$escaped.service
active

$ podman pod ps
POD ID    	NAME    	STATUS  	CREATED    	INFRA ID  	# OF CONTAINERS
cd12d516cb6f  guestbook   Running 	43 seconds ago  6c4d8a918ced  3

El servicio está activo y el pod del libro de visitas se está ejecutando.Hay tres contenedores corriendo dentro. guestbook vaina:

• guestbook-backend ¿El contenedor de la base de datos ejecuta Redis?

• guestbook-frontend Es el contenedor que ejecuta Apache Guestbook.
• 147333416a5c-infra son los llamados contenedores de infraestructura que mantienen abiertos ciertos recursos de pod (como espacios de nombres y puertos).

Pero como puede ver a continuación, hay un cuarto contenedor en ejecución. 5eabcc753cb5-service es un contenedor de servicioContenedores de servicio introducidos en Podman v4.2, ejecutados antes que cualquier Pod o Contenedor play kube Luego se detiene. Abarcan todo el ciclo de vida de una carga de trabajo de Kubernetes y permiten que systemd rastree y administre los servicios en consecuencia.

$ podman ps
CONTAINER ID  IMAGE                                    	COMMAND           	CREATED    	STATUS        	PORTS             	NAMES
4306a0e4af64  localhost/podman-pause:4.2.0-dev-1658325496                    	5 seconds ago  Up 3 seconds ago                    	5eabcc753cb5-service
1c8cd5e235ad  localhost/podman-pause:4.2.0-dev-1658325496                    	5 seconds ago  Up 3 seconds ago  0.0.0.0:8080->80/tcp  147333416a5c-infra
81d6414dce1a  docker.io/library/redis:6                	redis-server      	3 seconds ago  Up 2 seconds ago  0.0.0.0:8080->80/tcp  guestbook-backend
af0a26964fa9  gcr.io/google_samples/gb-frontend:v6     	apache2-foregroun...  2 seconds ago  Up 2 seconds ago  0.0.0.0:8080->80/tcp  guestbook-frontend

[ Learn how to manage your Linux environment for success. ]

Compruebe si el libro de visitas es válido visitando en el navegador de su elección.

Funciona como se esperaba.Una vez que haya terminado la prueba, puede detener el servicio systemctl:

$ systemctl --user stop podman-kube@$escaped.service

$ podman pod ps
POD ID  	NAME    	STATUS  	CREATED 	INFRA ID	# OF CONTAINERS

Creemos que este flujo de trabajo es superior a podman-generate-systemd Flujo de trabajo que requiere que el usuario primero cree un contenedor o pod, luego genere una unidad systemd para él y luego lo instale.En estos casos, mediante el uso start [email protected] Plantillas, los usuarios solo necesitan pasar su Kubernetes YAML y plantillas; systemd y Podman se encargarán del resto. Puede esperar que las futuras versiones de Podman mejoren este enfoque basado en plantillas y las mejores prácticas que esperamos desarrollar con la comunidad.

Visión: unificar las cargas de trabajo en contenedores

Imagine que está diseñando una aplicación compleja con varios contenedores que se ejecutan en varios módulos. La declaración de una carga de trabajo con Kubernetes YAML puede ejecutar la carga de trabajo en una variedad de entornos, desde desarrollarla en una estación de trabajo local hasta implementarla en un entorno de un solo nodo con Ansible y ejecutarla en systemd.

Además, estas aplicaciones también se pueden implementar en diferentes niveles de borde, como MicroShift o OpenShift de un solo nodoSin embargo, esto significa ejecutar muchos servicios en su dispositivo, lo que consume mucha memoria y tiempo de CPU, y es posible que no funcione en todos los entornos o casos de uso. Sin una forma unificada de declarar cargas de trabajo de contenedores en estos entornos (por ejemplo, Kubernetes YAML), nos vemos obligados a utilizar enfoques alternativos y más complejos, como Compose. Ejecutar la misma carga de trabajo de varias maneras aumenta la complejidad de la arquitectura y aumenta el costo de la capacitación, el desarrollo de herramientas, las pruebas y el mantenimiento. Ejecutar Kubernetes YAML con Podman ahora es una alternativa viable, y systemd se encarga de la gestión del ciclo de vida.

Finalmente, la misma carga de trabajo se puede implementar en los productos de Kubernetes, incluido OpenShift, para obtener todos los beneficios de un sistema realmente distribuido, que incluye conmutación por error, replicación y más.

envolver

Al agregar Kubernetes YAML, Podman proporciona una solución unificada para declarar cargas de trabajo de contenedores en todos los entornos y simplificar la complejidad para desarrolladores y administradores de sistemas. No dude en probar la función en Fedora 36 y CentOS Stream 9, donde Podman v4.2 ya está disponible.