Kubernetes Overview

What is Kubernetes?

Kubernetes is an open-source platform for automating deployment, scaling, and operations of application containers across clusters of hosts, providing container-centric infrastructure.

With Kubernetes, you are able to quickly and efficiently respond to customer demand:

Deploy your applications quickly and predictably.
Scale your applications on the fly.
Seamlessly roll out new features.
Optimize use of your hardware by using only the resources you need.

Our goal is to foster an ecosystem of components and tools that relieve the burden of running applications in public and private clouds.

Kubernetes is:
portable: public, private, hybrid, multi-cloud
extensible: modular, pluggable, hookable, composable
self-healing: auto-placement, auto-restart, auto-replication, auto-scaling

The Kubernetes project was started by Google in 2014. Kubernetes builds upon a decade and a half of experience that Google has with running production workloads at scale, combined with best-of-breed ideas and practices from the community.

Features of Kubernetes:

Following are some of the important features of Kubernetes.

• co-locating helper processes, facilitating composite applications and preserving the one-application-per-container model,
• mounting storage systems,
• distributing secrets,
• application health checking,
• replicating application instances,
• horizontal auto-scaling,
• naming and discovery,
• load balancing,
• rolling updates,
• resource monitoring,
• log access and ingestion,
• support for introspection and debugging, and
• identity and authorization.

Kubernetes Architecture:

1. Kubernetes Clients will get inputs from clients in the form of API, UI and CLI. 

2. Kubernetes Master is responsible for scheduling, provisioning, controlling and exposing the API to the clients (API, UI or CLI). Kubernetes understands declerative artifacts in the form of YAML and these YAML definitions are submitted to master. Based on the YAML configuration proivided, the Master will create pods in Nodes 

3. Kubernetes Nodes are the worker nodes, where the action is happening and they will provide the feedback to Master.

4. Registry is place where the Docker images are centrally stored. It will be public registry like Docker Hub or private registry running in local data center.

Kubernetes Master:

API Server is responsible for exposing various API's for various operations. Kubectl is a go-language binary talks to API Server. Kubernetes Dashboard also consumes API Server. So API Server forms the frontend or Gatekeeper for the entire cluster, where everything should pass through APi Server. 

Scheduler is one of the key components of Kubernetes master. It is a service in master responsible for distributing the workload. It is responsible for tracking utilization of working load on cluster nodes and then placing the workload on which resources are available and accept the workload. In other words, this is the mechanism responsible for allocating pods to available nodes. The scheduler is responsible for workload utilization and allocating pod to new node.

Controller Manager is responsible for most of the collectors that regulates the state of cluster and performs a task. In general, it can be considered as a daemon which runs in non-terminating loop and is responsible for collecting and sending information to API server. It works toward getting the shared state of cluster and then make changes to bring the current status of the server to the desired state. The key controllers are replication controller, endpoint controller, namespace controller, and service account controller. The controller manager runs different kind of controllers to handle nodes, endpoints, etc.

etcd stores the configuration information which can be used by each of the nodes in the cluster. It is a high availability key value store that can be distributed among multiple nodes. It is accessible only by Kubernetes API server as it may have some sensitive information. It is a distributed key value Store which is accessible to all.

Kubernetes Node:

Docker will help in running the encapsulated application containers in a relatively isolated but lightweight operating environment.

Kubelet is a small service in each node responsible for relaying information to and from control plane service. It interacts with etcd store to read configuration details and right values. This communicates with the master component to receive commands and work. The kubelet process then assumes responsibility for maintaining the state of work and the node server. It manages network rules, port forwarding, etc.

Kubernetes Proxy Service (kube-proxy) is a proxy service which runs on each node and helps in making services available to the external host. It helps in forwarding the request to correct containers and is capable of performing primitive load balancing. It makes sure that the networking environment is predictable and accessible and at the same time it is isolated as well. It manages pods on node, volumes, secrets, creating new containers’ health checkup, etc.

Supervisord: Both Docker and Kublet are combined to Supervisord layer, which is basically a process manager where you can run multiple processes inside one parent process. It ensures that both Docker and Kublet are running all the time 

Fluentd is responsible to managing the logs and talking to central logging mechanism configured. 

Pod is a unit of deployment, it is possible to have multiple pods and they can be of different configuration (that's why the Pods are depicted in different size and colours in the diagram). Pods could be homogeneous (i.e multiple version of same pod) Or heterogeneous (i.e completly different version and belong to different application) 

Addons are the optional components that you can install on core Kubernetes, which will help you to manage the Kubernetes setup well. Most popular Addon's are DNS and UI. 

Kubernetes Terminology:

Labels:

Labels are key-value pairs which are attached to pods, replication controller and services. They are used as identifying attributes for objects such as pods and replication controller. They can be added to an object at creation time and can be added or modified at the run time.

Selectors:

Labels do not provide uniqueness. In general, we can say many objects can carry the same labels. Labels selector are core grouping primitive in Kubernetes. They are used by the users to select a set of objects. Kubernetes API currently supports two type of selectors −

• Equality-based selectors
• Set-based selectors

Namespace:

Namespace provides an additional qualification to a resource name. This is helpful when multiple teams are using the same cluster and there is a potential of name collision. It can be as a virtual wall between multiple clusters.

Service:

A service can be defined as a logical set of pods. It can be defined as an abstraction on the top of the pod which provides a single IP address and DNS name by which pods can be accessed. With Service, it is very easy to manage load balancing configuration. It helps pods to scale very easily. A service is a REST object in Kubernetes whose definition can be posted to Kubernetes apiServer on the Kubernetes master to create a new instance.

Replica Set:

Replica Set ensures how many replica of pod should be running. It can be considered as a replacement of replication controller. The key difference between the replica set and the replication controller is, the replication controller only supports equality-based selector whereas the replica set supports set-based selector.

Deployments:

Deployments are upgraded and higher version of replication controller. They manage the deployment of replica sets which is also an upgraded version of the replication controller. They have the capability to update the replica set and are also capable of rolling back to the previous version.

Volumes:

In Kubernetes, a volume can be thought of as a directory which is accessible to the containers in a pod. We have different types of volumes in Kubernetes and the type defines how the volume is created and its content. The volumes that are created through Kubernetes is not limited to any container. It supports any or all the containers deployed inside the pod of Kubernetes.  Supports different types like emptyDir, hostPath, gcePersistentDisk, awsElasticBlockStore, nfs, iscsi, flocker, glusterfs, rbd, cephfs, gitRepo, secret, persistentVolumneClaim, downwardAPI, azureDiskVolume

Secrets:

Secrets can be defined as Kubernetes objects used to store sensitive data such as user name and passwords with encryption. There are multiple ways of creating secrets in Kubernetes.

1. Creating from txt files.
2. Creating from yaml file.

Network Policy:

Network Policy defines how the pods in the same namespace will communicate with each other and the network endpoint.