Kubernetes is a powerful open-source system initially developed by Google for containerized application management in a clustered environment. It aims to provide better ways to manage related and distributed components and services across multiple infrastructures.
In this guide, we will discuss some basic Kubernetes concepts. Let’s talk about the system architecture, the problems it solves, and the model it uses to handle container deployments and scalability.
What is Kubernetes?
Kubernetes, at its most basic level, is a system for running and coordinating container applications across a cluster of machines. It is a platform designed to fully manage the cycle of containerized applications and services using methods that provide predictability, scalability, and high availability.
As a Kubernetes user, you can define how your applications should run and the ways they should be able to interact with other applications or the outside world. You can scale your services up or down, perform seamless upgrades elegantly, and swap traffic between different versions of your applications to test resources or roll back problematic deployments. Kubernetes provides combinable platform interfaces and primitives that allow you to define and manage your applications with a high degree of flexibility, power, and reliability.
To understand how Kubernetes is able to deliver these features, it is helpful to have a sense of how it is designed and organized at a high level. Kubernetes can be viewed as a layered system, with each higher layer abstracting from the complexity found at the lower levels.
At its base, Kubernetes brings together individual physical or virtual machines in a cluster using a shared network to communicate between each server. This cluster is the physical platform where all Kubernetes components, resources, and workloads are configured.
Each of the cluster machines is given a role within the Kubernetes ecosystem. A server (or a small group in high availability deployments) acts as the master server. This server acts as a gateway and brain to the cluster, exposing an API to users and clients, checking the health of other servers, deciding how best to split and assign work (known as scheduling), and orchestrating communication between other components. The master server acts as the first point of contact with the cluster and is responsible for most of the centralized logic that Kubernetes provides.
The other machines in the cluster are referred to as nodes: servers responsible for accepting and running workloads using local and external resources. To aid in isolation, management, and flexibility, Kubernetes runs containerized applications and services, so each node must be equipped with the container runtime (such as Docker or rkt). The node receives work instructions from the master server and creates or destroys containers accordingly, adjusting network rules to properly route and route traffic.
As mentioned above, the applications and services themselves are running in the cluster within containers. The underlying components make sure that the desired state of applications matches the actual state of the cluster. Users interact with the cluster by communicating with the main server API, either directly or through clients and libraries. To start an application or service, a declarative plan is submitted in JSON or YAML defining what to create and how it should be managed. The master server then takes the plan and finds out how to execute it on the infrastructure by examining the requirements and the current state of the system. This user-defined application group, running according to a specified plan, represents the final layer of Kubernetes.
Master Server Components
As described above, the master server acts as the primary control plan for Kubernetes clusters. It serves as the primary point of contact for administrators and users, and also provides many systems throughout the cluster for relatively unsophisticated work nodes. In general, components on the master server work together to accept user requests, determine the best ways to schedule workload containers, authenticate clients and nodes, tune the entire cluster network, and manage scalability and verification responsibilities. Cheers.
These components can be installed on a single machine or distributed across multiple servers. Let’s take a look at each individual component associated with the master server in this section.
One of the key components Kubernetes needs to function is a globally available configuration store. The etcd project, developed by the CoreOS team, is a lightweight, distributed key-value store that can be configured to span multiple nodes.
Kubernetes uses etcd to store configuration data that can be accessed by each of the nodes in the cluster. This can be used for service discovery and can help components configure or reconfigure according to up-to-date information. It also helps maintain cluster state with features such as leader election and distributed locking. By providing a simple HTTP / JSON API, the interface for setting or retrieving values is very straightforward.
Like most other components in the control plan, etcd can be configured on a single master server or, in production scenarios, distributed across multiple machines. The only requirement is that it must be network accessible to each of the Kubernetes machines.
One of the most important services of the master server is the API server. This is the main point of contact for the entire cluster, as it allows a user to configure Kubernetes workloads and organizational units. He is also responsible for making sure the etcd storage and service details of the deployed containers match. It acts as a bridge between various components to maintain cluster health and disseminate information and commands.
The API server implements a RESTful interface, which means that several distinct tools and libraries can readily communicate with it. A client named kubectl is available as a standard method of interacting with the Kubernetes cluster from a local computer.
The controller manager is a general service that has many responsibilities. First, it manages different controllers that regulate the state of the cluster, manages the workload life cycle, and performs routine tasks. For example, a replication controller ensures that the number of replicas (identical copies) defined for a pod matches the number currently deployed in the cluster. Details of these operations are recorded in etcd, where the controller manager observes changes through the API server.