Generador de YAML de Kubernetes
Crea manifiestos de Kubernetes listos para aplicar a partir de un formulario sencillo. Elige los recursos que necesitas (Deployment, Service, Ingress, ConfigMap, Secret y HorizontalPodAutoscaler) y el YAML se escribe con las versiones estables actuales de la API, etiquetas coherentes, sondas de estado, solicitudes de recursos y un contexto de seguridad reforzado. Todo se genera en tu navegador.
Última actualización:
Manifiestos generados
Aplicar:
Cómo usar Generador de YAML de Kubernetes
- Elige los recursos que quieres en la parte superior; sus ajustes aparecen en el formulario.
- Describe la app: nombre, namespace, imagen (con una etiqueta de versión) y cualquier etiqueta adicional.
- Configura el Deployment: réplicas, puerto del contenedor, CPU y memoria, rutas de las sondas y variables de entorno.
- Exponla con un Service y un host de Ingress, y añade ajustes al ConfigMap o al Secret, o escalado automático con el HPA.
- Corrige las notas en rojo, luego copia o descarga el YAML y ejecuta el comando kubectl apply que se muestra.
Qué hace cada manifiesto
| Kind | apiVersion | Propósito | Vinculado mediante |
|---|---|---|---|
| Deployment | apps/v1 | Ejecuta N réplicas de tu pod y realiza actualizaciones progresivas | spec.selector.matchLabels |
| Service | v1 | IP de clúster y nombre DNS estables (web-api.default.svc) delante de los pods | spec.selector = etiquetas del pod |
| Ingress | networking.k8s.io/v1 | Enruta el tráfico HTTP(S) externo de un host y una ruta a un Service | backend.service.name y nombre del puerto |
| ConfigMap | v1 | Configuración no secreta como pares clave/valor | envFrom.configMapRef |
| Secret | v1 | Contraseñas, tokens y claves (codificados en base64) | envFrom.secretRef |
| HorizontalPodAutoscaler | autoscaling/v2 | Añade o quita pods para mantener la CPU o la memoria cerca de un objetivo | scaleTargetRef |
Cantidades de recursos
| Valor | Significado |
|---|---|
cpu: 1 | Una vCPU / núcleo |
cpu: 250m o 0.25 | Un cuarto de núcleo (m = milinúcleos) |
memory: 128Mi | 128 mebibytes = 134,217,728 bytes |
memory: 1Gi | 1 gibibyte = 1,073,741,824 bytes |
memory: 500M | 500 megabytes = 500,000,000 bytes (decimal) |
memory: 128m | 0.128 bytes: un error tipográfico habitual; usa Mi |
El HPA calcula la utilización como el uso real dividido entre la solicitud. Con una solicitud de CPU de 100m y un objetivo del 70%, añade pods cuando el pod medio usa más de 70m de CPU, con desiredReplicas = ceil(currentReplicas × currentUsage / target).
Lista de comprobación para producción
- Fija las versiones de las imágenes (
app:1.4.2o un digest@sha256:);latesthace que las reversiones no sean fiables. - Usa las mismas etiquetas en todas partes. El selector del Deployment es inmutable, así que elige la etiqueta
app.kubernetes.io/nameuna sola vez y deja las etiquetas adicionales fuera del selector. - Expón un endpoint de disponibilidad y gestiona SIGTERM para que las solicitudes en curso terminen durante las actualizaciones progresivas.
- Ejecuta al menos dos réplicas de todo lo que dé servicio a usuarios, y considera un PodDisruptionBudget para que el mantenimiento de nodos nunca tumbe todos los pods.
- Valida antes de aplicar:
kubectl apply --dry-run=server -f app.yamlokubectl diff -f app.yaml. - Ingress es estable pero está congelado; las nuevas funciones de enrutamiento de tráfico llegan a la Gateway API (HTTPRoute), que ya admiten muchos controladores.
Preguntas frecuentes
¿Cuál es la diferencia entre un Deployment y un Service?
Un Deployment ejecuta y actualiza un conjunto de pods idénticos (tus contenedores). Un Service da a esos pods una IP virtual y un nombre DNS estables y reparte el tráfico entre ellos, encontrando los pods mediante el selector de etiquetas. Después, un Ingress enruta el tráfico HTTP(S) externo de un host y una ruta hacia el Service.
¿Qué solicitudes de CPU y memoria debo definir?
Las solicitudes son lo que el planificador reserva para cada pod; empieza cerca del uso típico del pod (por ejemplo, 100m de CPU y 128Mi de memoria para una API pequeña) y ajústalas según kubectl top pod o tu monitorización. Define un límite de memoria para que una fuga no agote el nodo. Muchos equipos dejan sin definir el límite de CPU para evitar el estrangulamiento, aunque sí solicitan CPU.
¿Cuál es la diferencia entre las sondas de disponibilidad y de actividad?
Si falla la sonda de disponibilidad (readiness), el pod se retira de los endpoints del Service hasta que se recupera, así que deja de recibir tráfico pero sigue en ejecución. Si falla la sonda de actividad (liveness), el kubelet reinicia el contenedor. Apunta la de disponibilidad a una comprobación que incluya las dependencias, y la de actividad a una comprobación ligera que solo falle cuando el proceso esté bloqueado.
¿Un Secret de Kubernetes está cifrado?
No de forma predeterminada. Los valores de un Secret solo están codificados en base64 y se guardan en etcd, sin cifrar a menos que el clúster active el cifrado en reposo. Restringe el acceso con RBAC, nunca subas valores reales a Git y usa una herramienta como Sealed Secrets, External Secrets Operator o SOPS para GitOps.
¿Por qué falta replicas cuando el HPA está activado?
Cuando un HorizontalPodAutoscaler gestiona un Deployment, un campo replicas en el manifiesto restablecería el número de pods cada vez que ejecutaras kubectl apply. Omitirlo permite que el HPA mantenga el control entre sus minReplicas y maxReplicas.
¿Qué versiones de la API usa el generador?
apps/v1 para Deployment, v1 para Service, ConfigMap y Secret, networking.k8s.io/v1 para Ingress (estable desde Kubernetes 1.19) y autoscaling/v2 para el HPA (estable desde 1.23). Las versiones antiguas, como extensions/v1beta1 y autoscaling/v2beta2, se han eliminado del Kubernetes actual.
¿Cómo aplico los archivos generados?
Guarda el YAML (por ejemplo, web-api.yaml), asegúrate de que el namespace existe y ejecuta kubectl apply -f web-api.yaml. Comprueba el despliegue con kubectl rollout status deployment/web-api y usa kubectl apply --dry-run=server -f web-api.yaml para validarlo contra tu clúster sin modificarlo.
¿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.