Service architecture

The VK Cloud platform is based on OpenStack. The Cloud Containers service architecture, based on OpenStack, gives users a wide range of capabilities, fault tolerance, scalability and integration with other services of the platform.

A Kubernetes Cloud Containers cluster consists of two types of nodes, master nodes and worker nodes:

• Master nodes store cluster-wide state information and manage workload distribution across worker nodes.

• Worker nodes perform the workload (workload). They can be organized into groups of worker nodes. Place groups in different availability zones to improve fault tolerance.

Cluster high availablity depends on the number of master nodes. Possible configurations:

• Cluster with one master node.

  Such a cluster is not high available: even if there are several worker nodes and they are organized in groups, the cluster will become inoperative if the single master node is lost.

• A cluster with an odd number of master nodes (at least three).

  Such a cluster is high available: if several master nodes are lost, it will remain operational as long as there is at least one working master node. The further level of fault tolerance depends on the number and configuration of groups of worker nodes.

Regardless of the cluster topology chosen, the master nodes use distributed key-value storage etcd to store information about the state of the cluster:

• A cluster with one master node has one instance of etcd.
• Clusters with multiple master nodes have multiple instances of etcd running in cluster mode for high availability.
• Each etcd instance has a dedicated high-performance SSD disk (High-IOPS). This allows for the fastest possible interaction with the cluster API endpoint with minimal latency.

For high availability at the worker node level, it is recommended to create several groups of worker nodes in different availability zones and place application replicas on these nodes so that the replicas are also in different availability zones.

The following operating systems are used on the master and worker nodes:

• CentOS (up to Kubernetes 1.20).
• AlmaLinux (starting with Kubernetes 1.21). AlmaLinux is a fork of CentOS.

The cluster runs containers via Kubernetes Container Runtime Interface (CRI) with CRI-O (starting with Kubernetes version 1.20).

See Available Kubernetes versions and version support policy for details.

All interaction with the cluster is through the Kubernetes API.

The Cloud Containers cluster API endpoint is placed behind dedicated load balancer, so the cluster API can be accessed via the same IP address regardless of the number of master nodes.

Integration with the VK Cloud platform is achieved through standard Kubernetes interfaces:

• Container Storage Interface (CSI): integration with storage services.

  Allows to use Cloud storage in clusters as persistent volumes. Persistent Volume Claim (PVC) is available.

  Integration is achieved using OpenStack Cinder API. See Storage in cluster for details.

• Container Network Interface (CNI): integration with network services.

  Every Cloud Containers cluster has a Calico plugin that supports this interface. This plugin provides:

  • network connectivity between containers, pods, and cluster nodes;
  • application and enforcement of Kubernetes network policies.

  Calico integrates with VK Cloud platform using OpenStack Neutron API. See Network in cluster for details.

Pods can access various information and components of a Kubernetes cluster. With certain settings, pods themselves and the Kubernetes cluster in which they run can be vulnerable to attacks.

Since Kubernetes version 1.21, Open Policy Agent Gatekeeper is built into the cluster to increase the cluster's resistance to attacks. It allows you to apply constraints, which help to increase the security of deployed workload.

These constraints are created based on constraint templates. Cloud Containers clusters already contain preconfigured templates and constraints. You can create your own templates and constraints.

For clusters below version 1.21 it is recommended to install Gatekeeper manually or upgrade the cluster to the current version.

The Cloud Containers cluster has built-in scaling capabilities for master nodes and worker nodes.

Automatic scaling is also supported: if it is configured, the number of worker nodes in the cluster is automatically adjusted depending on the needs of the workload.