{product-title} assigns hosts different roles. These roles define the function of the machine within the cluster. The cluster contains definitions for the standard master and worker role types.
|
Note
|
The cluster also contains the definition for the bootstrap role. Because the bootstrap machine is used only during cluster installation, its function is explained in the cluster installation documentation. |
In a Kubernetes cluster, the worker nodes are where the actual workloads requested by Kubernetes users run and are managed. The worker nodes advertise their capacity and the scheduler, which is part of the master services, determines on which nodes to start containers and Pods. Important services run on each worker node, including CRI-O, which is the container engine, Kubelet, which is the service that accepts and fulfills requests for running and stopping container workloads, and a service proxy, which manages communication for pods across workers.
In {product-title}, MachineSets control the worker machines. Machines with the worker role drive compute workloads that are governed by a specific machine pool that autoscales them. Because {product-title} has the capacity to support multiple machine types, the worker machines are classed as compute machines. In this release, the terms "worker machine" and "compute machine" are used interchangeably because the only default type of compute machine is the worker machine. In future versions of {product-title}, different types of compute machines, such as infrastructure machines, might be used by default.
In a Kubernetes cluster, the master nodes run services that are required to control the Kubernetes cluster. In {product-title}, the master machines are the control plane. They contain more than just the Kubernetes services for managing the {product-title} cluster. Because all of the machines with the control plane role are master machines, the terms master and control plane are used interchangeably to describe them. Instead of being grouped into a MachineSet, master machines are defined by a series of standalone machine API resources. Extra controls apply to master machines to prevent you from deleting all master machines and breaking your cluster.
|
Note
|
Use three master nodes. Although you can theoretically use any number of master nodes, the number is constrained by etcd quorum due to master static Pods and etcd static Pods working on the same hosts. |
Services that fall under the Kubernetes category on the master include the API server, etcd, controller manager server, and HAProxy services.
| Component | Description |
|---|---|
API Server |
The Kubernetes API server validates and configures the data for Pods, Services, and replication controllers. It also provides a focal point for cluster’s shared state. |
etcd |
etcd stores the persistent master state while other components watch etcd for changes to bring themselves into the specified state. |
Controller Manager Server |
The Controller Manager Server watches etcd for changes to objects such as replication, namespace, and serviceaccount controller objects, and then uses the API to enforce the specified state. Several such processes create a cluster with one active leader at a time. |
Some of these services on the master machines run as systemd services, while others run as static Pods.
Systemd services are appropriate for services that you need to always come up on that particular system shortly after it starts. For master machines, those include sshd, which allows remote login. It also includes services such as:
-
The CRI-O container engine (crio), which runs and manages the containers. {product-title} {product-version} uses CRI-O instead of the Docker Container Engine.
-
Kubelet (kubelet), which accepts requests for managing containers on the machine from master services.
CRI-O and Kubelet must run directly on the host as systemd services because they need to be running before you can run other containers.