docker and kubectl have so many subcommands that the third-party tools (k9s, lazydocker, dive) thrive on letting you avoid the CLI. CliAI lets you stay on the CLI without paying the recall tax.
Docker
1. Logs of a container by name
clai
$ clai tail logs of the api container, last 100 lines and follow→ docker logs --tail 100 -f api
2. Purge dangling images
clai
$ clai remove all dangling docker images→ docker image prune -fTotal reclaimed space: 1.2GB
3. Disk usage breakdown
clai
$ clai how much disk is docker using and where→ docker system df -v
4. Exec into the running web container
clai
$ clai shell into the running web container→ docker exec -it $(docker ps -qf name=web) sh
Kubernetes
5. Pods that aren't Running
clai
$ clai show pods in the staging namespace that aren't Running→ kubectl -n staging get pods --field-selector=status.phase!=RunningNAME READY STATUS RESTARTS AGEapi-7d8f-xyz 0/1 CrashLoopBackOff 12 18m
6. Logs from all pods of a deployment
clai
$ clai stream logs from all pods of the api deployment in staging→ kubectl -n staging logs -l app=api --all-containers --tail=50 -f
7. Top memory consumers across the cluster
clai
$ clai which 10 pods are using the most memory cluster-wide→ kubectl top pods -A --sort-by=memory | head -11
8. Restart a deployment without changing the image
clai
$ clai trigger a rolling restart of the api deployment in staging→ kubectl -n staging rollout restart deployment/apideployment.apps/api restarted
This is the one that always trips people up — restart isn't kubectl restart. It's rollout restart. CliAI knows it; you don't have to.
See also
- Network triage — when the cluster networking is the actual problem.
- Cleanup old logs and backups — same theme, different surface.