¿Cómo hacer desarrollo local con Kubernetes?

Kubernetes parece tener que ver con la implementación de contenedores en una nube de clusters. Lo que parece no tocar es el desarrollo y los entornos de ensayo (o similares).

Durante el desarrollo, quiere estar lo más cerca posible del entorno de producción con algunos cambios importantes:

  • Implementado localmente (o al less en algún lugar donde usted y solo usted puede acceder )
  • Utilice el último código fuente en la actualización de la página (suponiendo que sea un website; idealmente, actualice automáticamente la página en el file local, lo que se puede hacer si monta el código fuente y usa algunas cosas como Yeoman ).

Del mismo modo, uno puede querer un entorno no público para hacer una continuous integration .

¿Admite Kubernetes ese tipo de entorno de desarrollo o es algo que uno debe build, esperando que durante la producción funcione?

Actualización (2016-07-15)

Con el lanzamiento de Kubernetes 1.3, Minikube es ahora la forma recomendada de ejecutar Kubernetes en su máquina local para el desarrollo.


Puede ejecutar Kubernetes localmente a través de Docker . Una vez que tiene un nodo en ejecución, puede iniciar un pod que tenga un server web simple y que monte un volumen desde su máquina host. Cuando acceda al server web, leerá desde el volumen y, si ha cambiado el file en su disco local, puede publicar la última versión.

Otro gran punto de partida es esta configuration de Vagrant , esp. si su sistema operativo host es Windows. Las ventajas obvias son

  • configuration rápida e indolora
  • fácil de destruir / recrear la máquina
  • límite implícito de resources
  • capacidad de probar el escalamiento horizontal creando múltiples nodos

Las desventajas: necesitas mucha RAM, y VirtualBox es VirtualBox … para bien o para mal.

Una ventaja / desventaja mixta es mapear files a través de NFS. En nuestra configuration, creamos dos sets de definiciones de RC: una que simplemente descarga una image acoplable de nuestros serveres de aplicaciones; el otro con 7 líneas adicionales que configuran el mapeo de files desde HostOS -> Vagabundo -> VirtualBox -> CoreOS -> Kubernetes pod; sobrescribir el código fuente de la image Docker.

La desventaja de esto es la caching de files NFS; con ella, es problemático, sin ella, es problemáticamente lenta. Incluso al establecer mount_options: 'nolock,vers=3,udp,noac' no elimina por completo los problemas de caching, pero funciona la mayor parte del time. Algunas tareas de Gulp ejecutadas en un contenedor pueden tardar 5 minutos cuando demoran 8 segundos en el sistema operativo host. Un buen compromiso parece ser mount_options: 'nolock,vers=3,udp,ac,hard,noatime,nodiratime,acregmin=2,acdirmin=5,acregmax=15,acdirmax=15' .

En cuanto a la recarga automática de códigos, eso es específico del idioma, pero estamos contentos con el devserver de Django para Python y Nodemon para Node.js. Para los proyectos de frontend, puedes hacer mucho con algo como gulp + browserSync + watch, pero para muchos desarrolladores no es difícil servir desde Apache y solo hacer hard refresh tradicional.

Mantenemos 4 juegos de files yaml para Kubernetes. Dev, "devstable", etapa, prod. Las diferencias entre ellos son

  • variables env definiendo explícitamente el entorno (dev / stage / prod)
  • cantidad de réplicas
  • devstable, stage, prod usa imágenes del acoplador
  • dev usa imágenes de acoplador y asigna una carpeta NFS con código fuente sobre ellas.

Es muy útil crear muchos alias de bash y autocomplete. Solo puedo escribir rec users y haré kubectl delete -f ... ; kubectl create -f ... kubectl delete -f ... ; kubectl create -f ... Si quiero que se inicie toda la configuration, recfo , y recrea una docena de services, tirando de las últimas imágenes del acoplador, importando el último volcado de bases de datos desde el entorno intermedio y limpiando los viejos files Docker para ahorrar espacio.

El tipo de "recarga caliente" es algo que tenemos planes de agregar, pero no es tan fácil como podría ser hoy. Sin embargo, si se siente aventurero, puede usar rsync con docker exec, kubectl exec u osc exec (todos hacen lo mismo aproximadamente) para sincronizar un directory local en un contenedor cada vez que cambie. Puedes usar rsync con kubectl u osc exec así:

 # rsync using osc as netcat $ rsync -av -e 'osc exec -ip test -- /bin/bash' mylocalfolder/ /tmp/remote/folder 

Hemos estado trabajando en una herramienta para hacer esto. La idea básica es que tiene un clúster de Kubernetes remoto, de hecho un entorno de transición, y luego ejecuta el código localmente y obtiene un proxy para el clúster remoto. Obtiene acceso de networking transparente, variables de entorno copydas, acceso a volúmenes … lo más cerca posible del entorno remoto, pero con su código ejecutándose localmente y bajo su control total.

Entonces puedes hacer un desarrollo en vivo, por ejemplo. Documentos en http://telepresence.io

Consulte https://github.com/kubernetes/kubernetes/issues/12278 para ver cómo montar un volumen desde la máquina host, el equivalente de:

 docker run -v hostPath:ContainerPath