Melissa Bafdel (Data Engineer at Expleo)
Expleo is a company that is involved in a wide range of activities in DevOps/MLops, and this article will focus on Kubernetes orchestrator and Rancher cluster Management.
In this article we will see three main points:
- Kubernetes and its management
- Rancher and how it works
- Example of kubernetes cluster architecture with Rancher at Expleo
Introduction
Microservices can be deployed very quickly with docker and can be replicated since they are all independent. However, how to manage all this manually if containers are scattered in a large number of machines? If there is a container that causes a problem, how to detect it? Which one would need more replications to support a sudden increase in load?
Kubernetes allows automating the deployment, the management of power demand, and the management of contained applications.
1. Kubernetes
Arrived in 2014 Kubernetes often abbreviated k8s, “K + 8 characters + s”, was born from the projectBorg and Omega. They were developed as purely internal systems to Google. In contrast, Kubernetes has now become a new open-source version with improved features to solve the old problems of cluster management and increased support from IBM, Cisco, and Redhat. Nowadays, the project is not owned by Google anymore; Google donated the Kubernetes project in 2015 to the newly formed Cloud Native Computing Foundation. [1]
Kubernetes architecture
The basic organizational unit in Kubernetes is the cluster. A cluster consists of several physical or virtual machines. A Kubernetes cluster has its own set of users, administrators, namespaces, storage resources and security settings. The cluster is the entity in which all distributed microserves-based applications will run.
The following figure represents the relation between the different components of a Kubernetes cluster :
Master node (Control plane)
Master node components provide the control plane for the cluster. Master components make global decisions about the cluster (e.g, scheduling), detect and respond to cluster events (e.g., start a new Pod ), and can be run on any machine in the cluster.
- kube-apiserver: it exposes the Kubernetes API. It’s the frontend for the Kubernetes control plane, which provides the interface to the shared cluster’s state through all other components.
- Etcd: it’s a consistent and highly available key-value database used as backup for all cluster data.
- kube-scheduler: this component monitors newly created pods that are not assigned to a node and selects a node on which to run them, depending on available resources.
- kube-controller-manager: its role is to execute the controllers. Each controller is a separate process. However, the controllers are compiled in a single binary and run in a single process to reduce complexity.
Worker node
Worker node components run on each node with worker role, keeping pods running and providing the environment.
- Kubelet: it’s an agent that runs on each cluster node. It interacts with the Master’s etcd database to retrieve information about the tasks to be performed. In addition, it assumes responsibility for keeping the containers in a pod in good working order and ensures that they are running according to the specification.
- kube-proxy: it’s a component that facilitates the implementation of Kubernetes networking services. The kube-proxy component manages network communications in and out of the cluster.
- Container Runtime: it’s the software used to run the containers. Kubernetes is compatible with several container runtime environments like Docker.
Kubernetes ressources
Kubernetes defines a set of tools that provide mechanisms for deploying, maintaining and scaling applications. These tools are designed to allow their combination and extension and thus enable various workloads.
It’s essential to know the Kubernetes object types and how to use them. Here are the main ones :
- Pods: It’s the basic unit of execution of a Kubernetes application and the smallest and simplest unit in the Kubernetes object model that one wants to create or deploy. A Pod encapsulates an application container (or in some cases, multiple containers), storage resources, a unique network identity (IP address), and options that control how the containers should run.
- Volumes: They are an abstraction that solves two problems, the loss of files when a container crashes and restarts. The second problem occurs when sharing files between containers running together in a Pod.
- Namespaces: are the unit for grouping resources to represent teams/projects and environments. They provide a scope for names. Resource names must be unique within a namespace, but not between namespaces. Namespaces cannot nest.
- Deployments: It provides declarative updates for Pods and ReplicaSets, and handles the rest of the pod lifecycle.
- ReplicaSets: this object maintains a stable number of Pods, to guarantee the availability of Pods.
- Secrets: They are used to manage and store sensitive data (configuration, ssh keys, login/password, etc.) and for technical configuration (connection to a registry, TLS certificates, etc.).
- ConfigMaps: They are managed in the same way as Secrets but are intended to present non-sensitive configuration data in key-value pairs.
- Services: a virtual grouping of pods with a particular label. Since resources are managed dynamically by Kubernetes, it is necessary to have an entry point to the microservices, as their addresses are not known a priori.
There are several ways to reach a service, according to techniques called:
- ClusterIP: It is the default service type in Kubernetes and this type gives a service inside the cluster and makes it accessible only from the cluster.
- NodePort: It exposes the service on each node’s IP address on a static port. The NodePort service type opens a specific port on all virtual machines to forward the traffic sent to that particular port to the service.
- LoadBalancer: It exposes the service externally. It allows to define an IP address for each service and redirects all requests to the service. Clusters coming from cloud infrastructure like Google Kubernetes Engine (GKE) or Azure Kubernetes Service integrate a LoadBalancer to their offer. However, in a Baremetal (On-premise) cluster, an installation is required. The LoadBalancer can support multiple protocols, such as HTTP, TCP and UDP, for example.
We can also use Ingress to expose services. Ingress is not a service type, but it serves as an entry-point for the cluster. It allows consolidation of routing rules into a single resource. It can expose multiple services under the same IP address with DNS names.
- Ingress: it exposes HTTP and HTTPS routes from outside the cluster to services within the cluster. Traffic routing is controlled by rules defined on the ingress resource. It can be configured to give services externally accessible URLs, external load balancing, SSL/TLS termination and name-based virtual hosting. An Ingress controller (runs like a reverse proxy) is responsible for running the Ingress. There are several (Traefik, Nginx, etc.), usually with a load-balancer. Ingress does not expose arbitrary ports or protocols. Exposing services other than HTTP and HTTPS to the Internet usually uses a NodePort or LoadBalancer service.
Communication with the Kubernetes cluster
There are several options like (python API, and Kubernetes dashboard…). However, The Kubectl command-line tool is most commonly used to communicate with the Kubernetes cluster. It serves to run commands on Kubernetes clusters to create and manage K8s objects, deploy applications, inspect and manage cluster resources, or view logs.
Installing Kubernetes
- Installing Kubernetes in a test environment: minikube installation is recommended for learning and development porpuses.
- Installing kubernetes in a production environment: there are different distribution of kubernetes dedicated to production, for example, kubeadm, microk8s and RKE (Rancher Kubernetes Engine).
2. Rancher
Between the management of resources, user rights, network rules, etc., managing a Kubernetes cluster is not an easy task. But things get even more complicated when deciding to deploy several clusters on different platforms (on-premise or cloud providers) for cost optimization or the deployment of sensitive applications.
Rancher is an open-source product designed to deal with these complex cases. It allows centralizing the creation, organizing, and management of several Kubernetes clusters via a graphical interface accessible from a web browser and/or an API. It offers us:
- The creation of Kubernetes clusters on different platforms
- Authentication and access rights
- Management and deployment of applications
- Log collection
- Monitoring of clusters and applications
How Rancher works
Rancher acts as a proxy to talk and interfere with the Kubernetes clusters it manages. The following schema shows the architecture and the communication between the different components of rancher [2]:
For example, to communicate with the cluster provisioned by RKE (the tool used to deploy a Kubernetes cluster from Rancher), the user first authenticates with Rancher’s Authentication Proxy component (1 on the diagram above). Then, its requests are passed to Rancher’s Server API (2), which is the hub for communicating with all Rancher components. Once the Rancher Server API has told the right Cluster Controller (3) the state to reach, knowing that each Cluster Controller is specific to a Kubernetes cluster, the Cluster Controller monitors the resources of the RKE cluster by interacting with its Cluster Agent (4). In case of changes, this one is responsible for applying them by interacting with the API Server (5) of the RKE cluster.
Deploying Rancher
To deploy Rancher, there are two ways:
- Deploying Rancher via Docker: this approach is only recommended for development and test environments.
- Deploying Rancher in high availability: Rancher is deployed on its Kubernetes cluster in this approach. It is the recommended method for a production environment.
3. Example of kubernetes cluster architecture with Rancher at Expleo
A simple architecture Rancher management cluster and three RKE lunched cluster on-premise/Cloud are shown below.
A Kubernetes cluster has been dedicated to the Rancher management server to Guarantee the Rancher server’s high availability, best performance, and security.
The following figure illustrates the list of Kubernetes clusters managed by Rancher on the UI. The local cluster is the one on which the Rancher instance is deployed.
In Expleo, we have set up different clusters, notably the ML cluster reserved for our data science activities. Then, we implemented an MLOps platform based on Kubeflow (Kubeflow Pipelines, Notebooks, KServing, etc.), presented in the following article.
