Managed Kubernetes Cluster Management

This article describes common operations for managing a Kubernetes cluster: adding and modifying worker groups, updating the Kubernetes version, and deleting the cluster. For each operation, it explains what will happen and how to verify the result.

If you haven’t created a cluster yet, start with the article “Creating and Configuring a Cluster”. To connect to the cluster and work with kubectl (the command-line tool for managing Kubernetes), see “Connecting to the Cluster and Working with kubectl”.

Cluster Dashboard

When you navigate to the created K8s cluster, the dashboard will open, a page providing an overview of the cluster’s status. 

The following are available here:

• Statistics – CPU load and RAM usage graphs for master nodes and worker groups
• Information – Kubernetes version and a “Connect” button for quick access to the kubeconfig. For more details, see the “Connecting to the Cluster” section
• Worker groups and nodes – number of nodes and their statuses
• Settings – number of master nodes, Kubernetes version, network parameters
• Add-ons – installed and available add-ons

Statistics

The “Statistics” section contains two tabs:

Groups and nodes:

• Worker group load – select a group using the selector
• Load by individual nodes – broken down by worker groups
• Number of pods in different statuses – broken down by namespace
• Number of container restarts – broken down by namespace

ControlPlane:

• CPU load on the master node
• RAM usage
• Disk utilization

Adding a Worker Group

A new worker group is needed when current resources are insufficient or when a different node configuration is required for a new type of workload.

Via the Control Panel

1. Go to the cluster dashboard → “Worker Groups and Nodes” tab
2. Click “Create New Group”
3. Set the group parameters: name, number of nodes, configuration, labels, and limits
4. Confirm creation

What happens

• Creation time – approximately 1–2 minutes per node. All nodes in the group are created simultaneously
• Pod scheduling – new pods will be automatically placed on the new nodes according to taints/tolerations policies
• Existing pods – remain on their current nodes and are not moved
• Impact on the cluster – adding a group does not affect the operation of existing nodes and pods

After the group is created, new nodes will appear in the cluster. You can verify this with the command:

kubectl get nodes

The new nodes must transition to Ready status.

Changing a Worker Group Configuration

You can modify the settings of an existing worker group: the number of nodes, labels, and taints.

Via the Control Panel

1. Go to the cluster dashboard → “Worker Groups and Nodes” tab
2. Click the edit icon (pencil) next to the desired group
3. Change the settings
4. Save the changes

Changing the number of nodes

Increasing – new nodes with the same configuration are added to the group. Existing pods continue to run without interruption.

Decreasing – pods are drained before nodes are removed. Pods are correctly migrated to other available nodes.

Changing node configurations (CPU, RAM, disk)

Node configuration supports in-place updates for the entire worker group:

• CPU and RAM – can be increased or decreased
• Disk – can only be increased

When the configuration is changed, pods are evicted from the node to apply the new settings. To avoid application downtime:

• Use more than one replica for each application
• Configure Pod Anti-Affinity so that replicas of the same application are not placed on the same node

Verifying the result

# Check the number and status of nodes
kubectl get nodes

# Check node labels
kubectl get nodes --show-labels

# Check node taints
kubectl describe node <node-name> | grep Taints

Updating the Kubernetes version

Updates are only possible to a newer version.

Via the control panel

1. Go to the cluster dashboard → “Settings” tab
2. In the “Kubernetes Version” space, select the target version
3. Confirm the update

Update process:

1. Master nodes are recreated, the version changes from the current one to the target version
2. After the control plane is successfully updated, the worker groups begin to update
3. Worker groups are updated sequentially, one group at a time
4. Within each group, nodes are updated one by one to minimize the impact on running applications

Release channel

A release channel is an update strategy that determines which Kubernetes version your cluster will be automatically upgraded to.

Three channels are available:

• Stable — upgrades to a version that is no more than two minor versions behind the latest available one. The most battle-tested option, with a lower risk of issues after an upgrade
• Balanced — upgrades to a version that is no more than one minor version behind. Newer than Stable, but with less risk than Latest
• Latest — upgrades to the most recent available Kubernetes version. New features arrive sooner, but the version is less proven

What a version number consists of

A Kubernetes version number has three parts — for example, 1.34.5:

• 1 — major version. Changes with fundamental changes to the product
• 34 — minor version. These releases add new features, promote existing options to stable (GA), or mark them as deprecated
• 5 — patch version. Fixes critical bugs and vulnerabilities without changing how things work

The release channel determines which minor version the cluster will be upgraded to. In addition, the cluster may be updated when new patch versions and internal platform versions are released — such updates do not change how things work.

How to change the release channel

1. Go to the cluster dashboard → the Settings card
2. In the Release channel field, select the option you need
3. Save the changes

Rules and limitations

• The Balanced channel is used by default — it provides the optimal version: recent enough, yet already proven
• The selected channel applies to subsequent updates — the current cluster version does not change when you switch channels
• Updates are performed according to the configured maintenance window
• The cluster is upgraded by no more than one minor version at a time

Maintenance window

The maintenance window determines when the platform may apply automatic cluster updates: Kubernetes patch versions, internal platform versions, and minor version upgrades within the selected release channel.

System update period

• Any time — updates are applied as soon as they become available
• Scheduled — updates are performed only within the window you specify. When Scheduled is selected, you configure:
  • Day of week — one or more days on which updates are allowed. The Any day checkbox allows updates on any day of the week
  • Time window — the start time and time zone. The window duration is fixed at 3 hours

How to change the maintenance window

1. Go to the cluster dashboard → the Settings card
2. In the System update period field, select Any time or Scheduled
3. For Scheduled, specify the days of the week, start time, and time zone
4. Save the changes

Recommendations

• Choose the hours when your services are under the lowest load: during an update, nodes are recreated one by one and pods are evicted to other nodes
• Keep more than one replica of your application and configure Pod Anti-Affinity so that updates go through without downtime
• A window that is too narrow (for example, one day a week) delays the installation of security fixes — keep this in mind when configuring it

Пара заметок: «Актуальный» перевёл как Latest (в GKE аналог — Rapid, но Latest понятнее), «В заданное время» — Scheduled. Если в интерфейсе уже есть английские названия полей, подгони под них.

Checking the Version

# API server version
kubectl version

# Kubelet version on nodes
kubectl get nodes

The VERSION column displays the kubelet version on each node. If the update is still in progress, different nodes may have different versions.

Add-ons

Add-ons are additional components that simplify the administration of Kubernetes clusters by adding monitoring, certificate management, network plugins, and other capabilities.

Managing Add-ons

1. Go to the cluster dashboard → “Add-ons” tab
2. The page displays a list of available add-ons with descriptions and statuses
3. To install, click “Install” on the add-on card
4. To view details or remove an add-on, click on the add-on card

Each add-on card includes:

• Description and purpose
• Components (which components are installed)
• Links to documentation

If you would like to suggest a new add-on, please contact technical support.

Deleting a Cluster

Via the Control Panel

1. Go to the cluster dashboard → “Settings” tab
2. At the bottom of the page, click “Delete Kubernetes Cluster”
3. Confirm the deletion

What Happens

When you delete a cluster, the following are deleted:

• All load balancers created via LoadBalancer-type services
• All worker group virtual machines
• Control plane nodes (master nodes)

Deletion occurs immediately.

All articles in this section

1. Kubernetes (K8s) – An Overview of the Managed Kubernetes Service
2. Kubernetes Basics – Key Concepts: Cluster, Nodes, Pods, Services
3. Creating and Configuring a Cluster – Master Node Configuration, Networking, and Worker Groups
4. Connecting to the Cluster and Working with kubectl – kubeconfig, Connectivity, and Core Kubernetes Tools
5. Cluster management – You are here
6. Networking and load balancers – network model, external and internal load balancers
7. Limits, quotas, and constraints – platform constraints, what can and cannot be changed

If you have any questions, please submit a ticket via the account dashboard (under “Help and Support”). And if you’d like to discuss this article or our products, we’d love to see you in our Telegram community.