Pinter Computing

To understand the types of available volumes read the official Kubernetes documentation on Volumes

The official documentation on Kubernetes Persistent Volume and Persistent Volume Claim is at Persistent Volumes

Migrating to CSI drivers from in-tree plugins

Kubernetes moves away from in-tree plugins, that had to be checked into the Kubernetes code repository to out-of-tree volume plugins like CSI ( Container Storage Interface ) drivers and Flexvolume. These drivers can be developed by third parties independently of Kubernetes, and have to be installed and configured on the node, see Migrating to CSI drivers from in-tree plugins

Mount propagation

Mount propagation allows containers to share volumes with other containers within the pod or with containers in other pods on the same host. For more information see Mount propagation

Access Mode

Access mode specifies the way volumes are accessed from one or multiple pods.

• ReadWriteOnce ( RWO ) – the volume can be mounted as read-write by a single node only
• ReadOnlyMany ( ROX ) – the volume can be mounted read-only by many nodes
• ReadWriteMany ( RWX )– the volume can be mounted as read-write by many nodes

For the latest access mode limitations for each volume type see Access Modes

Volume Types

persistentVolumeClaim

persistentVolumeClaim volumes mount PersistentVolume into a Pod without knowing the underlying storage backing, like GCE PersistentDisk or iSCSI volume. CSI (Computer Storage Interface) volume types do not support direct reference from Pods, can only be referenced via the PersistentVolumeClaim object.

nfs

nfs (Netwotk File System) Persistent Disks can be mounted simultaneously by multiple Pods for writing.

awsElasticBlockStore

awsElasticBlockStore AWS EBS volumes have limitations

• the Pods have to run on AWS EC2 instance nodes
• the EC2 instances have to be in the same region and availability-zone as the EBS volume
• only one EC2 instance can be mounted to the EBS
• the access mode can only be ReadWriteOnce

awsElasticBlockStore volume examples

Kubernetes can mount a volume directly to a pod. In this example we mount an AWS EBS volume to the Mongo database pod.

Create a 1 GB volume from the command line

aws ec2 create-volume –availability-zone=us-east-1a –size=1 –volume-type=gp2

Create the mongodb.yml file

apiVersion: v1
kind: Pod
metadata:
  name: mongodb-on-ebs
spec:
  containers:
  - image: mongo
    name: mongo-pod
    volumeMounts:
    - mountPath: /data/db
      name: mongo-volume
  volumes:
  - name: mongo-volume
    awsElasticBlockStore:
      volumeID: <THE_VOLUME_ID>
      fsType: ext4

Create the Mongo DB pod

kubectl create -f mongodb.yml

gcePersistentDisk

gcePersistentDisk can be read simultaneously by multiple Pods but written only by one at a time, so it is a good choice as a common configuration source.
Starting in Kubernetes version 1.10 a beta feature allows the creation of Regional Persistent Disks that are available from multiple zones of the same region.

The gcePersistentDisk limitations are

• the Pods have to run on GCE VM nodes
• the nodes have to be in the same GCE project and zone as the Persistent Disk
• can be mounted to multiple Pods for reading, but only one Pod can write it. If the Pod is controlled by a Replica Controller the access mode has to be read-only, or the replica count has to be 0 or 1

gcePersistentDisk volume example

Create the Persistent Disk (accessible from one zone only)

gcloud compute disks create --size=200GB --zone=us-central1-a my-gce-disk

To create a Regional Persistent Disk (beta in Kubernets 1.10)

gcloud beta compute disks create --size=200GB my-gce-disk
    --region us-central1
    --replica-zones us-central1-a,us-central1-b

Create the Regional Persistent Volume (beta in Kubernets 1.10)

apiVersion: v1
kind: PersistentVolume
metadata:
  name: gce-test-volume
  labels:
    failure-domain.beta.kubernetes.io/zone: us-central1-a__us-central1-b
spec:
  capacity:
    storage: 200Gi
  accessModes:
  - ReadWriteOnce
  gcePersistentDisk:
    pdName: my-gce-disk
    fsType: ext4

Then Pod definition

apiVersion: v1
kind: Pod
metadata:
  name: gce-pd
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: gce-test-container
    volumeMounts:
    - mountPath: /gce-pd
      name: gce-test-volume
  volumes:
  - name: gce-test-volume
    # The GCE Persistent Disk has to exist
    gcePersistentDisk:
      pdName: my-gce-disk
      fsType: ext4

Working with volumes

List all Persistent Volume Claims

kubectl get pvc

This is a great five part blog series on Kubernetes and a post on volumes by Sebastian Caceres. I recommend reading it even before the official Kubernetes tutorial to get a great overview of how Kubernetes really works.

• How does it work? Kubernetes: Episode 1 – Kubernetes general architecture
• How does it work? Kubernetes: Episode 2 – Kubernetes networking
• How does it work? Kubernetes: Episode 3 – Infrastructure as code: the tools of the trade
• How does it work? Kubernetes: Episode 4 – How to Ansible your CoreOS, and etc(d)!
• How does it work? Kubernetes: Episode 5 – Master and Worker, at last!
• Kubernetes vs Swarm: Volumes!

Kubernetes Tutorials

• Great tutorial on the Kubernetes website at Learn Kubernetes Basics – Kubernetes

• kubectl get – list resources
• kubectl describe – show detailed information about a resource
• kubectl logs – print the logs from a container in a pod
• kubectl exec – execute a command on a container in a pod

List existing pods

kubectl get pods

Get detailed information on the pods

kubectl describe pods

Start a proxy to access the containers within the pod

kubectl proxy

Get the pod name and store it in the POD_NAME environment variable

export POD_NAME=$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')
echo Name of the Pod: $POD_NAME

Access an API running in the pod. The name of the pod is in the POD_NAME environment variable

curl http://localhost:8001/api/v1/namespaces/default/pods/POD_NAME/proxy/

View the STDOUT of the only container of the pod

kubectl logs POD_NAME

View the STDOUT of a specific container of the pod

kubectl logs POD_NAME -c CONTAINER_NAME

View the STDOUT of all containers of the pod

kubectl logs POD_NAME --all-containers=true

Execute a command in the only container of the pod

kubectl exec POD_NAME MY_COMMAND

Execute a command in a container of the pod

kubectl exec POD_NAME -c CONTAINER_NAME MY_COMMAND

Start a Bash session in the container (container name is optional if the pod has only one container)

kubectl exec -ti POD_NAME -c CONTAINER_NAME bash

To check an API from the Bash console within the container (use localhost to address it within the container)

curl localhost:8080

Force the deletion of all pods of a deployment

Make sure the MY_DEPLOYMENT_NAME only returns the pods you really want to delete

# IMPORTANT!!!
# First make sure the query only returns the list of pods you really want to delete

kubectl get pods | grep MY_DEPLOYMENT_NAME | awk '{print $1}')

Execute the command to delete the pods

while IFS= read -r result
do
    kubectl delete pod $result --grace-period=0 --force
done < <(kubectl get pods | grep MY_DEPLOYMENT_NAME | awk '{print $1}')