Kubernetes 04 (storage class: provisioner | connect the nfs server (persistent storage)| Deployment | Strategy

Provisioner:

--> provisioner K8s.io/minikube-hostpathmeans the persistent volume created by the storage class is actually taking space from the minikube VM.

-->From where to take storage is the duty of the storage class (Eg Cloud, HD)

A good practice is to mention the storage class name in the persistent volume claim

here you will see that the given storage class is set to be default and it is set to be true.

How to change the default storage class:

--> by default one storage class is already provided named as standard

to edit it use :

kubectl describe sc standard

change this true to false

now you will see that it is no longer a storage class

now if we again create the pvc with same file then we have to mention storage class .

so good practise is always give a storage class in pvc

see in this storage class is not mentioned does we create pvc let see .

see the documentation for provisioner: https://kubernetes.io/docs/concepts/storage/storage-classes/

by default in kubernetes there is no provisioner program installed.

if we want to use it then we have to install it.

In this we are going to connect the nfs server (persistent storage) with the help of storage class provisioner.

--> we can create multiple storage classes

so lets do the practical : NFS in storage class

let set up the

step 1: go to you local vm running and and go to network setting and changed it to NAT and in second adapter select host only adapter

make note that both minikube and redhat linux have same network setting

now login to your local vm in my case I am using redhat version 9

makesure to stop the firewall other wise your server will not be created

manifest file for nfs

we make this folder (mayank_kube) so as we have mount this into volume mount in the manifest file of nfs

now lets run this:

when you use kubectl describe pods will help to see error if cause

lets make the storage class for it

manifest file of storage class

creating storage class

we clearly see that we have now two storage class

--> now pods will take storage from storage class

#deployment

deployment is one of the resource in kubernetes . it is helping you to create the strategies

Types of strategy in deployment

-->Ramped deployment (Rolling update)

-->Recreate deployment

-->Blue-green deployment

-->Canary deployment

-->A/B testing deployment

my developer is created web app and i want to provide this app to our customer and our customer is over the internet. They don't connect the web app directly they first connect to webserver . On the top of web server we run our app. To run our app we first copy the code on the top of webserver and run it . So copying the code and execute it is called as deployment.

for connecting to publicworld we use the service nodeport and if the traffic increase we have to make mulitple pods and to manage these pods we have to create the replicaset

deploying the pod == deploying the pod

whenever we launch the app we have multiple pod running behind the scene managing the app. since we know every app have some bugs and we fix those bugs and updating . for this we launch different different versions of app . our older pod like pod 1 , pod2 , pod3 is maintaining the older version of the app and I want the customer to connect my new pods running which have newer versions of app without any downtime . If it have downtime then it should we very less or 0%.

But if downtime like 1min for a bigger company like amazon , facebook make huge loss of business and customer.

whenever you release the newer version to the public world you want to create the strategy in such a way that downtime is 0%or less time or 100% uptime or if we have a bug on newer version so how quickly we roll back to our stable version

Its all depend upon strategy how well you create the strategy.

-->Ramped deployment (Rolling update)- if you are running a older version of pod .i am going to launch new in such a way that my customer start seeing the newer version without any downtime it internally connected with the new pod.

kubernetes precreated with two strategy (ramped and recreate)

To use these strategy we use keyword deployment

Recreate & rolling deployment strategies in Kubernetes

-->Recreate:- First remove all the older pods then launch new pods

>>Drawbacks :

\>> User loses the connectivity

\>> Has downtime

Use-case:-

If the bug/security vulnerabilities come up so we have to forcefully remove all the older versions of the pods & launch with an updated image

Rolling updates:-Removing one by one older pod and launching new pods simultaneously

-->We always launch the pod in Kubernetes with the keyword called deployment

--> As soon as we launch deployment internally they launch a replica set and ask a replica set to launch the pod

command for deployment:

`kubectl create deployment mydeploy --image=httpd`

we first check the deployment then create the deployement with the same command that we used to run the pods

but this time it internally create the replicaSet

and also pod is launched automatically

when you describe the deployment you see that is uses the rolling update strategy

so do the practical of ramped strategy

go to local vm running let say redhat version 9

now create the docker file where your app exist

and build the image

now we have uploaded the image in docker hub.

now we used to create the deployment with this image

now lets create the replicas

since I have to give access to public world so we have to use the node port so lets expose it

kubectl expose deploy mayadeploy --type=NodePort --port=80

let see the port exposed in public world

we clearly see the webpage I have created

now lets create the newer version of image to launch this new version on the basis of ramped strategy

our newer version will contain this

now lets launch our new web app without any downtime

updating deployment:

command to update the image or app or deployment :

kubectl set image deploy/mayadeploy ramweb=mayaworld13/ramweb:v2

thats all how we use ramped strategy

secret: if you want to store the content of manifest file rather than to store sensitive information in plain text like while launching MySQL pod which have lots of enviromental variable in which password is sensitive one so we should not put password directly in the yaml file as this yaml file we share every where so anyone can get the sensistive file and can do anything with this.

so to store these sensitive information we used to create a box called secret box in which we put the password in it.

\>>> A secret is an object that contains a small amount of sensitive data such as a password, a token, or a key

mostly we use secret for generic purpose

and TLS ( for example if we create the server and we want to change fromm http to https then their keys are stores in tls.

command to create secret : kubectl create secret generic mayasecret --from-literal=p=redhat --from-literal=u=mayank

Kustomize:

like in this

PVC
DB image --> deployment
SVC --> private
pod -->up
wordpress image --> deployment
svc -->nodeport

so we have lots of step to one by one like if i don't launch database pod then we don't run the wordpress application as it require database. so we have a lots of steps to do.

so if we want to do in single step then it is done through kustomize instead we have to tell the sequence only..

Kustomize is a way in Kubernetes in which we can create PVC, PV, Svc, deployment, and pods in one click

project for the wordpress:

manifest file for mysql_deployment.yml