Kubernetes Architecture – Lets go through it

Lets directly jump into the Architecture with out wasting any time. Kubernetes work as on Master and worker node architecture. In total Kubernetes has 7 components out of which 4 belongs to Master node and 3 belongs to worker node as described and shown below:

Master Node components:

1.     API Server

2.     Controller Manager

3.     ETCD

4.     Scheduler

Worker Node components:

1.     Kube-proxy

2.     Kubelet

3.     Runtime

Let’s discuss these components one by one –

MASTER NODE – As the name suggests it is the master for the cluster and entry point for all the administrative tasks which is responsible for managing the Kubernetes cluster.

There can be one or more than one Master inside a cluster for fault tolerance & high availability. Let’s check each component which are responsible to make a node Master.

-        API SERVER

This is the front end for the Kubernetes control plane. All API calls are sent to this server and server send commands to the other services.

No component talks to each other directly , API server is responsible for all the communication.

-        Etcd

This is the Key Value store for the cluster. When an object is created, that objects state is stored here.

Etcd acts as the reference for the cluster state. If the cluster differs from what is indicated in Etcd, cluster would change to match the declared state. For e.g 2 Pods supposed to run with certain image or task if any pods gets deleted it would automatically create one more to match the state.

-        Scheduler

When a new pod is created scheduler determines which node should run it & this decision is based on many factors including hardware, workload’s, affinity etc.

-        Controller Manager

It operates the cluster controllers –

·       Node Controller – Responsible for noticing and responding when nodes go down.

·       Replication Controller – responsible for maintaining the correct number of pods for every replication controller object in the system

·       Endpoints Controller – Populates the endpoint objects i.e. joins services and pods

·       Service Accounts & Token Controllers – creates default accounts and API access tokens for new namespaces

Below is the Architecture diagram and you can see each component and their communication flow

Worker Node (minions) – It is a physical server or VM which runs the applications using Pods which is controlled by the Master node. 

“Pods are the smallest working unit of Kubernetes just like container of Docker” or you can say Kubernetes doesn’t run containers instead it wraps one or more containers into a higher-level structure called POD. Pods are used as the unit of replication in Kubernetes.

Lets check the components of Worker Nodes –

Kube-Proxy:

-        This runs on the nodes and provides network connectivity for services on the nodes that connect to the pods.

-        It serves as a network proxy and a load balancer for a service on a single worker node and manages the network routing for TCP and UDP packets.

-        Kube-proxy runs on each node to deal with individual host sub-netting and ensure that the services are available to external parties.

Kubelet: 

-        It is an agent which communicates with the Master node and executes on nodes or the worker nodes. It gets the Pod specifications through the API server and executes the containers associated with the Pod and ensures that the containers described in those Pod are running and healthy.

Container Runtime:

-      This is the container manager. It can be any container runtime that is compliant with the Open Container initiative such as Docker or to run and manage a container’s lifecycle, we need a container runtime on the worker node.

-        Sometimes, Docker is also referred to as a container runtime, but to be precise, Docker is a platform which uses containers as a container runtime. 

Dockerfile - Intro, understanding and Best practices

What is the Dockerfile?

Dockerfiles are instructions. They contains all of the commands used to build an image.

• Docker images consist of read-only layers.
• Each represents a Dockerfile instruction.
• Layers are stacked. (layered architecture)
• Each layer is a result of the changes from the previous layer.
• Images are built using the docker image build command.

Dockerfile Layers

Dockerfile:

FROM ubuntu:15.04  
COPY . /app  
RUN make /app  
CMD python /app/app.py 

• FROM creates a layer from the ubuntu:15.04 Docker image.
• COPY adds files from your Docker client’s current directory.
• RUN builds your application with make.
• CMD specifies what command to run within the container.

Best Practices =>

General guidelines:

• Keep containers as ephemeral as possible.
• Follow Principle 6 of the 12 Factor App. (https://12factor.net/)
• Avoid including unnecessary files.
• Use .dockerignore.
• Use multi-stage builds.
• Don’t install unnecessary packages.
• Decouple applications.
• Minimize the number of layers.
• Sort multi-line arguments.
• Leverage build cache.

Lets check the instruction manual for Dockerfile :=>

FROM: Initializes a new build stage and sets the Base Image

RUN: Will execute any commands in a new layer

CMD: Provides a default for an executing container. There can only be one CMD instruction in a Dockerfile

LABEL: Adds metadata to an image

EXPOSE: Informs Docker that the container listens on the specified network ports at runtime

ENV: Sets the environment variable <key> to the value <value>

ADD: Copies new files, directories or remote file URLs from <src> and adds them to the filesystem of the image at the path <dest>.

COPY: Copies new files or directories from <src> and adds them to the filesystem of the container at the path <dest>.

ENTRYPOINT: Allows for configuring a container that will run as an executable

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

USER: Sets the user name (or UID) and optionally the user group (or GID) 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 in the Dockerfile

ARG: Defines a variable that users can pass at build-time to the builder with the docker build command, using the --build-arg <varname>=<value> flag

ONBUILD: Adds a trigger instruction to the image that will be executed at a later time, when the image is used as the base for another build

HEALTHCHECK: Tells Docker how to test a container to check that it is still working

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