Kubernetes Architecture

Cluster Architecture: 

The purpose of kas is to host the applications in the form of containers in an automated fashion, so that we can easily deploy as many containers as are required. There are many components that will make this happen.

Master node is also known as the controles control plane node.

Master node:

        It is mainly used for managing, planning, scheduling and monitoring the nodes and does all of these using Control plane components.

Worker node: 

Worker nodes are the one that is hosting your application. 

Worker node is also known as data plane. 

Kube-apiserver:

• Kubernetes API.
• The API server is the front end for the Kubernetes control plane.
• The kube api-server is responsible for orchestrating all operations within the cluster.
• When we run the kubeckicommand, the kubectl utility is in fact reaching the api server server.
• It exposes the Kubernetes API which is used by external users to perform management operations on clusters as well as various controllers to monitor the state of the cluster and make the necessary changes as required and by the worker node to communicate with the server. 
• The kube api-server first authenticates the requests and validates. 
• It then retrieves the data from the etcd server and responds back with the required information system.
• Bridge: default network driver 
• Bridget is the default network that is attached to a container. 
• The bridge network is an internal private network created by docker on the host.
• All containers attached to this network by default and they get an internal IP address.
• Usually in the range 172.17.xx.
• The containers can access each other using the Internal IP if required. To access any of these containers from the outside world we need to use port forwarding. 
• Another way to access the containers externally is to attach to the host network.
  • This takes out any isolation b/w docker host and the docker container.
• With the none Network, containers don’t have any access to the external network or other containers. They run in an isolated network. 

Docker Storage: 

• In this section, we shall see how data is stored in Docker.
• By default all the files we write will be present in the Writable layer. The data doesn’t persist when that container no longer exists.
• Non persistent data is going to be ephemerali.e.. If this data is going to be deleted there is nothing we can lose. 
• Good example is application code, because it is going to be tied to the life cycle of the container.
  1. By using docker image as build artifact we are baking our code into the image. And anytime we go and
  2. Bind mounts have been around since the early days of Docker. They have limited functionality compared to volumes. With bind mount, a file or directory on the host machine is mounted into a container 
  3. There are 2 ways of creating bind Mounts:
     1. Mount flag:
     2. Volume flag

• A file or directory on the host machine is mounted into a container.
• File or Directory does not need to exists on the Docker host already. 
• It is created on demand if it does not yet exists with -v option.

Docker tmpfs:

• A tmpf mount is not persisted on disk. 
• It can be used by a container during the life cycle of the container. 
• It is mainly used to store non-persistent state or sensitive information.
• Can’t share tmpfs mounts between containers. 

Docker tmpfs:

Preferred mechanism for persisting data generated by and used by docker containers.

Dockerfile:

What is the Dockerfile? 

• Dockerfiles are instructions. They contain all of the commands used to build an image.
• Docker images consist of read-only layers.
• Build images automatically by reading he instructions from the Dockerfile.
• Each represents a Dockerfile instruction.
• Layers are stacked.
• Each layer it a result of t changes from the previous layer

In the past, docker used a technology called Linux Containers or LXC to manage containers on Linux.

LXC used capabilities of the Linux Kernel such as Namespaces and CGroups, to create isolated environments on Linux known as containers.

Problem: LXC is linux-specific, which was from linux open source project. Whenever there was a new release of linux kernel and changes in the lxc would impact docker containers.

It was hard to work with LXC Directly for a normal user, that’s where docker provides a set of tools that made managing containers simpler.

Docker Inc. developed their own tool called libcontainer as a replacement for LXC

With the release of V0.9, docker introduced its own execution environment known as lib containers.

With lib containers, docker could now directly interact with the linux kernel features such as namespaces and cgroups, and thus libcontainer replaced LXC as the default execution environments of Docker.

Docker Daemon: 

• THe docker eliend 
• Interacts with the Docker deeme that perform running heavy lifting of building and distributing od focker containers

Docker Client: 

• It is the primary path of Docker users to interact with the Docker application. 
• The client sends these commands to dockerd.

From 1.11 they introduced 3 more components called

• ENTRYPOINT: Allows for configuring a container that will run as an executable 
• 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