En el capítulo 02 levantamos un cluster con un master. Funciona para aprender, pero es un punto único de fallo: si ese nodo cae, kubectl se detiene, el scheduler se detiene y no se crean nuevos pods.

Alta disponibilidad de control plane no es “tener tres máquinas”. Es tener tres etcds con quórum, un endpoint estable y un proceso de join que aguante la caída de un miembro.

Sello del curso: probado en Kubernetes 1.35 y Ubuntu 24.04. IPs ficticios (192.168.56.x).

Topología

Nombre	IP	Rol
k8s-master-01	192.168.56.10	control plane + etcd
k8s-master-02	192.168.56.11	control plane + etcd
k8s-master-03	192.168.56.12	control plane + etcd
VIP	192.168.56.100	endpoint del API server
workers	192.168.56.21–23	cargas

El endpoint 192.168.56.100:6443 debe apuntar a los tres masters. Quien hace esto puede ser:

• kube-vip (VIP con ARP/BGP, corre como static pod).
• HAProxy/nginx stream + keepalived (VIP en la capa 4).
• Un load balancer de cloud.

En este curso usamos la idea de kube-vip/HAProxy: una IP virtual que sobrevive a la caída de un master.

Por qué el número de masters debe ser impar

El etcd usa consenso Raft. La mayoría debe estar disponible:

Masters	Quórum	Tolera fallos
1	1	0
2	2	0 (peor que 1)
3	2	1
5	3	2

Con 2 masters, no toleras ningún fallo. Por eso el mínimo serio es 3. Nunca subas HA con 2.

1. Preparar el endpoint estable

Tienes dos opciones prácticas.

Opción A — kube-vip

El kube-vip corre como static pod y anuncia el VIP en la red. El manifiesto se encuentra en /etc/kubernetes/manifests/kube-vip.yaml, con vip, interface y la imagen del kube-vip. Se crea antes del kubeadm init y sobrevive al control plane.

Opción B — HAProxy + keepalived

Ejemplo de frontend TCP:

frontend k8s-api
    bind *:6443
    mode tcp
    default_backend k8s-api

backend k8s-api
    mode tcp
    balance roundrobin
    option tcp-check
    server master1 192.168.56.10:6443 check
    server master2 192.168.56.11:6443 check
    server master3 192.168.56.12:6443 check

El keepalived mantiene el VIP 192.168.56.100 en uno de los proxies. Si el proxy activo cae, el VIP migra.

Atención: el endpoint debe existir antes del kubeadm init. Cambiar el endpoint después es una cirugía. Planifícalo desde el principio.

2. Inicializar el primer master

En el master-01:

sudo kubeadm init \
  --control-plane-endpoint=192.168.56.100:6443 \
  --pod-network-cidr=10.244.0.0/16 \
  --upload-certs

--upload-certs publica los certificados necesarios para los otros masters en el cluster (cifrados con una certificate-key temporal).

Guarda la salida: trae el comando de join de workers y de control planes.

3. Join de los otros masters

En el master-02 y master-03:

sudo kubeadm join 192.168.56.100:6443 \
  --token <token> \
  --discovery-token-ca-cert-hash sha256:<hash> \
  --control-plane \
  --certificate-key <certificate-key>

Si la certificate-key expira, genera otra en el master-01:

sudo kubeadm init phase upload-certs --upload-certs

Después del join, valida:

kubectl get nodes
kubectl -n kube-system get pods -o wide | grep -E 'apiserver|etcd|scheduler|controller'

Debes ver tres apiservers, tres etcds, tres schedulers y tres controllers.

4. Join de los workers

sudo kubeadm join 192.168.56.100:6443 \
  --token <token> \
  --discovery-token-ca-cert-hash sha256:<hash>

5. Verificar el etcd

El etcd es el corazón del HA. Lista los miembros:

kubectl -n kube-system exec etcd-k8s-master-01 -- \
  etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  member list

Comprueba:

• 3 miembros, todos started.
• Un líder elegido.
• etcdctl endpoint health saludable en los tres.

Si el etcd pierde quórum (2 de 3), el control plane deja de aceptar escrituras. Recuperar quórum es un procedimiento de emergencia: restaura un snapshot o elimina el miembro muerto con member remove.

6. Prueba de fallo

Haz la prueba antes de necesitarla en producción:

# em um master, pare o kubelet (simula falha do nó)
sudo systemctl stop kubelet

# em outro terminal
kubectl get nodes
kubectl get pods -A | head

El kubectl debe seguir funcionando vía VIP, y el etcd debe mantener quórum con 2/3. Después:

sudo systemctl start kubelet

Si apagas el master entero, el comportamiento es el mismo — siempre que el VIP migre y el etcd mantenga 2/3.

7. Errores comunes

Síntoma	Causa probable
connection refused en el VIP	kube-vip/HAProxy no arrancó o el health check falló
join de master falla	certificate-key caducada
etcdserver: no leader	quórum perdido (2 masters fuera)
apiserver reinicia en bucle	certificado o endpoint incorrecto
workers no entran	token caducado o hash incorrecto
HA “funciona” pero cae con 1 master	subiste con 2 masters

Checklist

• [ ] VIP/endpoint estable definido antes del init.
• [ ] 3 masters con etcd stacked.
• [ ] --control-plane-endpoint igual en todos.
• [ ] kubectl get nodes muestra 3 control planes.
• [ ] etcdctl member list con 3 miembros y líder.
• [ ] Prueba de fallo de 1 master documentada.
• [ ] Snapshot del etcd configurado.

Glosario

• quórum: mayoría necesaria para que el etcd decida.
• VIP: IP virtual que migra entre nodos.
• stacked etcd: etcd corriendo en el mismo nodo del control plane.
• certificate-key: clave para distribuir certificados a los masters.
• fencing: garantizar que el nodo antiguo no siga escribiendo.

Siguiente

Con el control plane en HA, hablaremos de la red de los pods: flannel, Cilium y por qué NetworkPolicy puede ser un no-op si eliges la CNI equivocada.

Siguiente: Curso Kubernetes 06 — CNI: flannel, Cilium y NetworkPolicy