Requirements

What to prepare on the workload cluster nodes before and during creation in the platform GUI.

Here are the requirements for client (workload) clusters - Kubernetes clusters that are created in an already installed platform. Requirements for installing a management cluster (platform installation) are described separately: open loop and closed loop.

Node model and providers #

Whether nodes come from ready hosts or from VMs/instances created from an image or template prepared for the platform determines what you configure manually before cluster creation. The general scheme is on Creating nodes when deploying a client cluster.

The following providers are supported in the cluster creation wizard: Shturval v2, oVirt and virtualization analogues, VMware vSphere, OpenStack (including VK Cloud, Selectel), Basis Dynamix, VMware vCloud Director, Yandex Cloud. For all except Shturval v2, nodes are created by the platform from an image or template that has undergone uniform preparation by the stc utility according to the instructions Preparing a provider template; environment and network features - in the column below and on the How to deploy a cluster tabs.

The requirements below are formulated for all nodes of the client cluster. If the item applies only to Shturval v2 hosts or only to the path image/template after stc, this is clearly marked.

For hybrid clusters (the main provider is a VM from the template, nodes with GPUs are Shturval v2 hosts), the requirements for VMs and hosts are applied separately to the corresponding groups; the order of connecting Shturval v2 is in Hybrid clusters.

Client cluster resource requirements #

Minimum: 1 Control Plane + 1 Worker. For fault tolerance: 3 Control Plane + 2 Worker.

* WL - resources for workload applications. If there is no Infra Worker: 16 + WL vCPU for Worker.

** Logs and metrics from the client cluster are sent to the management cluster and are not stored locally on the infra node, so the infra node disk typically uses about 20 GiB. 100 GiB is the minimum with reserve for container images, log buffers, and local volumes of infra services. Plan additional local storage for user workloads separately.

Check: in the hypervisor, cloud console or on the host, check the allocated vCPU/RAM/disk with the table; if nodes are created from an image/template (all providers except Shturval v2), resources can often be overridden in the cluster creation wizard - see your provider tab in How to deploy a cluster and provider table; they must not be below the specified minimums. IOPS estimate based on storage capabilities or VM/instance storage policy.

The values in the table above are minimums for production clusters with dozens of worker nodes. For test and small clusters (several nodes, without significant user load), smaller configurations are acceptable - see below.

Minimal (test) configuration #

Only for test and demo clusters without significant user load.

With this configuration, the limiting resource is memory: on test benches, Control Plane and Infra nodes reach 68–75% RAM even without user load. For any real workload, use the main table above.

Supported operating systems #

All cluster nodes must use the same kernel OS version.

Infrastructure (where nodes can run): physical x86 architecture servers and/or virtual machines/cloud instances. For oVirt and VMware vSphere, the documentation usually indicates environment versions no lower than 4.4 (oVirt) and 6.7 update 3 (ESXi); for other providers, infrastructure requirements are on the provider tabs in How to deploy a cluster and in table above.

Local storage #

RawFile Provisioner is used as local storage; ZFS is not supported. Valid file systems: ext4, btrfs, xfs.

External load balancer #

When using an external balancer:

1. Balancing - at level L4.

2. The balancer must support savingBinding a session to an end node by source IP address.

3. An external balancer for the API server when deploying a cluster with the Shturval v2 provider must be configured before the start of creating a cluster (including the client one). More information about the node model - How to deploy a cluster - Shturval v2.

Details and example settings are in the requirements for open loop and closed loop.

Administrator qualifications #

The administrator must have:

• basic Linux administration skills;

• skills in working with Kubernetes and automation processes for managing container applications in clusters.

Network traffic diagrams and matrices #

Detailed diagrams and tables of traffic directions (including the interaction of the management cluster and client cluster) remain in the Internetworking Diagrams section of the platform installation requirements:

• Open contour - anchors of the form #capsm-v2-…, #capov-capvs-…, #capos-external-kubeapi-external-ingress-public-cloud, etc.

• Closed loop - the same scenario identifiers; public cloud scenarios (#capos-external-kubeapi-external-ingress-public-cloud) only apply to open loop.

General ports and rules for configuring loop firewalls are in the “Network Requirements” sections on the open and closed loop pages.

Requirements for DNS and network names #

• Cluster node - unique network name; valid DNS name no longer than 63 characters (when creating nodes from an image or template by the platform the name can be assigned automatically - nuances for a specific provider, see provider table).

• The name of each cluster is unique in combination with the organization’s domain zone.

• In DNS: one zone; for each node - a record of type A in this zone; for Ingress - wildcard *.<cluster_name>.<base_domain>.

• Hostnames, VIP and FQDN API/Ingress client cluster must resolve to IP addresses on the hosts. In a closed loop the FQDN of the mirror must also be resolved (for loading images).

Requirements for IP addresses and VIP #

• IP addresses of nodes do not change during operation; replacing a node - removing it from the cluster and adding it with a new address.

• All Control Plane nodes of the client cluster - one subnet and one broadcast segment.

• Without external balancers, KubeAPI and Ingress require two free VIP not assigned to node interfaces before installation.

• With one Control Plane: node address, then VIP API, then VIP Ingress - ascending addresses.

See also IP pools and FQDN and VIP.