← Volver al listado de tecnologías ← Índice de K3s

Capitulo 17: Alta Disponibilidad

Por: Artiko
k3skubernetesalta-disponibilidadetcdha

Capitulo 17: Alta Disponibilidad

< Volver al Indice del Tutorial

El Problema: Single Point of Failure

Un cluster K3s con un solo server funciona bien para desarrollo y pruebas, pero en produccion es un riesgo. Si ese unico server cae, pierdes acceso al API server, no puedes programar nuevos pods y los nodos agent quedan huerfanos.

Los pods existentes en los agents siguen corriendo, pero sin control plane no hay:

Para produccion necesitas alta disponibilidad (HA): multiples servers donde si uno cae, los demas mantienen el cluster operativo.

Opciones de HA en K3s

K3s ofrece dos mecanismos para HA:

Embedded etcd (Recomendado)

K3s incluye etcd embebido como base de datos distribuida. Los servers forman un cluster etcd entre si y replican los datos automaticamente.

Ventajas:

Requisitos:

External Datastore

Usar una base de datos externa (MySQL, PostgreSQL, etcd externo) como almacen compartido.

Ventajas:

Desventajas:

Para la mayoria de los casos, embedded etcd es la opcion recomendada.

Configurar Cluster HA con Embedded etcd

Paso 1: Inicializar el Primer Server

El primer server arranca el cluster etcd con --cluster-init:

curl -sfL https://get.k3s.io | sh -s - server \
  --cluster-init \
  --tls-san mi-balanceador.ejemplo.com

El flag --cluster-init activa etcd embebido en lugar de SQLite. El flag --tls-san agrega el dominio del balanceador al certificado TLS (lo explicamos mas adelante).

Obtener el token para unir nodos adicionales:

cat /var/lib/rancher/k3s/server/node-token

Paso 2: Unir Servers Adicionales

En el segundo y tercer server:

curl -sfL https://get.k3s.io | sh -s - server \
  --server https://IP_PRIMER_SERVER:6443 \
  --token TOKEN_DEL_PASO_1 \
  --tls-san mi-balanceador.ejemplo.com

Cada server adicional se une al cluster etcd y replica los datos. Repite este paso hasta tener al menos 3 servers.

Paso 3: Unir Agents

Los agents se unen igual que en un cluster normal, pero puedes apuntarlos a cualquier server:

curl -sfL https://get.k3s.io | K3S_URL=https://IP_CUALQUIER_SERVER:6443 \
  K3S_TOKEN=TOKEN sh -

En produccion, los agents deben apuntar a la IP del balanceador, no a un server especifico.

Balanceador de Carga Externo

Con multiples servers necesitas un balanceador frente a ellos. Sin balanceador, si el server al que apuntan los agents cae, los agents pierden comunicacion aunque los otros servers esten bien.

Por que es Necesario

                    ┌──────────────┐
                    │ Balanceador  │
                    │ (nginx/HAProxy)│
                    └──────┬───────┘
                           │
              ┌────────────┼────────────┐
              │            │            │
        ┌─────┴─────┐ ┌───┴───┐ ┌─────┴─────┐
        │ Server 1  │ │Server2│ │ Server 3  │
        └───────────┘ └───────┘ └───────────┘

El balanceador distribuye las conexiones entre los servers disponibles y detecta si uno cae para dejar de enviarle trafico.

Configurar con Nginx

stream {
    upstream k3s_servers {
        server 10.0.0.1:6443;
        server 10.0.0.2:6443;
        server 10.0.0.3:6443;
    }

    server {
        listen 6443;
        proxy_pass k3s_servers;
    }
}

Configurar con HAProxy

frontend k3s_frontend
    bind *:6443
    mode tcp
    default_backend k3s_servers

backend k3s_servers
    mode tcp
    balance roundrobin
    server server1 10.0.0.1:6443 check
    server server2 10.0.0.2:6443 check
    server server3 10.0.0.3:6443 check

Fixed Registration Address y TLS-SAN

El flag --tls-san agrega IPs o dominios adicionales al certificado TLS del API server. Sin esto, las conexiones a traves del balanceador fallan por error de certificado.

# Agregar IP del balanceador
--tls-san 10.0.0.100

# Agregar dominio
--tls-san mi-cluster.ejemplo.com

# Multiples valores
--tls-san 10.0.0.100 --tls-san mi-cluster.ejemplo.com

Debes usar --tls-san en todos los servers del cluster con los mismos valores.

Verificar Alta Disponibilidad

Verificar Nodos

kubectl get nodes

Deberias ver todos los servers y agents con estado Ready:

NAME       STATUS   ROLES                       AGE
server-1   Ready    control-plane,etcd,master   10m
server-2   Ready    control-plane,etcd,master   8m
server-3   Ready    control-plane,etcd,master   6m
agent-1    Ready    <none>                      4m

Verificar etcd

kubectl get endpoints -n kube-system

Simular Caida

Para probar HA, apaga uno de los servers:

# En server-2
sudo systemctl stop k3s

Desde otro server, verifica que el cluster sigue operativo:

kubectl get nodes
# server-2 deberia aparecer como NotReady

kubectl run test --image=nginx
# Deberia funcionar correctamente

Cuando levantes el server nuevamente, se reincorpora automaticamente:

sudo systemctl start k3s

Consideraciones de Produccion

Siguiente: Capitulo 18: Seguridad —>

← Volver al listado de tecnologías ← Índice de K3s