Deployments are upgraded and higher version of replication controller. They manage the deployment of replica sets which is also an upgraded version of the replication controller. They have the capability to update the replica set and are also capable of rolling back to the previous version.
They provide many updated features of matchLabels and selectors. We have got a new controller within the Kubernetes master called the deployment controller which makes it happen. It has the capability to change the deployment midway.

Changing the Deployment

Updating − The user can update the ongoing deployment before it is completed. In this, the existing deployment will be settled and new deployment will be created.
Deleting − The user can pause/cancel the deployment by deleting it before it is completed. Recreating the equivalent deployment will resume it.
Rollback − We can roll back the deployment or the deployment in progress. The user can create or update the deployment by using DeploymentSpec.PodTemplateSpec = oldRC.PodTemplateSpec.

Deployment Strategies

Deployment strategies help in defining how the new RC should replace the existing RC.
Recreate − This feature will kill all the existing RC and then bring up the new ones. This results in quick deployment however it will result in downtime when the old pods are down and the new pods have not come up.
Rolling Update − This feature gradually brings down the old RC and brings up the new one. This results in slow deployment, however there is no deployment. At all times, few old pods and few new pods are available in this process.
The configuration file of Deployment looks like this.
apiVersion: extensions/v1beta1 ———————>1
kind: Deployment ————————–> 2
metadata:
name: Tomcat-ReplicaSet
spec:
replicas: 3
template:
metadata:
lables:
app: Tomcat-ReplicaSet
tier: Backend
spec:
containers:
– name: Tomcatimage:
tomcat: 8.0
ports:
– containerPort: 7474
Within the above code, the only thing which is different from the replica set is we have defined the kind as deployment.

Create Deployment

$ kubectl create –f Deployment.yaml -–record
deployment “Deployment” created Successfully.

Fetch the Deployment

$ kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVILABLE AGE
Deployment 3 3 3 3 20s

Check the Status of Deployment

$ kubectl rollout status deployment/Deployment

Updating the Deployment

$ kubectl set image deployment/Deployment tomcat=tomcat:6.0

Rolling Back to Previous Deployment

$ kubectl rollout undo deployment/Deployment –to-revision=2

Kubernetes – Volumes

In Kubernetes, a volume can be thought of as a directory which is accessible to the containers in a pod. We have different types of volumes in Kubernetes and the type defines how the volume is created and its content.
The concept of volume was present with the Docker, however the only issue was that the volume was very much limited to a particular pod. As soon as the life of a pod ended, the volume was also lost.
On the other hand, the volumes that are created through Kubernetes is not limited to any container. It supports any or all the containers deployed inside the pod of Kubernetes. A key advantage of Kubernetes volume is, it supports different kind of storage wherewithin the pod can use multiple of them at the equivalent time.
Types of Kubernetes Volume
Here is a list of some popular Kubernetes Volumes −
• emptyDir − It is a type of volume that is created when a Pod is first assigned to a Node. It remains active as long as the Pod is running on that node. The volume is initially empty and the containers within the pod can read and write the files within the emptyDir volume. Once the Pod is removed from the node, the data within the emptyDir is erased.
• hostPath − This type of volume mounts a file or directory from the host node’s filesystem into your pod.
• gcePersistentDisk − This type of volume mounts a Google Compute Engine (GCE) Persistent Disk into your Pod. The data in a gcePersistentDisk remains intact when the Pod is removed from the node.
• awsElasticBlockStore − This type of volume mounts an Amazon Web Services (AWS) Elastic Block Store into your Pod. Just like gcePersistentDisk, the data in an awsElasticBlockStore remains intact when the Pod is removed from the node.
• nfs − An nfs volume allows an existing NFS (Network File System) to be mounted into your pod. The data in an nfs volume is not erased when the Pod is removed from the node. The volume is only unmounted.
• iscsi − An iscsi volume allows an existing iSCSI (SCSI over IP) volume to be mounted into your pod.
• flocker − It is an open-source clustered container data volume manager. It is employed for managing data volumes. A flocker volume allows a Flocker dataset to be mounted into a pod. If the dataset does not exist in Flocker, then you first need to create it by using the Flocker API.
• glusterfs − Glusterfs is an open-source networked filesystem. A glusterfs volume allows a glusterfs volume to be mounted into your pod.
• rbd − RBD stands for Rados Block Device. An rbd volume allows a Rados Block Device volume to be mounted into your pod. Data remains preserved after the Pod is removed from the node.
• cephfs − A cephfs volume allows an existing CephFS volume to be mounted into your pod. Data remains intact after the Pod is removed from the node.
• gitRepo − A gitRepo volume mounts an empty directory and clones a git repository into it for your pod to use.
• secret − A secret volume is employed to pass sensitive information, such as passwords, to pods.
• persistentVolumeClaim − A persistentVolumeClaim volume is employed to mount a PersistentVolume into a pod. PersistentVolumes are a way for users to “claim” durable storage (such as a GCE PersistentDisk or an iSCSI volume) without knowing the details of the particular cloud environment.
• downwardAPI − A downwardAPI volume is employed to make downward API data available to applications. It mounts a directory and writes the requested data in plain text files.
• azureDiskVolume − An AzureDiskVolume is employed to mount a Microsoft Azure Data Disk into a Pod.

Persistent Volume and Persistent Volume Claim

Persistent Volume (PV) − It’s a piece of network storage that has been provisioned by the administrator. It’s a resource within the cluster which is independent of any individual pod that uses the PV.
Persistent Volume Claim (PVC) − The storage requested by Kubernetes for its pods is known as PVC. The user does not need to know the underlying provisioning. The claims must be created within the equivalent namespace where the pod is created.
Creating Persistent Volume
kind: PersistentVolume ———> 1
apiVersion: v1
metadata:
name: pv0001 ——————> 2
labels:
type: local
spec:
capacity: ———————–> 3
storage: 10Gi ———————-> 4
accessModes:
– ReadWriteOnce ——————-> 5
hostPath:
path: “/tmp/data01” ————————–> 6
Within the above code, we have defined −
• kind: PersistentVolume → We have defined the kind as PersistentVolume which tells kubernetes that the yaml file being employed is to create the Persistent Volume.
• name: pv0001 → Name of PersistentVolume that we are creating.
• capacity: → This spec will define the capacity of PV that we are trying to create.
• storage: 10Gi → This tells the underlying infrastructure that we are trying to claim 10Gi space on the defined path.
• ReadWriteOnce → This tells the access rights of the volume that we are creating.
• path: “/tmp/data01” → This definition tells the machine that we are trying to create volume under this path on the underlying infrastructure.
Creating PV
$ kubectl create –f local-01.yaml
persistentvolume “pv0001” created
Checking PV
$ kubectl get pv
NAME CAPACITY ACCESSMODES STATUS CLAIM REASON AGE
pv0001 10Gi RWO Available 14s
Describing PV
$ kubectl describe pv pv0001
Creating Persistent Volume Claim
kind: PersistentVolumeClaim ————–> 1
apiVersion: v1
metadata:
name: myclaim-1 ——————–> 2
spec:
accessModes:
– ReadWriteOnce ————————> 3
resources:
requests:
storage: 3Gi ———————> 4
Within the above code, we have defined −
• kind: PersistentVolumeClaim → It instructs the underlying infrastructure that we are trying to claim a specified amount of space.
• name: myclaim-1 → Name of the claim that we are trying to create.
• ReadWriteOnce → This specifies the mode of the claim that we are trying to create.
• storage: 3Gi → This will tell kubernetes about the amount of space we are trying to claim.
Creating PVC
$ kubectl create –f myclaim-1
persistentvolumeclaim “myclaim-1” created
Getting Details About PVC
$ kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESSMODES AGE
myclaim-1 Bound pv0001 10Gi RWO 7s
Describe PVC
$ kubectl describe pv pv0001
Using PV and PVC with POD
kind: Pod
apiVersion: v1
metadata:
name: mypod
labels:
name: frontendhttp
spec:
containers:
– name: myfrontend
image: nginx
ports:
– containerPort: 80
name: “http-server”
volumeMounts: —————————-> 1
– mountPath: “/usr/share/tomcat/html”
name: mypd
volumes: ———————–> 2
– name: mypd
persistentVolumeClaim: ————————->3
claimName: myclaim-1
Within the above code, we have defined −
• volumeMounts: → This is the path within the container on which the mounting will take place.
• Volume: → This definition defines the volume definition that we are going to claim.
• persistentVolumeClaim: → Under this, we define the volume name which we are going to use within the defined pod.
So, this brings us to the end of blog. This Tecklearn ‘How to manage Deployments and Concept of Kubernetes Volume’ blog helps you with commonly asked questions if you are looking out for a job in DevOps. If you wish to learn Kubernetes and build a career in DevOps domain, then check out our interactive, Continuous Orchestration using Kubernetes Training, that comes with 24*7 support to guide you throughout your learning period. Please find the link for course details:

Continuous Orchestration using Kubernetes

Continuous Orchestration using Kubernetes Training

About the Course

Tecklearn has specially designed this Continuous Orchestration using Kubernetes Training Course to advance your skills for a successful career in this domain. Kubernetes training helps you master the container orchestration tool. As part of the training, you will learn detailed Kubernetes, architecture of Kubernetes, what are Kubernetes Pods, node, how to deploy Kubernetes, creating a Kubernetes cluster, what are the various services available and how Kubernetes makes container orchestration simple. You will get an in-depth knowledge of these concepts and will be able to work on related demos. Upon completion of this online training, you will hold a solid understanding and hands-on experience with Kubernetes.

Why Should you take Continuous Orchestration using Kubernetes Training?

• The average salary for people who possess Kubernetes as a skill is $117,000. – PayScale.com
• Apple, Capital One, AT&T, Oracle, Raytheon & many other MNC’s worldwide use Kubernetes across industries.
• The Kubernetes orchestration engine powers some of the biggest and most complex deployments in the world.

What you will Learn in this Course?

Introduction to DevOps
• What is Software Development
• Software Development Life Cycle
• Why DevOps?
• What is DevOps?
• DevOps Lifecycle
• DevOps Tools
• Benefits of DevOps
• How DevOps is related to Agile Delivery
• DevOps Implementation
Continuous Orchestration using Kubernetes
• Containers and Container Orchestration
• Introduction to Kubernetes
• Docker Swarm vs Kubernetes
• Kubernetes Architecture
• Deploying Kubernetes using Kubeadms
• Alternate ways of deploying Kubernetes
• Understanding YAML
• Creating a Deployment in Kubernetes using YAML
• Creating a Service in Kubernetes
• Installing Kubernetes Dashboard
• Deploying an App using Dashboard
• Using Rolling Updates in Kubernetes

474