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