Kubernetes en Servidores Dedicados 2025: Guía Avanzada | Hosting

El despliegue de Kubernetes sobre servidores dedicados se ha convertido en la opción predilecta para empresas que buscan un control granular sobre su infraestructura, evitando los costes ocultos y las limitaciones de los entornos cloud públicos. En 2025, esta combinación representa el estándar de facto para cargas de trabajo críticas que requieren alta disponibilidad, rendimiento predecible y soberanía de datos. Este artículo explora en profundidad las estrategias, herramientas y consideraciones técnicas para orquestar contenedores en hardware físico, maximizando el rendimiento y minimizando la complejidad operativa.

Ventajas de Kubernetes en Servidores Dedicados

Migrar de un cloud público a un clúster de Kubernetes sobre servidores dedicados no es una moda, sino una decisión estratégica. Las ventajas son tangibles cuando se analiza el rendimiento y el coste a largo plazo.

Rendimiento sin Contención

En un entorno cloud, los recursos de CPU y RAM se comparten con otros inquilinos (el “noisy neighbor” effect). Con servidores dedicados, el clúster controla toda la potencia del hardware. Esto es crítico para aplicaciones de machine learning, bases de datos en memoria o procesamiento de streaming en tiempo real.

Costes Predecibles y Soberanía

El modelo de pago por uso en la nube puede generar facturas impredecibles, especialmente con cargas de trabajo stateful. Con servidores dedicados, el coste es fijo. Además, para empresas sujetas a regulaciones como GDPR o la Ley de Protección de Datos, tener el control físico del hardware es un requisito de cumplimiento normativo.

[INFO] En 2025, el 40% de las empresas con más de 500 empleados ya han migrado al menos un clúster de Kubernetes desde nubes públicas a servidores dedicados, según estudios de sector.

Planificación de la Infraestructura Física

Antes de instalar una sola línea de YAML, es crucial diseñar la topología del clúster. Kubernetes no es mágico; necesita una base sólida.

Elección del Hardware

Para un clúster de producción, se recomienda un mínimo de tres nodos worker y dos nodos master (para garantizar el quorum de etcd). Las especificaciones mínimas para 2025 son:

Nodos Master (Control Plane): 4 vCPU, 16 GB RAM, SSD NVMe de 256 GB.
Nodos Worker: 16 vCPU, 64 GB RAM, SSD NVMe de 1 TB (ajustable según carga).
Red: Interfaces de 10 Gbps (o 25 Gbps para clústeres con alta latencia de red).

Red y Almacenamiento

La red es el talón de Aquiles de cualquier clúster bare-metal. Se debe configurar una VLAN dedicada para el tráfico interno de Kubernetes (kubelet, etcd, CNI). Para el almacenamiento persistente, las opciones son:

Ceph o Longhorn: Para almacenamiento distribuido sobre discos locales.
NVMe-oF (NVMe over Fabrics): Para baja latencia extrema.

[WARNING] No uses discos rotativos (HDD) para etcd ni para los logs de los pods. El rendimiento de escritura será un cuello de botella catastrófico.

Instalación del Clúster Kubernetes

Existen múltiples caminos para instalar Kubernetes en servidores dedicados. En 2025, las herramientas más robustas son kubeadm, kubespray y Talos Linux (un sistema operativo inmutable diseñado para Kubernetes).

Método Recomendado: kubeadm + Containerd

Este enfoque ofrece el máximo control y es el más documentado.

1. Preparación del Sistema Operativo

Se recomienda Ubuntu 24.04 LTS o Debian 12. Configura el firewall, desactiva swap y habilita los módulos del kernel necesarios.

# Deshabilitar swap
sudo swapoff -a
sudo sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab

# Habilitar módulos del kernel
cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF

sudo modprobe overlay
sudo modprobe br_netfilter

# Parámetros del sistema
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

2. Instalación de Containerd y Kubernetes

# Instalar containerd
sudo apt-get update
sudo apt-get install -y containerd

# Configurar containerd para usar systemd cgroup driver
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml
sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/g' /etc/containerd/config.toml
sudo systemctl restart containerd

# Instalar kubeadm, kubelet y kubectl
sudo apt-get install -y apt-transport-https ca-certificates curl gpg
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.30/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.30/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

3. Inicialización del Plano de Control

En el primer nodo master:

sudo kubeadm init --pod-network-cidr=10.244.0.0/16 --control-plane-endpoint=192.168.1.10

[TIP] Usa una IP flotante (VIP) para el control-plane-endpoint. Herramientas como keepalived pueden gestionar esta IP entre los nodos master para alta disponibilidad.

Alta Disponibilidad en Bare Metal

La alta disponibilidad en servidores dedicados no es trivial, ya que no contamos con los balanceadores de carga gestionados de un cloud. Hay que implementarlo manualmente.

Balanceo de Carga del Plano de Control

Existen dos enfoques principales:

VIP con keepalived: Configura una IP virtual que flota entre los nodos master. El kube-apiserver escucha en esa IP.
Balanceador externo: Usa HAProxy o nginx en un par de servidores dedicados adicionales (o en el mismo nodo master con restricciones).

Ejemplo de configuración para keepalived:

# En /etc/keepalived/keepalived.conf
vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1234
    }
    virtual_ipaddress {
        192.168.1.10/24
    }
}

Estrategias de Drenaje y Reequilibrio

En un clúster bare-metal, cuando un nodo falla, los pods no se reubican mágicamente. Se debe usar PodDisruptionBudgets y desalojos controlados. Para mantenimiento planificado:

kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data

Después del mantenimiento:

kubectl uncordon <node-name>

Redes y CNI para Servidores Dedicados

La elección del plugin de red (CNI) es crucial. En servidores dedicados, donde la red física es más rápida que en la nube, las opciones cambian.

Calico con BGP

Calico en modo BGP (Border Gateway Protocol) es la opción más potente. Permite que cada nodo anuncie las IPs de los pods directamente a los routers físicos, eliminando la necesidad de túneles VXLAN.

kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.28/manifests/calico.yaml

Luego, configura el peer BGP con el router de borde:

kubectl edit felixconfiguration default
# Añadir:
spec:
  bgp:
    peerIP: 10.0.0.1
    asNumber: 64512

Cilium con eBPF

Cilium aprovecha eBPF para ofrecer políticas de red a nivel de kernel y reemplazar kube-proxy. Es ideal para cargas de trabajo que requieren alta velocidad de paquetes.

[INFO] Cilium con eBPF puede reducir la latencia de red entre pods hasta un 40% comparado con iptables, y es compatible con kernels 5.10+.

Almacenamiento Persistente y StatefulSets

Las aplicaciones stateful (bases de datos, colas) necesitan almacenamiento persistente. En servidores dedicados, la solución más popular es Rook con Ceph.

Despliegue de Rook/Ceph

git clone --single-branch --branch v1.15 https://github.com/rook/rook.git
cd rook/deploy/examples
kubectl create -f crds.yaml -f common.yaml -f operator.yaml
kubectl create -f cluster.yaml

Esto crea un clúster Ceph que utiliza los discos locales de los nodos worker. Luego, se pueden crear StorageClasses para aprovisionar volúmenes.

Ejemplo de PVC para una base de datos PostgreSQL:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-data
spec:
  storageClassName: rook-ceph-block
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi

Monitoreo y Observabilidad

Un clúster en servidores dedicados no tiene el “panel de control” de un cloud. Hay que construir la observabilidad desde cero.

Stack Prometheus + Grafana + Loki

Prometheus: Recoge métricas de kube-state-metrics, node-exporter y cAdvisor.
Grafana: Dashboards para ver el estado del clúster.
Loki: Agregación de logs de todos los pods.

Para notificaciones, Alertmanager puede enviar alertas a Slack, PagerDuty o correo electrónico.

Herramientas Específicas para Bare Metal

Kured: Reinicia automáticamente los nodos cuando hay actualizaciones del kernel pendientes.
Node Problem Detector: Detecta problemas de hardware (discos defectuosos, memoria ECC, etc.) y los reporta como eventos de Kubernetes.

Seguridad en el Borde Físico

La seguridad en servidores dedicados abarca tanto el plano físico como el lógico.

Aislamiento de Red

Usa NetworkPolicies para segmentar el tráfico entre namespaces. Ejemplo para aislar el namespace de producción:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Gestión de Secretos

No almacenes secretos en ConfigMaps. Usa HashiCorp Vault o Sealed Secrets para cifrar los secretos en el repositorio Git.

[WARNING] Nunca expongas el puerto 10250 (kubelet) a Internet. Asegúrate de que solo los nodos del plano de control puedan acceder a él.

Automatización del Despliegue con GitOps

En 2025, el despliegue de Kubernetes en servidores dedicados no se hace a mano. GitOps es el estándar.

Flujo de Trabajo con ArgoCD

El equipo sube manifiestos YAML a un repositorio Git.
ArgoCD sincroniza automáticamente el clúster con el estado deseado.
Si alguien hace un cambio manual en el clúster, ArgoCD lo revierte (auto-healing).

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Luego, configura una aplicación:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/mi-empresa/k8s-manifests.git
    targetRevision: HEAD
    path: production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Resumen y Mejores Prácticas para 2025

Desplegar Kubernetes en servidores dedicados es una decisión que paga dividendos en rendimiento y control, pero exige una inversión inicial en planificación y automatización. Los puntos clave a recordar:

Usa un sistema operativo inmutable como Talos Linux o Flatcar Container Linux para reducir la superficie de ataque.
Implementa alta disponibilidad desde el día uno: tres nodos master, VIP con keepalived y etcd con respaldo automático.
Elige el CNI adecuado: Calico con BGP para redes grandes, Cilium con eBPF para máxima velocidad.
Automatiza todo con GitOps: ArgoCD o Flux son tus mejores aliados.
Monitoriza el hardware: No confíes solo en las métricas de Kubernetes; usa herramientas como Prometheus node_exporter para ver la temperatura de la CPU y el estado de los discos.

En 2025, la orquestación de contenedores sobre hardware físico ya no es una rareza, sino una estrategia madura para empresas que priorizan el rendimiento y el control de costes. Si sigues estas pautas, tu clúster será tan robusto como cualquier solución cloud, pero con la libertad del hardware propio.