kubernetes in Neha’s word
Limited Time Offer!
For Less Than the Cost of a Starbucks Coffee, Access All DevOpsSchool Videos on YouTube Unlimitedly.
Master DevOps, SRE, DevSecOps Skills!
Why Kubernetes ?
- Containers were solving the problem that we are facing with Vms , such as Uptime was very quick as well as stats were low but there were several issues .
- Container technology were not providing the scaling , As the docker host can manage the containers only on it’s host machine, It was becoming difficult for scaling the containers.
- if we deploy containers having same image for the application ( ex . nginx , mysql ) on the same docker host that there were issue with port forwarding as single port can be allocated to single container on the host machine.
- Docker engine on one node cannot control the containers on other nodes.
- Due to these above problems there is a need for Kubernetes Orchestration
- Kubernetes have resolved all the problems that we have faced with container technologies.
- It provides a single interface for managing the containers , managing the networking that resolved the port forwarding issue and also now there is no need to allocate the container to a single node only.
- It also provides the capability to schedule the nodes as and when required .
- It also provides other capabilities like namespaces , networking , storage , etc.
What is Kubernetes ?
- Kubernetes acquires it’s name from the word “Helmsman”, which indicates the a pilot that can take care of everyhting.
- Kubernetes is an orchestration tool for maintaining the containers.
- It consists of various components that helps in eliminating a lot of trouble for the operation people. It follows the declarative approach for writing the manifests.
- It provides capability to the organisation to enable continous integration and continous Delivery.
How Kubernetes works?
- Kubernetes consists of the various components such as master ( control Plane) or node.
- the master is also divided into various components such as apiserver , controller-manager , etcd store , cloud-store , scheduler.
- api -server is the main component responsible for communication within cluster and outside cluster using stateless apis
- scheduler distributes the workload among the nodes .
- etcd store consists of the key-value pairs for maintianing all the configurations and it is also the source of truth.
- controller-manager just checks the controller scripts and try to retrieve information from the pods on the nodes through the api-server. If anything is not at desired state it asks the api-server to inform the scheduler
- On the node side we are having kubelete, kube-proxy and container engine.
What is a Pod ?
- A pod is an logical unit and the smallest unit of k8s.
- It is not created but instaintiated.
- It consists of the conatines which can be loosely coupled or tightly coupled
- All containers share the same pod resources such as namespaces , networking , storage.
Define ReplicaSets with atleast 2 example .
- ReplicaSets and ReplicationController are same but the only difference is that ReplicaSets are a combination of ReplicationController with all bug fixes of rc.
- ReplicationController/ReplicaSets are used for creating pods replicas.
- It make sure that that number of pods always exists and should match with the desired state.
- Replication Controller also providesĀ other benefits, such as the ability to scale the number of pods, and to update or delete multiple pods with a single command.
Example for replication controller:
Example1: Creating rc using yaml file
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: soaktest spec: replicas: 5 template: metadata: labels: app: soaktest spec: containers: - name: soaktest image: nickchase/soaktest ports: - containerPort: 80
Example2: Increasing number of pods through cli.
kubectl scale –replicas=7 rc/replicationcontroller-example -n=neha
Example3: ReplicaSets:
apiVersion: apps/v1
kind: ReplicaSet
metadata:
creationTimestamp: “2021-10-06T05:18:08Z”
generation: 1
labels:
app: guestbook
tier: frontend
name: frontend
namespace: neha
resourceVersion: “194271”
uid: 0f3e11bf-58e2-40df-8a9f-ec822d094339
spec:
replicas: 3
selector:
matchLabels:
tier: frontend
template:
metadata:
creationTimestamp: null
labels:
tier: frontend
spec:
containers:
– image: nginx
imagePullPolicy: Always
name: nginx
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
dnsPolicy: ClusterFirst
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
terminationGracePeriodSeconds: 30