Ejemplo de Patrón Sidecar en Kubernetes

Siguiendo con nuestros artículos de Kubernetes, en esta nueva entrada vamos a ver un Ejemplo de Patrón Sidecar en Kubernetes.

Kubernetes es un open-source orquestador de contenedores, que entre otras cosas, nos permite el despliegue continuo, el escalado, y la gestión de esos contenedores. Actualmente es el estándar de facto, para todas aquellas aplicaciones contenerizadas.

Tal y como comentamos en este artículo, un Pod es el objeto más simple y pequeño en Kubernetes y representa una sola instancia de la aplicación. Además un Pod es una colección de uno o más contenedores, y encapsula un contenedor de una aplicación. Por lo que partiendo de esta base y definición vamos a ver como funciona y qué es el patrón Sidecar en Kubernetes.

¿Qué es el Patrón Sidecar en Kubernetes?

Como hemos comentado antes un Pod es una colección de uno o más contenedores, es decir, múltiples contenedores pueden ser alojados en el mismo Pod.

Ahora si partimos del principio de separación de preocupaciones (separation of concerns principle), cada contenedor tiene que hacer una y sola una única cosa. Por lo que, qué pasa si necesitamos que un Pod haga más de una?, pues que necesitaríamos por ejemplo, aplicar el Patrón sidecar.

En el Sidecar Pattern o Patrón Sidecar en Kubernetes, lo que hacemos es ejecutar otro contenedor dentro del Pod. Por lo que al definir el pod o el deployment, el nuevo contenedor se encargará de realizar una nueva función.

Características principales del Patrón Sidecar

• El Patrón Sidecar va a permitir el diseño de contenedores modulares. Los cuales con funcionalidades diversas van a poder ser reutilizados en diferentes partes con mínimos cambios.
• Un sidecar, se ejecuta en el mismo Pod de la aplicación contenedora, como un contenedor aparte, compartiendo mismo volúmen y red.
• Los usos más comunes en donde se suele emplear el sidecar es en el envío de logs, monitorización de logs y agentes de monitorización.
• Una de las ventajas de aplicar este patrón de diseño es que al tener el contenedor separado para una funcionalidad específica, vamos a poder reiniciar o tener health checks diferentes. Y además podremos utilizar las funcionalidades de Kubernetes para contenedores.
• Hay que tener en cuenta que el objetivo del Sidecar es que sea independiente, lo más simple posible y que pueda ser conectado a cualquier sitio. Por lo que si el sidecar consume muchos recursos o es muy complejo habría que pensar en unirlo a la aplicación principal o no utilizar este patrón.

Vamos a verlo mejor con un ejemplo:

Ejemplo de Patrón Sidecar en Kubernetes

Imagína que tenemos un Pod el cual esta ejecutando una imagen de nginx. Todos los logs que nuestro nginx genera necesitamos que puedan ser consultados por el equipo de monitorización, de manera que puedan detectar cualquier problema, por lo que deben ser enviados a un volumen. Por lo que tenemos nuestro nginx que funciona como web server, y siguiendo el principio de separación de preocupaciones, no puede encargarse de otra tarea, por lo que necesitamos otro contenedor que envíe los logs al volúmen especificado.

Es en este caso cuando aplicamos el patrón sidecar, lo que estamos haciendo es emplear otro contenedor para que dentro del mismo Pod haga una tarea concreta.

Podríamos definir un Pod con un sidecar de envío de logs de un nginx de la siguiente manera:

apiVersion: v1
kind: Pod
metadata:
  name: sidecar-pattern
spec:
  volumes:
    - name: nginx-logs
      emptyDir: {}

  containers:
    - name: nginx
      image: nginx
      volumeMounts:
        - name: nginx-logs
          mountPath: /var/log/nginx

    - name: sidecar-container
      image: busybox
      command: ["sh","-c","while true; do cat /var/log/nginx/access.log /var/log/nginx/error.log; sleep 20; done"]
      volumeMounts:
        - name: nginx-logs
          mountPath: /var/log/nginx

En la definición del Pod anterior podemos ver dos diferentes imagenes dentro del mismo Pod. Vemos la imagen principal que sería el web server en nginx, y el sidecar, que en este caso sería el famoso busybox.

Como hemos comentado anteriormente la idea en este ejemplo es poder ver los logs de nginx, que por defecto, son access.log y error.log. Para ello vamos a montar, un volúmen (el cual será efímero para el ejemplo), al que se volcarán los logs y nuestro sidecar los consultará cada 20 segundos.

Si nos fijamos en nuestro sidecar, cumple las características principales que hemos comentado anteriormente, se ejecuta en el mismo Pod, como un contenedor aparte, es independiente y muy sencillo; y además se encarga de envíar y mostrar logs.

Conclusión

En esta entrada hemos visto un ejemplo de Patrón Sidecar en Kubernetes, para ver cuándo y como usarlo, el cual nos ayudará a añadir nuevas funcionalidades a nuestros Pods cuando así lo necesitemos.

No te olvides de seguirnos en nuestras redes sociales Facebook o Twitter para estar actualizado.