Trabajar · 2 de 6
Docker y Kubernetes
Un contenedor abre una shell en una pestaña; un cluster completo tiene su propia vista en vivo, con las shells, los logs de sus pods y kubectl en la misma vista.
Docker
+ → Docker: "Esta Mac" o "Remoto por SSH" (un host SSH guardado), luego un contenedor en ejecución y el comando (por ejemplo sh). Al conectar se abre docker exec en una pestaña.
Kubernetes
+ → Kubernetes: context y namespace de
~/.kube/config, y un puerto opcional para el proxy de la API: mientras dura la sesión, otras herramientas de este Mac llegan a la API del cluster en http://127.0.0.1:<puerto>, como con kubectl proxy (exec y attach no pasan por el proxy).Al conectar se abre la pestaña Cluster: Pods, Workloads, Config y Network, un selector de namespace, un filtro y el botón del panel de sesiones.
Por pod: shell, logs, reenviar, describir, reiniciar y eliminar (estos dos confirman con un segundo clic). La shell y los logs abren en el panel de sesiones, abajo. Los pods que fallan muestran ¿Por qué?: el asistente lee la salida de describe del pod y la explica.
Workloads: Logs de todas las réplicas sigue todos los pods de un Deployment, StatefulSet, DaemonSet o Job como un solo flujo en el panel de sesiones: cada línea empieza con el nombre de su pod en un color propio (y el del contenedor, si el pod tiene varios). Los pods que agrega un rollout se suman con + y los que desaparecen se marcan con ×. Qué réplica recibió un pedido se ve de un vistazo; para ver pods lado a lado, una pestaña admite hasta cuatro partes.
Los workloads también tienen rollout restart. Config: ConfigMaps y Secrets; mantener presionado el ojo revela un valor, que se puede copiar. Network: services y rutas de ingress, con reenvío a un service.
Los reenvíos sobreviven al reemplazo del pod: siguen las etiquetas del pod.
Fijar en hosts, en el panel junto a la shell de un pod, la guarda como host (con el nombre de su workload), que tras un deploy se reconecta al pod que coincida.
El panel de sesiones
Todo lo que necesita un cluster queda en su única pestaña, como en k9s: un panel debajo de las tablas reúne las sesiones de este cluster —la consola de kubectl, las shells y los logs de los pods—, una ficha cada una. Abrir de nuevo la shell o los logs de un pod enfoca la sesión que ya está abierta; la fila del pod muestra cuáles lo están.
Consola de kubectl: el botón de terminal a la izquierda de la vista (o p) abre una shell donde
kubectl (y k) ya apunta a este cluster y al namespace que muestra la vista; cambiar el namespace cambia también el de kubectl. No hace falta instalar nada: la primera vez, Shellden descarga el kubectl oficial (unos 60 MB, verificado contra su checksum publicado), con el progreso en el panel. La tienen los clusters guardados y los que se abren desde el árbol de Cloud, EKS incluido.Teclas, con el foco en la vista (un clic en la tabla): ↑↓ eligen un pod, s abre su shell, l sus logs, d lo describe, p muestra u oculta el panel, m lo maximiza, x cierra su sesión activa (también ⌘W dentro del panel) y Escape cierra una ventana. Desde cualquier lugar, terminales incluidas, ⌘J muestra u oculta el panel (se cambia en la hoja del teclado). El botón del teclado, arriba a la derecha, las lista todas; el botón i explica la vista.
La shell de un pod busca la shell que tiene: bash, luego sh, luego la de BusyBox. Una imagen sin ninguna (distroless) lo indica y ofrece Abrir un contenedor de depuración: un contenedor BusyBox se suma al pod compartiendo los procesos del contenedor —sus archivos quedan en
/proc/1/root—, como hace kubectl debug. Queda en el pod hasta que el pod se reemplace, por eso se agrega solo a pedido; el cluster tiene que permitir contenedores efímeros y poder descargar busybox.Un pod con más de un contenedor muestra un selector de contenedor junto a su shell.
El borde superior se arrastra para cambiar el alto. Maximizar le da al panel toda la vista; ocultarlo mantiene todas las sesiones corriendo (el botón del panel lo trae de vuelta); la × de una ficha cierra esa sesión.
Abrir en una pestaña mueve la sesión a una pestaña propia de la ventana, sin cortarla: nada se reconecta.
kubectl acompaña al cluster: un cluster a más de una versión del kubectl que trae Shellden recibe el kubectl de su propia versión, así los clusters viejos y los nuevos siguen funcionando. Descargarlo necesita conexión a internet; sin conexión, el panel indica qué versiones están en juego y vuelve a intentarlo solo en cuanto haya conexión (un kubectl de esa versión descargado antes también sirve sin conexión).
La credencial del cluster nunca sale de Shellden: kubectl habla con un punto local privado que abre la sesión, con una clave que solo esa consola conoce.