Saltar a contenido

Instalación y Configuración Básica

Creación de clústeres con kubeadm

Es vital entender esto para el examen: kubeadm no aprovisiona infraestructura. No crea máquinas virtuales ni configura redes a nivel de SO. Asume que tú ya tienes los nodos (Linux) listos y conectados en red.

El Proceso Paso a Paso

Para que un clúster nazca, la secuencia obligatoria es la siguiente:

[!NOTE] Para la administración de los nodos master y work se utilizará la herramienta multipass. Set-ExecutionPolicy Bypass -Scope Process .\Manage-K8sCluster.ps1 -Action Install .\Manage-K8sCluster.ps1 -Action Uninstall

1. Preparación del Sistema (En TODOS los nodos - Control Plane y Workers):

# Preparacion del sistema
$PrepScript = @"
sudo swapoff -a
sudo sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab

cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF

sudo modprobe overlay -q
sudo modprobe br_netfilter -q

cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables  = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward                 = 1
EOF

sudo sysctl --system -q

sudo apt-get update -qq
sudo DEBIAN_FRONTEND=noninteractive apt-get install -qq -y containerd

sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml > /dev/null
sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml

sudo systemctl restart containerd -q
sudo systemctl enable containerd -q

sudo apt-get update -qq
sudo DEBIAN_FRONTEND=noninteractive apt-get install -qq -y apt-transport-https ca-certificates curl gpg

curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.29/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.29/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list

sudo apt-get update -qq
sudo DEBIAN_FRONTEND=noninteractive apt-get install -qq -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl
"@
$PrepScript = $PrepScript -replace "`r", ""
# End Preparacion del sistema

[!IMPORTANT] Para registrar parámetros del kernel de Linux

Persistencia de los módulos 

sudo modprobe overlay
sudo modprobe br_netfilter

cat /etc/modules-load.d/k8s.conf
overlay
br_netfilter

Persistencia de parámetros * Editar en sudo nano /etc/sysctl.d/k8s.conf * Recargar sudo sysctl --system * Verificar sudo sysctl -a | grep net.ipv4.forward

2. Inicializar el Control Plane (SOLO en el nodo Master):

# Iniciar control Plane
multipass exec $MasterName -- sudo kubeadm init --pod-network-cidr=10.244.0.0/16
# End Iniciar control Plane

3. Configurar el acceso para kubectl (En el nodo Master):

# Configurar acceso
Write-Host "🔑 Configurando acceso kubectl..."
multipass exec $MasterName -- bash -c "mkdir -p ~/.kube && sudo cp /etc/kubernetes/admin.conf ~/.kube/config && sudo chown `$(id -u):`$(id -g) ~/.kube/config"
# End Configurar acceso

4. Instalar el Plugin de Red / CNI (Desde el nodo Master):

Sin esto, el nodo master estará eternamente en estado NotReady y los pods de CoreDNS estarán atrapados en estado Pending.

# Instalar CNI (Cilium)
Write-Host "🕸️ Instalando Cilium CNI..."
# Instalar CNI
multipass exec $MasterName -- bash -c "CILIUM_CLI_VERSION=`$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt) && GOOS=linux && GOARCH=amd64 && curl -L --fail --remote-name-all https://github.com/cilium/cilium-cli/releases/download/`$CILIUM_CLI_VERSION/cilium-linux-amd64.tar.gz && sudo tar xzvfC cilium-linux-amd64.tar.gz /usr/local/bin && rm cilium-linux-amd64.tar.gz"
multipass exec $MasterName -- cilium install --version 1.19.1
# End Instalar CNI

5. Unir los Nodos Worker (SOLO en los Workers):

# Vincular worker node
Write-Host "🔗 Obteniendo token y uniendo el Worker al clúster..."
$JoinCmd = multipass exec $MasterName -- kubeadm token create --print-join-command
$JoinCmd = $JoinCmd.Trim()
multipass exec $WorkerName -- bash -c "sudo $JoinCmd"
# End Vincular worker node

Tips de Supervivencia para el Examen (CKA)

  • El Token Perdido: El token de unión expira a las 24 horas. Si en el examen te piden unir un nodo nuevo y el token original ya no está en la pantalla o caducó, genera uno nuevo e imprime el comando completo en un segundo con: kubeadm token create --print-join-command

  • El archivo intocable: La configuración principal que usa kubeadm en el master está en /etc/kubernetes/manifests/. Si cometes un error aquí, los componentes del Control Plane se caerán inmediatamente.

  • Troubleshooting rápido: Si el comando kubeadm init o join falla, los logs del error casi siempre están en el servicio del sistema operativo: journalctl -xeu kubelet.

Gestión de Alta Disponibilidad

En un clúster básico, tienes 1 nodo Control Plane (Master). Si ese nodo cae, las aplicaciones (Pods) que ya estaban corriendo en los Workers seguirán funcionando, pero pierdes el control total del clúster: no puedes crear nuevos pods, no puedes hacer despliegues, el tráfico no se enrutará a nuevos servicios y si un Worker falla, nadie reprogramará sus pods en otro lugar.

La Alta Disponibilidad significa replicar los componentes del Control Plane (especialmente el kube-apiserver y la base de datos etcd) en múltiples servidores.

La Regla de Oro: El Quórum (Números Impares)

Para que un clúster HA funcione, la base de datos etcd (que guarda el estado de todo) necesita mantener un quórum (una mayoría absoluta de votos) para tomar decisiones y evitar el síndrome del "cerebro dividido" (split-brain).

  • ¿Cuántos nodos necesitas? Siempre un número impar: 3, 5 o 7.

  • La matemática de la supervivencia:

  • Si tienes 3 nodos y 1 falla, te quedan 2 vivos. 2 es mayoría de 3 --> El clúster sobrevive.

  • Si tienes 2 nodos y 1 falla, te queda 1 vivo. 1 no es mayoría de 2 --> El clúster entra en pánico, se bloquea y muere por protección. ¡Por eso nunca se diseñan clústeres de 2 masters!

Las Dos Topologías Oficiales

Existen dos formas de diseñar la arquitectura:

1. Topología Apilada (Stacked etcd) - La más común e ideal para iniciar

  • Cómo es: Cada nodo Master corre todos los componentes de control (API, Scheduler, Controller) y además tiene su propia instancia de etcd ejecutándose dentro.
  • Ventaja: Requiere menos infraestructura (mínimo 3 máquinas Master). Es más barata y más fácil de configurar nativamente con kubeadm.
  • Desventaja: Mayor riesgo de acoplamiento. Si un servidor físico cae, pierdes tanto un servidor de la API como un miembro del quórum de la base de datos al mismo tiempo.

2. Topología Externa (External etcd) - La más robusta e independiente

  • Cómo es: Separas el cerebro de la gestión. Tienes nodos Master (que solo corren la API, Scheduler y Controller) y tienes máquinas completamente separadas dedicadas exclusivamente a correr el clúster de etcd.
  • Ventaja: Máxima resiliencia. Si pierdes un nodo Master por un pico de CPU, no afecta en lo absoluto el quórum de tu base de datos ni los datos guardados.
  • Desventaja: Requiere el doble de servidores (Ej: mínimo 3 Masters + 3 nodos etcd = 6 servidores solo para controlar el clúster).

El Componente Mágico: El Load Balancer

Si tienes 3 nodos Master trabajando en paralelo, ¿a qué IP se conectan los Workers o tu comando kubectl de tu consola? ¡No pueden depender de la IP de un solo Master, porque si ese cae, se pierde la conexión aunque los otros dos estén vivos!

  • Necesitas colocar un Balanceador de Carga (Load Balancer) externo (como HAProxy, NGINX, o un LoadBalancer de AWS/GCP) delante de tus nodos Master.
  • Este Load Balancer tendrá una IP Virtual (VIP) estática o un DNS. Distribuirá todo el tráfico de gestión hacia el puerto 6443 de los kube-apiserver que se encuentren sanos.

El Enfoque kubeadm

Cuando vas a crear un clúster de Alta Disponibilidad con kubeadm, el comando inicial cambia drásticamente respecto al de un solo nodo. Debes decirle que habrá un balanceador y que debe compartir la criptografía:

kubeadm init --control-plane-endpoint "IP_O_DNS_DEL_LOAD_BALANCER:6443" --upload-certs
  • --control-plane-endpoint: Le dice a todos los componentes internos y a los workers que el "jefe" se encuentra en esa IP del balanceador, no en el nodo local.
  • --upload-certs: Sube los certificados de seguridad (las CA) de forma temporal y cifrada a etcd. Así, cuando ejecutes el comando kubeadm join --control-plane en los otros 2 servidores Master, estos podrán descargar las llaves maestras y clonar la seguridad.