• Kubelet
• Kube-proxy
• pod
• container

The API server is a component of the Kubernetes control plane that exposes the Kubernetes API. The API server is the front end for the Kubernetes control plane.

The main implementation of a Kubernetes API server is kube-apiserver. kube-apiserver is designed to scale horizontally—that is, it scales by deploying more instances. You can run several instances of kube-apiserver and balance traffic between those instances.

etcd

Consistent and highly-available key value store used as Kubernetes’ backing store for all cluster data.

If your Kubernetes cluster uses etcd as its backing store, make sure you have a back up plan for those data.

You can find in-depth information about etcd in the official documentation.

kube-scheduler

Control plane component that watches for newly created Pods with no assigned node, and selects a node for them to run on.

Factors taken into account for scheduling decisions include: individual and collective resource requirements, hardware/software/policy constraints, affinity and anti-affinity specifications, data locality, inter-workload interference, and deadlines.

kube-controller-manager

Control plane component that runs controller processes.

Logically, each controller is a separate process, but to reduce complexity, they are all compiled into a single binary and run in a single process.

Some types of these controllers are:

• Node controller: Responsible for noticing and responding when nodes go down.
• Job controller: Watches for Job objects that represent one-off tasks, then creates Pods to run those tasks to completion.
• Endpoints controller: Populates the Endpoints object (that is, joins Services & Pods).
• Service Account & Token controllers: Create default accounts and API access tokens for new namespaces.

2. Master and worker nodes

3. Scalable

4. load balancer

5. Cluster

6. Containers

7. Self healing

8. Service

MAINTAINER – The MAINTAINER instruction allows you to set the Author field of the generated images.
RUN – builds your application with make
eg : RUN make /app
CMD – specifies what command to run within the container
LABEL – The LABEL instruction adds metadata to an image.
EXPOSE – Informs Docker that the container listens on the specified network port(s) at runtime.
ENV – The ENV instruction sets the environment variable to the value .
ADD – Copies new files, directories, or remote file URLs from and adds them to the filesystem of the image at the path .

COPY – Copies new files or directories from and adds them to the filesystem of the image at the path .
ENTRYPOINT – Allows you to configure a container that will run as an executable. Command line arguments to docker run will be appended after all elements in an exec form ENTRYPOINT and will override all elements specified using CMD.
Only the last ENTRYPOINT instruction in the Dockerfile will have an effect.The shell form prevents any CMD or run command line arguments from being used, but the ENTRYPOINT will start via the shell. This means the executable will not be PID 1 nor will it receive UNIX signals. Prepend exec to get around this drawback.

VOLUME – Creates a mount point with the specified name and marks it as holding externally mounted volumes from native host or other containers.

USER – The USER instruction sets the user name or UID to use when running the image and for any RUN, CMD and ENTRYPOINT instructions that follow it in the Dockerfile.

WORKDIR – Sets the working directory for any RUN, CMD, ENTRYPOINT, COPY, and ADD instructions that follow it.

ARG – Defines a variable that users can pass at build-time to the builder with the docker build command using the –build-arg = flag.Multiple variables may be defined by specifying ARG multiple times

ONBUILD – Adds to the image a trigger instruction to be executed at a later time, when the image is used as the base for another build. The trigger will be executed in the context of the downstream build, as if it had been inserted immediately after the FROM instruction in the downstream Dockerfile.

STOPSIGNAL – The STOPSIGNAL instruction sets the system call signal that will be sent to the container to exit. This signal can be a valid unsigned number that matches a position in the kernel’s syscall table, for instance 9, or a signal name in the format SIGNAME, for instance SIGKILL.

HEALTHCHECK – HEALTHCHECK [] CMD (check container health by running a command inside the container)

SHELL – Allows the default shell used for the shell form of commands to be overridden.

Docker kill : Kill a running container (send SIGKILL, or specified signal). This will stop the main entrypoint process/program abruptly. Any pending file system changes that the main process still had in memory will be lost, so the file system might end up damaged

A container created will have all the root file system that of a linux environment f the image is of linux architecure.

for eg: Below is the container started from an httpd docker image.

Docker container root folder structure

The root folder structure of a docker container is similar to the rootfs of a linux environemnt.

A developer if need to run a java application, They can create docker image with java packages. Once this image is pulled the user can use java commands inside the container start their applications