Llevo tres años gestionando clusters Kubernetes. He aprendido kubectl, helm, kustomize, escribo YAMLs dormido, y aun así… hay días que abro Rancher y respiro tranquilo. Porque sí, kubectl es potente y la terminal mola. Pero cuando son las 3 de la mañana y algo se ha caído, ver gráficos de CPU en vez de piped JSON es la diferencia entre arreglarlo en 5 minutos o perder una hora.
Rancher no te convierte en peor administrador de Kubernetes. Te convierte en uno más eficiente. Y eso es lo que vamos a montar hoy.
Qué es Rancher y por qué lo uso#
Rancher es una plataforma de gestión para Kubernetes que te da una interfaz web para hacer todo lo que harías desde terminal, pero viendo lo que pasa. Desplegar apps, escalar pods, ver logs en tiempo real, gestionar volúmenes, RBAC, helm charts… todo desde un navegador.
La magia de Rancher no es que te evite la terminal (aunque a veces sí). Es que te da contexto visual. Puedes ver de un vistazo qué namespace está consumiendo recursos, qué pods están en crash loop, qué nodos tienen problemas de disco. En terminal eso requiere lanzar 8 comandos diferentes y correlacionar outputs.
Mi setup actual tiene 14 nodos K3s (3 control plane en casa con ZimaBoards + 11 workers repartidos entre casa y oficina). Gestionar eso solo con kubectl es posible, pero ineficiente. Con Rancher veo el estado completo en una pantalla.
Preparativos antes de instalar#
Rancher se puede instalar de varias formas, pero la más sensata para un homelab es via Helm en tu propio cluster. Asumimos que ya tienes Kubernetes funcionando. Si no, monta K3s primero (es más ligero que K8s vanilla y funciona igual).
Requisitos:
- Cluster Kubernetes corriendo (K3s, K8s, RKE2, lo que sea)
- kubectl configurado para acceder al cluster
- Helm 3 instalado
- 4 GB RAM libres mínimo en algún nodo
- Cert-manager (Rancher lo necesita para certificados)
Verifica que tu cluster responde:
| |
Deberías ver tus nodos Ready. Si alguno está NotReady, arréglalo antes de continuar.
Instalar cert-manager primero#
Rancher usa cert-manager para gestionar certificados TLS automáticamente. Sin cert-manager, no arranca.
| |
Espera a que los pods arranquen:
| |
Cuando veas cert-manager, cert-manager-cainjector y cert-manager-webhook en Running, puedes continuar.
Instalar Rancher con Helm#
Ahora sí, Rancher. Vamos a instalarlo en el namespace cattle-system (nombre por defecto que usa Rancher).
| |
Ajusta el hostname a tu dominio. En mi caso uso un wildcard DNS *.k3s.midnightlab.build que apunta a la IP Tailscale de mi control plane. Si no tienes DNS, puedes usar nip.io o xip.io temporalmente.
El deploy tarda un par de minutos. Monitoriza:
| |
Cuando rancher-XXX esté Running, Rancher está listo.
Exponer Rancher (Ingress o NodePort)#
Rancher crea un servicio ClusterIP por defecto. Necesitas exponerlo. Dos opciones:
Opción 1: Ingress (recomendado)
Si tienes un ingress controller (Traefik en K3s viene por defecto), Rancher ya ha creado un Ingress. Revisa:
| |
Debería mostrar el hostname que configuraste. Accede via https://rancher.k3s.midnightlab.build (o tu dominio).
Opción 2: NodePort (rápido y sucio)
Si no tienes ingress o quieres acceso directo:
| |
Anota el puerto (ej: 30443). Accede via https://IP-NODO:30443
En mi caso uso Ingress porque Traefik ya gestiona todo el tráfico entrante del cluster. Más limpio.
Configuración inicial de Rancher#
Primera vez que accedes, Rancher te pide configurar la contraseña de admin. Usa la bootstrapPassword que pusiste en el helm install. Te pedirá cambiarla.
Después te pregunta la URL del servidor. Pon el mismo hostname que usaste (rancher.k3s.midnightlab.build). Esta URL es la que Rancher usará para comunicarse con otros clusters si añades más después.
Acepta los términos, dale Next, y entras al dashboard.
Explorando el dashboard#
Lo primero que ves es el cluster local (el que acabas de instalar Rancher). Haz clic en “local” y entras a la vista del cluster.
Panel izquierdo:
- Cluster: vista general, nodos, eventos
- Workload: pods, deployments, statefulsets, daemonsets, jobs
- Service Discovery: services, ingress
- Storage: persistent volumes, storage classes
- Apps: marketplace de Helm charts
- Monitoring: Prometheus y Grafana integrados
Vista de nodos:
Cluster > Nodes. Ves tus 14 nodos (o los que tengas) con CPU, RAM, disco, estado. Haces clic en un nodo y ves pods corriendo, recursos asignados, taints, labels.
En mi cluster tengo nodos llamados k3s-cp1, k3s-cp2, zima1, zima2, k3s-01, k3s-longhorn-01, etc. Cada uno con specs diferentes. Rancher me muestra en un vistazo cuál tiene carga alta. Sin Rancher tendría que hacer kubectl top nodes y correlacionar con kubectl get pods –all-namespaces -o wide.
Vista de workloads:
Workload > Pods. Lista todos los pods de todos los namespaces. Puedes filtrar por namespace, buscar por nombre, ver logs en tiempo real, abrir shell en el pod, editar el YAML, escalar el deployment… todo desde la UI.
Ejemplo real: el otro día vi un pod en CrashLoopBackOff en el namespace longhorn-system. Hice clic, vi los logs, detecté que faltaba un volume. Edité el PVC desde Rancher, y el pod arrancó. Todo sin tocar kubectl.
Vista de storage:
Storage > Persistent Volumes. Ves todos los PVs y PVCs. Puedes crear nuevos, borrar los huérfanos, ver qué pod usa cada volumen.
En mi cluster uso Longhorn como storage distribuido. Rancher me muestra los 12.5 TB de storage total, cuánto está usado, qué réplicas tiene cada volumen. Longhorn tiene su propia UI, pero Rancher centraliza la info.
Instalar apps desde el marketplace#
Rancher incluye un marketplace de Helm charts. Apps > Charts. Encuentras Prometheus, Grafana, Cert-Manager, Longhorn, Nextcloud, GitLab… cientos de apps.
Voy a instalar Monitoring (stack Prometheus + Grafana que Rancher mantiene).
Apps > Charts > Monitoring (Rancher)
Haces clic, eliges el namespace (normalmente cattle-monitoring-system), dejas las opciones por defecto, y le das Install.
Rancher despliega Prometheus Operator, Grafana, Alertmanager, node exporters en todos los nodos, y dashboards preconfigurados. En 3 minutos tienes monitorización completa.
Vas a Cluster Tools > Monitoring y ahí tienes el enlace a Grafana. Usuario admin, contraseña prom-operator. Dashboards con métricas del cluster, nodos, pods, namespaces… todo funcionando.
Antes de Rancher montaba esto a mano con Helm, configurando values.yaml, creando ingress, conectando datasources. Con Rancher es literalmente 4 clics.
Gestionar múltiples clusters#
Rancher no solo gestiona el cluster local. Puedes añadir otros clusters (en otras máquinas, en la nube, en Raspberry Pis) y controlarlos todos desde una única interfaz.
En el menú hamburguesa arriba a la izquierda, tienes “Cluster Management”. Ahí ves todos tus clusters.
Para añadir un cluster nuevo:
Cluster Management > Import Existing > Generic
Rancher te da un comando kubectl apply que ejecutas en el cluster remoto. Ese cluster se registra en Rancher y aparece en tu lista. A partir de ahí lo gestionas igual que el local.
Yo no tengo múltiples clusters todavía, pero si montara uno en OVH o en una Raspberry Pi en casa de mis padres, añadirlo a Rancher sería inmediato.
RBAC y control de acceso#
Si trabajas en equipo (o simplemente quieres separar permisos), Rancher tiene RBAC integrado.
Global Settings > Users. Puedes crear usuarios con diferentes roles:
- Administrator: control total
- Standard User: puede ver clusters, pero no modificar configuración global
- User-Base: acceso limitado a proyectos específicos
Cada cluster puede tener proyectos (agrupaciones de namespaces). Un proyecto puede ser “producción”, otro “desarrollo”. Asignas usuarios a proyectos con roles específicos.
En mi homelab soy solo yo, pero si montara algo compartido (por ejemplo un cluster para amigos), usaría esto. Cada uno accede solo a sus namespaces.
Logs en tiempo real#
Una de las cosas que más uso en Rancher: logs.
Workload > Pods > [elige un pod] > tres puntos > View Logs
Se abre una pestaña con los logs en tiempo real. Puedes buscar, filtrar por timestamp, descargar el log. Si el pod tiene múltiples contenedores, eliges cuál ver.
Compara esto con kubectl logs -f [pod] donde tienes que saber el nombre exacto del pod, copiar/pegar, y si quieres ver logs de otro contenedor necesitas -c [contenedor].
En Rancher hago clic y veo. Simple.
Shell dentro de pods#
Otra funcionalidad que uso constantemente: abrir shell en pods.
Workload > Pods > [pod] > tres puntos > Execute Shell
Se abre una terminal web conectada al pod. Puedes ejecutar comandos, inspeccionar el filesystem, hacer troubleshooting.
Hace una semana tuve un problema con una app que no conectaba a PostgreSQL. Abrí shell en el pod de la app, hice ping al servicio postgres, vi que resolvía bien, ejecuté psql para probar la conexión… diagnostiqué el problema sin salir del navegador.
Equivalente en kubectl:
| |
Funciona, pero requiere conocer el nombre exacto del pod. Con Rancher navegas visualmente.
Backups automáticos con Rancher#
Rancher tiene un sistema de backups que guarda la configuración completa del cluster. Si el cluster explota, puedes restaurarlo.
Cluster Tools > Backups > Create
Defines dónde se guardan los backups (S3, NFS, local), periodicidad, retención. Rancher usa Velero por detrás.
En mi cluster tengo backups diarios a MinIO (S3-compatible corriendo en mi Unraid). Rancher hace snapshot de todos los recursos del cluster, PVs incluidos. Si algo se rompe, restauro el último backup y vuelvo al estado anterior.
Montar esto manualmente con Velero es posible, pero Rancher lo integra con UI. Ves el historial de backups, puedes lanzar uno manual, restaurar con un clic.
Limitaciones y cosas a tener en cuenta#
Rancher es potente, pero no es perfecto.
Consume recursos. Rancher + Monitoring (Prometheus/Grafana) pueden usar fácilmente 2-3 GB de RAM. En un cluster pequeño (ej: 3 Raspberry Pis con 4 GB cada una), eso es mucho. En mi cluster con 100 GB de RAM total, no es problema.
No reemplaza kubectl. Hay cosas que siguen siendo más rápidas en terminal. Editar manifiestos complejos, aplicar kustomizations, depurar networking… kubectl sigue siendo necesario. Rancher es complementario.
Updates. Rancher se actualiza frecuentemente. A veces una actualización rompe algo. Siempre revisa las release notes antes de actualizar.
Dependencia. Si Rancher se cae, tu cluster sigue funcionando (Rancher es solo una capa de gestión), pero pierdes la UI. Por eso es importante saber kubectl por si acaso.
Alternativas a Rancher#
Rancher no es la única opción para gestionar Kubernetes desde UI.
Kubernetes Dashboard: La UI oficial de Kubernetes. Más básica que Rancher, pero suficiente para ver estado del cluster. Gratuita, open source. Menos features que Rancher.
Lens: Aplicación de escritorio para gestionar Kubernetes. Muy popular entre developers. Más ligera que Rancher (no corre en el cluster, solo en tu PC). Versión gratuita limitada, versión Pro de pago.
Portainer Business: Portainer (que ya cubrí en otro post) tiene una versión Business que incluye gestión de Kubernetes. Más cara que Rancher.
K9s: Cliente de terminal interactivo. No es una UI web, pero es visual. Si te gusta la terminal pero quieres algo más que texto plano, K9s está bien.
Yo uso Rancher porque cubre todo: multi-cluster, RBAC, marketplace, monitoring integrado, backups. Para un homelab es la solución más completa sin coste.
Cómo actualizar Rancher#
Rancher se actualiza via Helm. Simple:
| |
Revisa las release notes antes. A veces hay breaking changes que requieren ajustes.
Mi workflow diario con Rancher#
En un día normal:
Mañana: Abro Rancher, reviso el dashboard general. Veo uso de CPU/RAM, estado de nodos, alertas de Prometheus. Si algo está rojo, investigo.
Despliegue de apps: Si necesito instalar algo (ej: un servicio nuevo para probar), voy a Apps > Charts, busco, configuro, instalo. En 5 minutos está corriendo.
Troubleshooting: Si algo falla, voy a Workload > Pods, busco el que está mal, veo logs, abro shell si necesito. Arreglo el problema.
Escalado: Si un servicio necesita más réplicas, voy al deployment, edito el YAML, cambio replicas de 2 a 4, guardo. Kubernetes lo escala automáticamente.
Noches: Antes de dormir, reviso que no haya pods en crash loop o nodos con problemas. Rancher me lo muestra en un vistazo.
No uso Rancher para todo. Cosas complejas (ej: aplicar un bundle de manifiestos con kustomize, o hacer un port-forward rápido) las hago en terminal. Pero el 70% de mi interacción con el cluster es via Rancher.
Montar Rancher en Docker (alternativa ligera)#
Si no tienes un cluster Kubernetes todavía, o solo quieres probar Rancher sin compromiso, puedes correrlo en un contenedor Docker standalone.
| |
Accedes via https://localhost. Rancher arranca y te permite crear un cluster desde cero, o importar uno existente.
Esta instalación es más ligera (1 contenedor vs todo el stack en Kubernetes), pero pierde features como alta disponibilidad. Vale para testing.
Conclusión#
Rancher no te hace peor administrador de Kubernetes. Te ahorra tiempo y estrés.
Kubectl es potente. Pero cuando son las 3 de la mañana y el servicio de producción está caído, ver métricas en gráficos y tener acceso a logs con un clic te hace más rápido. Y en producción (o en tu homelab cuando necesitas que algo funcione YA), la velocidad importa.
He gestionado clusters sin UI. Es factible. Pero desde que uso Rancher, mi eficiencia ha subido. Detecto problemas antes, despliego más rápido, gasto menos tiempo buscando documentación de kubectl.
Si tienes un cluster Kubernetes, instala Rancher. Dale una semana de uso. Si después de una semana sigues prefiriendo puro kubectl, desinstálalo. Pero apuesto a que no vas a querer volver.
La terminal es cool. Pero la productividad gana partidas.