This article explains the key concepts of Kubernetes that you’ll need to work with Managed Kubernetes. If you’re already familiar with Kubernetes, skip ahead to creating a cluster.

The complete Kubernetes documentation is available on the official website.

What is Kubernetes

Kubernetes (K8s) is a platform for automating the deployment, scaling, and management of containerized applications.

Instead of manually starting an application on a specific server, monitoring its status, and restarting it in case of failures, you describe the desired state (how many instances of the application should be running, how many resources to allocate, how to handle traffic), and Kubernetes maintains that state automatically.

Containers

A container is an isolated environment for running an application. The application itself is packaged into the container along with all its dependencies: libraries, configuration, and runtime environment. As a result, with Kubernetes containers, the application behaves identically regardless of where it is run, on a developer’s local machine or on a server in a cloud infrastructure.

Containers are created from images. An image is a template used to run a container. The most common format is Docker images.

Cluster

A Kubernetes cluster is a set of servers (nodes) grouped together to jointly run containerized applications. A cluster consists of two types of components:

Control plane (Master nodes) – components that manage the cluster’s state: they receive requests, distribute the load, and monitor the status of applications. The control plane Kubernetes is fully managed by the platform.
Worker nodes – servers on which your applications actually run.

Node

A node is an individual server within a cluster. There are two types of nodes:

Master node – a server in the control plane. It runs the Kubernetes components responsible for coordinating the cluster:

API server – accepts commands (for example, from `kubectl`, the command-line tool for managing Kubernetes)
etcd – the cluster state store
Scheduler – decides on which node to launch a new pod
Controller Manager – ensures that the current state of the cluster matches the desired state

Worker node – a server for running user applications. Each worker node runs:

kubelet – an agent that receives instructions from the control plane and manages containers on the node
kube-proxy – manages network rules for accessing applications
Container runtime – an environment for running containers

Pods

A pod is the smallest deployment unit in Kubernetes. Every container in Kubernetes runs inside a pod. A pod contains one or more containers that:

run on the same node
share a network namespace (have a shared IP address)
can use shared volumes for data storage

Most often, a single pod contains a single container with an application. Multiple containers in a single pod are used when the containers are closely related and must work together (for example, an application and a sidecar proxy for logging).

Pods are not created directly; they are managed by controllers.

Controllers

Controllers monitor the status of applications and maintain them in accordance with the specified configuration.

Deployment is the most common controller. It specifies which container to run and how many instances (replicas) to create. If a pod fails, the Deployment automatically creates a new one.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

This manifest creates three pods running Nginx. If one of the pods terminates with an error, the Deployment will launch a new one to ensure that the number of running instances remains at three.

Other common controllers:

StatefulSet – for stateful applications (databases, queues). Unlike Deployment, it guarantees consistent pod names and startup order.
DaemonSet – runs one pod per node. Used for system tasks: log collection, monitoring, and network agents.
Job / CronJob – for one-time or periodic tasks (migrations, backups, reports).

Services

Pods in Kubernetes are assigned IP addresses, but these addresses are temporary; the address changes when the pod is recreated. Kubernetes uses services to solve this problem: a service provides a stable network address for a group of pods.

A service selects pods based on labels and distributes traffic among them.

Main service types:

ClusterIP (default) – accessible only within the cluster. Used for communication between application components.
NodePort – opens a port on each cluster node for external access.
LoadBalancer – creates an external load balancer. When creating a LoadBalancer service, the platform automatically provides a load balancer. For more details, see the article “Networking and load balancers”.

Namespaces

A namespace is a way to logically separate resources within a single cluster. Different teams, environments, or applications can operate in their own namespaces without interfering with one another.

By default, a cluster has several namespaces:

default – used if no namespace is explicitly specified
kube-system – Kubernetes system components
kube-public – resources available to all cluster users

Creating your own namespace:

kubectl create namespace my-app

Manifests

Resource configurations in Kubernetes are described in YAML manifests. A manifest is a file that specifies which resource to create and with what parameters.

Manifest structure:

apiVersion: v1          # API version
kind: Pod               # resource type
metadata:
  name: my-pod          # resource name
  namespace: default    # namespace
  labels:
    app: my-app         # identification tags
spec:                   # resource specification
  containers:
  - name: app
    image: my-app:latest

The manifest is applied by the command:

kubectl apply -f manifest.yaml

Labels and Selectors

Labels are key-value pairs assigned to Kubernetes resources. They are used to organize and select resources.

metadata:
  labels:
    app: frontend
    env: production

Selectors allow you to select resources based on labels. For example, a service can route traffic only to pods with a specific label:

selector:
  app: frontend

Taints and Tolerations

Taints and Tolerations are a mechanism that controls which pods can run on which nodes.

A taint is assigned to a node and prevents pods without a corresponding toleration from running on that node.

A toleration is specified in a pod’s specification and allows it to run on a node with a specific taint.

How it works

A taint consists of a key, a value, and an effect:

<key>=<value>:<effect>

Effects:

NoSchedule – Pods without the corresponding Toleration will not be scheduled on this node. Pods already running are not affected.
PreferNoSchedule – Kubernetes will avoid scheduling pods without Toleration, but may schedule them if resources are scarce on other nodes.
NoExecute – Pods without Toleration will not only not be scheduled, but will also be removed from the node if they are already running.

Example

Suppose you have a group of nodes dedicated to critical services. You apply a taint to these nodes:

kubectl taint nodes node1 dedicated=critical:NoSchedule

Now, regular pods will not be able to run on node1. For a pod to run on this node, you must specify a Toleration in its manifest:

spec:
  tolerations:
  - key: "dedicated"
    operator: "Equal"
    value: "critical"
    effect: "NoSchedule"
  containers:
  - name: app
    image: my-critical-app:latest

Why is this necessary?

Load isolation – to dedicate nodes to specific applications, preventing unrelated pods from running on them
Environment separation – to prevent dev-pods from running on production nodes
Specialized hardware – to reserve nodes with GPUs or large amounts of memory exclusively for suitable tasks

Taints can be assigned when creating or editing a worker group; they are automatically applied to all nodes in the group. For more details, see the article “Creating and Configuring a Cluster”.

All articles in this section

Kubernetes (K8s) – An Overview of the Managed Kubernetes Service
Kubernetes Basics – You are here
Creating and Configuring a Cluster – Master Node Configuration, Networking, and Worker Groups
Connecting to the Cluster and Working with kubectl – kubeconfig, Connectivity, and Core Kubernetes Tools
Cluster management – adding nodes, changing configuration, updating, and deleting
Networking and load balancers – network model, external and internal load balancers
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.

What is Kubernetes (K8s)? Key terms: cluster, container, services