kube-apiserver

kubernetes API server validates and configures data for the api objects which include pods, services, replications controllers and others. This is the only component that communicates with the etcd cluster, making sure data is stored in etcd and is in agreement with the service details of the deployed pods

kube-controller

It runs number of distinct controller processes in the background( replication controller controls number of replicas in a pod). And it will regulate the shared state of the cluster and perform routine tasks. When a change in a service configuration occurs. The controller spots the change and starts working towards the new desire state.

kube-scheduler

It reads the requirements and schedules it on the nodes, this will runs each time there is a need to schedule pods. It must know the total resources available as well as resources allocated to existing workloads on each node.

kubelet

Regularly taking in new or modified pod specifications and ensuring that pods and their containers are healthy and running in the desired state. This component also reports to the apiserver on the health of the host where it is running.

kub-proxy

A service that runs on each worker node to deal with individual host, it performs request forwarding to the correct pods/container across the various isolated networks in a cluster.

kubectl

Command line toll that interacts with kube-apiserver and send commands to the master node. Each command is converted into an API call.

etcd

It is used to store the all data, as kubernetes is a distributed systems so its configuration data, state data and metadata.

1. Docker Image has many layers which holds the information required for the configuration.
2. Base image + parent image + layers+ container layer + docker manifest.
3. Each of the files that make up a Docker image is known as a layer.
4. These layers form a series of intermediate images, built one on top of the other in stages, where each layer is dependent on the layer immediately below it. Thus, you should organize layers that change most often as high up the stack as possible. This is because, when you make changes to a layer in your image, Docker not only rebuilds that particular layer, but all layers built from it. Therefore, a change to a layer at the top of a stack involves the least amount of computational work to rebuild the entire image.
5. Each time Docker launches a container from an image, it adds a thin writable layer, known as the container layer, which stores all changes to the container throughout its runtime.
6. The first layer of a Docker image is known as the parent image. It’s the foundation upon which all other layers are built and provides the basic building blocks for your container environments.
7. A base image is an empty first layer, which allows you to build your Docker images from scratch.
8. The image in JSON format and comprises information such as image tags, a digital signature, and details on how to configure the container for different types of host platforms.

On go we can change the settings of the container using Update command

Before updating the memory-swap

After updating the memory-swap and memory

Wait:

Docker wait command waits for 1 or more container to exit and provides the return status of the docker exit.
Once docker wait is used the control will go inside the container and waits there until its get exited.

docker stop will send SIGTERM to the process and docker will have some-time seconds to clean up like saving files or emitting some messages.

docker stop  <docker_id>
docker inspect <docker_id>

Will return “ExitCode:0”

docker kill will terminate the process used in-case the docker is in locked up state or not responding state.

docker kill <docker_id>
docker inspect <docker_id>

Will return “ExitCode:137”