Pods

Module

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

Overview

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

Prerequisites

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

mkdir ~/data/pods

Run

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

Create

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.

~/data/pods/01_pods.yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-single-app
  labels:
    env: formation
spec:
  containers:
  - 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.

~/data/pods/02_pods.yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-multi-app
  labels:
    env: formation
spec:
  containers:
  - name: nginx
    image: nginx
  - name: postgres
    image: postgres
  - name: redis
    image: redis
kubectl create -f ~/data/pods/02_pods.yaml

Apply

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.

~/data/pods/03_pods.yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-single-nginx14
  labels:
    env: formation
spec:
  containers:
  - name: nginx
    image: nginx:1.14
kubectl apply -f ~/data/pods/03_pods.yaml

Get

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.

kubectl get pods

Exercise n°2

List pods deployed on the namespace default.

kubectl get pods -n default

Exercise n°3

List all pods in all namespaces.

kubectl get pods --all-namespaces

Exercise n°4

List all pods, services, deployments in the kube-system namespace.

kubectl get pods,service,deployment -n kube-system

Logs

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.

~/data/pods/04_pods.yaml
apiVersion: v1
kind: Pod
metadata:
  name: busybox-logs
spec:
  containers:
  - 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.

kubectl logs busybox-logs

Describe

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.

kubectl describe po busybox

Exec

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.

exit

Exercise n°2

Connect to the postgres container in the my-multi-app pod in the namespace default.

kubectl exec -it my-multi-app -c postgres env

Edit

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

Explain

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.

kubectl explain pods.spec

Add the --recursive flag to display all of the fields at once without descriptions.

Delete

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. Deploy each containers of the Voting App in a single Pod called voting-app in his dedicated namespace created in the previous module.

  2. Ensure the Pods are up and running

  3. Check the logs of each Pods

External documentation

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

PreviousOrchestrationNextReplicaSet

Last updated