[Kubernetes] Pods

Pods are the smallest deployable units of computing that you can create and manage in Kubernetes.

Pods | Kubernetes

• A Pod consists of one or more containers and resources shared by those containers.

Creating a Pod

(Example) A simple pod running an nginx container

• Create a YAML file

apiVersion: v1
kind: Pod
metadata:
  name: my-nginx
  namespace: pod-test
  labels:
    app: nginx
    rel: stable
spec:
  containers:
  - name: my-nginx
    image: nginx
    ports:
    - containerPort: 80

• Create/Apply a Pod using the yaml definition

kubectl create -f <yaml-file> --save-config

# Create (if not exist) + Update
kubectl apply -f <yaml-file>

Checking Pods

# Get a list of pods in the default namespace
kubectl get pods 
# Get a list of pods in all namespaces
kubectl get pods --all-namespaces 
kubectl get pods -A

# Get a list of pods in the specified namespace
kubectl get pods -n <ns-name>
# Get a list of system pods running in the cluster
kubectl get pods -n kube-system 

# Get the IP addresses of pods
kubectl get pods -o wide 

kubectl describe pod <pod-name>
kubectl describe pod <pod-name> --namespace <ns-name>

Running a Pod

kubectl run --image=nginx

Exposing a Pod port

# external port:internal port
kubectl port-forward <pod-name> 8080:80 

Running a command in a Pod

kubectl exec -- <command>

kubectl exec <pod-name> -- date
kubectl exec <pod-name> -- curl 10.222.1.2

Testing a Service/Pod with curl

You can quickly test if a service and a pod are working:

kubectl exec <pod-name> --curl s http://<pod-ip>

# example
kubectl exec nginx -- curl s http://10.224.1.2

# shell into a pod
kubectl exec <pod-name> -it sh
> curl -s http://<pod-ip>

Editing a Pod

You can only modify some specifications of an existing POD:

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

For example, you cannot edit the environment variables, service accounts, resource limits of a running pod. If you want to edit these, you need to extract the definition file, delete the existing one, edit the yaml file, and create a new one.

<Option 1> kubectl edit

kubectl edit pod <pod-name>

This will open the pod specification in an editor (vi editor). Then edit the required properties. When you try to save it, you cannot do it because you are attempting to edit a field on the pod that is not editable.

A copy of the file is saved in a temporary location as shown above. Then delete the existing pod and create a new one with the definition file:

kubectl delete pod <pod-name>

kubectl create -f /tmp/<file-name>.yaml

<Option 2> kubectl get

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

Then make the changes to the exported file using an editor (vi editor), delete the existing pod, and create a new pod.

kubectl delete pod <pod-name>

kubectl create -f <file-name>.yaml

Multi-Container Pods

You can create multiple containers simply by providing a list of container items in the “spec.containers” section.

Types of multi-container pods

• Sidecar
  • One container performs a helping task to assist the main container.
• Adapter
  • It normalizes the interface among different applications.
    • It transforms the main container’s output to some other standard forms that can be consumed in other applications.
• Ambassador
  • It provides a proxy to control traffics to / from the main container.
    • It is used to access to different environment such as Dev and Production.

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-app
    image: nginx
  - name: my-service
    image: busybox

Init Containers

In some multi-container scenarios, a secondary container (or more) might need to be used before the main app containers.

Init containers are like regular containers but

• they always run to completion
• Each init container must complete successfully before the next one starts.

[Note] If a Pod’s init container fails, the kubelet repeatedly restarts that init container until it succeeds. However, if the Pod has a restartPolicy of Never, and an init container fails during startup of that Pod, Kubernetes treats the overall Pod as failed.

Benefits

• By moving setup scripts to init containers, the app container images can be lighter.
• Init containers can block or delay app container startup until all preconditions are met.

apiVersion: v1
kind: Pod
metadata:
  name: app-pod
spec:
  containers:
  - name: yapp-container
    image: busybox
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-service1
    image: busybox
    command: ['sh', '-c', "echo doing some work1 && sleep 100"]
  - name: init-service2
    image: busybox
    command: ['sh', '-c', "echo doing some work2 && sleep 100"]