Features of Kubernetes

Features of Kubernetes

Pod — Collection of Containers

A pod is a deployment unit in the K8S with a single IP address. Inside it, the Pause container handles networking by holding a network’s namespace, port, and IP address, which in turn is used by all containers within the pod.

Replication Controller

A replication controller ensures that the desired number of containers is up and running at any given time. Pod templates are used to define the container image identifiers, ports, and labels. Using liveness probes, it auto-heals pods and maintains the number of pods as per the desired state. It can also be manually controlled by manipulating the replica count using kubectl.

Storage Management

Pods are ephemeral in nature — any information stored in a pod or container will be lost once the pod is killed or rescheduled. In order to avoid data loss, a persistent system — like Amazon Elastic Block Storage (EBS) or Google Compute Engine’s Persistent Disks (GCE PD) — or a distributed file system — such as the Network File System (NFS) or the Gluster File System (GFS) — is needed.

Resource Monitoring

Monitoring is one of the key aspects to run infrastructure successfully. It is the base of the hierarchy of reliability. Heapster is an addon used to collect metrics from kubelet, which is integrated with a cAdvisor. cAdvisor is used to collect metrics related to CPU, memory, I/O, and network stats of the running containers. Data collected by Heapster is stored in an influx DB and is displayed in the UI using Grafana. There are also other sinks available like Kafka or Elastic Search, which can be used for storing data and displaying it in the UI.

Health Checking

Health checking in Kubernetes is done by a kubelet agent. It is divided into two liveness and readiness probes.

There are mainly three types of handlers:

ExecAction: 

Shell command is executed, and if the resulting exit code is 0, it means that the instance is healthy. Under any other circumstances, the instance is not healthy.

TCPAction: 

Kubelet will try to connect to a specified port, and if it establishes a connection to the given socket, the diagnostic is successful.

HTTPGetAction: 

Based on the HTTP endpoint that the application exposes, kubelet performs an HTTP GET request against the container IP address on a specified path, and if it returns with a 200 to 300 response code, the diagnostic is successful.

Each probe usually has three results:

Success: The Container has passed the diagnostic.

Failure: The Container has failed the diagnostic.

Unknown: The diagnostic has failed, so no action should be taken.

Horizontal Auto Scaling

Autoscaling utilizes computational resources based on the load. K8S scale pod automatically uses a HorizontalPodAutoscaler object, which gets metrics data from Heapster, and it decreases or increases the number of pods accordingly. For example, if auto-scaling is based on memory utilization, then the controller starts observing memory usage in the pod and scales the replica count based on it.

Service Discovery

Kubernetes pods are ephemeral, and the Replication Controller creates them dynamically on any node, so it is a challenge to discover services in the cluster. A service needs to discover an IP address and ports dynamically related to each other to communicate within a cluster.

There are two primary ways of finding it — Environment variables and DNS

DNS-based service discovery is preferable, and it is available as a cluster add-on. It keeps track of new services in the cluster and creates a set of DNS records for each.

Networking

To manage a cluster fully, a network has to be set up properly, and there are three distinct networking problems to solve:

1. Container-to-Container communications: pods solve this problem through localhost communications and by using the Pause container network namespace

2. Pod-to-Pod communications: this problem is solved by software-defined networking as shown in the Architecture diagram above

3. External-to-Pod communications: this is covered by services.

Kubernetes provides a wide range of networking options. Furthermore, there is now support for the Container Networking Interface (CNI) plugins, which is common plugin architecture for containers. It’s currently supported by several orchestration tools such as Kubernetes, Mesos, and CloudFoundry.

There are various overlay plugins, some of which are discussed below:

• Flannel is a very simple etcd backed overlay network that comes from CoreOS. It creates another virtual, routable IP Per Pod network, which runs above the underlay network; ergo, it is called an overlay network. Each pod will be assigned one IP address in this overlay network, and they communicate with each other using their IP directly.

• Weave provides an overlay network that is compatible with Kubernetes through a CNI plugin.

Services

Kubernetes services are abstractions that route traffic to a set of pods to provide a microservice. Kube-proxy runs on each node and manages services by setting up a bunch of iptable rules.

There are three modes of setting up services:

1. ClusterIP (only provides access internally)

2. NodePort (needed to open the firewall on a port; not recommended for public access)

3. LoadBalancer (owned by public cloud providers like AWS or GKE)

ConfigMap and Secret

ConfigMap makes it possible to inject a configuration based on an environment while keeping the container image identical across multiple environments. These can be injected by mounting volumes or environment variables, and it stores these values in the key/value format.

Rolling Deployment and Rollback

A Deployment object holds one or more replica sets to support the rollback mechanism. In other words, it creates a new replica set every time the deployment configuration is changed and keeps the previous version in order to have the option of rollback. Only one replica set will be in an active state at a certain time.

Logging

To oversee application behavior, one has to check logs — multiple are generated in each pod. To start searching logs in the Dashboard UI, there has to be some mechanism that collects and aggregates them into one log viewer. To illustrate, Fluentd, an open-source tool and part of Cloud Native Computing Foundation (CNCF), combines perfectly with ElasticSearch and Kibana.

Relevant Blogs:

Kubernetes AWS Integration  

Kubernetes multi-master Rolling update in kubernetes 

Multi tier application in kubernetes

Cloud Security