Docker Notes

 ARG:

if you want to pass or change something in that can set during image build you can use this instruction 

This will be available till image build.

It has life time of till building an image

ENV:

this will be environment variable available in RUN container.

It has life time of building an image and running container.

This value can be set or changed while container is created.

For ex: if you want to select database when app is running , you can choose that DB by using ENV variable.

ADD:

if you want to download file from URL(from internet) , you can use this instruction

COPY:

If you want to copy your local file to image to build image you can use this instruction.

FROM:

its a base and primary command to build docker image at the starting of Dockerfile.

CMD:

to run any scripts or any commands while building image or in container , you can use this instruction.

RUN:

Expose:

to expose your container to specific port , you can use this instruction.

Healthcheck:

you can use this instruction to check health of image or container for timeout, interval and stop states.

ONBUILD:

you can use this instruction while building an image .

.dockerignore:

If you want to ignore any files or sensitive information , you can use this file to ignore while building an image.

Sample webapp to push docker image to Docker hub

Kubernetes Tutorial

 Why Kubernetes

• Self Healing containers.
• large scaling application deployments
• Rolling updates and rollback features

Architecture of Kubernetes

Cluster: Different machines combined together to make K8s work , here each machine is called as NODE.

In simple terms CLUSTER is combo of nodes. The responsibility of master node is to maintain the cluster.

Master node runs in Linux nodes and it can't be windows machine.

Node: where actual work is done.

Kubernetes master and Node components

kube-apiserver:

• Responsible for the communication

etcd:

• Whatever is happening in cluster is stored here . which node is running, how many are running , state of the nodes etc.
• All the details of Kubernetes cluster stored here.
• this also named it as cluster store.
• It is distributed key value store.
• It is desired to work with multiple machines

Scheduler:

• When new task created , it assigns to the healthy node
• Whenever you want to create new , this component will come into picture.
• this will create according to your requirement like nodes and communication between them.

Controller-manager

It is responsible for maintaining desired states mentioned in the manifest

It looks like single component but with it has 

Node controller : for noticing and responding when the node goes down

Replication controller : for maintaining the correct number of pods for every replication controller

endpoint controller: Populates the endpoint object, means it exposes the app to desired endpoint(port).

Node components:

nodes can be either windows or Linux machines.

Kubelet:

This is an agent which runs on each node in the cluster

means it will listen master node commands and act accordingly

Container runtime:

means which technology you are going for running containers, in our case DOCKER.

there are different technologies for this case like rocket.

kube-proxy:

All the networking is maintained by kube-proxy, means it is a networking component on each node.

like giving IP address , DNS names or DNS resolutions etc.

Kubernetes objects

This is persistent storage and it has object specification and object state.

Basic workflow:

Write a specification in yaml format and save in a file.

To create/modify 

------

kubectl  apply -f <path of yaml>

-------

* TO delete

-----

kubectl delete -f  <path of yaml>

* To get status

-----

kubectl get <object-kind >

Pod:

Atomic unit in K8s

Pod contains Container(s)

Each pod gets an IP address, which will assign by kube-proxy.

when we have more than one contatiner in the Pod , all these inside the pod can be access by using Pod IP address, for inter container communication and container have to use Local host.

In k8s ,scaling means increasing the pods not the container(s) inside the Pod.

When you have multi container Pod 

•  one container could be main car container
• and another container would be side car container.

Whenever we want to write Pod specification in Yaml t, the following 4 fields should be there

-----

apiVersion:

kind:

metadata:

spec:

kubectl apply -f <name of yml/path of yaml file> -w 

using this we can check the status of container

kubectl apply -f <name of yml/path of yaml file> -o wide

Using this we can check where the container is running. 

To get the IP address or full info of Pod

---

kubectl get pods -o wide

---

Fields of yml file

Namespace: is a logical cluster , means generally we will save data as object in some location , so that location will be logically created to utilize according to our purpose. Hence we call this as a logical cluster.

Is used to create virtual environment.

In K8s we can create virtual clusters using Namespace.

Pods are belongs to the namespace.

---

kubectl get namespace

-----

api-resources: All the different resources avaialbel in K8s.

---

kubectl api-resources

---

Workloads:

Initi-containers:

which will execute before the main containers and these supposed to be executed at certain time.

For ex: if ypu want to execute certain things before starting main container and it has fixed life time.

Controllers:

control the workload objects.//

Replication controller:

In RC, we can set no:of pods as the desired state in master node , so that RC will created desired no.of Pods as below.

Every Pod will get unique IP address.

Daemon set: creating a pod on every node in your cluster., it is used majorly on agent side.

Replica set:

almost same as replication controller but RC set can be preserved and revisited.

Statefull sets:

• It will store data 
• stable and unique network identifiers
• stable and persistant storage
• ordered , graceful deployments and scaling
• ordered and automated rolling updates.

Stateless sets:

Doesn't store any data, if they want to store data , it will rely on external system.

Like other K8S objects, controllers also have 

specification : is more about controlling the objects/workloads

• can define the workload
• how to manage the workload

status

Service:

consider the scenario , where we have app server and DB server .

app server will communicate with DB server to store or retrieve data like below

Now due to application load , we have done the scale pods to 3.

Now lets assume node which mysql pod is running has failed, in that case we get a new mysql pod which will have new IP address as below.

In this case application will stop working as DB is not connected.

To resolve this K8S uses "Service" , which will communicating with DB Pod.

as below

Now Pod has failed and new pod is created then DB serveice will talk to the DB Pod which is created as below.

When a service is created , in the specification we are asked to provide label information.

K8S service will forward the traffic to the pods matching with labels given in service spec.

Service is a layer 4 Load balancer(port, protocol , IP address ).

In K8s layer-7 is supported by ingress which speaks about HTTP.

Service will communicate with etcd to get the Pods which are having specific app labels.

Changing labels is not take any downtime activity.

Labels and Pod are written in metadata in yml file.

service is not a Pod, and it is a rule book created by k8s networking i.e kube-proxy.

service is a logical component not a concrete component, Hence service never fails.

Whenever you are creating a Pod , create labels to that.

K8S deployments

In k8 deployments specifications we need to describe 

• How many replications of Pod
• Pod spec
• Strategy

Deployments internally use replica sets(these are not persistent)

In this scenario we are deploying 3 Pods with your application (Docker image and service) as below

Now new version of your app with tag:1.5 is available 

Then we make changes to spec and rollout deployments as below.

Always remember that Pods will have more than one label , so that if one label matches to perform our operations on Pod , it works better.

Now for some reason we have new version is defective , Now we have to roll back,

like below

Storage in K8s:

• Volume
• Persistent volumes
• Storage class
• Persistent volume claims

Areas of concerns:

• Docker containers are ephermal(once you remove the volume , the data will be lost) to overcome this we have docker volumes.
• Pods also ephermal , means once pod is deleted data also deleted.
• K8s works in many platforms.

K8S storage:

• Volumes life time is equal to life time of Pod.
• so, it will be applicable only to Pod
• Persistent volume life time is equal to life time of cluster.
• it will be applicable for cluster(all the pods in the cluster)

Persistent volume workflow

1. create a persistent volume(PV) with request able attributes
2. while creating a Pod which needs PV , a claim/request is sent out to K8S which is persistent volume claim(PVC).
3. K8s searches for all the available PVs with the requested attributes in PVC.
4. if it finds PV then Pod is created with attached PV whihc has mounted to docker container.

Persistent volumes and storage classes

• PVs can be created statically and dynamically
• To get this dynamic provisioning storage classes will help us

Networking in K8S

• Container networking
• Pod  to pod networking
• Pod to service networking
• Ingress
• Service discovery

Mode details here you can refer.

refer for an app using K8S deployment.