Convertidor de Docker Compose a Kubernetes
Pega un docker-compose.yml y obtén manifiestos de Kubernetes: un Deployment y un Service por servicio, ConfigMaps para las variables de entorno, un Secret para las contraseñas, PersistentVolumeClaims para los volúmenes y probes a partir de los healthchecks. Las notas explican cada ajuste que requiere tu atención.
Última actualización:
Cómo usar Convertidor de Docker Compose a Kubernetes
- Pega tu docker-compose.yml o abre el archivo. Primero se carga un ejemplo con un servidor web, una API, una base de datos y una caché.
- Elige las opciones: namespace, tipo de Service, cómo se tratan las variables de entorno y los montajes bind, y el tamaño del PVC.
- Lee las notas debajo del resultado. Señalan lo que Compose hace y Kubernetes hace de otra forma, como depends_on o las imágenes construidas localmente.
- Filtra por tipo para revisar Deployments, Services o PVCs uno por uno, y luego copia o descarga el YAML o un ZIP.
- Aplícalo con
kubectl apply -f k8s.yamly revisa los pods conkubectl get pods.
Cómo se corresponden las claves de Compose con Kubernetes
| docker-compose.yml | Kubernetes | Notas |
|---|---|---|
| servicio | Deployment + Service | Las etiquetas app.kubernetes.io/name los conectan |
image, command, entrypoint | image, args, command | En Kubernetes, command sustituye el ENTRYPOINT de la imagen |
ports: "8080:80", expose | port / targetPort del Service | Los puertos del host solo se aplican a NodePort (30000-32767) |
environment | ConfigMap + envFrom | Los nombres sensibles van a un Secret |
env_file | kubectl create configmap --from-env-file | El archivo no está disponible en el navegador |
| volumen con nombre | PersistentVolumeClaim | ReadWriteOnce por defecto |
| archivo montado con bind | ConfigMap con subPath | Rellénalo a partir del archivo real |
healthcheck | livenessProbe, readinessProbe | interval → periodSeconds, retries → failureThreshold, start_period → initialDelaySeconds |
deploy.replicas | spec.replicas | deploy.mode: global → DaemonSet |
deploy.resources, mem_limit, cpus | resources.limits / requests | 512M → 512Mi, 0.5 CPU → 500m |
user, cap_add, privileged, read_only | securityContext | runAsUser necesita un UID numérico |
depends_on, networks, container_name | (ninguno) | Usa probes, NetworkPolicies y nombres de Service |
Después de convertir: una breve lista de comprobación
- Imágenes: cada Deployment debe apuntar a una imagen de un registro del que el clúster pueda descargarla, idealmente con una etiqueta fija.
- Secrets: sustituye las contraseñas de ejemplo y mantén los valores reales de los Secret fuera de Git (usa Sealed Secrets, SOPS o un operador de secretos externo).
- Almacenamiento: revisa los tamaños de los PVC y la storage class. Las bases de datos suelen ir en un StatefulSet cuando una sola réplica se queda corta.
- Tráfico: añade un Ingress o un Gateway para los servicios HTTP que deban ser públicos, en lugar de exponer cada puerto como LoadBalancer.
- Recursos: define requests de CPU y memoria para cada contenedor para que el scheduler pueda ubicar los pods de forma sensata.
- Valida el resultado con el validador de YAML de Kubernetes y guarda las contraseñas con el generador de Secrets de Kubernetes.
Preguntas frecuentes
¿Puede Kubernetes ejecutar directamente un docker-compose.yml?
No. Kubernetes usa sus propios tipos de recursos, así que hay que traducir el archivo de Compose: cada servicio se convierte en un Deployment que ejecuta los pods y, si tiene puertos, en un Service que le da un nombre y una dirección estables. Esta herramienta hace esa traducción en tu navegador, de forma similar a la herramienta de línea de comandos kompose.
¿Cómo se encuentran los servicios entre sí tras la conversión?
Cada Service conserva el nombre del servicio de Compose, y el DNS de Kubernetes resuelve ese nombre dentro del namespace, así que una aplicación que se conecta a db:5432 sigue funcionando. Desde otro namespace usa db.namespace.svc.cluster.local. Los nombres con guiones bajos o mayúsculas se renombran porque los nombres de Kubernetes deben ser etiquetas DNS en minúsculas.
¿Qué pasa con depends_on?
Kubernetes no tiene orden de arranque entre Deployments; todos los pods arrancan a la vez. Haz que cada aplicación reintente sus conexiones, confía en las readiness probes para que el tráfico solo llegue a pods listos, o añade un init container que espere a la dependencia.
¿Cómo se convierten los volúmenes?
Los volúmenes con nombre se convierten en PersistentVolumeClaims montados en la misma ruta, y los Deployments que usan uno reciben la estrategia Recreate para que el pod antiguo libere primero el volumen. Un único archivo montado con bind, como nginx.conf, se convierte en un ConfigMap montado con subPath. Las carpetas montadas con bind se convierten en un PVC, emptyDir o hostPath según la opción que elijas.
¿Por qué mi puerto publicado es un Service ClusterIP?
Un Service ClusterIP solo es accesible dentro del clúster, que es la opción segura por defecto. Para acceder desde fuera, elige NodePort o LoadBalancer en las opciones, añade un Ingress para el tráfico HTTP o usa kubectl port-forward durante las pruebas.
¿Qué pasa con las imágenes construidas con build:?
Los nodos de Kubernetes descargan las imágenes de un registro; no pueden construirlas a partir de un Dockerfile de tu proyecto. Construye la imagen, súbela a un registro al que el clúster pueda acceder y pon ese nombre de imagen en el Deployment. La herramienta marca estos servicios con una nota en rojo.
¿Se sube mi archivo de Compose?
No. El YAML se analiza y se convierte con JavaScript en la pestaña de tu navegador, así que las contraseñas y los nombres de host internos del archivo nunca salen de tu computadora.
¿Se prueban todas las herramientas de FreeToolCabin para comprobar su calidad y precisión?
Sí. Cada herramienta del sitio pasa pruebas automáticas en navegadores reales para comprobar que el resultado es correcto y que no hay errores. Si encuentras un fallo o tienes una sugerencia, escríbenos a [email protected] y lo revisaremos.