Kubernetes: Exec

Let's return to the docker material for a moment. In Docker, you can enter a running container using the docker exec command. Similarly, in Kubernetes, you can enter a container within a pod using the kubectl exec command.

Catatan: Since a pod can have more than one container, you can specify the container you want to enter by using the -c {container_name} option. The full command looks like this:

kubectl exec -it {nama_pod} -c {nama_container} -- /bin/sh

So, if you want to enter the container that was created earlier, the command would be:

kubectl exec -it sample-nginx -- /bin/sh

/ # ls
bin                   home                  proc                  sys
dev                   lib                   root                  tmp
docker-entrypoint.d   media                 run                   usr
docker-entrypoint.sh  mnt                   sbin                  var
etc                   opt                   srv
/ #

Comments

[疏影]

kubectl exec is the daily-driver for debugging, but for storage / volume work the patterns are sharper than people realize:

1. hostPath vs emptyDir vs PV — hostPath ties the pod to a specific node (anti-pattern for production because pods cannot reschedule). emptyDir is per-pod lifetime and disappears on restart. PV (with NFS, CephFS, cloud disk) is the right answer for anything that needs to survive pod rescheduling.

2. exec into a pod to read a file — kubelet streams stdin/stdout to the apiserver, which means RBAC for pods/exec has to be granted per-service-account, not cluster-wide. Most teams grant too much and never audit; a quarterly 'who can exec into prod' report keeps it sane.

3. Debug sidecar with shared volume — if your service writes to a PV that you want to inspect from outside, a debug pod with the same PVC mounted is the cleanest way. No hostPath hack, no kubectl cp loop.

Mount layer for ops browsing PV-backed files from Windows: ScsDriver