Networking in Managed Service for Kubernetes

When creating a Kubernetes cluster, you can configure the following:

• Network and subnet for the master.
• Range of IP addresses for pods.
• Range of IP addresses for services.
• Node subnet mask.

You can also:

• Request a public IP address to access the cluster from outside Yandex Cloud.
• Configure network policy controllers to manage the address space within the cluster.

Network resourcesNetwork resources

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

• Subnets.

  When creating a cluster without tunnel mode, 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 addresses.

  When you create a cluster with public access, the master will get a public IP address.

  When you create a node group with public access, each of its nodes will get a public IP address.

Managing the address spaceManaging the address space

Kubernetes clusters that do not use tunnel mode have the following limitations:

• Ranges of the subnets being created should not overlap with the existing ranges.
• Only a half of the possible subnet range is available for pods, nodes, and services. This limitation is due to the Virtual Private Cloud specifics to ensure the availability of an unused IP address range for cluster service distribution.

The following subnet ranges are available for the pods, nodes, and services of such clusters:

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16

The node subnet mask and the subnet size for the pods determines the maximum number of nodes in the cluster and the maximum number of pods per node.

In addition, Kubernetes has a standard limit of 110 pods per node.

For clusters in tunnel mode, the following subnet ranges are available:

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16

For example, when creating a cluster with the following parameters:

• Tunnel mode is not enabled.
• Range of IP addresses for pods: 10.1.0.0/16.
• Range of IP addresses for services: 10.2.0.0/16.
• Node subnet mask: 24.

The cluster will have:

• Ranges of IP addresses for nodes: 10.1.128.0/24 – 10.1.255.0/24.
• IP addresses for pods on each node: 10.1.128.2 – 10.1.128.255, 10.1.129.2 – 10.1.129.255, etc.

Node name and FQDNNode name and FQDN

Managed Service for Kubernetes generates a name for each node when it is created. This name will be the host's fully qualified domain name (FQDN). You cannot change the node name or FQDN.

Use the FQDN to access the node within a single cloud network. For more information, see Cloud resource addresses.

Public access in a clusterPublic access in a cluster

If you enable public access for the master or nodes in a node group, they will be accessible from the internet via their public IP addresses.

You can enable public access:

• For the master, only when creating a cluster.
• For nodes in a group, when creating or updating the group.

If you disable public access for the master or nodes, they will be accessible only via their private IP addresses from the cloud network the cluster resides in.

Internet access for cluster worker nodesInternet access for cluster worker nodes

To connect to external resources, e.g., Docker image registries such as Container Registry, Cloud Registry, or Docker Hub as well as Object Storage buckets, the group nodes must have internet access.

To enable internet access, assign a public IP address to the nodes and configure a security group. As an alternative to public IP addresses, you can also create and configure a NAT gateway or a NAT instance in the subnet hosting the nodes.

If you create a cluster with no internet access, it will not be possible to connect to external resources from the cluster’s nodes.

However, this does not apply to the following Yandex Cloud services, which you can access via private IP addresses:

• Object Storage: To access buckets, use a VPC service connection or create the required infrastructure manually.
• Container Registry: To access registries, create the required infrastructure manually.

Impact of security groupsImpact of security groups

Security groups assigned to node groups contain a basic rule that allows connections to external resources.

If you use more granular rules that significantly restrict network traffic, they may block internet access for the nodes. Access may be blocked entirely or in part, i.e., only to certain external resources.

If you encounter any problems with nodes’ internet access, edit your security group rules to allow the traffic you need.