Kubernetes in Testing
Helping a new user to understand Kubernetes with intent to deploy Selenium Grid using Kubernetes
Objective
The aim of this story is to get familiar with basic kubernetes terms so that one can work, troubleshoot with kubernetes with the aim of deployment a Selenium Grid setup on Kubernetes.
What is Kubernetes?
Kubernetes (K8s) is an open-source system for automating deployment, scaling, and management of containerized applications.
Back in 2014, Google open sourced the project it was using to manage its deployments. It came up to be the largest project for container management. With its 15+ years of experience, google have implemented the industries best practices and the several ideas on the problems faced by them in day to day practices.
Kubernetes Architecture
A high level architectural view is represented below :
Kubernetes Contains following components :-
Kubernetes master, consisting of a Scheduler, API Server, Controllers and etcd.
Kubernetes Nodes, consisting of a Kubelet, Kube-Proxy and Pods.
Let us now quickly understand the roles and responsibility of each one of them.
Understanding Kubernetes Master
Master acts as a Manager of the nodes. It controls all the nodes and is responsible to send the commands to the nodes about what it needs to do. It acts as a place for user to interact with kubernetes.
We can interact with Kubernetes using Kubernetes API server through command line tools “kubectl”. We need to hit an exposed REST API through the JSON requests on Kube API server to get our task done.
Master keep the information all the available nodes on the component called etcd. If you are from the Linux background, etcd is not something new you have heard. This is similar to what we have in linux. “etcd” is a strongly consistent, distributed key-value store that provides a reliable way to store data that needs to be accessed by a distributed system. If you are not from linux background, consider it similar to you system windows registry with all the details of the nodes.
In Kubernetes, controllers are control loops that watch the state of your cluster(current state), then make or request changes where needed(desired state). for example, a thermostat in a room:-
When you set the temperature, that’s telling the thermostat about your desired state. The actual room temperature is the current state. The thermostat acts to bring the current state closer to the desired state, by turning equipment on or off.
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
Let us not worry of the controllers yet, it was more of a theoretical thing, for now we should just keep in mind that when we need to change the state to our desired state, we would require a controller.
A scheduler watches for newly created Pods that have no Node assigned. For every Pod that the scheduler discovers, the scheduler becomes responsible for finding the best Node for that Pod to run on. The scheduler reaches this placement decision taking into account the scheduling principles described below.
Understanding Kubernetes Nodes
Nodes are the place where the actual job will be performed. All what we have specified in Master will actually be executed on the Node. Master will command the nodes to do the tasks we will specify in the manifest file(YML or JSON)
The kubelet is the primary “node agent” that runs on each node. Kubelet ensures that the containers described by master are running and healthy. It just report the health status for the healthy or a damaged pods, it will not take action to repair the damage.
Kube-Proxy acts as a network manager for Pods. It helps in connection forwarding and other network rules on the pods.
Pods are the smallest deployable units of computing that can be created and managed in Kubernetes. A Pod encapsulates an application’s container (or, in some cases, multiple containers), storage resources, a unique network identity (IP address), as well as options that govern how the container(s) should run. A Pod represents a unit of deployment: a single instance of an application in Kubernetes, which might consist of either a single container or a small number of containers that are tightly coupled and that share resources.
We would require a container runtime to run a pod. the most common container runtime used with kubernetes is Docker.
Pods are atomic, if it dies, it will not wait for a crashing pod to recover. The another pod will be created instantly, as defined in controllers.
So Once we have a basic structure in mind, we can move forward to the concept in action.
After knowing the above concepts, we can move to deploy Kubernetes on the local servers or on the cloud, so let us brush up these concepts and move for the deployments.(Article Coming soon for local Selenium grid deployments)
