Pods are the smallest deployable units of computing that can be created and managed in Kubernetes.


At the end of this module, you will :
  • Learn the format of a YAML file
  • Learn how to manage a Pods
  • Learn how to manage containers


Create the directory data/pods in your home folder to manage the YAML file needed in this module.
mkdir ~/data/pods


The run command creates a Pod based on the parameters specified, such as the image or the environment variables. This deployment is issued to the Kubernetes master which launches the Pods and containers required. Kubectl run is similar to docker run but at a cluster level.

Exercise n°1

Run a busybox pod on the default namespace.
kubectl run busybox --image=busybox -n default --restart=Never


In imperative object configuration, the kubectl command specifies the operation (create, replace, etc.), optional flags and at least one file name. The file specified must contain a full definition of the object in YAML or JSON format.
The create command create a resources based on the imperative declaration (command line or YAML file).

Exercise n°1

Create a pod that contain a single nginx container with a simple YAML file.
The file created in this exercise will be reused, do not delete it.
apiVersion: v1
kind: Pod
name: my-single-app
env: formation
- name: nginx
image: nginx
kubectl create -f ~/data/pods/01_pods.yaml

Exercise n°2

Create a pod that contain multiple containers : nginx, redis, postgres with a single YAML file.
apiVersion: v1
kind: Pod
name: my-multi-app
env: formation
- name: nginx
image: nginx
- name: postgres
image: postgres
- name: redis
image: redis
kubectl create -f ~/data/pods/02_pods.yaml


When using declarative object configuration, a user operates on object configuration files stored locally, however the user does not define the operations to be taken on the files. Create, update, and delete operations are automatically detected per-object by kubectl. This enables working on directories, where different operations might be needed for different objects.
The apply command manage the status of resources in the Kubernetes cluster. It can create, update and delete resources based on one or more YAML files.

Exercise n°1

Update the image version of the previous nginx pods.
apiVersion: v1
kind: Pod
name: my-single-nginx14
env: formation
- name: nginx
image: nginx:1.14
kubectl apply -f ~/data/pods/03_pods.yaml


The get command list the object asked. It could be a single object or a list of multiple objects comma separated. This command is useful to get the status of each object. The output can be formatted to only display some information based on some json search or external tools like tr, sort, uniq.
The default output display some useful information about each services :
  • Name : the name of the newly created resource
  • Ready : the amount of container ready in the Pods
  • Status : the deployment status
  • Restarts : the count that the Pods has restarted from his creation
  • Age : the age since the Pods creation

Exercise n°1

List pods deployed on the current namespace.
CLI Return
kubectl get pods
busybox 0/1 Completed 0 4m
my-multi-app 3/3 Running 0 3m
my-single-nginx 1/1 Running 0 3m
my-single-nginx14 1/1 Running 0 3m

Exercise n°2

List pods deployed on the namespace default.
CLI Return
kubectl get pods -n default
busybox 0/1 Completed 0 9m
my-multi-app 3/3 Running 0 8m
my-single-nginx 1/1 Running 0 8m
my-single-nginx14 1/1 Running 1 8m

Exercise n°3

List all pods in all namespaces.
CLI Return
kubectl get pods --all-namespaces
default busybox 0/1 Completed 0 10m
default my-multi-app 3/3 Running 0 9m
default my-single-nginx 1/1 Running 0 9m
default my-single-nginx14 1/1 Running 1 8m
kube-system coredns-86c58d9df4-l2hlv 1/1 Running 0 59m
kube-system coredns-86c58d9df4-vwf67 1/1 Running 0 59m
kube-system default-http-backend-5ff9d456ff-r4fk8 1/1 Running 0 59m
kube-system etcd-minikube 1/1 Running 0 58m
kube-system kube-addon-manager-minikube 1/1 Running 0 58m
kube-system kube-apiserver-minikube 1/1 Running 0 59m
kube-system kube-controller-manager-minikube 1/1 Running 0 58m
kube-system kube-proxy-s5frv 1/1 Running 0 59m
kube-system kube-scheduler-minikube 1/1 Running 0 58m
kube-system metrics-server-6fc4b7bcff-wsjsq 1/1 Running 0 59m
kube-system nginx-ingress-controller-7c66d668b-sc6g8 1/1 Running 0 59m
kube-system storage-provisioner 1/1 Running 0 59m

Exercise n°4

List all pods, services, deployments in the kube-system namespace.
CLI Return
kubectl get pods,service,deployment -n kube-system
coredns-86c58d9df4-l2hlv 1/1 Running 0 1h
coredns-86c58d9df4-vwf67 1/1 Running 0 1h
default-http-backend-5ff9d456ff-r4fk8 1/1 Running 0 1h
etcd-minikube 1/1 Running 0 1h
kube-addon-manager-minikube 1/1 Running 0 1h
kube-apiserver-minikube 1/1 Running 0 1h
kube-controller-manager-minikube 1/1 Running 2 1h
kube-proxy-s5frv 1/1 Running 0 1h
kube-scheduler-minikube 1/1 Running 2 1h
metrics-server-6fc4b7bcff-wsjsq 1/1 Running 0 1h
nginx-ingress-controller-7c66d668b-sc6g8 1/1 Running 0 1h
storage-provisioner 1/1 Running 0 1h
default-http-backend NodePort <none> 80:30001/TCP 1h
kube-dns ClusterIP <none> 53/UDP,53/TCP 1h
metrics-server ClusterIP <none> 443/TCP 1h
coredns 2 2 2 2 1h
default-http-backend 1 1 1 1 1h
metrics-server 1 1 1 1 1h
nginx-ingress-controller 1 1 1 1 1h


Once an application is running, it is inevitably a need to debug problems or check the configuration deployed.
The logs command display the stdout and stderr logs of each container in a pod. The containers within a Pod must be started to get information otherwise nothing will be displayed.
This command is really useful to debug a container deployed in a Pod.

Exercise n°1

Create a new Pods that send a message in stdout.
apiVersion: v1
kind: Pod
name: busybox-logs
- name: busybox
image: busybox
command: ["/bin/sh"]
args: ["-c", "echo \"$(date) - INFO - My first logs output on $(hostname)\""]
restartPolicy: Never
Create the resource based on the previous yaml file definition.
kubectl create -f ~/data/pods/04_pods.yaml
Get the logs of the busybox-logs Pod created previously.
CLI Return
kubectl logs busybox-logs
Thu Feb 28 22:19:56 UTC 2019 - INFO - My first logs output on busybox-logs


Once an application is running, it is inevitably a need to debug problems or check the configuration deployed.
The describe command display a lot of configuration information about the container(s) and Pod (labels, resource requirements, etc.) or any other Kubernetes objects, as well as status information about the container(s) and Pod (state, readiness, restart count, events, etc.).
This command is really useful to introspect and debug a container deployed in a Pod.

Exercise n°1

Get the information of the pod busybox deployed on the default namespace.
CLI Return
kubectl describe po busybox
Name: busybox
Namespace: default
Priority: 0
PriorityClassName: <none>
Node: minikube/
Start Time: Wed, 13 Feb 2019 12:45:52 -0500
Labels: run=busybox
Annotations: <none>
Status: Succeeded
Container ID: docker://5a3892c9be87e3f15e752f99d127d6d84525d1a29f3a5bb1b11713a3ae373eb1
Image: busybox
Image ID: docker-pullable://busybox@sha256:7964ad52e396a6e045c39b5a44438424ac52e12e4d5a25d94895f2058cb863a0
Port: <none>
Host Port: <none>
State: Terminated
Reason: Completed
Exit Code: 0
Started: Wed, 13 Feb 2019 12:45:55 -0500
Finished: Wed, 13 Feb 2019 12:45:55 -0500
Ready: False
Restart Count: 0
Environment: <none>
/var/run/secrets/kubernetes.io/serviceaccount from default-token-wpxhp (ro)
Type Status
Initialized True
Ready False
ContainersReady False
PodScheduled True
Type: Secret (a volume populated by a Secret)
SecretName: default-token-wpxhp
Optional: false
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s
node.kubernetes.io/unreachable:NoExecute for 300s
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 18m default-scheduler Successfully assigned default/busybox to minikube
Normal Pulling 18m kubelet, minikube pulling image "busybox"
Normal Pulled 18m kubelet, minikube Successfully pulled image "busybox"
Normal Created 18m kubelet, minikube Created container
Normal Started 18m kubelet, minikube Started container


Execute a command in a container is sometimes needed for debug or development purpose.
The exec command manage the SSH connection to a container deployed in a Pod.
Usually, the format is : kubectl exec -it POD_NAME -c CONTAINER_NAME

Exercise n°1

Connect to the pod my-single-app in the namespace default.
kubectl exec -it my-single-app bash
Exit the container with this command.

Exercise n°2

Connect to the postgres container in the my-multi-app pod in the namespace default.
CLI Return
kubectl exec -it my-multi-app -c postgres env


Sometimes it’s necessary to make narrow, non-disruptive updates to resources created. It is suggested to maintain a set of configuration files in source control, so that they can be maintained and versioned along with the code for the resources they configure. But sometimes for debug and development purpose, it could be useful to directly manage a Kubernetes object deployed in a cluster in real time.
The edit command allows to directly edit any API resource retrieve via the command line tools. It will open the editor defined by your KUBE _EDITOR, or EDITOR environment variables, or fall back to 'vi' for Linux or 'notepad' for Windows. Multiple objects can edit, although changes are applied one at a time.

Exercise n°1

Edit the my-single-app pods to update the image.
KUBE_EDITOR="nano" kubectl edit pods my-single-app


Kubernetes come with a lot of documentation about his objects and the available options in each one. Those information can be find easily in command line or in the official Kubernetes documentation.
The explain command allows to directly ask the API resource via the command line tools to display information about each Kubernetes objects and their architecture.

Exercise n°1

Get the documentation of a specific field of a resource.
CLI Return
kubectl explain pods.spec
RESOURCE: spec <Object>
Specification of the desired behavior of the pod. More info:
PodSpec is a description of a pod.
activeDeadlineSeconds <integer>
Optional duration in seconds the pod may be active on the node relative to
StartTime before the system will actively try to mark it failed and kill
associated containers. Value must be a positive integer.
affinity <Object>
If specified, the pod's scheduling constraints
automountServiceAccountToken <boolean>
AutomountServiceAccountToken indicates whether a service account token
should be automatically mounted.
containers <[]Object> -required-
List of containers belonging to the pod. Containers cannot currently be
added or removed. There must be at least one container in a Pod. Cannot be
dnsConfig <Object>
Specifies the DNS parameters of a pod. Parameters specified here will be
merged to the generated DNS configuration based on DNSPolicy.
dnsPolicy <string>
Set DNS policy for the pod. Defaults to "ClusterFirst". Valid values are
'ClusterFirstWithHostNet', 'ClusterFirst', 'Default' or 'None'. DNS
parameters given in DNSConfig will be merged with the policy selected with
DNSPolicy. To have DNS options set along with hostNetwork, you have to
specify DNS policy explicitly to 'ClusterFirstWithHostNet'.
enableServiceLinks <boolean>
EnableServiceLinks indicates whether information about services should be
injected into pod's environment variables, matching the syntax of Docker
hostAliases <[]Object>
HostAliases is an optional list of hosts and IPs that will be injected into
the pod's hosts file if specified. This is only valid for non-hostNetwork
hostIPC <boolean>
Use the host's ipc namespace. Optional: Default to false.
hostNetwork <boolean>
Host networking requested for this pod. Use the host's network namespace.
If this option is set, the ports that will be used must be specified.
Default to false.
hostPID <boolean>
Use the host's pid namespace. Optional: Default to false.
hostname <string>
Specifies the hostname of the Pod If not specified, the pod's hostname will
be set to a system-defined value.
imagePullSecrets <[]Object>
ImagePullSecrets is an optional list of references to secrets in the same
namespace to use for pulling any of the images used by this PodSpec. If
specified, these secrets will be passed to individual puller
implementations for them to use. For example, in the case of docker, only
DockerConfig type secrets are honored. More info:
initContainers <[]Object>
List of initialization containers belonging to the pod. Init containers are
executed in order prior to containers being started. If any init container
fails, the pod is considered to have failed and is handled according to its
restartPolicy. The name for an init container or normal container must be
unique among all containers. Init containers may not have Lifecycle
actions, Readiness probes, or Liveness probes. The resourceRequirements of
an init container are taken into account during scheduling by finding the
highest request/limit for each resource type, and then using the max of of
that value or the sum of the normal containers. Limits are applied to init
containers in a similar fashion. Init containers cannot currently be added
or removed. Cannot be updated. More info:
nodeName <string>
NodeName is a request to schedule this pod onto a specific node. If it is
non-empty, the scheduler simply schedules this pod onto that node, assuming
that it fits resource requirements.
nodeSelector <map[string]string>
NodeSelector is a selector which must be true for the pod to fit on a node.
Selector which must match a node's labels for the pod to be scheduled on
that node. More info:
priority <integer>
The priority value. Various system components use this field to find the
priority of the pod. When Priority Admission Controller is enabled, it
prevents users from setting this field. The admission controller populates
this field from PriorityClassName. The higher the value, the higher the
priorityClassName <string>
If specified, indicates the pod's priority. "system-node-critical" and
"system-cluster-critical" are two special keywords which indicate the
highest priorities with the former being the highest priority. Any other
name must be defined by creating a PriorityClass object with that name. If
not specified, the pod priority will be default or zero if there is no
readinessGates <[]Object>
If specified, all readiness gates will be evaluated for pod readiness. A
pod is ready when all its containers are ready AND all conditions specified
in the readiness gates have status equal to "True" More info:
restartPolicy <string>
Restart policy for all containers within the pod. One of Always, OnFailure,
Never. Default to Always. More info:
runtimeClassName <string>
RuntimeClassName refers to a RuntimeClass object in the node.k8s.io group,
which should be used to run this pod. If no RuntimeClass resource matches
the named class, the pod will not be run. If unset or empty, the "legacy"
RuntimeClass will be used, which is an implicit class with an empty
definition that uses the default runtime handler. More info:
This is an alpha feature and may change in the future.
schedulerName <string>
If specified, the pod will be dispatched by specified scheduler. If not
specified, the pod will be dispatched by default scheduler.
securityContext <Object>
SecurityContext holds pod-level security attributes and common container
settings. Optional: Defaults to empty. See type description for default
values of each field.
serviceAccount <string>
DeprecatedServiceAccount is a depreciated alias for ServiceAccountName.
Deprecated: Use serviceAccountName instead.
serviceAccountName <string>
ServiceAccountName is the name of the ServiceAccount to use to run this
pod. More info:
shareProcessNamespace <boolean>
Share a single process namespace between all of the containers in a pod.
When this is set containers will be able to view and signal processes from
other containers in the same pod, and the first process in each container
will not be assigned PID 1. HostPID and ShareProcessNamespace cannot both
be set. Optional: Default to false. This field is beta-level and may be
disabled with the PodShareProcessNamespace feature.
subdomain <string>
If specified, the fully qualified Pod hostname will be
"<hostname>.<subdomain>.<pod namespace>.svc.<cluster domain>". If not
specified, the pod will not have a domainname at all.
terminationGracePeriodSeconds <integer>
Optional duration in seconds the pod needs to terminate gracefully. May be
decreased in delete request. Value must be non-negative integer. The value
zero indicates delete immediately. If this value is nil, the default grace
period will be used instead. The grace period is the duration in seconds
after the processes running in the pod are sent a termination signal and
the time when the processes are forcibly halted with a kill signal. Set
this value longer than the expected cleanup time for your process. Defaults
to 30 seconds.
tolerations <[]Object>
If specified, the pod's tolerations.
volumes <[]Object>
List of volumes that can be mounted by containers belonging to the pod.
More info: https://kubernetes.io/docs/concepts/storage/volumes
Add the --recursive flag to display all of the fields at once without descriptions.


The delete command delete resources by filenames, stdin, resources and names, or by resources and label selector.
Some resources, such as pods, support graceful deletion. These resources define a default period before they are forcibly terminated (the grace period) but you may override that value with the --grace-period flag, or pass --now to set a grace-period of 1.
Note that the delete command does NOT do resource version checks, so if someone submits an update to a resource right when you submit a delete, their update will be lost along with the rest of the resource.

Exercise n°1

Delete the busybox pod deployed previously in the default namespace.
kubectl delete pods busybox -n default

Exercise n°2

Delete the nginx pod deployed previously in the default namespace with declarative method.
kubectl delete -f ~/data/pods

Module exercise

The purpose of this section is to manage each steps of the lifecycle of an application to better understand each concepts of the Kubernetes course.
The main objective in this module is to deploy the Voting App Pods in his dedicated namespace.
For more information about the application used all along the course, please refer to the Exercise App > Voting App link in the left panel.
Based on the principles explain in this module, try by your own to handle this steps. The development of a yaml file is recommended.
The file developed has to be stored in this directory : ~/data/votingapp/01_pods
  1. 1.
    Deploy each containers of the Voting App in a single Pod called voting-app in his dedicated namespace created in the previous module.
  2. 2.
    Ensure the Pods are up and running
  3. 3.
    Check the logs of each Pods
Yaml file definition to deploy the Voting App containers.
apiVersion: v1
kind: Pod
name: db
namespace: voting-app
- name: db
image: postgres:10.4
apiVersion: v1
kind: Pod
name: redis
namespace: voting-app
- name: redis
image: redis
apiVersion: v1
kind: Pod
name: result
namespace: voting-app
- name: result-app
image: wikitops/examplevotingapp-result:1.1
apiVersion: v1
kind: Pod
name: vote
namespace: voting-app
- name: voting-app
image: wikitops/examplevotingapp-vote:1.1
apiVersion: v1
kind: Pod
name: worker
namespace: voting-app
- name: worker
image: wikitops/examplevotingapp-worker:1.1
Kubectl command to deploy the Pods based on the previous definition file.
kubectl create -f ~/data/votingapp/01_pods/pods.yaml
Ensure the Pods are created.
kubectl get pods -n voting-app
Check the logs of each Pods to ensure the main process is running.
# Get the database logs
kubectl logs db -n voting-app
# Get the queue logs
kubectl logs redis -n voting-app
# Get the result logs
kubectl logs result -n voting-app
# Get the vote logs
kubectl logs vote -n voting-app
# Get the worker logs
kubectl logs worker -n voting-app

External documentation

Those documentations can help you to go further in this topic :