[Yandex Cloud documentation](../../index.md) > [Yandex Managed Service for Kubernetes](../index.md) > Concepts > Resource relationships

# Resource relationships in Managed Service for Kubernetes


[Kubernetes](https://kubernetes.io/) is a containerized application management system. Kubernetes provides tools for working with clusters to automate deployment, scaling, and management of applications in containers.

The main entity Kubernetes operates is a _Kubernetes cluster_.

## Kubernetes cluster {#kubernetes-cluster}

Kubernetes clusters consist of a master and one or multiple node groups. The master manages a Kubernetes cluster. Containerized user applications run on nodes.

Kubernetes fully manages the master and monitors the state and health of node groups. Users can manage nodes directly and configure Kubernetes clusters using the Yandex Cloud management console and the Managed Service for Kubernetes CLI and API.

Kubernetes clusters in the Yandex Cloud infrastructure use the following resources:

Resource | Quantity | Comment
--- | --- | ---
Subnet | 2 | When creating a cluster without [tunnel mode](network-policy.md#cilium), Managed Service for Kubernetes reserves two subnets: for pods and services. For a cluster with tunnel mode, subnets in the address space of the cloud network are not reserved.
Public IP address | N | The number of IP addresses may vary depending on whether you are using [public access](network.md#public-access-to-a-host) in the cluster.

{% note info %}

To connect to external resources, e.g., Docker image registries such as [Container Registry](../../container-registry/concepts/index.md), [Cloud Registry](../../cloud-registry/concepts/index.md), or [Docker Hub](https://hub.docker.com/) as well as [Object Storage buckets](../../storage/concepts/bucket.md), the group nodes must have internet access.

To enable internet access, [assign](../operations/node-group/node-group-update.md#node-internet-access) a public IP address to the nodes and [configure](../operations/connect/security-groups.md#rules-internal-nodegroup) a security group. As an alternative to public IP addresses, you can also create and configure a [NAT gateway](../../vpc/operations/create-nat-gateway.md) or a [NAT instance](../../vpc/tutorials/nat-instance/index.md) in the subnet hosting the nodes.

For more information, see [Internet access for cluster worker nodes](network.md#nodes-internet).

{% endnote %}

### Cluster labels {#cluster-labels}

To break Kubernetes into logical groups, use [cloud labels](../../resource-manager/concepts/labels.md).

Cloud labels for Kubernetes clusters are subject to the following rules:

  * Label key parameters:
  
    * It must be from 1 to 63 characters long.
    * It may contain lowercase Latin letters, numbers, hyphens, and underscores.
    * Use a letter for the first character.
  
  * Label value parameters:
  
    * It may be up to 63 characters long.
    * It may contain lowercase Latin letters, numbers, hyphens, and underscores.

Learn more about managing cloud labels in [Updating a cluster](../operations/kubernetes-cluster/kubernetes-cluster-update.md#manage-label).

{% note info %}

You cannot assign [Kubernetes labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) to a cluster.

{% endnote %}

## Master {#master}

A _master_ is a component that manages a Kubernetes cluster.

A master runs Kubernetes control processes including the Kubernetes API server, scheduler, and main resource controllers. A master lifecycle is managed by Kubernetes when creating or deleting a Kubernetes cluster. The master is responsible for global solutions executed on all Kubernetes cluster nodes. These include scheduling workloads, such as containerized applications, managing the lifecycle of workloads, and scaling.

There are two types of masters that differ by number of master hosts and by their [availability zone](../../overview/concepts/geo-scope.md) placement:
* _Base_: Contains one master host in a single availability zone. Such a master is generally cheaper but it does not guarantee high availability.

* `Highly available`: Contains three master hosts that you can place as follows:
  * In one availability zone and one subnet. Choose this type if you want to ensure high availability of the cluster and reduce its internal network latency.
  * In three different availability zones. This master ensures the best [fault tolerance](../../architecture/fault-tolerance.md): if one zone becomes unavailable, the master will continue to function.

  The internal IP address of a highly available master is available only within a single Yandex Virtual Private Cloud cloud network.

For more information about master settings, see [Creating a Managed Service for Kubernetes cluster](../operations/kubernetes-cluster/kubernetes-cluster-create.md).

### Master computing resources {#master-resources}

{% note warning %}

Starting June 18, 2026, master node pricing has changed, with fees now based on the number of vCPUs and the amount of RAM. Use [this table](master-configuration.md) to estimate the required master node resources for your cluster.

{% endnote %}

_By default_, the following resources are provided for the operation of one master host:
* [Platform](../../compute/concepts/vm-platforms.md): Intel Cascade Lake
* Guaranteed vCPU share: 100%
* vCPU: 2
* RAM: 8 GB

When [creating](../operations/kubernetes-cluster/kubernetes-cluster-create.md) or [updating](../operations/kubernetes-cluster/kubernetes-cluster-update.md#manage-resources) a cluster, you can select a master configuration suitable for your tasks.

The selected configuration allocates minimum resources to the master. Depending on the load, the amount of RAM and number of vCPUs will increase automatically.

The following master configurations are available for Intel Cascade Lake with a guaranteed vCPU share of 100%:

* **Standard**: Standard hosts with 4:1 RAM to vCPU ratio: {#master-standard}

  ID | Number of vCPUs | RAM, GB
  --- | --- | ---
  s-c2-m8    | 2 | 8
  s-c4-m16   | 4 | 16
  s-c8-m32   | 8 | 32
  s-c16-m64  | 16 | 64
  s-c32-m128 | 32 | 128
  s-c64-m256 | 64 | 256
  s-c80-m320 | 80 | 320

* **CPU-optimized**: Hosts with a decreased RAM to vCPU ratio of 2:1: {#master-cpu-optimized}

  ID | Number of vCPUs | RAM, GB
  --- | --- | ---
  c-c4-m8   | 4 | 8
  c-c8-m16  | 8 | 16
  c-c16-m32 | 16 | 32
  c-c32-m64 | 32 | 64

* **Memory-optimized**: Hosts with an increased RAM to vCPU ratio of 8:1: {#master-memory-optimized}

  ID | Number of vCPUs | RAM, GB
  --- | --- | ---
  m-c2-m16 | 2 | 16
  m-c4-m32 | 4 | 32
  m-c8-m64 | 8 | 64
  m-c16-m128 | 16 | 128
  m-c32-m256 | 32 | 256

For more information, see [Getting a list of available master configurations in a Kubernetes cluster](../operations/kubernetes-cluster/kubernetes-cluster-configuration-list.md).

You can update the master configuration without stopping your Managed Service for Kubernetes cluster.

## Node group {#node-group}

A _node group_ is a Yandex Compute Cloud [instance group](../../compute/concepts/instance-groups/index.md) in a Kubernetes cluster, where VM instances share the same configuration and are used to run the user's containers.

Individual nodes in node groups are Yandex Compute Cloud virtual machines with automatically generated names. To configure nodes, [follow the node group management guides](../operations/index.md#node-group).

{% note alert %}

Do not change node VM settings, including names, network interfaces, and SSH keys, using the Compute Cloud interfaces or SSH connections to the VM.

This can disrupt the operation of individual nodes, node groups, and the whole Managed Service for Kubernetes cluster.

{% endnote %}

See also the [description of instance groups during a zonal incident and mitigation guidelines](../../compute/concepts/instance-groups/zonal-inc/overview.md).

For a node group, you can specify the following settings:
* Name and description
* [Kubernetes version](k8s-supported-versions.md)
* [Node group cloud labels](../../resource-manager/concepts/labels.md)
* [Scaling parameters](node-group/cluster-autoscaler.md)
* [Deployment policy](node-group/deploy-policy.md)
* [Reserved instance pools](node-group/reserved-pools.md)
* [Variables in a node template](node-group/variables-in-the-template.md)
* [VM configuration](#config)
* [Taints and tolerations](#taints-tolerations)
* [Node labels](#node-labels)

For Managed Service for Kubernetes, only [containerd](https://containerd.io/) is available as a container runtime environment.

### VM configuration {#config}


When creating a node group, you can configure the following VM parameters:

* VM type. To pay less for your cluster, consider [preemptible VMs](../../compute/concepts/preemptible-vm.md).

   
   {% note tip %}
   
   To evict pods automatically from a preemptible node when shutting it down, use the Yandex Cloud Marketplace product called [node-sitter](../operations/applications/node-sitter.md).
   
   {% endnote %}
   

* Type and number of cores (vCPUs).
* Amount of memory (RAM) and disk space.
* [Placement group](../../compute/concepts/placement-groups.md).

  {% note info %}
  
  The placement group determines the maximum available node group size:
  
  * In an instance group with the [spread placement](../../compute/concepts/placement-groups.md#spread) strategy, the maximum number of instances depends on the [limits](../../compute/concepts/limits.md#compute-limits-vm).
  * In an instance group with the [partition placement](../../compute/concepts/placement-groups.md#partition) strategy, the maximum number of instances in a partition depends on the [quotas](../../compute/concepts/limits.md#vm-quotas).
  
  
  {% endnote %}

* Kernel parameters:
  * _Safe_ kernel parameters are isolated between pods.
  * _Unsafe_ parameters affect the operation of the pods and the node as a whole. In Managed Service for Kubernetes, you cannot change unsafe kernel parameters unless you explicitly specified their names when [creating a node group](../operations/node-group/node-group-create.md).

  {% note info %}

  You should only specify kernel parameters that belong to [namespaces](#namespace), e.g., `net.ipv4.ping_group_range`. Parameters that do not belong to namespaces, e.g., `vm.max_map_count`, should be resolved directly in the OS or using a DaemonSet with containers in privileged mode after creating a [Managed Service for Kubernetes node group](#node-group).

  {% endnote %}

  Learn more about kernel parameters in [this Kubernetes guide](https://kubernetes.io/docs/tasks/administer-cluster/sysctl-cluster/).

You can create groups with different configurations in a single Kubernetes cluster and spread them across multiple availability zones.

### Taints and tolerations {#taints-tolerations}

_Taints_ are special policies placed on nodes in the group. Using taints, you can ensure that certain pods are not scheduled onto inappropriate nodes. For example, you can allow the rendering pods to schedule only on [nodes with GPU](node-group/node-group-gpu.md).

Taints give you the following advantages:
* Taints persist when a node is restarted or replaced with a new one.
* When adding nodes to a group, taints are placed on the node automatically.
* Taints are automatically placed on new nodes when [scaling a node group](autoscale.md).

You can place a taint on a node group only when [creating](../operations/node-group/node-group-create.md) it. 

{% note tip %}

You can use Terraform to [add](../operations/node-group/node-group-update.md#assign-taints) or [remove](../operations/node-group/node-group-update.md#remove-taint) a taint for a Terraform node group resource; however, this will also delete the node group itself and recreate it with the new configuration.

{% endnote %}

Each taint has three parts:

```text
<key> = <value>:<effect>
```

The following taint effects are available:
* `NO_SCHEDULE`: Prohibit scheduling new pods on the group nodes. It does not affect currently running pods.
* `PREFER_NO_SCHEDULE`: Avoid scheduling pods on the group nodes if there are resources available for this purpose in other groups.
* `NO_EXECUTE`: Stop pods on the nodes, evict them to other groups, and prohibit running new pods.

_Tolerations_: Exceptions from taints. With tolerations, you can allow particular pods to run on nodes even if the node group's taint prohibits this.

There are two types of tolerations:

  * `Equal` triggers if the key, value, and effect of the taint match those of the toleration. It is used by default.

  * `Exists` triggers if the key and effect of the taint match those of the toleration. The key value is ignored.

  For example, if the `key1=value1:NoSchedule` taint is set for the group's nodes, you can use tolerations to place pods on a node as follows:

  ```yaml
  apiVersion: v1
  kind: Pod
  ...
  spec:
    ...
    tolerations:
    - key: "key1"
      operator: "Equal"
      value: "value1"
      effect: "NoSchedule"
  ```
  Or, alternatively:

  ```yaml
  apiVersion: v1
  kind: Pod
  ...
  spec:
    ...
    tolerations:
    - key: "key1"
      operator: "Exists"
      effect: "NoSchedule"
  ```

{% note info %}

To system pods, tolerations are added automatically so they can run on any available node.

{% endnote %}

For more on taints and tolerations, see [this Kubernetes guide](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/).

### Node labels {#node-labels}

You can group nodes in Managed Service for Kubernetes using _node labels_. There are two types of node labels:

* [Cloud labels](../../resource-manager/concepts/labels.md) are used for logical separation and labeling of resources. For example, you can use cloud labels to [track how much you spend](../../billing/operations/get-folder-report.md#format) on different node groups. They are designated as `template-labels` in the CLI and as `labels` in Terraform.

  Cloud labels for nodes are subject to the following rules:

  Label key parameters:
  
    * It may contain lowercase Latin letters, numbers, and `-_./\@` symbols.
    * Use a letter for the first character.
    * It may be up to 63 characters long.
  
  Label value parameters:
  
    * It may contain lowercase Latin letters, numbers, and `-_./\@` symbols.
    * It may be up to 63 characters long.

  Learn more about managing cloud labels in [Updating a node group](../operations/node-group/node-group-update.md#manage-label).

* [Kubernetes labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) are used to group Kubernetes objects and [distribute pods across cluster nodes](https://kubernetes.io/docs/tasks/configure-pod-container/assign-pods-nodes). They are designated as `node-labels` in the CLI and as `node_labels` in Terraform.

  When adding Kubernetes labels, specify the node properties to group objects by. You can find examples of Kubernetes labels in [this Kubernetes guide](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#motivation).

  You can define a set of `key: value` Kubernetes labels for every object. All of its keys must be unique.

  Kubernetes label keys of nodes may consist of two parts separated by `/`: prefix and name.
  
  A prefix is an optional part of a key. Follow these prefix requirements:
  * It must be a DNS subdomain, i.e., a series of DNS tags separated by `.`.
  * It may be up to 253 characters long.
  * The last character must be followed by `/`.
  
  A name is a required part of a key. Follow these naming requirements:
  * It may be up to 63 characters long.
  * It may contain lowercase Latin letters, numbers, and `-_.` symbols.
  * Use a letter or number for the first and last characters.
  
  The same rules apply to the value as to the name.
  
  Label example: `app.kubernetes.io/name: mysql`, where `app.kubernetes.io/` is the prefix, `name` is the name, and `mysql`, the value.

  You can use the [Managed Service for Kubernetes API](../managed-kubernetes/api-ref/index.md) and [Kubernetes API to manage Kubernetes](https://kubernetes.io/docs/concepts/overview/kubernetes-api) labels. Their features:

  * Kubernetes labels added via the Kubernetes API may be missing because, when [updating or modifying a node group](../operations/node-group/node-group-update.md), some nodes are recreated with different names and some of the old ones are deleted.
  * If Kubernetes labels are created via the Managed Service for Kubernetes API, you cannot delete them using the Kubernetes API. They will be restored once you delete them.

  {% note warning %}

  To make sure no labels are missing, use the Managed Service for Kubernetes API.

  {% endnote %}

  For more information about adding and deleting Kubernetes labels, see [Managing Kubernetes node labels](../operations/node-group/node-label-management.md). Adding or deleting a label will not result in the node group recreation.

You can use both types of labels concurrently, e.g., when [creating a node group](../operations/node-group/node-group-create.md) via the CLI or Terraform.

### Connecting to group nodes {#node-connect-ssh}

You can connect to nodes in a group in the following ways:
* Via an SSH client using a standard SSH key pair, see [Connecting to a node over SSH](../operations/node-connect-ssh.md).
* Via an SSH client and the CLI using OS Login, see [Connecting to a node via OS Login](../operations/node-connect-oslogin.md).

## Pod {#pod}

A _pod_ is a request to run one or multiple containers on a group node. In a Kubernetes cluster, each pod has its unique IP address so that applications do not conflict when using ports.

Containers are described in pods via JSON or YAML objects. You can connect to running container terminals using [kubectl](https://kubernetes.io/ru/docs/tasks/tools/install-kubectl/) or directly from the [management console](../operations/kubernetes-console/pod-terminal.md).

### Masquerading IP addresses for pods {#pod-ip-masquerade}

If a pod needs access to resources outside the cluster, its IP address will be replaced with the IP address of the node the pod is running on. For this, the cluster uses [IP masquerading](https://kubernetes.io/docs/tasks/administer-cluster/ip-masq-agent/).

By default, masquerading is enabled for the entire IP address range except for pod CIDRs and [link-local address](https://en.wikipedia.org/wiki/Link-local_address) CIDRs.

To implement IP masquerading, the `ip-masq-agent` pod is deployed on each cluster node. The settings for this pod are stored in a ConfigMap object called `ip-masq-agent`. If you need to disable pod IP masquerading in a particular direction, e.g., to access the pods over a VPN or [Yandex Cloud Interconnect](../../interconnect/index.md), specify these IP address ranges in the `data.config.nonMasqueradeCIDRs` parameter:

```yaml
...
data:
  config: |+
    nonMasqueradeCIDRs:
      - <non-masquerade_CIDRs_of_IP_addresses>
...
```

To view how the IP masquerading rules are configured in `iptables` on a specific node, [connect to the node over SSH](../operations/node-connect-ssh.md) and run this command:

```bash
sudo iptables -t nat -L IP-MASQ -v -n
```

For more information, see the [ip-masq-agent page on GitHub](https://github.com/kubernetes-sigs/ip-masq-agent).

## Service {#service}

A [_service_](service.md) is an abstraction that provides network load balancing. Traffic rules are configured for pods grouped by a set of labels.

By default, a service is only available within a specific Kubernetes cluster, but it can be public and receive [requests from outside](../operations/create-load-balancer.md#create-lb) the Kubernetes cluster.

## Namespace {#namespace}

A _namespace_ is an abstraction that logically isolates Kubernetes cluster resources and distributes [quotas](https://console.yandex.cloud/cloud?section=quotas) for them. This is useful for isolating resources of different teams and projects in a single Kubernetes cluster.

## Service accounts {#service-accounts}

Managed Service for Kubernetes clusters use two types of service accounts:
* **Cloud service accounts**

  These accounts exist at the level of an individual folder in the cloud and can be used by Managed Service for Kubernetes as well as by other services.

  For more information, see [Access management in Managed Service for Kubernetes](../security/index.md) and [Service accounts](../../iam/concepts/users/service-accounts.md).
* **Kubernetes service accounts** 

  These accounts exist and run only at a level of an individual Managed Service for Kubernetes cluster. Kubernetes uses them to:
  * Authenticate cluster API calls from applications deployed in the cluster.
  * Configure access for these applications.

  When deploying a Managed Service for Kubernetes cluster, a set of Kubernetes service accounts is automatically created in the `kube-system` namespace.

  For authentication within the Kubernetes cluster hosting the service account, create a token for this account manually.

  For more information, see [Creating a static configuration file](../operations/connect/create-static-conf.md) and [this Kubernetes guide](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/).

{% note warning %}

Do not confuse [cloud service accounts](../security/index.md#sa-annotation) with Kubernetes service accounts.

In our Managed Service for Kubernetes guides, a _service account_ means a regular cloud service account unless otherwise specified.

{% endnote %}

## Managed Service for Kubernetes cluster statistics {#metrics}

Managed Service for Kubernetes automatically sends cluster metrics to [Yandex Monitoring](../../monitoring/index.md). Metrics are available for the following Kubernetes objects:

* Container
* [Master](index.md#master)
* [Node](index.md#node-group)
* [Pod](index.md#pod)
* [Persistent volume](volume.md#persistent-volume)

You can get cluster metrics using the following tools:

* [Management console](https://console.yandex.cloud)
* [Monitoring interface](https://monitoring.yandex.cloud)
* [Monitoring API](../../monitoring/api-ref/authentication.md)
* [Metrics Provider](https://yandex.cloud/en/marketplace/products/yc/metric-provider)
* [Prometheus Operator](https://yandex.cloud/en/marketplace/products/yc/prometheus-operator)

For more information, see [Monitoring cluster state Managed Service for Kubernetes](../operations/kubernetes-cluster/kubernetes-cluster-get-stats.md).

You can find metrics description in [Yandex Monitoring metric reference](../metrics.md).

## Use cases {#examples}

* [Creating and configuring a Kubernetes cluster with no internet access](../tutorials/k8s-cluster-with-no-internet.md)
* [Backing up a Managed Service for Kubernetes cluster to Object Storage](../tutorials/kubernetes-backup.md)
* [Cluster monitoring with the help of Prometheus Operator with Yandex Monitoring support](../tutorials/prometheus-grafana-monitoring.md)
* [Using node groups with GPUs without pre-installed drivers](../tutorials/driverless-gpu.md)

#### Useful links {#see-also}

* [Kubernetes: Why use it, how it works, and what makes it an industry standard](https://yandex.cloud/ru/blog/posts/2025/03/kubernetes-guide)