Getting started with Kubernetes
8 min read
In the past, there were monolithic applications, meaning that all of the application's components ran in the same container and were bundled together. Let's look at an example to better understand. We have an application with a frontend, a backend, a database, etc, therefore if we need to update either of them, we must deploy the entire thing again. The same is true when scaling. Therefore, this is not optimal.
Microservices were introduced to tackle this. We used to run all the components of a monolithic application in a single container, but with microservices, we can now run each component independently. Now, we only need to deploy the component that has changed, and we can scale the components independently based on our needs, hence saving cost.
When designing and running any large-scale system, a containerized application may need managing hundreds or thousands of containers.
As was mentioned above, there are numerous microservices running for every application that require scheduling, networking, scaling, etc, and an orchestrator is what we use to manage these microservices.
What is an orchestrator?
Container orchestration is the operational effort required to run containerized workloads and services.
This consists of different types of aspects that must be managed throughout a container's lifecycle, including:
- Updates with no downtime
- Scaling (up and down)
- Self healing of the containers
- Providing security
There are many options for container orchestration, such as Apache Mesos or Docker Swarm, Kubernetes. But Kubernetes has become industry standard.
Kuberentes is a greek word which means helmsman. It is also known as K8s.
Kubernetes is a container orchestrator. It is an open source platform. It automates the process of scheduling, scaling, load balancing, fault tolerance, deployment, rollouts, and rollbacks, etc. of the containerized application. It is highly extensible and portable. By using several plugins, it offers networking and security.
History of Kubernetes
Google launched Borg in 2003 or 2004 and began using it privately for small projects. Borg was a large-scale internal cluster management system that managed hundreds of thousands of clusters, each with up to tens of thousands of servers, and hundreds of thousands of jobs from thousands of different applications.
Google introduced Omega in 2013, a scalable and flexible scheduler for large compute clusters.
Later, Google released Kubernetes as an open source version of Borg in the middle of 2014. Kubernetes is now included in the CNCF's graduating projects.
Components of Kubernetes:
A cluster is created when you deploy Kubernetes. Control plane and worker nodes are present in the cluster. What are these, exactly?
- Worker Nodes: It is similar to a server or virtual machine. This is the place where your application is running. At least one worker node is present in every cluster.
- Control Plane: It is incharge of controlling the worker nodes, and we have kubectl, a CLI tool for interacting with the control plane.
It is a command Line tool for Kubernetes. Kubectl communicates with the control plane. It may interact in one of two ways:
- Declarative way: By writing the manifest(yaml) files.
- Imperative way: Through specific commands in terminal.
The best practise is to use declarative way rather than writing everything out repeatedly.
Control Plane Components:
The components decide on scheduling, create new pods when a requirement is not met, ensure that all pods are healthy, etc.
kube-apiserver: It is a control plane component that exposes the Kubernetes API. All the communication will happen via the API server. The API server configures the Kubernetes objects like pods, deployments, services, etc. We can interact with this API using kubectl, aka Kube control. The API server is the front end for the Kubernetes control plane. It is available on HTTPS/443.
etcd: It is a central database used to store all the cluster data. We can determine the state of the cluster by querying the etcd.
kube-scheduler: It continuously scans for any brand-new pods that have no assigned node and chooses the node based on the needs for resources, networking, and hardware/software policies, etc.
kube-controller-manager: It executes a control loop that keeps track of the cluster's shared state via the apiserver and makes adjustments to try to move the current state in the desired direction. If you use a cloud service provider, they will use their own control manager.
Types of controller managers include:
Node controller: It keeps an eye on the nodes and reacts when one of them goes down.
Job controller: It creates on one or more pods and keeps running until a predetermined number of them terminate successfully.
Endpoint controller: Joins the services and the pods.
Service Account & Token controllers: It creates default accounts and API access tokens for new namespaces.
Node components run on every node, maintaining running pods and providing the Kubernetes runtime environment.
kubelet: It runs on each node in the cluster and checks to see if the pod's containers are active and in good condition. It schedules, listens to the API server, and if it is unable to complete the task, it simply informs the control plane, which will handle it from there.
Container runtime: It is responsible for running the containers. Kubernetes supports container runtimes such as containerd, CRI-O, etc.
kube-proxy: It is a network proxy that runs on each node. It maintains the network-rule in the nodes and allows network communication of pods from inside and outside the cluster.
A fundamental scheduling component of Kubernetes. Our containers run within the pod. One or more containers can be found in pods. Although most pods just have one container, many will have several that collaborate closely to carry out a specific function.
- a unique IP address (which allows them to communicate with each other)
- persistent storage volumes (as required)
- configuration information that determine how a container should run.
Minikube: Use minikube if your system has limited resources and you want to run Kubernetes locally. It is useful for learning purposes. In minikube, there is only one node that serves as both a worker node and a control plane. The link for entire setup is here. See here
Kubeadm: A multi-node Kubernetes cluster can be built up using this real-time setup. However, you can use cloud-based VMs if you wish to use kubeadm but have limited resources. Installing kubeadm.
Cloud providers: Kubernetes management and operation services are offered by a number of cloud providers. Here, all of the resources are provided by the cloud; you just need to pay for the resources you use and the time you use them. Azure, Civo, GCE, AWS, and others are some examples of cloud service providers.
Playgrounds: These playgrounds can be used if you only wish to test Kubernetes without setting up a cluster. Some playground links:
Kubernetes manifest file:
Kuberentes objects can be declared in yaml or json, respectively. We include all the necessary information, including the sort of object we wish to build and the tasks we anticipate it performing, in this file. Check out my other blog to learn the full format of the Kuberentes manifest file.
- Check to see if kubectl is already installed on your machine.
$ kubectl version --output=yaml clientVersion: buildDate: "2022-06-15T14:22:29Z" compiler: gc gitCommit: f66044f4361b9f1f96f0053dd46cb7dce5e990a8 gitTreeState: clean gitVersion: v1.24.2 goVersion: go1.18.3 major: "1" minor: "24" platform: linux/amd64
- I'm using minikube for this demonstration. Let's launch Minikube now.
$ minikube start 😄 minikube v1.26.0 on Ubuntu 20.04 ✨ Using the docker driver based on existing profile 👍 Starting control plane node minikube in cluster minikube 🚜 Pulling base image ... 🔄 Restarting existing docker container for "minikube" ... 🐳 Preparing Kubernetes v1.24.1 on Docker 20.10.17 ... 🔎 Verifying Kubernetes components... ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5 🌟 Enabled addons: storage-provisioner, default-storageclass 🏄 Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default
- You can also check the status of Minikube.
$ minikube status
- We'll use this manifest file for the demonstration.
apiVersion: v1 kind: Pod metadata: name: nginx-pod labels: app: nginx spec: containers: - name: nginx-container image: nginx
- Deploy the pod
$ kubectl create -f pod.yaml pod/nginx-pod created
- To list all the pods
$ kubectl get pods NAME READY STATUS RESTARTS AGE nginx-pod 1/1 Running 0 2m37s
- To get more information about the pod
$ kubectl get pods nginx-pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx-pod 1/1 Running 0 3m45s 172.17.0.3 minikube <none> <none>
Get pod configuration in YAML format.
$ kubectl get pod nginx-pod -o yaml
Get pod configuration in JSON format
$ kubectl get pod nginx-pod -o json
This will provide the pod's details, including a list of all events from the moment the pod was sent to the node until the pod's present status.
$ kubectl describe pod nginx-pod
Expose pod using NodePort service
$ kubectl expose pod nginx-pod --type=NodePort --port=80 service/nginx-pod exposed
We can view the pods and other things using the Kubernetes dashboard.
$ minikube dashboard
This is how the dashboard will appear.
To view the running containers
$ docker container ls CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 941125036a70 gcr.io/k8s-minikube/kicbase:v0.0.32 "/usr/local/bin/entr…" 8 days ago Up 12 minutes 127.0.0.1:53567->22/tcp, 127.0.0.1:53568->2376/tcp, 127.0.0.1:53565->5000/tcp, 127.0.0.1:53566->8443/tcp, 127.0.0.1:53569->32443/tcp minikube
- To get cluster information
$ kubectl config view
To view a list of all the things currently in use
$ kubectl get all
Deleting the pod
$ kubectl delete pod nginx-pod pod "nginx-pod" deleted
- Stopping the minikube
These are a few of the resources that help us operate with Kubernetes more effectively.
Did you find this article valuable?
Support WeMakeDevs by becoming a sponsor. Any amount is appreciated!