Kubernetes Pod Operations

Internal

• Kubernetes Operations
• Pod and Container Concepts

Get Information about Pods

get

All pods in a namespace (or the default namespace if -n is not used):

kubectl [-n namespace] get pods|po

Monitor a pod and be notified when the status of the pod is changing:

kubectl get --watch pod <pod-name>

Get more columns in the output:

kubectl get -o wide pod <pod-name>

Along the default columns, we get IP, NODE, NOMINATED NODE, READINESS GATES.

More general options:

kubectl get

describe

kubectl describe pod <pod-name>

Logs

kubectl log <pod-name>

"Follow" logging:

kubectl logs -f <pod-name>

This shell command could be used to log a pod in such a way logging survives a pod restart:

while ! kubectl -n my-namespace logs -f my-pod; do sleep 1; done

If the pod has multiple containers, the target container can be specified with the --container flag:

kubectl logs ... --container <target-container-name> ...

Obtaining a Pod's Phase

kubectl-o jsonpath="{.status.phase}" get pod <pod-name>

Create Pods

A singleton pod can be created by posting a pod manifest to the API server with:

kubectl apply -f <pod-manifest-file-name>.yaml

Execute Commands inside a Pod

Execute a command in the first container of the pod:

kubectl exec [-it] <pod-name> <command>

The -it flags make the exec session interactive and connects stdin and stdout of the terminal kubectl was executed from to the stdin and stdout of the process executing inside the first container of the pod.

If the pod has multiple containers, the target container can be specified with the --container flag:

kubectl exec ... --container <target-container-name> ...

Removing an Individual Pod

kubectl delete pod <pod-name>

Remove Immediately

kubectl delete pod <pod-name> --grace-period=0 --force

Scaling Up and Down

This usually involves one of the higher level pod controllers:

• Scaling Deployments Up and Down

Updating Pods

Pod metadata cannot be updated with kubectl get pod -o yaml → modify → kubectl apply -f except for very specific fields:

• spec.containers[*].image
• spec.initContainers[*].image
• spec.activeDeadlineSeconds
• spec.tolerations

This approach works to update deployment configurations, though.

Troubleshooting Containers

This procedure applies to both application containers and init containers. The logs of a container can be accessed by identifying the name of the container (application or init) with

kubectl describe pod <pod-name>

or

kubectl get -o yaml get pod <pod-name>

then

kubectl logs -f -c <container-name> pod <pod-name>