Un Deployment en Kubernetes es un recurso que se utiliza para gestionar aplicaciones de manera declarativa, asegurando que un número específico de réplicas de un Pod (contenedores) estén siempre en ejecución. Por ejemplo, si defines un Deployment con tres réplicas, Kubernetes se encarga de crear y mantener esos tres Pods, reiniciándolos o reubicándolos automáticamente si fallan o si un nodo del clúster deja de funcionar.

Esto se logra mediante un archivo YAML que especifica la configuración del Deployment, como la imagen del contenedor, los puertos y las políticas de actualización, y se aplica con comandos como kubectl apply. Es una forma básica pero poderosa de garantizar disponibilidad y escalabilidad, aunque requiere que configures manualmente cada detalle.
Deployment de MySQL en el clúster
Ejemplo: Asumimos que hemos creado un cluster en GKE de Google Cloud Platform o en otra plataforma cloud, como AKS de Azure, EKS de Amazon o OKE de Oracle Cloud Platform. Accedemos mediante consola o en la CLI local para hacer un deployment de la base de datos MySQL.
Requerimos de un secreto, que es la clave de usuario de MySQL, para lo cual podemos usar este comando:
kubectl create secret generic mysql-secrets --from-literal=ROOT_PASSWORD="password"
Luego vamos a definir la creación de un volumen persistente para datos con un archivo volume.yaml:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mysql-data-disk
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
Procedemos a crear nuestro deployment con el archivo deployment.yaml:
apiVersion: apps/v1
kind: Deployment
metadata:
name: mysql-deployment
labels:
app: mysql
spec:
replicas: 1
selector:
matchLabels:
app: mysql
template:
metadata:
labels:
app: mysql
spec:
containers:
- name: mysql
image: mysql:8.0
ports:
- containerPort: 3306
volumeMounts:
- mountPath: "/var/lib/mysql"
subPath: "mysql"
name: mysql-data
env:
- name: MYSQL_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: mysql-secrets
key: ROOT_PASSWORD
- name: MYSQL_USER
value: testuser
- name: MYSQL_PASSWORD
value: password
volumes:
- name: mysql-data
persistentVolumeClaim:
claimName: mysql-data-disk
Finalmente creamos nuestro sevicio con service.yaml:
apiVersion: v1
kind: Service
metadata:
name: mysql-service
spec:
selector:
app: mysql
ports:
- protocol: TCP
port: 3306
targetPort: 3306
Para hacer el deployment de nuestra base de datos en nuestro cluster ejecutamos los siguientes comandos:
kubectl apply -f volume.yaml
kubectl apply -f deployment.yaml
kubectl apply -f service.yaml
Esperamos un tiempo prudencial y verificamos la cración del recurso con un status running:
kubectl get pods
Para borrar el deployment pudes utilizar:
kubectl delete -f service.yaml
kubectl delete -f deployment.yaml
kubectl delete -f volume.yaml
Deployment de MySQL en el clúster usando Helm
Por otro lado, un Helm Chart es una herramienta más avanzada que simplifica la gestión de aplicaciones en Kubernetes. Se trata de un paquete que contiene plantillas predefinidas de recursos YAML (como Deployments, Services, ConfigMaps, etc.) junto con un archivo values.yaml que permite personalizar esas plantillas sin modificarlas directamente.
Desde la consola agregamos el repositorio Bitmani Helm:
helm repo add bitnami https://charts.bitnami.com/bitnami
Actualizamos los paquetes:
helm repo update
Instalamos MySQL utilizando Helm:
helm install mydb bitnami/mysql
Esperamos un tiempo prudencial y verificamos la cración del recurso con un status running:
kubectl get pods
Puedes listar los deployments creados con Helm usando:
helm ls
Para borrar el deployment pudes utilizar:
helm delete mydb

Helm, conocido como el «gestor de paquetes de Kubernetes», te permite instalar, actualizar o eliminar aplicaciones complejas con un solo comando (por ejemplo, helm install mi-app ./mi-chart), manejando dependencias y versiones de manera eficiente. Es especialmente útil para aplicaciones grandes o reutilizables, ya que organiza y automatiza lo que de otra forma serían múltiples archivos YAML manuales, ahorrando tiempo y reduciendo errores.
En Kubernetes, la técnica más utilizada hoy en día depende del contexto, pero en general, usar Helm Charts ha ganado mucha popularidad y se considera una práctica más común y recomendada frente a los deployments manuales, especialmente en entornos de producción o proyectos más complejos. Vamos a desglosarlo:
Deployments Manuales
- Qué implica: Crear y aplicar archivos YAML directamente (por ejemplo, con kubectl apply -f archivo.yaml) para definir recursos como Pods, Deployments, Services, etc.
- Cuándo se usa más:
- En entornos pequeños o experimentales (como pruebas locales o clusters personales).
- Cuando se necesita algo rápido y simple, como un despliegue único sin muchas dependencias.
- Por personas que están aprendiendo Kubernetes y quieren entender los fundamentos antes de usar herramientas más avanzadas.
- Limitaciones:
- Es propenso a errores humanos.
- Difícil de mantener y escalar en aplicaciones complejas con múltiples recursos.
- No facilita la reutilización ni la gestión de versiones.
Helm Charts
- Qué implica: Helm es un gestor de paquetes para Kubernetes que usa «Charts», que son plantillas preconfiguradas de recursos YAML con valores personalizables. Permite instalar, actualizar y gestionar aplicaciones con comandos como helm install o helm upgrade.
- Cuándo se usa más:
- En entornos de producción o proyectos grandes donde se necesita consistencia y automatización.
- Cuando se deployan aplicaciones complejas con múltiples componentes (por ejemplo, bases de datos + backend + frontend).
- En equipos que requieren colaboración, ya que Helm Charts se pueden versionar y compartir fácilmente.
- Ventajas:
- Simplifica la gestión de configuraciones con variables (valores personalizables en values.yaml).
- Permite actualizaciones y rollback de manera más controlada.
- Hay un ecosistema amplio de Charts públicos (como los de Bitnami) que ahorran tiempo.
Tendencia Actual
- Según la comunidad y las prácticas modernas (2025), Helm Charts es la técnica dominante en entornos profesionales y de escala. Esto se ve reflejado en:
- Su adopción en DevOps y CI/CD (integración con herramientas como GitOps, ArgoCD o Flux).
- La preferencia por la automatización y la reproducibilidad, que Helm facilita.
- Encuestas como las de la CNCF (Cloud Native Computing Foundation) suelen mostrar un uso creciente de Helm frente a YAML manual.