Montar un clúster de Kubernetes en Ubuntu 24.04 debería ser directo, pero en la práctica aparecen sorpresas. Aquí presento mi ruta de resolución de problemas al configurar un clúster de dos nodos en Ubuntu 24.04, con los obstáculos encontrados y las soluciones que funcionaron.
Problema inicial Paquetes y repositorios: al intentar instalar kubectl kubelet kubeadm apareció un error indicando que no se encontraban los programas. Causa y solución: Google actualizó las URLs de su repositorio en 2024 y muchos tutoriales usan las antiguas packages.cloud.google.com. Pasos que resolvieron el problema: sudo rm -f /etc/apt/sources.list.d/kubernetes.list sudo rm -f /etc/apt/keyrings/kubernetes-apt-keyring.gpg sudo apt-get update sudo apt-get install -y apt-transport-https ca-certificates curl gpg curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.31/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.31/deb/ / | sudo tee /etc/apt/sources.list.d/kubernetes.list sudo apt-get update sudo apt-get install -y kubectl kubelet kubeadm sudo apt-mark hold kubelet kubeadm kubectl
Problema 2 Confusión con el socket CRI: al ejecutar kubeadm init apareció un mensaje para definir el crisocket. Esto ocurre cuando hay más de un runtime de contenedores instalado, por ejemplo Docker y containerd. Solución: elegir un runtime y usar el socket explícito. En mi caso opté por containerd e hice: sudo apt-get install -y containerd 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 sed -i s/disabled_plugins = \\[\'cri\'\\]/disabled_plugins = \\[]/g /etc/containerd/config.toml sudo systemctl enable --now containerd sudo kubeadm init --cri-socket unix:///var/run/containerd/containerd.sock
Problema 3 Error CRI v1 Runtime API: aunque containerd estaba instalado, apareció el error runtime.v1.RuntimeService no implementado. Causa y arreglo: la configuración generada por defecto podía tener el plugin CRI deshabilitado o una config incompatible. Pasos efectivos: sudo systemctl stop containerd sudo rm /etc/containerd/config.toml sudo containerd config default | sudo tee /etc/containerd/config.toml sudo sed -i s/SystemdCgroup = false/SystemdCgroup = true/g /etc/containerd/config.toml Comprobar que disabled_plugins no incluya cri y reiniciar sudo systemctl start containerd Probar con sudo crictl version
Problema 4 Resolución de nombres del host: Ubuntu 24.04 registra 127.0.1.1 para el hostname local, pero 127.0.1.1 no es accesible desde otras máquinas del clúster. Solución: usar la IP real de la interfaz de red en /etc/hosts y en la inicialización del API server. Obtener la IP real con ip route get 8.8.8.8 y usar esa dirección en /etc/hosts y en kubeadm init como --apiserver-advertise-address=192.168.1.244
Problema 5 Puerto 6443 ya en uso: tras varios resets seguía apareciendo el error de puerto en uso. La limpieza a fondo fue la clave: sudo kubeadm reset --force --cri-socket unix:///var/run/containerd/containerd.sock sudo rm -rf /etc/kubernetes/ sudo rm -rf /var/lib/etcd/ sudo rm -rf /var/lib/kubelet/ sudo rm -rf ~/.kube/ sudo rm -rf /etc/cni/net.d/ sudo iptables -F && sudo iptables -t nat -F && sudo iptables -t mangle -F && sudo iptables -X sudo pkill -f kube-apiserver sudo pkill -f etcd sudo pkill -f kubelet sudo systemctl restart containerd sudo systemctl restart kubelet
Problema 6 El nodo worker no alcanza el control plane: al intentar unir el worker apareció timeout al pedir la config del cluster. Aunque la IP era correcta, no había conectividad. En mi caso influyeron factores como ejecutar Tailscale solo en el control plane, reglas de firewall y complejidad de la red virtualizada de las VM.
La solución final y lección aprendida: a veces empezar de cero es la mejor opción. En vez de seguir depurando un entorno con muchos elementos cambiantes, hice lo siguiente: crear una VM limpia configurar primero Tailscale antes de instalar cualquier componente de Kubernetes elegir un solo runtime de contenedores desde el principio usar las IP de Tailscale para toda la comunicación del clúster Esto simplificó el enrutamiento, evitó problemas de firewall y eliminó la confusión de IPs y runtimes.
Puntos clave y recomendaciones: Google cambió las URLs de repositorio para Kubernetes en 2024, usar pkgs.k8s.io. En Ubuntu 24.04 containerd necesita SystemdCgroup habilitado. Siempre especificar el CRI socket cuando haya más de un runtime. No usar 127.0.1.1 para clústeres multinodo, usar la IP de red real o las IPs de una red overlay como Tailscale. Al resetear kubeadm limpiar directorios, iptables y procesos colgados. Los problemas de conectividad de red son los más difíciles de depurar; considerar redes overlay o VPN desde el inicio.
En Q2BSTUDIO ayudamos a empresas a diseñar infraestructuras robustas para despliegues en la nube y clústeres containerizados. Como especialistas en desarrollo de software a medida y aplicaciones a medida ofrecemos prácticas recomendadas para automatización, despliegue y seguridad. Si necesitas soporte para migraciones, despliegues escalables o integración con servicios cloud, conoce nuestros servicios cloud aws y azure y nuestras soluciones de ia para empresas que combinan agentes IA, inteligencia de negocio y automatización.
Resumen final No te sientas mal por tener que empezar de nuevo. Kubernetes tiene una curva de aprendizaje pronunciada y la red es la parte que más complica incluso a veteranos. Empezar con un plan claro, una red estable y un único runtime suele ser más rápido que permanecer horas corrigiendo una configuración fragmentada. ¿Te ha pasado algo parecido al montar un clúster? Comparte tu experiencia y dilema.
Palabras clave incluidas: aplicaciones a medida, software a medida, inteligencia artificial, ciberseguridad, servicios cloud aws y azure, servicios inteligencia de negocio, ia para empresas, agentes IA, power bi para mejorar posicionamiento web.
