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
PersistentVolume types are implemented as plugins. Kubernetes currently supports the following plugins:
awsElasticBlockStore - AWS Elastic Block Store (EBS)
azureDisk - Azure Disk
azureFile - Azure File
cephfs - CephFS volume
csi - Container Storage Interface (CSI)
fc - Fibre Channel (FC) storage
gcePersistentDisk - GCE Persistent Disk
glusterfs - Glusterfs volume
hostPath - HostPath volume (for single node testing only; WILL NOT WORK in a multi-node cluster; consider using local volume instead)
iscsi - iSCSI (SCSI over IP) storage
local - local storage devices mounted on nodes.
nfs - Network File System (NFS) storage
portworxVolume - Portworx volume
rbd - Rados Block Device (RBD) volume
vsphereVolume - vSphere VMDK volume
For a Developer, everything is a Yaml file only!
Toay's Excercise:
Lets create a PVClaim first
Then Install the Postgres
Expose it to the world
Connect it from your computer
Delete it all