Tutorial: Kubernetes con k3s — Clúster de 3 Nodos, Ingress y Cloudflare en 30 Minutos

Montar un clúster de Kubernetes suena a proyecto de semanas, certificaciones y un presupuesto que necesita aprobación de junta directiva. Y durante años fue así. Pero en 2026, con k3s —el Kubernetes ligero de Rancher— puedes tener un clúster funcional de 3 nodos en lo que tardas en almorzar.

Este tutorial te lleva de cero a un clúster real corriendo una aplicación web, expuesta con Ingress, SSL con certificado de Cloudflare de 15 años y dominio propio. Sin servicios administrados. Sin excusas.

Lo que vas a construir

Al final de este tutorial tendrás:

                   ┌──────────────┐
                   │  Cloudflare  │
                   │  (DNS + SSL) │
                   └──────┬───────┘
                          │
                   ┌──────▼───────┐
                   │   Ingress    │
                   │  (Traefik)   │
                   └──────┬───────┘
                          │
              ┌───────────┼───────────┐
              │           │           │
        ┌─────▼─────┐ ┌──▼────┐ ┌───▼─────┐
        │  Master   │ │Worker1│ │Worker2  │
        │  k3s      │ │k3s   │ │k3s      │
        └───────────┘ └───────┘ └─────────┘
              │
    ┌─────────┼─────────┐
    │         │         │
┌───▼──┐ ┌───▼──┐ ┌───▼──┐
│ Pod1 │ │ Pod2 │ │ Pod3 │  ← Tu app web escalada
└──────┘ └──────┘ └──────┘

Tres servidores, un clúster real, y una app accesible desde internet con dominio propio.

Lo que necesitas antes de empezar

1. Tres servidores con Linux

Crea tres VPS. Las opciones más accesibles en mayo 2026:

Proveedor	Plan mínimo	Precio/mes (aprox)	Qué contratar
Hetzner	CX22 (2 vCPU, 4 GB)	~$4	3x CX22 con red privada
DigitalOcean	Basic Droplet (1 vCPU, 1 GB)	~$6	3x Droplets con VPC
OVH	VPS Starter (1 vCPU, 2 GB)	~$4	3x VPS
Linode	Nanode (1 vCPU, 1 GB)	~$5	3x Nanodes

Importante para el tutorial: al crear los servidores, activa la red privada si tu proveedor la ofrece (Hetzner la llama "Network", DigitalOcean "VPC", OVH "vRack"). Esto te da IPs internas para comunicación entre nodos sin exponer tráfico interno a internet.

Cada servidor debe tener:

1 GB de RAM mínimo (2 GB recomendado para el master)
1 CPU
10 GB de disco
Ubuntu 24.04 LTS (sistema operativo)
Red privada habilitada entre los tres (opcional pero altamente recomendado)

⚠️ Imprescindible: IP pública en el master. Sin una IP pública en el nodo master, Cloudflare no puede apuntar el dominio a tu servidor y Let's Encrypt no puede verificar que controlas el dominio. Los workers pueden tener solo IP privada si están en la misma red que el master, pero el master debe ser accesible desde internet en los puertos 80 y 443. Esto es no negociable para el SSL y el dominio.

Todos los proveedores mencionados arriba (Hetzner, DigitalOcean, OVH, Linode) incluyen una IPv4 pública con cada VPS sin costo adicional.

2. Acceso SSH a los tres servidores

Cuando creas cada VPS, el proveedor te da:

Una IP pública (ej: 167.99.123.45)
Un usuario (normalmente root en Hetzner/OVH, o el que configuraste en DigitalOcean)
Una contraseña o llave SSH

Verifica que puedes conectarte a cada uno desde tu terminal local:

ssh root@IP_DEL_SERVIDOR

Si usas llave SSH (recomendado):

# Si aún no tienes llave SSH en tu máquina local:
ssh-keygen -t ed25519 -C "tu-email@ejemplo.com"

# Copiarla a cada servidor:
ssh-copy-id root@IP_DEL_SERVIDOR

Si el proveedor te dio contraseña en vez de llave, cámbiala al conectarte por primera vez y configura acceso por llave.

3. Un dominio en Cloudflare

Necesitas un dominio configurado en Cloudflare. Si ya tienes uno, ve al panel de Cloudflare y asegúrate de que:

Los nameservers de tu dominio apuntan a Cloudflare (ej: eliza.ns.cloudflare.com)
El plan es Free (suficiente para este tutorial, incluye proxy y SSL)

Si no tienes dominio, compra uno en Cloudflare directamente (.com ~$10/año, .tech ~$8/año, .dev ~$12/año) o en Namecheap/Porkbun y luego añádelo a Cloudflare.

Para este tutorial usaré k3s.tu-dominio.com como subdominio de ejemplo. Tú usarás tu dominio real.

4. kubectl instalado en tu máquina local

kubectl es la herramienta de línea de comandos para controlar Kubernetes. La usarás para ver nodos, desplegar apps y monitorear.

# En tu máquina local (Linux/Mac):
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
chmod +x kubectl
sudo mv kubectl /usr/local/bin/

# En macOS con Homebrew:
brew install kubectl

# En Windows (PowerShell como administrador):
# winget install Kubernetes.kubectl

# Verificar instalación:
kubectl version --client

(Si prefieres no instalar kubectl, puedes ejecutar todos los comandos con sudo kubectl directamente en el master vía SSH.)

5. Verificación final antes de empezar

Ejecuta esto en tu terminal local y asegúrate de tener todas las respuestas antes de seguir:

# 1. ¿Puedo conectarme por SSH a los tres servidores?
ssh root@IP_DEL_MASTER "echo 'OK: master'"
ssh root@IP_DEL_WORKER1 "echo 'OK: worker1'"
ssh root@IP_DEL_WORKER2 "echo 'OK: worker2'"

# 2. ¿El master tiene IP pública? (debe mostrar una IP, no 10.x ni 192.168.x)
ssh root@IP_DEL_MASTER "curl -s ifconfig.me"
# Esto debe devolver la misma IP que usarás en Cloudflare

# 3. ¿Tengo kubectl?
kubectl version --client 2>/dev/null && echo "OK: kubectl" || echo "FALTA: kubectl"

# 4. ¿Tengo mi dominio en Cloudflare?
# Abre https://dash.cloudflare.com y confirma que ves tu dominio en la lista

¿Todo OK? Vamos a construir el clúster.

Nombres e IPs de ejemplo para este tutorial

En los comandos que siguen usaré estos nombres. Reemplázalos por los tuyos:

Master:  10.0.1.10  (k3s-master)   ← IP privada del master
Worker1: 10.0.1.20  (k3s-worker-1) ← IP privada del worker 1
Worker2: 10.0.1.30  (k3s-worker-2) ← IP privada del worker 2

IP pública del master: 167.99.123.45  ← La que usará Cloudflare
Dominio: k3s.tu-dominio.com
Email: tu-email@ejemplo.com  ← Para Let's Encrypt

Anota los tuyos en un bloc de notas. Los vas a necesitar en cada paso.

Paso 1: Preparar los tres servidores

Conéctate por SSH a cada uno de los tres servidores y ejecuta lo mismo en todos. Empecemos por el master, pero la preparación base es idéntica.

# Actualizar el sistema
sudo apt update && sudo apt upgrade -y

# Instalar dependencias mínimas
sudo apt install -y curl wget ufw

# Configurar hostname para identificar cada nodo
# En el master:
sudo hostnamectl set-hostname k3s-master

# En worker1:
sudo hostnamectl set-hostname k3s-worker-1

# En worker2:
sudo hostnamectl set-hostname k3s-worker-2

# Abrir puertos necesarios en el firewall
# Master:
sudo ufw allow 6443/tcp    # API server
sudo ufw allow 80/tcp      # HTTP para Ingress
sudo ufw allow 443/tcp     # HTTPS para Ingress
sudo ufw allow 22/tcp      # SSH
sudo ufw --force enable

# Workers (no necesitan 6443):
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 22/tcp
sudo ufw --force enable

¿Por qué el master necesita el puerto 6443? Ahí escucha el API server de Kubernetes. Los workers se comunican con él, y tú también cuando usas kubectl. Los puertos 80 y 443 son para el tráfico web que llegará al Ingress Controller.

Paso 2: Instalar k3s en el nodo master

k3s se instala con un solo comando. No es magia, es un script oficial que empaqueta Kubernetes, containerd, Traefik (Ingress Controller) y CoreDNS en un solo binario de menos de 100 MB.

# En el master
curl -sfL https://get.k3s.io | sh -s - \
  --write-kubeconfig-mode 644 \
  --disable servicelb \
  --node-name k3s-master

Qué hace cada flag:

--write-kubeconfig-mode 644: hace que el kubeconfig sea legible sin sudo (comodidad para desarrollo; en producción usa 600).
--disable servicelb: desactiva el balanceador de carga interno de k3s. Usaremos Traefik como Ingress, no necesitamos ServiceLB.
--node-name: nombre explícito del nodo.

En 30 segundos tienes un nodo master funcional. Verifiquemos:

# Ver los nodos del clúster
sudo kubectl get nodes

# Deberías ver:
# NAME          STATUS   ROLES                  AGE   VERSION
# k3s-master    Ready    control-plane,master   30s   v1.32.x+k3s1

Ese Ready significa que el plano de control está arriba, CoreDNS funciona, y Traefik está corriendo. Todo en un nodo que consume ~400 MB de RAM.

Paso 3: Obtener el token y la IP del master

Para que los workers se unan al clúster necesitan dos cosas: el token de join y la IP del master.

# En el master, guarda el token
sudo cat /var/lib/rancher/k3s/server/node-token
# Ejemplo de salida: K10d8f7e6a5b4c3d2e1f0a9b8c7d6e5f4a3b2c1d0e9f8g7h6i5j4k3l2m1n0::server:abc123def456

# Guarda la IP del master (la que usarán los workers para conectarse)
# Si tienes red privada, usa esa IP. Si no, la pública.
hostname -I | awk '{print $1}'

Importante: si tus servidores están en redes distintas y usas IP pública para la comunicación entre nodos, asegúrate de que el puerto 6443 esté abierto en el firewall del master hacia internet. En entornos de producción, una VPN o red privada entre nodos es lo recomendado.

Paso 4: Unir los workers al clúster

En cada worker ejecuta el siguiente comando, reemplazando MASTER_IP por la IP de tu master y TOKEN por el token que obtuviste:

# En worker-1 y worker-2
curl -sfL https://get.k3s.io | K3S_URL=https://MASTER_IP:6443 \
  K3S_TOKEN="TOKEN" \
  sh -s - \
  --node-name k3s-worker-1   # o k3s-worker-2

Ejemplo concreto:

curl -sfL https://get.k3s.io | K3S_URL=https://10.0.1.10:6443 \
  K3S_TOKEN="K10d8f7e6a5b4c3d2e1f0a9b8c7d6e5f4a3b2c1d0e9f8g7h6i5j4k3l2m1n0::server:abc123def456" \
  sh -s - \
  --node-name k3s-worker-1

El worker descarga k3s, se une al clúster y en unos segundos está listo. Verifica desde el master:

sudo kubectl get nodes

# Deberías ver los tres nodos:
# NAME            STATUS   ROLES                  AGE   VERSION
# k3s-master      Ready    control-plane,master   5m    v1.32.x+k3s1
# k3s-worker-1    Ready    <none>                 30s   v1.32.x+k3s1
# k3s-worker-2    Ready    <none>                 20s   v1.32.x+k3s1

Tres nodos, clúster funcional. Eso fue todo. Sin etcd separado, sin cert-manager manual, sin binarios de Kubernetes compilados a mano. Bienvenido a 2026.

Paso 5: Crear una aplicación web sencilla

Ahora que tienes el clúster, vamos a desplegarle algo. Crearemos una aplicación web en Node.js que es mínima pero útil: un dashboard que muestra información del servidor donde corre —nombre del pod, nodo, uso de memoria— para que puedas ver el balanceo de carga en acción.

Todo esto lo hacemos desde el master o desde tu máquina local con kubectl.

# Crear directorio para la app
mkdir -p ~/k3s-demo && cd ~/k3s-demo

# Crear package.json
cat > package.json << 'EOF'
{
  "name": "k3s-demo",
  "version": "1.0.0",
  "scripts": { "start": "node server.js" },
  "dependencies": { "express": "^4.21.0" }
}
EOF

# Crear server.js
cat > server.js << 'EOF'
const express = require('express');
const os = require('os');

const app = express();
const PORT = process.env.PORT || 3000;

app.get('/', (req, res) => {
  const mem = process.memoryUsage();
  res.json({
    app: 'k3s-demo',
    version: '1.0.0',
    pod: os.hostname(),
    node: process.env.NODE_NAME || 'unknown',
    memory: {
      heapUsed: `${Math.round(mem.heapUsed / 1024 / 1024)} MB`
    },
    uptime: `${Math.floor(process.uptime())}s`,
    time: new Date().toISOString()
  });
});

app.get('/health', (req, res) => {
  res.json({ status: 'ok' });
});

app.listen(PORT, () => {
  console.log(`k3s-demo corriendo en puerto ${PORT}`);
});
EOF

Esta app expone un endpoint / que devuelve información del entorno y uno /health que usaremos como health check de Kubernetes. Simple pero suficiente para ver el clúster en acción.

Paso 6: Crear el Dockerfile y construir la imagen

Necesitamos empaquetar la app en un contenedor. Como k3s usa containerd, podemos construir la imagen en el master y cargarla localmente, o usar un registro. Para este tutorial usaremos el registro de imágenes local de k3s.

cat > Dockerfile << 'EOF'
FROM node:22-alpine
WORKDIR /app
COPY package.json ./
RUN npm install --production
COPY server.js ./
EXPOSE 3000
USER node
CMD ["node", "server.js"]
EOF

# Construir la imagen
docker build -t k3s-demo:1.0.0 .

# Si estás en el master, impórtala a containerd
# k3s incluye una herramienta para esto:
sudo k3s ctr images import k3s-demo.tar

# Alternativa: usar 'docker save' y 'k3s ctr images import'
docker save k3s-demo:1.0.0 -o k3s-demo.tar
sudo k3s ctr images import k3s-demo.tar

Nota sobre registros: en un entorno real usarías un registro privado (Docker Hub, GHCR, Harbor) o el registry integrado de k3s. Para este tutorial la importación local es suficiente. Si quieres usar Docker Hub:

docker tag k3s-demo:1.0.0 tu-usuario/k3s-demo:1.0.0
docker push tu-usuario/k3s-demo:1.0.0
# Luego en los manifests usar image: tu-usuario/k3s-demo:1.0.0

Paso 7: Crear los manifiestos de Kubernetes

Crea los archivos YAML que definen el despliegue. Empecemos con un Deployment que mantiene 3 réplicas de tu app:

cat > deployment.yaml << 'EOF'
apiVersion: apps/v1
kind: Deployment
metadata:
  name: k3s-demo
  labels:
    app: k3s-demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: k3s-demo
  template:
    metadata:
      labels:
        app: k3s-demo
    spec:
      containers:
      - name: k3s-demo
        image: k3s-demo:1.0.0
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 3000
        env:
        - name: NODE_NAME
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        resources:
          requests:
            memory: "64Mi"
            cpu: "50m"
          limits:
            memory: "128Mi"
            cpu: "200m"
        readinessProbe:
          httpGet:
            path: /health
            port: 3000
          initialDelaySeconds: 5
          periodSeconds: 10
        livenessProbe:
          httpGet:
            path: /health
            port: 3000
          initialDelaySeconds: 15
          periodSeconds: 20
EOF

Fíjate en dos detalles importantes:

imagePullPolicy: IfNotPresent: usa la imagen local si existe, no intenta descargarla. Perfecto para nuestra imagen importada.
NODE_NAME se inyecta vía fieldRef para que la app sepa en qué nodo físico corre. Lo verás en la respuesta del endpoint.
resources con requests y limits: en producción esto es obligatorio. Evita que un pod acapare recursos y que el scheduler tome decisiones informadas.

Luego el Service:

cat > service.yaml << 'EOF'
apiVersion: v1
kind: Service
metadata:
  name: k3s-demo
  labels:
    app: k3s-demo
spec:
  type: ClusterIP
  selector:
    app: k3s-demo
  ports:
  - port: 80
    targetPort: 3000
    protocol: TCP
EOF

Y el Ingress que expone la app al mundo con SSL:

cat > ingress.yaml << 'EOF'
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: k3s-demo
  annotations:
    traefik.ingress.kubernetes.io/router.entrypoints: websecure
    traefik.ingress.kubernetes.io/router.tls: "true"
spec:
  tls:
  - hosts:
    - k3s.tu-dominio.com
    secretName: cloudflare-origin-cert
  rules:
  - host: k3s.tu-dominio.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: k3s-demo
            port:
              number: 80
EOF

Fíjate en secretName: cloudflare-origin-cert. Así es como Kubernetes maneja SSL: creas un secreto TLS con tu certificado y llave, y lo referencias en el Ingress. Nada de Let's Encrypt, nada de renovaciones automáticas. El certificado de Cloudflare dura 15 años y es gratis. Vamos a crearlo en el siguiente paso.

Paso 8: Configurar Cloudflare — DNS y certificado SSL

Cloudflare no solo nos da DNS. También ofrece certificados SSL gratuitos de 15 años para el tráfico entre Cloudflare y tu servidor. Esto elimina la necesidad de Let's Encrypt y sus renovaciones cada 90 días.

8.1 Crear el registro DNS

Abre tu panel de Cloudflare, selecciona tu dominio, y ve a DNS → Records. Pulsa Add record:

Tipo: A
Name: k3s (esto crea k3s.tu-dominio.com)
IPv4 address: la IP pública de tu master (ej. 167.99.123.45)
Proxy status: Proxied (icono naranja, activado)
TTL: Auto
Haz clic en Save

Así se ve en el panel:

┌─────────────────────────────────────────────────────────┐
│ Type  │ Name  │ Content          │ Proxy  │ TTL  │
│ A     │ k3s   │ 167.99.123.45   │ 🟠     │ Auto │
└─────────────────────────────────────────────────────────┘

El proxy naranja de Cloudflare es clave: oculta la IP real de tu servidor, te da protección DDoS básica y acelera la entrega con CDN.

8.2 Configurar SSL/TLS en Cloudflare

Ve a SSL/TLS → Overview y selecciona el modo Full (strict). Esto obliga a que el tráfico entre Cloudflare y tu servidor vaya cifrado con un certificado válido en el origen.

8.3 Generar el certificado SSL de origen (15 años gratis)

Ve a SSL/TLS → Origin Server y haz clic en Create Certificate:

Deja marcado "Let Cloudflare generate a private key and a CSR"
En Hostnames agrega: *.tu-dominio.com y tu-dominio.com
Certificate Validity: 15 años
Haz clic en Create

Cloudflare te mostrará dos bloques de texto:

Origin Certificate (PEM) — el certificado
Private Key (PEM) — la llave privada

Guarda ambos AHORA. La llave privada solo se muestra una vez. Si cierras la ventana, tendrás que generar otro certificado.

Copia cada bloque a un archivo en el master:

# En el master, crea los archivos del certificado
# Pega el contenido del Origin Certificate entre los delimitadores:
cat > /tmp/cloudflare-cert.pem << 'CERTEOF'
-----BEGIN CERTIFICATE-----
... pega aquí el certificado completo ...
-----END CERTIFICATE-----
CERTEOF

# Pega el contenido de la Private Key:
cat > /tmp/cloudflare-key.pem << 'KEYEOF'
-----BEGIN PRIVATE KEY-----
... pega aquí la llave privada completa ...
-----END PRIVATE KEY-----
KEYEOF

8.4 Crear el secreto TLS en Kubernetes

Con los archivos en el master, crea el secreto que el Ingress usará:

sudo kubectl create secret tls cloudflare-origin-cert \
  --cert=/tmp/cloudflare-cert.pem \
  --key=/tmp/cloudflare-key.pem

# Verificar que se creó correctamente
sudo kubectl describe secret cloudflare-origin-cert

El nombre cloudflare-origin-cert debe coincidir con el secretName en el ingress.yaml que creaste en el paso 7.

8.5 Verificar propagación DNS

El DNS puede tardar de 30 segundos a 5 minutos en propagarse:

# Desde tu terminal local:
nslookup k3s.tu-dominio.com

# Deberías ver la IP de Cloudflare (no la de tu servidor):
# k3s.tu-dominio.com
# Address: 104.21.xx.xx   ← IP de Cloudflare
# Address: 172.67.xx.xx   ← IP de Cloudflare

Listo. Tienes dominio, DNS y un certificado SSL de 15 años sin depender de Let's Encrypt.

Paso 9: Desplegar todo y verificar

Con el secreto TLS creado, Cloudflare apuntando y el certificado de origen listo, aplica los manifiestos en orden:

# 1. Primero el Deployment (crea los pods)
sudo kubectl apply -f deployment.yaml

# 2. Luego el Service (expone los pods internamente)
sudo kubectl apply -f service.yaml

# 3. Finalmente el Ingress (expone la app con SSL usando el certificado de Cloudflare)
sudo kubectl apply -f ingress.yaml

# Ver los pods en ejecución (espera unos segundos)
sudo kubectl get pods -o wide

# Ver el ingress
sudo kubectl get ingress

# Ver los servicios
sudo kubectl get svc

Cuando todos los pods estén Running, tu app está viva y servida con SSL. Como el certificado ya está cargado en el secreto TLS, no hay que esperar a ninguna verificación externa — funciona inmediatamente.

Prueba tu aplicación:

curl https://k3s.tu-dominio.com

Deberías ver algo como:

{
  "app": "k3s-demo",
  "version": "1.0.0",
  "pod": "k3s-demo-7f8c9b6d5-abc12",
  "node": "k3s-worker-1",
  "memory": { "heapUsed": "18 MB" },
  "uptime": "45s",
  "time": "2026-05-14T01:30:00.000Z"
}

Recarga varias veces. Verás que el pod y el node cambian — el Ingress está balanceando la carga entre los tres pods, que a su vez están distribuidos entre los workers. Kubernetes orquestando sin que hayas escrito una línea de lógica de balanceo.

Paso 10: Escalar a demanda

Una de las ventajas de tener un clúster es escalar con un comando:

# De 3 réplicas a 6
kubectl scale deployment k3s-demo --replicas=6

# Ver cómo se crean los nuevos pods
kubectl get pods -w    # -w = watch, actualiza en vivo

En segundos tienes 6 pods repartidos entre los workers. Si uno de los workers se cae, Kubernetes reubica sus pods en los nodos sanos automáticamente.

# Simular fallo de un worker (borrar pods no sirve, se recrean solos)
# Pero puedes ver que pasa si drenas un nodo:
kubectl drain k3s-worker-1 --ignore-daemonsets --delete-emptydir-data
kubectl get pods -o wide   # Todos migraron al master y worker-2

Esto es capacidad de autosanación real. Sin scripts, sin monitoreo manual, sin despertarte a las 3 AM.

Lo que este clúster NO tiene (todavía)

Este tutorial te dio un clúster funcional en ~30 minutos. Pero un clúster productivo necesita más:

Almacenamiento persistente: PVCs con Longhorn o Rook-Ceph para bases de datos y archivos
Monitoreo: Prometheus + Grafana para métricas, alertas y dashboards
Logging centralizado: Loki o ELK para logs de todos los pods en un solo lugar
CI/CD: ArgoCD o Flux para despliegues GitOps automatizados
Políticas de seguridad: NetworkPolicies, PodSecurityPolicies, OPA/Gatekeeper
Backups: Velero para backups automáticos del clúster y volúmenes
Alta disponibilidad real: Múltiples masters con etcd externo

Este clúster es un Fórmula 1 sin frenos, telemetría ni casco. Corre, pero no está listo para la pista.

¿Te gustó lo que construiste y quieres llevarlo al siguiente nivel? En Guayoyo Tech diseñamos, desplegamos y operamos arquitecturas cloud native sobre Kubernetes para empresas que necesitan más que un tutorial:

Clústeres multi-cloud y on-premise con alta disponibilidad real, no "a punta de fe"
GitOps con ArgoCD para que cada cambio esté versionado, revisado y desplegado automáticamente
Monitoreo y observabilidad que te avisa antes de que el cliente se entere
Estrategias de migración de VPS tradicionales a contenedores orquestados sin downtime
Entrenamiento para tu equipo en Kubernetes, Docker, CI/CD y cloud native desde cero

Lo que acabas de montar en 30 minutos es la puerta de entrada. Nosotros construimos la casa completa.

Hablemos →

推荐订阅源

DEV Community