docker y kubectl tienen tantos subcomandos que las herramientas de terceros (k9s, lazydocker, dive) prosperan permitiéndote evitar la CLI. CliAI te deja quedarte en la CLI sin pagar el coste de la memoria.
Docker
1. Logs de un contenedor por nombre
clai
$ clai sigue las últimas 100 líneas de logs del contenedor api→ docker logs --tail 100 -f api
2. Purgar imágenes huérfanas
clai
$ clai elimina todas las imágenes docker huérfanas→ docker image prune -fTotal reclaimed space: 1.2GB
3. Desglose de uso de disco
clai
$ clai cuánto disco usa docker y dónde→ docker system df -v
4. Shell en el contenedor web
clai
$ clai entra a la shell del contenedor web en ejecución→ docker exec -it $(docker ps -qf name=web) sh
Kubernetes
5. Pods que no están Running
clai
$ clai muestra pods en staging que no están Running→ kubectl -n staging get pods --field-selector=status.phase!=RunningNAME READY STATUS RESTARTS AGEapi-7d8f-xyz 0/1 CrashLoopBackOff 12 18m
6. Logs de todos los pods de un deployment
clai
$ clai stream de logs de todos los pods del deployment api en staging→ kubectl -n staging logs -l app=api --all-containers --tail=50 -f
7. Top consumidores de memoria del cluster
clai
$ clai qué 10 pods usan más memoria en todo el cluster→ kubectl top pods -A --sort-by=memory | head -11
8. Reiniciar un deployment sin cambiar la imagen
clai
$ clai dispara un rolling restart del deployment api en staging→ kubectl -n staging rollout restart deployment/apideployment.apps/api restarted
Este es el que siempre engaña — restart no es kubectl restart, es rollout restart. CliAI lo sabe; tú no tienes que hacerlo.
Ver también
- Triage de red — cuando la red del cluster es el verdadero problema.
- Limpieza de logs y backups viejos — mismo tema, otra superficie.