ReplicaSet:

A ReplicaSet’s purpose is to maintain a stable set of replica Pods running at any given time. As such, it is often used to guarantee the availability of a specified number of identical Pods.

There are many ways we can use replicasets such that always required number of pods running is guarangteed.

1. While creating the deployment

 kubectl create deployment ramesh --image=scmgalaxy/nginx-devopsschoolv1 --replicas=3 -n=ramesh

2. While the deployment is running

kubectl edit deploy ramesh -n=ramesh
Replicas:               2 desired | 2 updated | 2 total | 2 available | 0 unavailable //change this value to desired number of replicas

3. Using scale option

kubectl scale --replicas=1 deploy/ramesh -n=ramesh

Always the required number of pods are running is guaranteed.

[centos@ip-172-31-22-14 ramesh]$ kubectl create deployment ramesh --image=scmgalaxy/nginx-devopsschoolv1 --replicas=3 -n=ramesh
deployment.apps/ramesh created
[centos@ip-172-31-22-14 ramesh]$ kubectl get deploy -n=ramesh
NAME READY UP-TO-DATE AVAILABLE AGE
ramesh 3/3 3 3 9s
[centos@ip-172-31-22-14 ramesh]$ kubectl get pods -n=ramesh
NAME READY STATUS RESTARTS AGE
ramesh-88bcb4f5d-9jq4d 1/1 Running 0 18s
ramesh-88bcb4f5d-dtn2c 1/1 Running 0 18s
ramesh-88bcb4f5d-hppkz 1/1 Running 0 18s
[centos@ip-172-31-22-14 ramesh]$ kubcectl delete pod ramesh-88bcb4f5d-hppkz -n=ramesh
-bash: kubcectl: command not found
[centos@ip-172-31-22-14 ramesh]$ kubectl delete pod ramesh-88bcb4f5d-hppkz -n=ramesh
pod "ramesh-88bcb4f5d-hppkz" deleted
[centos@ip-172-31-22-14 ramesh]$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nagesh 1/1 Running 0 93m
[centos@ip-172-31-22-14 ramesh]$ kubectl get pods -n=ramesh
NAME READY STATUS RESTARTS AGE
ramesh-88bcb4f5d-9jq4d 1/1 Running 0 52s
ramesh-88bcb4f5d-dtn2c 1/1 Running 0 52s
ramesh-88bcb4f5d-qms2q 1/1 Running 0 10s //this is the newly created pod after deleting the existing POD

Kubernetes cluster is a combination of nodes with atleast one Master node and a worked node.

Control plane components:

1. Api Server: Provides Api to connect to worker nodes
2. Cluster store (etcd): Persistant storage of cluster state and it stores data in key and value pair in etcd db.
3. Controller Manager: It is a controller of controllers.
4. Kube schedular: It will just schedule the pods and assigns the work

Node components:

1. Kubelet (Minion): To attach worked node to master to add it in a cluster and it instantiates the Pod
2. Container engine: It is Docker
3. Kube Proxy: Pod gets the network using proxy so that all the pods can be communicated using the ip.

Pod:

1. Pod is an atomic unit of kubernetes
2. Pod consists of a container
3. Pod can’t be created but can only be instantiated
4. All Pods can communicate with each other

Pod Life cycle:

Pending->Running->success/fail

• Kubernetes solves the problem of managing containers to automatically scale-up/ scale-down when the nodes having the container fails, so it will deliver the required performance with the desired number of services are always running.
• Kubernetes also provides the load balancing technique in simple/ round-robin fashion though the same container is running in same node.
• Kubernetes guarantee the number of pods (containers/services) always running at any cost.
• Kubernetes provides auto-scaling feature as per the load.
• It is self-healing and has the ability to recover from disaster.
• It does automatic rollbacks when the new deployment fails.
• the deployments can be done very fast
• It provides multi master technique for High availability.
• Simple to setup and easy to trouble shoot.

CMD Entrypoint

1. the executable command will be replaced by the command 1. The executable command can’t be changed
   given while running the container
2. We can’t pass the arguments for the CMD command 2. The commands passed while running the container will be appended to the RUN command
3. Multiple times can be added in the dockerfile 3. same as CMD
   but the last line will override the previous
4. Choose CMD if you need to provide a default command 4. Prefer ENTRYPOINT to CMD when building executable Docker image
   and/or arguments that can be overwritten from command line and you need a command always to be execute
   when docker container runs
5. Treated as additional param when it is used 5. Always the main command
   along with ENTRYPOINT

It will remove the intermediate container and take the latest changes.

FROM ubuntu
MAINTAINER Rajesh Kumar << rajesh@scmgalaxy.com>>
ENV DEBIAN_FRONTEND=noninteractive
RUN apt-get update
RUN apt-get -y install tzdata
RUN apt-get install git -y && apt-get install -yq apache2
CMD echo "Hello world"
CMD echo "Hi"

result:
Hi
Last CMD will be executed.

What about if you 2 ENRTYPOINT?

It will remove the intermediate container and take the latest changes.

FROM ubuntu 
MAINTAINER Rajesh Kumar << rajesh@scmgalaxy.com>> 
ENV DEBIAN_FRONTEND=noninteractive 
RUN apt-get update RUN apt-get -y install tzdata 
RUN apt-get install git -y && apt-get install -yq apache2 
ENTRYPOINT ["/bin/echo", "Hello"]
ENTRYPOINT ["/bin/echo", "Hi"]

result:
Hi
Last Entry point will be executed.

What about if you 1 ENRTYPOINT 1 CMD?

Entry point executed first then CMD executed.

FROM ubuntu 
MAINTAINER Rajesh Kumar << rajesh@scmgalaxy.com>> 
ENV DEBIAN_FRONTEND=noninteractive 
RUN apt-get update RUN apt-get -y install tzdata 
RUN apt-get install git -y && apt-get install -yq apache2 
ENTRYPOINT ["/bin/echo", "Hi"]
CMD echo "Hello world"

Output:
Hi /bin/sh -c echo "Hello world"

Docker Update:
Update the container configuration like cpu, memory, restart policy, etc.

docker update --kernel-memory 512M ramesh
docker update --restart=on-failure:3 ramesh
docker update --cpus 2 ramesh
docker update --restart=no ramesh

Docker Wait:

Block until one or more containers stop, then print their exit codes.

docker wait ramesh
127
docker ps -a |grep ramesh
7181391c7b98 ubuntu "bash" 50 minutes ago Exited (127) 30 seconds ago
docker wait ramesh
0
docker stop ramesh
docker wait ramesh
137
docker kill ramesh

prints the exit codes accordingly.

Docker Pause will suspend all the process inside a container by sending SIGSTOP command, where as in Docker stop the main process will receive SIGTERM and after a grace period it receives SIGKILL.

SIGSTOP is the pause signal. The only behavior is to pause the process; the signal cannot be caught or ignored. The shell uses pausing (and its counterpart, resuming via SIGCONT) to implement job control.

SIGTERM is the termination signal. The default behavior is to terminate the process, but it also can be caught or ignored. The intention is to kill the process, gracefully or not, but to first allow it a chance to cleanup.

SIGKILL is the kill signal. The only behavior is to kill the process, immediately. As the process cannot catch the signal, it cannot cleanup, and thus this is a signal of last resort.

What is Docker?

Docker provides a platform for running applications in a containerized approach, where in each container have a file system, pid map and own network.

Docker directly interacts with kernel to create mount, pid map, network and a user for each application.

Below are the docker components.

• Docker Engine

Docker Engine is responsible for sending commands to kernel to create infrastructure for running an application

• Docker Image

Docker Image contains executable code and instructions like a template. This exists in registry which needs to be pulled and run.

What is Container?

Docker container provides runtime environment to run our application independently.

Each docker container has a separate file system, pid map, network and a user.

When an image pulled from registry and is run then that program will be run in a container

Benefit of Docker?

It is open source and no license is required.

provides isolated environment to run applications, so same kind of applications can be run independently without any conflict.

Saves Cost by running application in data centers, so the procurement of resource is limited.

Takes less time to setup and runs the application with minimal downtime.

Developers and QA can focus on their development and testing tasks instead of wasting their time for setup and running the applications in VM

Docker Architecture?

User –> Docker client –>RESTFUL–> Docker Server(Deamon) –> ContainerD –> Kernal

This whole setup is inside Docker Engine.

Container lifecycle?

create -> start -> stop -> start -> restart -> pause -> unpause -> kill -> remove

How Docker Works?

When a user runs any docker command then it will be first sent to Docker client.

Docker client checks and verify the command and send it to the Docker Daemon through REST.

Docker server receives the command and checks whether the image exists locally

if exists then the Docker daemon sends request to kernel to create separate file system, pid map, network and user then runs the image in a containerized manner

If not exists then the docker image is pulled from docker registry and performs the above step.