Session 6 - Application Rollout & Storage

The different types of application Deployments / Rollouts:

https://gitlab.com/jayaramk/springboot/-/blob/main/deployment/deployment-strategy.yaml

strategy:

type: RollingUpdate

rollingUpdate:

maxUnavailable: 25%

# When this many pods are unavailable, stop the Rollout.

# If the deployment has 4 pods and if even 1 pod is unavailable for any reason, stop the Rollout.

maxSurge: 25%

# Do not increase more than this many pods, at a time

# If the deployment has 4 pods, increase one Pod, wait till it is healthy and then increase one more and so on....

# Can also be a number such as the following is not feasible when there are a large number of Pods.

#maxUnavailable: 1

#maxSurge: 1

# Next type of Deployment strategy is Recreate. Destroy all pod and after that create all new pods. This is better for large updates and overhauls.

#type: Recreate

The following exercise:

RollingUpdate

spec:

replicas: 3

strategy:

type: RollingUpdate

rollingUpdate:

maxSurge: 2 # how many pods we can add at one time

maxUnavailable: 0 # how many pods can be unavailable

# at the time of rolling update

Recreate

spec:

replicas: 3

strategy:

type: Recreate


Blue-Green Deployment (aka Red-Black)

Deploy a version 2.0, along with version 1.0 and validate it.

Then change the service and remove the old deployment

apiVersion: v1

kind: Service

metadata:

name: my-app

labels:

app: my-app

spec:

selector:

app: my-app

version: v1.0


# Update the label “version” with v2.0



Canary

Add a new deployment, exactly same as the old deployment, with 1 pod of the newer version:

spec:

replicas: 1

#https://gitlab.com/jayaramk/springboot/-/blob/main/deployment/canary-deployment.yaml


A/B Testing:

Managed by Load balancer or Istio service mesh:

route:

- tags:

version: v1.0.0

weight: 90

- tags:

version: v2.0.0

weight: 10


Storage

Containers are ephemeral.

Any container generated data gets stored into its own filesystem and will be deleted automatically if the container is deleted or restarted.

Kubernetes volumes provide a way for containers to access external disk storage or share storage among containers.

K8 Volumes are available to all containers in the pod and must be mounted in each container specific file location.


Kubernetes supports multiple types of volumes. Some of them are:

emptyDir: Used for mounting temporary empty directory from worker node Disk/RAM

hostPath: Used for mounting Worker node filesystem into the pod

persistentVolumeClaim: Used for mounting dynamically provisioned storage into the pod

nfs: Used for mounting existing NFS (Network file system) into the pod

configMap/secret: Used for mounting these values into the pod

emptyDir

An empty directory created when a Pod is assigned to a node and remains active until pod is running. All containers in the pod can read/write the contents to the emptyDir volume. An emptyDir volume will be erased automatically once the pod is terminated from the node.

#https://gitlab.com/jayaramk/springboot/-/blob/main/deployment/emptyDir.yaml

Login to the java Pod and create a file in the folder /app/assets and they will be visible in the nginx pod.

kubectl exec -i -t -n jayaram basic-java-deployment-84674cb675-clkh4 -c myjava -- sh -c "clear; (bash || ash || sh)"

/opt/app # cd /app/assets/;ls

/app/assets # mkdir hello

/app/assets # touch hi

/opt/app # cd /app/assets/;ls

hello hi



kubectl exec -i -t -n jayaram basic-java-deployment-84674cb675-clkh4 -c nginx -- sh -c "clear; (bash || ash || sh)"

root@basic-java-deployment-84674cb675-clkh4:/# cd /app/assets/;ls

hello hi

root@basic-java-deployment-84674cb675-clkh4:/app/assets#

hostPath

emptyDir volume and its contents get deleted automatically when the Pod is deleted.

Kubernetes hostPath volume helps us to persist volume contents even after pod deleted from the worker node.

Kubernetes hostPath volume mounts a file or directory from the worker node's filesystem into the pod.

A pod running on the same worker node can only mount to the file/directory of that node.


Kubernetes hostPath volume supports following types while mounting

Type Description

Directory A directory must exist in the specified path on the host

DirectoryOrCreate An empty directory will be created when the specified path does not exist on the host

File A file must exist in the specified path on the host

FileOrCreate An empty file will be created when the specified path does not exist on the host

Socket A UNIX socket must exist in the specified path


Login to the Pod to create the files:

kubectl exec -i -t -n jayaram hostpath-java-deployment-6f8fcdf75d-d2gck -c myjava -- sh -c "clear; (bash || ash || sh)"

/opt/app # ls

app.jar shareddoc

/opt/app # cd shareddoc/;ls

/opt/app/shareddoc # touch hi

/opt/app/shareddoc # mkdir b

/opt/app/shareddoc # ls

b hi

/opt/app/shareddoc # pwd

/opt/app/shareddoc

/opt/app/shareddoc #

Login to the Node and you see those files created magically:


[root@prentxappl38 /]# cd /mnt/;ls

shareddoc

[root@prentxappl38 mnt]# cd shareddoc/;ls

b hi

[root@prentxappl38 shareddoc]#


PersistentVolume and PersistentVolumeClaim

Types of Persistent Volumes

PersistentVolume types are implemented as plugins. Kubernetes currently supports the following plugins:

For a Developer, everything is a Yaml file only!



Toay's Excercise:

  1. Lets create a PVClaim first

  2. Then Install the Postgres

  3. Expose it to the world

  4. Connect it from your computer

  5. Delete it all