What is Kubernetes
Today, I will be discussing what I learned about Kubernetes this week. I have been exploring Kubernetes in preparation for junior roles in the dev operations companies. Kubernetes is an orchestrator for containerized applications. Kubernetes is greek for “helmsman” and came out of Google. Kubernetes was donated to the Cloud Native Computing Foundation in 2014. Kubernetes is written in Go and is an open source project.
Monoliths vs. Microservices
Monoliths and microservices are two differing ways of structuring applications. Monolithic applications are the traditional way of building applications. Monolithic applications are one single large code base. These application are single, indivisible units and lack modularity. On the other hand, applications can be broken down into microservices. Each microservice has its own logic, database, and carries out a different service. Each service can be updated and deployed without affecting the project as a whole. These microservices are loosely coupled and communicate to comprise a larger application.
Containerizing Microservices
The microservices are hosted in a container. A container is an environment where the microservice can run as a self-contained process with all the libraries and settings it needs. Containerizing microservices allows for portability, reproducibility and scalability. Programs such as Docker are a container engine that allows us to run containerized microservices. A container image is a collection of filesystem information and execution parameters for use within a container runtime. A container is then the runtime instance of an image.
Kubernetes serves as the orchestrator of containerized microservices. The goals of kubernetes are to distribute containers in a logical and efficient way, to scale up or down fast, to keep processes running continuously and healthy, and to give us the power to choose what processes are run.
Kubernetes Architecture
Big Picture View
The orchestration of various microservices under Kubernetes form a Kubernetes cluster. A Kubernetes cluster is made of one or more masters and. a bunch of nodes. The masters make up the Kubernetes control plane. The nodes do the work of running the microservices and the overall application in the big picture. The application is containerized and sent to the Kubernetes cluster. Application is defined in an object called a deployment. The deployment is a .yaml manifest that tells Kubernetes what the application should look like.
Masters
Masters run typically run on a single server. The masters are free of user workloads for the application. The master has four main components: kube-apiserver, cluster store, controller manager, and kube-scheduler. The kube-apiserver is the front end of the control plane, it exposes a RESTful API and consumes JSON. The cluster store serves as persistant storage for the master and stores state and configuration. The controller manager manages several controllers and watches for changes. The controller manager helps to maintain desired state.
The apiserver is the only master component that exposes an API endpoint. The api server is given a manifest file that describes how we want the cluster to look and feel. The manifest file constitutes the desired state. Anytime the actual state differs from the desired state, Kubernetes acts until the actual state matches the desired state.
Nodes
The nodes are the Kubernetes workers. Nodes consist of three parts: kubelet, container engine, kube-proxy. The kubelet is the main agent of the node. The kubelet registers the node with the cluster, watches the apiserver, instantiates pods, reports back to the master, and exposes an endpoint for inspection. The container engine talks to the container runtime. The container engines manages container activity by pulling images and starting and stopping containers. The kube-proxy serves the network brains. The kube-proxy sets up pod IP addresses and load balances.
Pods
In Kubernetes, the atomic unit is the pod. A pod is an environment where containers run. Containers always run in pods. Pods can have multiple, tightly coupled containers. All containers in a pod share an environment. Pods either are up running or are down. For example, a pod with multiple containers can not have one container running and one container down. A pod is mortal as it is born, runs and then dies. A replication controller takes a pod and adds features around them. A replication controller deploys multiple replicas of a single pod definition.
A deployment object takes the replication controller further adding features to it. Deployment objects are self documenting, versioned and spec’d once to allow for multiple deployments. Deployment objects allow for simple rolling updates and rollbacks. Deployments are defined in the manifest .yaml file sent to the apiserver.
Services
In Kubernetes, every newly instantiated pod gets a new IP address. A service object provides a stable IP address for communication between the front-end and the back-end for the application. The service object updates itself and keeps the same IP and DNS when pods are changed. Also, the service object allows for load balances. Labels allow for services to be tied together with pods. This can be very useful for controlling which pods are tied to a service when versions are updated.
In conclusion, this blog post serves as an introduction to what Kubernetes is and what some of the inner workings of Kubernetes are. I would like to acknowledge the getting started with Kubernetes course by Nigel Poulton on Plural Sight and the Kubernetes comic by Google.
