Kubernetes (K8s) es una plataforma de código abierto para automatizar la implementación, el escalado y la administración de aplicaciones en contenedores. Se construyó para trabajar con Docker y según con quien hables te dirá que es un infierno o que está chupado. ¿La verdad?, pues que si te has pegado con infraestructura (servidores, redes), le has echado muchas horas de vuelo a Linux, Docker y contenedores, igual no es tan infierno y dependerá del número de horas que le eches 😂.
Como casi todos mis apuntes, basados en documentar mi Home Lab, con horas de pruebas, cosas que dejan de funcionar cuando menos te lo esperas, pero lo bueno es que se aprende una barbaridad y, si eres un poco friki hasta te diviertes. Te dejo mi experiencia, con truquillos, meteduras de pata y todo lo que me hubiera gustado saber antes de empezar.
Introducción
¿Por qué me meto con Kubernetes a estas alturas?, pues culpa de mi amigo Iván. Me dijo que estaba perdiendo el tiempo y la categoría con Proxmox, que iba disfrutar con K8s, y la verdad, me ha picado. De paso me avisó que hay dos formas de meterle mano, la complicada, empezar por abajo, aprender las tripas de K8s e ir subiendo. O bien, la fácil, pillar una de las distros “sencillas”, instalarla y empezar a jugar; tiempo habrá de meterse a bajo nivel.
Este es el resultado, mi primer apunte, de una serie, sobre Kubernetes. Una aclaración previa, ¿qué es eso de K8s?. Bueno, pues se trata de una abreviatura numérica o numerónimo, sale de contar las letras entre la “K y la última “s”: K 8 (u, b, e, r, n, e, t, e) s. Otro ejemplo de numerónimo es i18n, por “internacionalization”.
Volviendo al tema de Home Lab. Siempre me marco un objetivo “en producción”, y el de ahora es ni más ni menos que migrar mi Proxmox 9, sus VM’s y contenedores a K8s, que se dice rápido. Empezaré por replicar lo que tengo (10 LXC’s, varias VM’s y 15 stacks en docker) a un nuevo servidor “Mono-Nodo” que llamaré tierra, con Ubuntu y K3s (distribución super sencilla de K8s). Lo que se pueda, se quedará en Docker, y lo que no, pues VM (sobre KVM, gracias al proyecto KubeVirt que permite “gestionar” VM’s/KVM desde K8s).
Nociones básicas:
K8s es una plataforma de orquestación de contenedores. Si Docker te permite empaquetar y ejecutar aplicaciones en contenedores de forma aislada, K8s va un paso más allá: puedes gestionar, escalar y coordinar múltiples contenedores distribuidos en uno o varios servidores como si fueran una sola unidad.
Imagina que tienes una aplicación web con una base de datos, un backend API y un frontend. Con Docker puedes crear contenedores para cada uno, pero ¿qué pasa si necesitas escalar el backend porque hay más tráfico? ¿O si un contenedor se cae? ¿Cómo gestionas la comunicación entre ellos?. La solución es K8s, resuelve todos esos problemas de forma automática.
En K8s los contenedores que conforman una aplicación se agrupan en unidades lógicas llamadas Pods para facilitar la administración y el descubrimiento de contenedores. Un Pod es la unidad más pequeña y puede contener uno o varios contenedores que comparten recursos de red, almacenamiento. Los Pods siempre se ejecutan en el mismo nodo (servidor).
K8s está preparado para trabajar a lo bestia, lo diseñó Google, que ejecuta miles de millones de contenedores, puede escalar sin aumentar el equipo que lo opera. El tipo de cargas pueden ser simples o super complejas, es código abierto, se puede montar en infraestructura propia (on-premise) o híbrida o en la nube. Lo mejor, se pueden mover las cargas sin esfuerzo dónde se quiera.
Cluster con un “Nodo único”
Vamos a empezar por lo mas sencillo, un único Cluster con un único Nodo, haciendo de Controlador (Master) y Currante (Worker). Físicamente será un NUC donde monto Ubuntu y le añado k3s.
Empiezo por instalar Ubuntu Server, descargo la ISO de Ubuntu 24.04.3 LTS, la quemo en una USB y la uso para instalarlo.
- Servidor:
tierra - IP Fija:
192.168.103.1 - Nombre DNS en mi home lab:
tierra.parchis.org - Paquetes: Solo instalo
openssh
Hago login vía SSH con mi usuario y lo preparo para administración remota.
- Hago que mi usuario
luispueda ejecutar comandossudosin contraseña (un poco desudoers). - Adapto el
.ssh/authorized_keys, le añado la clave pública de mi estación de trabajo (SSH sin contraseña) - En el servidor instalo CLI Setup. Opcional, pero recomendado, ojo que es mi “CLI potente con entornos y herramientas idénticas” en cualquier Linux, MacOS o Windows. Echa un ojo al repositorio.
En mi estación de trabajo preparo .ssh/config para llegar “fácil” a tierra.
# Servidor K8s tierra
Host tierra tierra.parchis.org 192.168.103.1
HostName 192.168.103.1
User luis
Port 22
IdentityFile ~/.ssh/id_ed25519
IdentitiesOnly yes
Instalación de K3s:
Siguiente paso, instalar K3s, una de las versiones más ligeras de K8s, orientada a IoT y Edge computing, se monta en un binario de menos de 70MB y levanta todo lo necesario. Echa un ojo a la documentación ofical en el enlace.
Como vamos a lo fácil, en vez de seguir el proceso de instalación descrito en su documentación, uso k3sup 🚀 (pronunciado ‘ketchup’). Una herramienta cross-compilada para Windows, Linux, MacOS que te instalas en tu puesto de trabajo y te permite montar K3s en remoto en un periquete. Lo que oyes, no te hace falta ni hacer SSH al servidor, lo hace todo en remoto.
- Me instalo la última release de
k3sup. En Windows me descargué el ejecutable desde Releases y lo copié a un directorio de mi PATH. - Como ya tenía el SSH preparado, solo tuve que ejecutar el comando siguiente y me instaló todo en
tierra, el binario de K3s y la configuración del Cluster con un único nodo “Master y Worker” de K8s.
k3sup install --ip 192.168.103.1 --user luis --ssh-key ~/.ssh/id_ed25519 --local-path C:\Users\luis\kubeconfig
Ya está, ya tienes un K8s “up & running”. Además me deja un fichero local (ejemplo en windows: C:\Users\luis\kubeconfig) que usará la herramienta Cliente (más adelante). Hasta aquí ha sido super sencillo. No necesito ir al servidor, pero no puedo resistirme y me conecto a ver cómo de sano está k3s (he reducido la salida).
[🪟] luis@kymeraw:~ ❯ ssh tierra
[🐧] luis@tierra:~ ❯ sudo k3s check-config
Verifying binaries in /var/lib/rancher/k3s/data/86a616cdaf0fb57fa13670ac5a16f1699f4b2be......
- sha256sum: good
- links: good
System:
- /usr/sbin iptables v1.8.10 (nf_tables): ok
- swap: should be disabled
- routes: ok
Limits:
- /proc/sys/kernel/keys/root_maxkeys: 1000000
modprobe: FATAL: Module configs not found in directory /lib/modules/6.8.0-86-generic
info: reading kernel config from /boot/config-6.8.0-86-generic ... <==== !!!!!!!!!!!!!!!!!!!
Generally Necessary:
- cgroup hierarchy: cgroups V2 mounted, cpu|cpuset|memory controllers status: good
- /usr/sbin/apparmor_parser
apparmor: enabled and tools installed
- CONFIG_NAMESPACES: enabled
:
- CONFIG_POSIX_MQUEUE: enabled
Optional Features:
- CONFIG_USER_NS: enabled
:
- CONFIG_RT_GROUP_SCHED: missing <==== !!!!!!!!!!!!!!!!!!!
:
- Network Drivers:
- "overlay":
- CONFIG_VXLAN: enabled (as module)
Optional (for encrypted networks):
- CONFIG_CRYPTO: enabled
:
- CONFIG_INET_XFRM_MODE_TRANSPORT: missing <==== !!!!!!!!!!!!!!!!!!!
- Storage Drivers:
- "overlay":
- CONFIG_OVERLAY_FS: enabled (as module)
STATUS: pass
Explico algunas cosas que salen…
modprobe: FATAL: Module configs not found.... No hace falta hacer nada, es cosmético.CONFIG_RT_GROUP_SCHED: missing. Falta el soporte de planificación en tiempo real para cgroups. No es necesario para la operación estándar de k3s o K8s y como no voy a tener cargas de trabajo de tiempo real, lo ignoro.CONFIG_INET_XFRM_MODE_TRANSPORT: missing. Falta el soporte para el modo de transporte ESP. Es una característica opcional para la encriptación de VXLAN. Como no lo voy a usar pues lo ignoro.
La siguiente me llamó la atención.
- swap:
should be disabled. Importante, K3s (y K8s en general) recomienda desactivar la memoria swap.
Edito el fichero /etc/fstab, comento la línea siguiente:
#/swap.img none swap sw 0 0
Rearranco el servidor NUC:
# reboot
Cliente
kubectl es “La Herramienta” de K8s. Esta hay que aprendérsela!!. Con ella vas a poder ejecutar comandos en Clusters de K8s, desplegar aplicaciones, inspeccionar y gestionar recursos y ver registros. Todo se hace en remoto, desde tu puesto, habla con los endpoints del servidor API de K8s. En mi caso lo instalo en un par de puestos con Windows y MacOS.
Por cierto, mi herramienta CLI Setup lo instala en cualquier OS, pero aquí tienes enlaces sobre cómo instalarla en macOS, Windows o Linux. Un ejemplo:
# MacOS
brew update
brew install kubectl
# Windows
scoop install kubectl
kubeconfig: Para facilitarle el trabajo a kubectl tenemos este fichero, que le dice dónde está tu cluster(s) y muchas cosas mas. Tiene información acerca de los clústeres, los usuarios, los Namespaces y los mecanismos de autenticación. Puedes escoger un clúster y comunicarte con su servidor API, guarda contextos (URLs y credenciales).
En mi caso el programita k3sup me creó uno ya preparado para acceder al cluster de tierra.
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: <---------------clave-------------->
server: https://192.168.103.1:6443
name: default
contexts:
- context:
cluster: default
user: default
name: default
current-context: default
kind: Config
preferences: {}
users:
- name: default
user:
client-certificate-data: <---------------clave-------------->
client-key-data: <---------------clave-------------->
Para usar kubectl recomiendo preparar una variable para que sepa dónde encontrar el fichero.
# En linux/macOS
export KUBECONFIG="${HOME}/kubeconfig"
# En Windows/PowerShell
$env:KUBECONFIG = (Get-Location).Path + "\kubeconfig"
# En Windows/CMD
set KUBECONFIG=%CD%\kubeconfig
A partir de ahora ya puedo usar kubectl para administrar mi cluster en remoto. Dejo a continuación un ejemplo ejecutando desde un par de puestos remotos (uso el mismo kubeconfig en ambos, windows y macos).
Componentes y conceptos
Antes de seguir y meter comandos a nuestro Cluster; es importante entender algunos conceptos fundamentales de K8s. Ya he mencionado algunos arriba, pero aquí los explico de forma más clara y cómo se relacionan entre sí:
Cluster: Cuando desplegamos K8s, obtenemos un Cluster. Es el conjunto completo de máquinas (Nodos) que trabajan juntas para ejecutar nuestras aplicaciones. En este apunte, el cluster es tierra, un único servidor con K3s.
Nodo (Node): Un Nodo es una máquina de trabajo en K8s. Puede ser un servidor físico o una máquina virtual. En nuestro Cluster mono-nodo, tierra actúa tanto como Nodo Maestro (control plane) como Nodo Trabajador (worker). En producción, normalmente tendrías varios nodos separados para alta disponibilidad.
Pod: Ya lo mencioné antes, pero es la unidad más pequeña desplegable de computación en K8s. Un Pod agrupa uno o varios contenedores que comparten recursos de red y almacenamiento, además de una especificación sobre cómo deben ejecutarse dichos contenedores. Siempre se ejecutan en el mismo Nodo. Cuando despliegas una aplicación, K8s crea Pods para ejecutar tus contenedores.
Los Pods en K8s son efímeros: están diseñados para ser desechables y reemplazables. No podemos añadir un contenedor a un Pod una vez creado. En su lugar, normalmente eliminamos y reemplazamos los Pods de manera controlada utilizando deployments (despliegues).
Control Plane (Plano de control): Es el “cerebro” del cluster. Expone la API de K8s (la que usa kubectl para comunicarse), gestiona el estado deseado del cluster, programa los Pods en los nodos y coordina todo el orquestado. En K3s, el control plane está embebido y simplificado, por eso es tan ligero.
En resumen, un cluster de K8s está formado por Nodos Worker que ejecutan aplicaciones en contenedores (dentro de Pods), y un Control Plane que gestiona y orquesta todo. En nuestro caso, con K3s y un cluster mono-nodo, tierra hace ambas cosas: es el control plane y el worker a la vez.
Plano de Control (Control Plane)
- etcd: Almacén de datos clave-valor de alta disponibilidad que guarda el estado de configuración y los datos del clúster. Es la fuente de verdad de K8s.
- API (kube-apiserver): El punto al que conectarse para el plano de control. Expone la API de K8s. Es el único componente que interactúa con
etcd. - sched (kube-scheduler): Observa los Pods recién creados sin un nodo asignado y selecciona un nodo para que se ejecute el Pod (basado en recursos, políticas, etc.).
- c-m (kube-controller-manager): Ejecuta los procesos de Control. Cada controlador se encarga de un tipo de recurso (ej. Deployment, StatefulSet, Node). Su foco es llevar el estado actual del clúster al estado deseado.
- c-c-m (cloud-controller-manager): Ejecuta controladores específicos para interactuar con la API del proveedor de nube subyacente (AWS, Azure, GCP, etc.). Se encarga de provisionar recursos como nodos, balanceadores de carga y almacenamiento persistente. (Solo es necesario en clústeres en la nube).
Nodos de Trabajo (Worker Nodes)
- kubelet: Un agente que se ejecuta en cada nodo. Se comunica con el API Server, asegura que los Pods se estén ejecutando en el nodo y que su estado coincida con lo que el API Server le ha indicado. Es el responsable de crear y administrar los contenedores en el Pod.
- k-proxy (kube-proxy): Mantiene las reglas de red en el host y actuar como un proxy de red para los Services de K8s.
Otros conceptos
CRI, o Container Runtime Interface: Esuna interfaz que permite a kubelet (el agente en cada nodo de K8s) comunicarse con diferentes motores de ejecución de contenedores (CRI-O o containerd), sin necesidad de recompilar los componentes del clúster. Define el protocolo para que kubelet pueda crear, iniciar y gestionar contenedores en los nodos, asegurando que K8s pueda funcionar con una variedad de soluciones de tiempo de ejecución de contenedores de forma estandarizada.
- Interfaz de Plugin: Permite a kubelet trabajar con cualquier motor de ejecución de contenedores compatible, haciendo a K8s más flexible.
- Protocolo gRPC: La interfaz define una comunicación basada en el protocolo gRPC entre kubelet y el motor de ejecución del contenedor.
- Motores de Ejecución: Ejemplos populares de implementaciones que utilizan CRI incluyen CRI-O (desarrollado por Red Hat) y Containerd.
- Estándares OCI: Los motores compatibles con la CRI de K8s suelen ser compatibles con los estándares de la Open Container Initiative (OCI), lo que garantiza la interoperabilidad.
Taint/Toleration: El mecanismo de Taints y Tolerations (manchas y tolerancias) funciona como un par para asegurar que los Pods no se programen en nodos inapropiados.
Taint (Mancha): Se aplica al nodo. Marca al nodo para que evite o expulse a los Pods que no toleran esa mancha.
Toleration (Tolerancia): Se aplica al Pod. Es la capacidad de un Pod para aceptar o “tolerar” una mancha específica en un nodo, permitiendo que el Pod sea programado allí.
Por supuesto, esto es solo rascar la superficie. K8s tiene muchísimo más: Services, Deployments, ConfigMaps, Secrets, Namespaces… pero para empezar y entender cómo funciona lo básico, con esto es suficiente. Si quieres profundizar, te recomiendo la documentación oficial de K8s.
Trabajar con el Cluster
Una vez instalado K3s y ahora que tenemos acceso, vamos a trabajar con el Cluster, ver si está funcionando, si mi nodo único es Master y Worker, etc. En K3s, por defecto, un nodo master sí puede ejecutar workloads (pods), a diferencia de K8s estándar donde los nodos master suelen tener un taint que evita que se ejecuten pods en ellos.
Para verificar que el Nodo tierra puede ejecutar Pods, uso estos comandos.
1. Ver los roles y labels del nodo:
[⚡] luis@kymeraw:~ ❯ kubectl get node tierra -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
tierra Ready control-plane,master 13d v1.33.5+k3s1 192.168.103.1 <none> Ubuntu 24.04.3 LTS 6.8.0-86-generic containerd://2.1.4-k3s1
[⚡] luis@kymeraw:~ ❯ kubectl get node tierra --show-labels
NAME STATUS ROLES AGE VERSION LABELS
tierra Ready control-plane,master 13d v1.33.5+k3s1 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/instance-type=k3s,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=tierra,kubernetes.io/os=linux,node-role.kubernetes.io/control-plane=true,node-role.kubernetes.io/master=true,node.kubernetes.io/instance-type=k3s
Veo roles como control-plane,master y el estado Ready, lo cual es buena señal.
2. Verificar los taints del nodo:
Los taints son “manchas” que evitarían que se ejecuten pods en un nodo. Si tiene taints que bloquean pods, no actuará como worker:
[⚡] luis@kymeraw:~ ❯ kubectl describe node tierra | grep -i taint
Taints: <none>
# O de forma más directa:
[⚡] luis@kymeraw:~ ❯ kubectl get node tierra -o jsonpath='{.spec.taints}'
kubectl get node tierra -o jsonpath='{.spec.taints}'
Si el resultado está vacío ([] o null), significa que no hay taints y el nodo puede ejecutar pods. En K3s, por defecto no se añaden taints al nodo master, así que puede actuar como worker.
3. Ver pods corriendo en el nodo:
Una forma práctica de verificar es comprobar si hay pods del sistema ejecutándose en el nodo:
[⚡] luis@kymeraw:~ ❯ kubectl get pods -A -o wide | grep tierra
kube-system coredns-64fd4b4794-dl9th 1/1 Running 2 (4h51m ago) 13d 10.42.0.18 tierra <none> <none>
kube-system helm-install-traefik-crd-dwb4w 0/1 Completed 0 13d <none> tierra <none> <none>
kube-system helm-install-traefik-nwtpb 0/1 Completed 1 13d <none> tierra <none> <none>
kube-system local-path-provisioner-774c6665dc-2hqnz 1/1 Running 2 (4h51m ago) 13d 10.42.0.15 tierra <none> <none>
kube-system metrics-server-7bfffcd44-p6ghl 1/1 Running 2 (4h51m ago) 13d 10.42.0.16 tierra <none> <none>
kube-system svclb-traefik-195315a9-9jnnq 2/2 Running 4 (4h51m ago) 13d 10.42.0.17 tierra <none> <none>
kube-system traefik-c98fdf6fb-wjknn 1/1 Running 2 (4h51m ago) 13d 10.42.0.14 tierra <none> <none>
Yo no hice nada, fue la instalación de K3s la que instaló esos Pods del sistema (como coredns, traefik, local-path-provisioner, etc.) y están ejecutándose en tierra.
4. Desplegar un pod de prueba:
La forma más directa de empezar a jugar es intentar desplegar un pod y ver si se programa en el Nodo:
[⚡] luis@kymeraw:~ ❯ kubectl run test-pod --image=nginx --restart=Never
pod/test-pod created
[⚡] luis@kymeraw:~ ❯ kubectl get pod test-pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
test-pod 1/1 Running 0 17s 10.42.0.19 tierra <none> <none>
Si el pod se programa en tierra y pasa a estado Running, entonces tu nodo está actuando correctamente como Master y Worker a la vez. Una vez verificado, puedes eliminar el pod de prueba:
[⚡] luis@kymeraw:~ ❯ kubectl delete pod test-pod
pod "test-pod" deleted from default namespace
En resumen, muestra roles control-plane,master, no tiene taints que bloqueen pods, puedo ejecutar pods en él. Tiene buena pinta, el nodo único está actuando como Master y Worker simultáneamente, que es exactamente lo que quería en un cluster mono-nodo con K3s.
5. Checks rápidos adicionales
# Ver que flannel / coredns / traefik están sanos
kubectl -n kube-system get deploy,ds,po -o wide
# Ver cgroup v2 (Ubuntu 24.04 viene OK)
stat -fc %T /sys/fs/cgroup # => cgroup2fs
# Confirmar swap off persistente
swapon --show # vacío
grep -E '\sswap\s' /etc/fstab # comentado
# Ver CRI y versión
crictl --version || ctr --version
kubectl version --short
Entender el Cluster
Ya hemos visto qué tenemos en el Cluster y que podemos añadir un Pod de prueba, etc. Pero antes, me gustaria entender qué es eso que me ha montado k3s.
k3s servicelb (klipper-lb): en tus pods aparece svclb-traefik-*, señal de que no lo deshabilitaste. En mono-nodo no molesta, pero si luego introduces MetalLB habrá conflicto. Decide:
Mantener Klipper-LB (simple, local).
O deshabilitarlo y usar MetalLB (mejor si amplías cluster/red).
Interfaz gráfica (GUI)
He descubierto que K3s por defecto no instala ninguna interfaz gráfica web para gestionar el cluster. Todo se hace desde la línea de comandos con kubectl. Sin embargo, me gustaria conseguir hacer algo vía GUI:
Una opción por lo visto es K8s Dashboard, me han dicho
K3s por defecto no instala ninguna interfaz gráfica web para gestionar el cluster. Todo se hace desde la línea de comandos con kubectl. Sin embargo, si prefieres trabajar con una interfaz web desde el navegador, tienes varias opciones:
Kubernetes Dashboard
El Kubernetes Dashboard es la interfaz web oficial de K8s. Proporciona una interfaz gráfica para gestionar aplicaciones, ver recursos, logs, etc.
Para instalarlo en K3s:
# Aplicar el manifiesto oficial del Dashboard
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.7.0/aio/deploy/recommended.yaml
# Crear un usuario de servicio para acceder
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: admin-user
namespace: kubernetes-dashboard
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: admin-user
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: admin-user
namespace: kubernetes-dashboard
EOF
# Obtener el token para acceder
kubectl -n kubernetes-dashboard create token admin-user
# Acceder vía port-forward
kubectl port-forward -n kubernetes-dashboard service/kubernetes-dashboard-kong-proxy 8443:443
Luego accedes desde el navegador a https://localhost:8443 usando el token obtenido.
Rancher
Rancher es una plataforma de gestión de K8s muy popular, especialmente para K3s (ya que K3s es desarrollado por Rancher Labs). Proporciona una interfaz web completa y potente para gestionar clusters, desplegar aplicaciones, ver métricas, etc.
Para instalarlo en K3s, la forma más sencilla es usar Helm:
# Añadir el repositorio de Helm de Rancher
helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
helm repo update
# Instalar Rancher
helm install rancher rancher-latest/rancher \
--namespace cattle-system \
--create-namespace \
--set hostname=rancher.tierra.parchis.org \
--set bootstrapPassword=admin
Rancher es más pesado que el Dashboard, pero ofrece muchas más funcionalidades. Es ideal si quieres una solución completa de gestión.
k9s (Terminal UI)
Aunque no es una interfaz web, k9s es una herramienta TUI (Terminal User Interface) muy popular y potente. Aunque no se ejecuta en el navegador, es una alternativa gráfica muy eficiente para gestionar K8s desde la terminal.
Se instala en tu estación de trabajo (no en el cluster):
# macOS
brew install k9s
# Windows
scoop install k9s
# Linux
curl -sS https://webinstall.dev/k9s | bash
Una vez instalado, simplemente ejecutas k9s y se conecta automáticamente usando tu kubeconfig. Es muy rápido y eficiente para trabajar desde la terminal.
Recomendación
Para empezar y probar, te recomiendo k9s si te sientes cómodo con la terminal, o el Kubernetes Dashboard si prefieres una interfaz web. Si más adelante necesitas funcionalidades avanzadas, gestión multi-cluster, o una solución más completa, entonces Rancher es la mejor opción.