Requirements

Infrastructure, license, network, resources.

Open loop requirements #

Requirements for administrator qualifications #

The administrator must have:

• basic Linux administration skills;
• skills in working with Kubernetes and automation processes for managing container applications in clusters.

Supported providers #

• Shturval v2 - bare metal / hosts via SSH
• oVirt (including zVirt, HostVM, ED Virtualization, ROSA Virtualization)
• VMware vSphere
• OpenStack (including Selectel, VK Cloud)
• Yandex Cloud

More details: How work with providers works.

Resource requirements #

The management cluster must consist of at least one Control Plane node. For fault tolerance - at least three Control Planes and three Workers.

When installing a management cluster on one Control Plane node, only services critical for the operation of the cluster are installed on it of the Shturval repository. Logging, monitoring and backup services are not installed in this configuration.

Note: A management cluster consisting of only one Control Plane node is not recommended for production, because does not provide fault tolerance. However, if necessary, you can deploy up to 5 client clusters on it.

The license package of the platform specifies a limit on the number of Worker nodes or vCPUs. When the limit is exceeded, a notification is displayed on the GUI screens.

When resources are loaded over 80% it is recommended to add nodes. By default, system metrics are stored for 7 days; system logs are rotated according to their content. User logs and metrics are not collected by default.

Minimum configuration (Only 1 Control Plane node) {#minimum-configuration-only-1-Control Plane-node} #

For test installations only

Minimum recommended configuration (1 CP + 3 Workers) #

Not recommended for production installations

Fault-tolerant configuration (3 CP + 3 Worker) #

Stand-alone cluster (without client clusters) #

The mode in which management cluster is used for workloads as well. For more information about the mode, see the section Management cluster operating modes.

Machine resources shtil #

For installation you will need the shtil utility. Downloading and working with the utility is described in the preparation for installation section. Machine shtil: the shtil utility must be run from a host with Linux OS. Minimum free resources: 3 vCPU, 3 GiB RAM, 20 GiB disk. The shtil machine must have Docker or Podman installed (see Preparation).

Supported operating systems for the shtil startup machine #

The shtil utility for installing a management cluster is launched from a separate machine. The following OS are supported:

Requirements for hosts and OS #

Supported operating systems #

All cluster nodes must use the same kernel OS version.

Required packages on nodes: openssh-server and dependencies, package manager (yum or apt), sudo, iptables, gnupg.

Infrastructure: physical servers of x86 architecture using pre-provisioned hosts. For infrastructure provider oVirt and similar versions no lower than 4.4. For infrastructure provider VMware vSphere (hypervisor no lower than 6.7 update 3).

Cluster nodes #

• Nodes must resolve the FQDN image repository r.shturval.tech and other network names used by the selected script.
• SELinux — mode permissive or disabled.
• Inaccessible OS package repositories should be disabled or removed.
• For the Linux user on whose behalf theinstallation (for example, /home/shturval), a home directory must be created.
• The installation user runs sudo without a password on all target nodes. For the Shturval v2 provider, the password can be set in the installation wizard or passed from the console — see SSH user password for sudo. Without a password, the installer works as before.

More details about settings and checks (see Preparation)

Remote access via SSH during installation on pre-created hosts #

Each server must have:

1. The OpenSSH service accepts connections on port TCP 22.
2. An identical service account for installation was created on all nodes.
3. Authentication using the same public key is configured on all nodes.
4. The service account is allowed to run sudo without a password. If sudo asks for a password, set User password during installation — see SSH user password for sudo.

Local storage #

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

Network requirements #

Firewalls should not block connections required by platform components.

Main ports #

LDAP, OIDC (Keycloak, Blitz): can be located in the external perimeter or in the cloud if the security policy allows it.

S3 (Velero): can be cloud or internal S3-compatible storage.

Addressing and access rules #

1. IP addresses of nodes do not change during cluster operation.
2. Machine shtil and all cluster nodes must have direct outgoing access to r.shturval.tech:443.
3. Management cluster must have access to the API of the infrastructure providers used (oVirt Engine, vCenter, etc. - according to the deployment scenario).

Control Plane subnet and virtual IPs (VIPs) #

The IP addresses of the Control Plane nodes must belong to the same subnet and the same broadcast segment. When using internal balancers for KubeAPI and Ingress, one free VIP is required for each.

If external balancers are used for KubeAPI and/or Ingress, VIP allocation is not required. Requirements and exampleThe external balancer settings are shown below.

Additional rules for domestic VIP:

1. VIP should not be configured on host interfaces prior to installation.
2. The VIP for the API server must belong to the same subnet as the IP addresses of the Control Plane nodes.
3. VIP for Ingress is used on the network load balancer.
4. For a management cluster with one Control Plane, IP addresses must be assigned in ascending order: first the node IP address, then the VIP API server, then the VIP Ingress.

External load balancer #

When deploying a cluster with multiple Control Plane nodes, KubeAPI requires a load balancer. The platform can use a built-in (VIP via Kube-VIP) or external balancer.

An external load balancer is also used for Ingress when traffic must go through a common entry point such as HAProxy in front of the cluster.

Requirements:

1. Balancing is performed at level L4 (TCP).
2. The balancer must support maintaining host selection by source IP address (sticky session / source IP affinity), for example balance source in HAProxy.
3. An external balancer for KubeAPI when installing a cluster with the Shturval v2 provider must be configured before the start of the cluster installation.

HAProxy configuration example (static configuration) {#haproxy-configuration example-static-configuration} #

#---------------------------------------------------------------------
# myclustername cluster
#---------------------------------------------------------------------

frontend myclustername-api-server
    bind 10.11.12.100:6443
    default_backend myclustername-api-server
    mode tcp

backend myclustername-api-server
    balance source
    mode tcp
    server master1 10.11.13.1:6443 check
    server master2 10.11.13.2:6443 check
    server master3 10.11.13.3:6443 check

frontend myclustername-ingress-http
    bind 10.11.12.100:80
    default_backend myclustername-ingress-http
    mode tcp
    option tcplog

backend myclustername-ingress-http
    balance source
    mode tcp
    server worker1 10.11.13.4:80 check
    server worker2 10.11.13.5:80 check

frontend myclustername-ingress-https
    bind 10.11.12.100:443
    default_backend myclustername-ingress-https
    mode tcp
    option tcplog

backend myclustername-ingress-https
    balance source
    mode tcp
    server worker1 10.11.13.4:443 check
    server worker2 10.11.13.5:443 check

Dynamically adding backends (CoreHA) #

The shturval-coreha module allows HAProxy to dynamically obtain a list of nodes from the Ingress Controller via DNS. This is useful when scaling or migrating pods.

Setting up CoreHA:

1. Install and enable Module for searching for nodes with running hostport services (shturval-coreha) in the Services andrepositories.
2. Configure chart parameters, for example:

   config:
     zoneName: cluster-prod01-dc1.shturval
   

3. Apply ShturvalServicePatch to shturval-ingress-controller with label ingress.cluster/name and hostPort enabled.
4. In HAProxy use resolvers and server-template:

resolvers coredns-cluster
    nameserver ns1 <api-server-vip>:1053
    accepted_payload_size 8192

backend cluster-prod01-dc1-ingress-http
    balance source
    mode tcp
    server-template daemonset 2 <label_value>.ingress.<zoneName>:80 check resolvers coredns-cluster init-addr none

Where <api-server-vip> is the address of the cluster API server, <zoneName> is the value of config.zoneName in shturval-coreha, <label_value> is the value of the ingress.cluster/name label.

Check: dig @<api-server-vip> -p 1053 <label_value>.ingress.<zoneName>.

Ports and traffic directions #

When using CoreHA, the balancer connects to the module’s DNS server on port 1053 (VIP Control Plane) to dynamically resolve backend names.

By provider #

DNS and network names #

• Each cluster node must have a unique network name.
• The full network name of the host must be a valid DNS name no longer than 63 characters.
• The cluster name must be unique in combination with the organization’s DNS zone and form a valid DNS subdomain.
• A zone must be created in the DNS; For each cluster node, a record of type A must be created in this zone.
• An A-record of the form api.<cluster_name>.<base_domain> is created for the management cluster API server.
• A wildcard record of the form *.<cluster_name>.<base_domain> is created for the Ingress of the management cluster.

Firewalls should not block network connections. This is required to support interaction between platform components.

In the matrices below, Registry is the image repository of r.shturval.tech (HTTPS, 443), unless otherwise noted.

Internetworking schemes #

Shturval v2 with internal balancer for KubeAPI and external balancer for Ingress and CoreHA for client cluster #

Shturval v2 with internal balancer for KubeAPI and external balancer for Ingress #

Shturval v2 with internal balancer for KubeAPI and Ingress #

Shturval v2 with external balancer for KubeAPI and Ingress #

Shturval v2 stand-alone cluster with internal balancer for KubeAPI and Ingress #

Shturval v2 stand-alone with internal balancer for KubeAPI and external for Ingress #

Shturval v2 DR platform with internal balancer for KubeAPI and external for Ingress #

oVirt, VMware vSphere with internal balancer for KubeAPI and external for Ingress #

oVirt, VMware vSphere with internal balancer for KubeAPI, external for Ingress and CoreHA in client cluster #

oVirt, VMware vSphere with internal balancer for KubeAPI and Ingress #

OpenStack and Yandex Cloud with external balancer for KubeAPI and Ingress #

Additional requirements #

Browser requirements #

Recommended monitor resolution: 1498×906.

Supported #

Browsers from which the GUI is not available #

• IE;
• Opera Mini;
• UC Browser for Android;
• QQ Browser;
• Baidu Browser;
• KaiOS Browser;
• Opera Mobile;
• Android Browser;
• Firefox for Android;
• Samsung Internet Browser;
• Safari on iOS.

Once you have read the requirements, proceed to the Preparation section.