How to Get Started with Kubernetes
By: Bhargav Bachina
Tags: DevOps, Software Development, Programming, Web Development, Kubernetes

How to Get Started with Kubernetes

A beginner’s guide to Kubernetes

Photo by Gesina Kunkel on Unsplash

Kubernetes is an open-source container orchestration engine for automating deployment, scaling, and management of containerized applications. In this post, we will go through the architecture of Kubernetes for beginners and what are the different options to get started for beginners.

Kubernetes Architecture

Different Options To Get Started

Minikube

Kubernetes Dashboard

How To Deploy In Cluster

Some Examples

Summary

Conclusion

Kubernetes Architecture

Kubernetes is the orchestration platform for the containerized applications. It follows the declarative configuration which defines the desired state of the applications and Kubernetes work hard to maintain that state throughout the lifecycle.

It’s very important for anyone to understand the architecture of the Kubernetes before getting started. Let’s dive into the architecture principles of this tool.

Kubernetes Architecture

If you look at the above diagram, we have master nodes and worker nodes. Worker nodes are managed by the master. The worker node has the following services to be able to run the container applications in the pods.

Kubelet

Kube-proxy

container runtime

Kubelet

This is the most important service in the Kubernetes which is responsible for the execution of the container execution layer. Without kubelet, Kubernetes is just REST API backed by key-value store. Kubernetes executes isolated container application by default. containers are not only isolated from each other and they are also isolated from the underlying host system. This is critical to decoupling the management of individual applications from each other and from management of the underlying cluster physical/virtual infrastructure.

API admission control may reject pods or add additional scheduling constraints to them, but Kubelet is the final arbiter of what pods can and cannot run on a given node, not the schedulers or DaemonSets.

Kube-proxy

This provides an abstraction layer for the group of pods in the node under a common access policy, for example, load balancer. Every node implements Kube-proxy which provides the virtual IP address for the clients to access the dynamic set of pods. This provides a highly available load balancing solution with low-performance overhead.

container runtime

This is responsible for running the container such as Docker, rkt, containerd

The main components of the master nodes are as follows

API Server

Scheduler

Controller-manager

etcd

API Server

This is the basis for all the communication in the cluster. All the components in the cluster communicate through this. It exposes the kubernetes API.

Scheduler

The scheduler is responsible for assigning applications or kubernetes objects to the worker node. It is responsible for placing the pods on the nodes based on the resource requirements.

Controller-manager

This maintains the cluster such as node failures, maintaining the correct amount of pods, for example, if you deploy the application with 3 replicas, it makes sure that there are three pods running at any particular point of time.

etcd

This is the key value store that stores the cluster configuration. If you want to back up the cluster, all you need to save is this key value distributed store.