What is Kubernetes ?
It might be easy to deploy a container, but operationalising containers at scale, especially in concert with microservices — is not for weekend enthusiasts. It requires planning, and most experts say an orchestration tool is a must.
That’s the point at which the conversation will likely turn to Kubernetes. The platform was first developed by a team at Google, and later donated to the Cloud Native Computing Foundation (CNCF). It’s not the only option for container management, but it has rapidly become one of the most popular one.
I have been using Kubernetes for last twelve months or so and I must say I am quite impressed with the way our microservices based applications are being managed now. Earlier, some of the biggest challenge we faced were:
- Remembering where our containers are deployed.
- Scaling them manually or taking help of cloud provider’s configurations.
- Being so tightly coupled with the cloud provider that migrating the environment to a more economical provider was a nightmare.
- Dependence on cloud provider’s API gateway.
- Not being able to utilise the VMs to their full potential due to manual orchestration and having to do the math around RAM and processor consumption on the VMs.
- Inability to use some of the industry best-practices such as circuit breakers, rater limiters, uniform logging at each VM etc.
- Issues with reusing the same VMs for different environments such as DEV, QA, UAT and PROD.
- Canary releases of updated containers.
With the introduction of Kubernetes clusters, most of the challenges listed above have now been overcome with least amount of efforts. Kubernetes is an opinionated solution to these issues but the best part is it really doesn’t matter if you are deploying the cluster over AWS or Azure once the configurations are established. Also, managing which container goes where is no longer our headache, Kubernetes control plane takes over such tasks and does them very efficiently.
Throughout this series I will try to emphasise on the above mentioned challenges and how Kubernetes helped me solve them, also I will introduce a starter-kit that I have prepared for beginners to learn Kubernetes from Zero. Hopefully by the end of second part you will have fair bit of information and a good starting point into the Kubernetes wonderland!
What does Kubernetes mean?
The name Kubernetes originates from Greek, meaning helmsman or pilot, and is the root of governor and cybernetic. K8s is an abbreviation derived by replacing the 8 letters “ubernete” with “8”.
Its an open source platform that automates Linux container operations eliminating many of the manual processes involved in deploying and scaling containerised applications. Kubernetes provides a platform to schedule and run containers on clusters of physical or virtual machines. More broadly, it helps you fully implement and rely on a container-based infrastructure in production environments. And to do so in a way that automates many operational tasks.
In other words, you can cluster together groups of hosts running Linux containers, and Kubernetes helps you easily and efficiently manage those clusters.
What does Kubernetes do?
As a Kubernetes user, you can define how your applications should run and the ways they should be able to interact with other applications or the outside world. You can scale your services up or down, perform graceful rolling updates, and switch traffic between different versions of your applications to test features or rollback problematic deployments. Kubernetes provides interfaces and composable platform primitives that allow you to define and manage your applications with high degrees of flexibility, power, and reliability.
Kubernetes eliminates all of the manual processes involved in the deployment and scaling of containerised applications. It’s capable of clustering together groups of servers hosting Linux Containers while also allowing administrators to manage those clusters easily and efficiently.
Kubernetes makes it possible to respond to consumer demands quickly by deploying your applications within a timely manner, scaling those same applications with ease and seamlessly rolling out new features, all while limiting hardware resource consumption. It’s extremely modular and can be hooked into by other applications or frameworks easily. It also provides additional self-healing services, including auto-placement, auto-replication and auto-restart of containers.
Kubernetes vs Docker Swarm
There also exists Docker’s own platform called Swarm. It accomplishes much of the same tasks and boasts a lot of the same features. The primary difference between the two is that Swarm is centralised around the use of Docker, while Kubernetes tends to adopt a more generalised container support model.
Docker and Kubernetes can actually work together. As far as management platforms go, you can use either Kubernetes or Docker Swarm for your Docker engines. Kubernetes currently holds the largest market share and is pretty much the standard platform. It works around the concept of pods, which are scheduling units (and can contain one or more containers) in the Kubernetes ecosystem and they are distributed among nodes to provide high availability.
It has the advantage of using years of research done by Google, hence leveraging the expertise. Being open source, it has a vibrant, growing community with plenty of helpful resources, and guidance available to anyone looking. It can run on either a public cloud service or on premises, and is easy to learn and implement.
Docker Swarm has the advantage of tightly integrated into the Docker ecosystem, and uses its own API. Its filtering and scheduling system enables the selection of optimal nodes in a cluster to deploy containers. As it is developed by Docker itself, Docker Swarm removes many compatibility and other differences and integrates smoothly. Kubernetes usually is not a complete solution and requires custom plug-ins to set up.
Sometimes production applications will span across multiple containers, and those containers may be deployed across multiple physical server machines. Both Kubernetes and Swarm give you the orchestration and management capabilities required to deploy and scale those containers to accommodate the always changing workload requirements.
Architecture
Kubernetes follows the master-slave architecture. The components of Kubernetes can be divided into those that manage an individual node and those that are part of the control plane.
Kubernetes control plane (master)
The Kubernetes Master is the main controlling unit of the cluster, managing its workload and directing communication across the system. The Kubernetes control plane consists of various components:
- etcd: Consistent and highly-available key value store used as Kubernetes’ backing store for all cluster data. Practically speaking I was never required to bother how etcd works, its well encapsulated within the control plane boundaries and is efficiently managed by Kubernetes.
- API-Server: Component on the master that exposes the Kubernetes API. It is the front-end for the Kubernetes control plane. Every time we execute a kubectl command, it goes directly to the api server and is executed by it after taking a good look at the configuration and available hardware.
- Kube-Scheduler: Component on the master that watches newly created pods that have no node assigned, and selects a node for them to run on.
- Kube-Controller-Manager: Component on the master that runs controllers. 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. These controllers include:
- 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 Endpoints object (that is, joins Services & Pods).
- Service Account & Token Controllers: Create default accounts and API access tokens for new namespaces.
Kubernetes node (slave)
The Node, also known as Worker or Minion, is a machine where containers are deployed. If you take example of AWS, you can say these nodes are nothing but simple EC2 instances with a given RAM and CPU configuration.
Every node in the cluster must run a container runtime such as Docker, as well as the below-mentioned components, for communication with master for network configuration of these containers.
- Kubelet: An agent that runs on each node in the cluster. It makes sure that containers are running in a pod. The kubelet takes a set of PodSpecs that are provided through various mechanisms and ensures that the containers described in those PodSpecs are running and healthy.
- Kube-proxy: Enables the Kubernetes service abstraction by maintaining network rules on the host and performing connection forwarding.
- Container runtime: The container runtime is the software that is responsible for running containers. Kubernetes supports several runtimes: Docker, containerd, cri-o, rktlet and any implementation of the Kubernetes CRI (Container Runtime Interface).
Kubernetes Objects
Kubernetes defines a set of building blocks (“primitives”), which collectively provide mechanisms that deploy, maintain, and scale applications based on CPU, memory or custom metrics.
This extensibility is provided in large part by the Kubernetes API, which is used by internal components as well as extensions and containers that run on Kubernetes. The platform exerts its control over compute and storage resources by defining resources as Objects, which can then be managed as such. The key objects are:
- Pods
A Pod is a Kubernetes abstraction that represents a group of one or more application containers (such as Docker or rkt), and some shared resources for those containers such as volumes, DNS etc.
A Pod models an application-specific “logical host” and can contain different application containers which are relatively tightly coupled. For example, a Pod might include both the container with your Node.js app as well as a different container that feeds the data to be published by the Node.js webserver. The containers in a Pod share an IP Address and port space, are always co-located and co-scheduled, and run in a shared context on the same Node.
Example of a Pod definition:
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
spec:
containers:
- name: myapp-container
image: busybox
command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']- Services
A Kubernetes Service is an abstraction which defines a logical set of Pods and a policy by which to access them - sometimes called a micro-service. The set of Pods targeted by a Service is (usually) determined by a Label Selector.
Kubernetes Pods are mortal. They are born and when they die, they are not resurrected. ReplicaSets in particular create and destroy Pods dynamically. While each Pod gets its own IP address, even those IP addresses cannot be relied upon to be stable over time. This leads to a problem: if some set of Pods (let’s call them backends) provides functionality to other Pods (let’s call them frontends) inside the Kubernetes cluster, how do those frontends find out and keep track of which backends are in that set? This is where the concept of a service kicks in.
Example of a Service definition:
kind: Service
apiVersion: v1
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376- Volumes
In Docker, a volume is simply a directory on disk or in another Container. Lifetimes are not managed and until very recently there were only local-disk-backed volumes. Docker now provides volume drivers, but the functionality is very limited for now (e.g. as of Docker 1.7 only one volume driver is allowed per Container and there is no way to pass parameters to volumes).
A Kubernetes volume, on the other hand, has an explicit lifetime — the same as the Pod that encloses it. Consequently, a volume outlives any Containers that run within the Pod, and data is preserved across Container restarts. Of course, when a Pod ceases to exist, the volume will cease to exist, too. Perhaps more importantly than this, Kubernetes supports many types of volumes, and a Pod can use any number of them simultaneously.
At its core, a volume is just a directory, possibly with some data in it, which is accessible to the Containers in a Pod. How that directory comes to be, the medium that backs it, and the contents of it are determined by the particular volume type used.
AWS EBS Example configuration:
apiVersion: v1
kind: Pod
metadata:
name: test-ebs
spec:
containers:
- image: k8s.gcr.io/test-webserver
name: test-container
volumeMounts:
- mountPath: /test-ebs
name: test-volume
volumes:
- name: test-volume
# This AWS EBS volume must already exist.
awsElasticBlockStore:
volumeID: <volume-id>
fsType: ext4- Namespaces
Kubernetes namespaces can be seen as a logical entity used to represent cluster resources for usage of a particular set of users. This logical entity can also be termed as a virtual cluster. One physical cluster can be represented as a set of multiple such virtual clusters (namespaces). The namespace provides the scope for names. Names of resources within one namespace need to be unique.
By default, Kubernetes starts with the following three namespaces:
- Default: Catch-all namespace for all objects not belonging to either of the kube-public or kube-system namespaces. The default namespace is used to hold the default set of pods, services, and deployments used by the cluster.
- Kube-public: Namespace for resources that are publicly available/readable by all
- Kube-system: Namespace for objects/resources created by Kubernetes systems
kubectl
Kubectl controls the Kubernetes Cluster. It is one of the key components of Kubernetes which runs on the workstation on any machine when the setup is done. It has the capability to manage the nodes in the cluster. Kubectl commands are used to interact and manage Kubernetes objects and the cluster. Some of the important commands are as follows:
- kubectl apply − It has the capability to configure a resource by file or stdin.
$ kubectl apply –f <filename>- kubectl attach − This attaches things to the running container.
$ kubectl attach <pod> –c <container>
$ kubectl attach 123456-7890 -c tomcat-conatiner- kubectl autoscale − This is used to auto scale pods which are defined such as Deployment, replica set, Replication Controller.
$ kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min = MINPODS] --max = MAXPODS [--cpu-percent = CPU] [flags]
$ kubectl autoscale deployment foo --min = 2 --max = 10- kubectl cluster-info − It displays the cluster Info.
$ kubectl cluster-infoWeb UI (Dashboard)
Dashboard is a web-based Kubernetes user interface. You can use Dashboard to deploy containerised applications to a Kubernetes cluster, troubleshoot your containerised application, and manage the cluster resources. You can use Dashboard to get an overview of applications running on your cluster, as well as for creating or modifying individual Kubernetes resources (such as Deployments, Jobs, DaemonSets, etc). For example, you can scale a Deployment, initiate a rolling update, restart a pod or deploy new applications using a deploy wizard.
Dashboard also provides information on the state of Kubernetes resources in your cluster and on any errors that may have occurred. Some sample images from the starter-kit we are going to discuss in part-2 of this series are as follows:
Conclusion
This concludes the first part of the series on Kubernetes. I hope via this illustration, the readers would have received some insight into what this new technology entails.
The second part of the series is a little more hands-on kind which will allow you to setup a Kubernetes cluster of your own in a matter of minutes with all the prominent Kubernetes objects covered in-depth along with practical examples of deploying a microservices based product on it.
If it was interesting or helpful to you, please do press the 👏 clap button and help others find this story too.
Did you know you could give up to 50 claps?
