Despliegue de Docker en Kubernetes

13

Estoy usando una biblioteca de terceros que crea contenedores acoplables hermanos a través de:

docker run -d /var/run/docker.sock:/var/run/docker.sock ...

Estoy tratando de crear una implementación de Kubernetes del contenedor anterior, pero actualmente obtengo:

No se puede conectar al demonio Docker en unix: ///var/run/docker.sock. ¿Se está ejecutando el Docker Daemon?

Esto se espera porque no estoy declarando /var/run/docker.sockcomo un volumen en la implementación yaml.

El problema es que no sé cómo hacer esto. ¿Es posible montar /var/run/docker.sockcomo volumen en un despliegue yaml?

Si no es así, ¿cuál es el mejor enfoque para ejecutar contenedores de hermanos Docker desde una implementación / pod de Kubernetes?

kubernetes docker-in-docker

— rys
fuente

19

Sin verificar, ya que me parece frágil iniciar un contenedor fuera de la supervisión de k8s, pero debería poder montarlo /var/run/docker.sockcon un volumen hostPath .

Ejemplo de variación de la documentación:

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: gcr.io/google_containers/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /var/run/docker.sock
      name: docker-sock-volume
  volumes:
  - name: docker-sock-volume
    hostPath:
      # location on host
      path: /var/run/docker.sock
      # this field is optional
      type: File

Creo que un montaje simple debería ser suficiente para permitir la comunicación del cliente de Docker dentro del contenedor al Docker Daemon en el host, pero en caso de que obtenga un error de permiso de escritura, significa que debe ejecutar su contenedor como contenedor privilegiado utilizando un objeto securityContext como tal (solo un extracto de arriba para mostrar la suma, valores tomados de la documentación ):

spec:
  containers:
  - image: gcr.io/google_containers/test-webserver
    securityContext:
      privileged: true
    name: test-container

— Tensibai
fuente

Esto funcionó, gracias. Sí, es una herramienta de terceros, por lo que no es ideal. Pero al menos quiero que el contenedor principal en Kubernetes lo haga más confiable. El contenedor aumenta los contenedores temporales con navegadores para pruebas de IU de automatización, luego se destruye el contenedor del navegador.

— rys

@rys sí, ese fue un caso en el que pensé, aún puede tener problemas si la carga del nodo es demasiado alta ya que los k8 pueden mover su contenedor 'lanzador'. Pero supongo que el fracaso del conjunto de pruebas es algo aceptable en este caso

— Tensibai, el

2

Aunque esta es una solución que funciona (la uso yo mismo), existen algunos inconvenientes para ejecutar Docker en un pod Kubernetes montando /var/run/docker.sock

Principalmente el hecho de que está trabajando con contenedores Docker fuera del control de Kubernetes.

Otra solución sugerida que encontré es usar un contenedor lateral en su cápsula. Vea un caso para Docker-in-Docker en Kubernetes . Hay dos partes donde la solución propuesta está en la parte 2 .

Espero que esto ayude.

— Eldad Assis
fuente