docker und kubectl haben so viele Subkommandos, dass Drittanbieter-Tools (k9s, lazydocker, dive) davon leben, dich an der CLI vorbeizuführen. Mit CliAI bleibst du an der CLI, ohne den Erinnerungs-Tribut zu zahlen.
Docker
1. Logs eines Containers per Name
clai
$ clai folge den letzten 100 Zeilen Logs des api-Containers→ docker logs --tail 100 -f api
2. Dangling-Images aufräumen
clai
$ clai entferne alle Dangling-Docker-Images→ docker image prune -fTotal reclaimed space: 1.2GB
3. Speicherverbrauch aufschlüsseln
clai
$ clai wieviel Disk verbraucht Docker und wo→ docker system df -v
4. Shell im laufenden web-Container
clai
$ clai gib mir eine Shell im laufenden web-Container→ docker exec -it $(docker ps -qf name=web) sh
Kubernetes
5. Pods, die nicht Running sind
clai
$ clai zeige Pods im Namespace staging, die nicht Running sind→ kubectl -n staging get pods --field-selector=status.phase!=RunningNAME READY STATUS RESTARTS AGEapi-7d8f-xyz 0/1 CrashLoopBackOff 12 18m
6. Logs aller Pods eines Deployments
clai
$ clai Stream aller Pod-Logs des api-Deployments in staging→ kubectl -n staging logs -l app=api --all-containers --tail=50 -f
7. Speicherfresser im Cluster
clai
$ clai welche 10 Pods im Cluster verbrauchen am meisten Speicher→ kubectl top pods -A --sort-by=memory | head -11
8. Deployment neu starten ohne Image-Wechsel
clai
$ clai löse Rolling-Restart des api-Deployments in staging aus→ kubectl -n staging rollout restart deployment/apideployment.apps/api restarted
Das ist die Stelle, an der alle stolpern — Restart heißt nicht kubectl restart, sondern rollout restart. CliAI weiß es; du musst es nicht.
Siehe auch
- Netzwerk-Triage — wenn das Cluster-Netzwerk das eigentliche Problem ist.
- Logs und Backups aufräumen — selbes Thema, andere Oberfläche.