Контейнери і Kubernetes

Навіщо це

У вас є API в образі Docker. Треба запустити дві репліки за HTTPS-балансувальником, оновлювати версію без простою, додавати репліки під навантаженням і не платити за нічний простій. Хмара пропонує три відповіді різної ваги: платформу, якій віддають образ і ліміти (Cloud Run, Fargate, Container Apps), кластер Kubernetes, де вузли лишаються вашим клопотом, і кластер Kubernetes у режимі, де вузлами теж керує провайдер.

Різниця вимірюється в грошах і в людях. Мінімальний прод-кластер з двома вузлами коштує близько $190 на місяць ще до першого застосунку, а сервіс тієї самої ваги на Fargate разом із балансувальником обходиться приблизно в $45–55. Кластеру потрібен хтось, хто розуміє його оновлення, мережу й диски. Платформі такий хтось не потрібен, зате вона не вміє того, що вміє кластер. Тому модуль іде від простого до складного: реєстри образів, платформи без Kubernetes, потім керований Kubernetes. Наприкінці ви самі відповісте, чи Kubernetes потрібен вашому проєкту.

Передумови. Ролі, політики й федерація (модуль 3), віртуальні машини, з яких складаються вузли (модуль 4), підмережі та балансувальники (модуль 5), блочні диски (модуль 6). Контейнер на рівні ядра (простори імен і cgroups) пояснено в курсі ОС: Віртуалізація і контейнери.

Контейнер і образ

Контейнером називають звичайний процес Linux, до якого ядро застосувало простори імен і контрольні групи. Ядро спільне з господарем, тому ізоляція слабша, ніж у віртуальної машини. Тег образу на кшталт 1.4.2 є міткою, яку можна переставити на інший образ, а дайджест (sha256:…) вказує на конкретний вміст. Тому продакшен розгортають за дайджестом або незмінним тегом, а latest лишають для експериментів.

Реєстр образів

Реєстр образів (container registry) зберігає шари, віддає їх вузлам під час pull і перевіряє, хто може читати та писати. У кожної хмари він свій: Amazon ECR, Azure Container Registry (ACR) і Google Artifact Registry. Усі три дають приватні репозиторії, сканування на вразливості, правила очищення й авторизацію через IAM хмари.

З реєстром пов’язані три рішення, які пізніше важко змінити. Розташування: реєстр тримають у регіоні вузлів, бо завантаження з іншого регіону додає затримку до холодного старту й вихідний трафік до рахунку (модуль 5). Незмінні теги: ECR (image_tag_mutability) і Artifact Registry (immutable_tags) забороняють перезапис тега, і відкат зводиться до повернення старого тега. Очищення: кожна збірка лишає образ, тож без правил реєстр росте безкінечно; зберігання дешеве (близько $0.10 за ГБ на місяць), але сотні образів по 500 МБ складаються в десятки доларів.

Контейнерні платформи без Kubernetes

Така платформа бере образ, ліміти процесора з пам’яттю й правила масштабування, а решту робить сама: вибирає машину, розкладає репліки за зонами доступності, видає адресу й сертифікат, перезапускає впалі контейнери. Ви працюєте з трьома поняттями: сервіс (довгоживучий процес, зазвичай HTTP), завдання (job, що запускається й завершується) і правила автомасштабування.

ECS і Fargate. Amazon ECS є власним оркестратором AWS: опис завдання (task definition) фіксує образ і ресурси, а сервіс (service) підтримує потрібну кількість завдань. Запускати їх можна на ваших ВМ або на Fargate, де машини належать AWS; там платять за vCPU і пам’ять від початку завантаження образу до зупинки, з мінімумом у хвилину. Нові проєкти спрощує ECS Express Mode: за образом і двома ролями IAM він створює сервіс на Fargate, балансувальник, автомасштабування й мережу, без окремої плати за сам режим. Саме його AWS радить замість App Runner, який від 30 квітня 2026 року не приймає нових клієнтів.

Azure Container Apps працює поверх Kubernetes, але ховає його: доступу до API кластера немає, є середовище (environment) із застосунками. Застосунок масштабується правилами (одночасні HTTP-запити, довжина черги, розклад) і може скочуватися до нуля реплік. План Consumption оплачує секунди роботи реплік, план Dedicated резервує профілі вузлів. Нові версії виходять ревізіями з розподілом трафіку.

Cloud Run приймає образ і віддає HTTPS-адресу. Один інстанс обробляє багато запитів одночасно: 80 за замовчуванням, до 1000. Цим Cloud Run відрізняється від Lambda, де одне середовище виконання обслуговує один запит (модуль 9). Оплата йде або за запит (CPU виділено, поки обробляється запит), або за інстанс (CPU виділено, поки інстанс існує). Функції Cloud Run functions виконуються на тій самій платформі.

Коли платформи досить. Коли застосунок зводиться до HTTP-сервісів, обробників черги й запланованих завдань, не тримає стан на локальному диску й не залежить від нестандартного планування. Для більшості корпоративних API і воркерів так і є. Не вистачає її тоді, коли з’являється щось із цього:

• власні контролери й ресурси (CRD, оператори), наприклад оператор бази даних;
• DaemonSet, тобто агент на кожному вузлі;
• складне планування (спорідненість, taints, пули під GPU);
• сервісна мережа (service mesh) або мережеві політики між подами;
• десятки сервісів, що ділять одну мережеву й політичну модель;
• вимога однакового API на кількох хмарах і в дата-центрі.

Кожну з вимог платформи частково закривають (sidecar-контейнери, приватна мережа). Коли їх набирається кілька, кластер починає виправдовувати свою вагу.

Що лишається вам у кожному способі. Вузли переходять до вас лише в режимі пулів, а обʼєкти Kubernetes зʼявляються лише там, де є кластер.

Керований Kubernetes

Kubernetes підтримує бажаний стан: ви описуєте його обʼєктами (Deployment, Service, PersistentVolumeClaim), а контролери постійно зводять дійсність до опису. Площина керування складається з kube-apiserver, сховища etcd, планувальника й менеджера контролерів. Площина даних складається з вузлів, де працюють kubelet і containerd. Под є найменшою одиницею планування: один або кілька контейнерів зі спільною мережею й дисками.

Хто керує площиною керування

У EKS, AKS і GKE провайдер запускає, розкладає за зонами й оновлює площину керування. Ви отримуєте ендпоінт API і платите щогодини:

• EKS: $0.10 за годину (близько $73 на місяць). Версії, що вийшли зі стандартної підтримки (14 місяців після випуску), ще 12 місяців працюють у розширеній підтримці за $0.60 за годину.
• AKS: рівень Free без плати за площину і без SLA, Standard за $0.10 за годину з SLA, Premium за $0.60 за годину з підтримкою версій на два роки.
• GKE: $0.10 за годину за кластер, але кожен платіжний акаунт щомісяця отримує $74.40 кредиту, що покриває один зональний кластер або Autopilot.

Нова мінорна версія Kubernetes виходить приблизно раз на чотири місяці, а підтримка кожної обмежена. Тому оновлення лишається вашою постійною роботою: провайдер оновить API-сервер, але сумісність застосунків і аддонів (а в режимі пулів і самих вузлів) перевіряєте ви.

Пули вузлів

Пул вузлів (node pool) об’єднує однакові вузли: тип машини, образ ОС, мітки, taints, межі масштабування. В EKS аналог називається керованою групою вузлів (managed node group). Кілька пулів потрібні для різнорідного навантаження: GPU, spot-інстанси для пакетних завдань, ARM, малий системний пул.

Вузол оплачується як звичайна ВМ, зайнята чи ні, тож головною величиною стає щільність упаковки (bin packing): поди, чиї запити погано збігаються з розміром машини, лишають частину оплаченого процесора без діла. Класичний Cluster Autoscaler додає вузли в задані пули, коли з’являються поди, що не вміщаються, і вибирає лише з типів, дозволених пулом.

Автоматичні вузли: Karpenter, EKS Auto Mode, Autopilot, AKS Automatic

Ці назви описують один рух: провайдер бере на себе вузли.

Karpenter діє інакше, ніж Cluster Autoscaler: дивиться на поди, які планувальник не розмістив, підбирає найдешевший підхожий тип інстанса й запускає вузол напряму, без наперед створеної групи; порожні вузли консолідує. Це відкритий проєкт, який працює й поза AWS.

EKS Auto Mode віддає AWS запуск і оновлення вузлів, масштабування на Karpenter, балансувальники, EBS-диски, мережу подів і DNS. Вузли працюють на образах Bottlerocket без доступу по SSH чи SSM, а їхній вік обмежено 21 днем. Ціна: вартість інстансів EC2 плюс плата за керування залежно від типу інстанса (у прикладах AWS від $0.02064 до $0.07344 за годину).

GKE Autopilot переносить білінг з вузлів на поди: платять за запити процесора, пам’яті й ефемерного диска з маніфесту, а вузлів у рахунку немає. Тому завищений requests коштує грошей, навіть коли под майже не працює. Режим доступний і для окремих навантажень у кластерах Standard через класи обчислень.

AKS Automatic вмикає автоматичне надання вузлів (node auto-provisioning, NAP), побудоване на Karpenter і доступне з середини липня 2025 року, а з ним керовану мережу, workload identity і безпечні політики розгортання. Windows-вузлів у ньому немає.

Ціна спрощення: менше налаштувань і менше контролю. Привілейовані контейнери, hostPath і власні образи ОС у таких режимах обмежені.

Вхідний трафік: від Ingress до Gateway API

Ingress довго був єдиним стандартним способом описати HTTP-маршрутизацію. Стандарт вийшов мінімальним, тож усе цікаве (перезаписи, ліміти, автентифікацію) реалізували анотаціями, у кожного контролера власними. Найпоширеніший, ingress-nginx, у березні 2026 року завершив підтримку: нових випусків і виправлень безпеки немає, наявні розгортання працюють. Проєкт Kubernetes радить Gateway API.

Gateway API розділяє роботу між ролями. GatewayClass каже, яка реалізація обслуговує шлюзи (це вибір провайдера або платформної команди). Gateway описує адреси, порти й сертифікати. HTTPRoute описує маршрути до сервісів і належить команді застосунку. Ці три ресурси мають стабільну версію v1; поточний реліз проєкту 1.6.2 (вересень 2026).

• EKS. AWS Load Balancer Controller з версії 3.0 (березень 2026) підтримує Gateway API: маршрути L7 стають ALB, маршрути L4 стають NLB. Вбудований контролер EKS Auto Mode, за наявними даними, Gateway API поки не підтримує.
• AKS. Керований Gateway API в application routing add-on (клас approuting-istio) працює на полегшеному шарі Istio без повної service mesh; у нових кластерах AKS Automatic з Kubernetes 1.36 він за замовчуванням. Керований NGINX add-on Microsoft підтримує з виправленнями безпеки лише до листопада 2026 року.
• GKE. Контролер Gateway керує Google і створює зовнішні чи внутрішні Application Load Balancer (gke-l7-global-external-managed, gke-l7-rilb та інші класи).

Диски: StorageClass

Под просить диск через PersistentVolumeClaim, а StorageClass визначає, який драйвер і з якими параметрами створить диск у хмарі. Драйвер CSI (Container Storage Interface) створює блочний диск через API провайдера й монтує його на вузол: ebs.csi.aws.com (в Auto Mode ebs.csi.eks.amazonaws.com), disk.csi.azure.com, pd.csi.storage.gke.io.

Блочні диски зональні (модуль 6): диск живе в одній зоні доступності, і под може працювати лише там. Якщо диск створено до планування пода, под застряє в Pending, коли в тій зоні немає вузлів. Тому в StorageClass ставлять volumeBindingMode: WaitForFirstConsumer: диск створюється після того, як планувальник обрав вузол. Спільний доступ із кількох подів потребує файлового сховища (EFS, Azure Files, Filestore). Стан краще тримати в керованій базі (модуль 7), яка бере на себе резервні копії й відновлення.

Ідентичність пода в хмарі

Поду часто потрібен доступ до хмарних API. Найгірший спосіб — покласти ключ у Secret: ключ довго живе, його копіюють, і права він зазвичай має надто широкі. Роль вузла не краща, бо всі поди на вузлі отримують однакові права (модуль 3).

Правильний спосіб дає ідентичність робочого навантаження (workload identity). Под працює під ServiceAccount, Kubernetes видає для нього токен, а хмара обмінює токен на короткоживучі облікові дані для конкретної ролі. Це та сама федерація, що й OIDC із CI без ключів (модуль 3), лише джерелом довіри тут кластер.

Ланцюжок однаковий у трьох хмарах. Різняться посередник у кластері та місце, де записано довіру.

• EKS Pod Identity. На вузлі працює агент (DaemonSet). Ви створюєте асоціацію: кластер, простір імен, ServiceAccount, роль IAM. У політиці довіри ролі стоїть один принципал, pods.eks.amazonaws.com, з діями sts:AssumeRole і sts:TagSession. Провайдер OIDC на кожен кластер не потрібен, на відміну від старішого IRSA. На Fargate Pod Identity не працює, там лишається IRSA.
• AKS Workload Identity. На кластері вмикають OIDC-видавця й workload identity, створюють керовану identity і federated credential для токенів ServiceAccount кластера. ServiceAccount отримує анотацію azure.workload.identity/client-id, а под мітку azure.workload.identity/use: "true". На одну identity припадає не більше 20 federated credentials. В AKS Automatic усе це вже ввімкнено.
• GKE Workload Identity Federation. Кластер має пул ідентичностей PROJECT_ID.svc.id.goog, а в політиці IAM ServiceAccount позначають принципалом principal://iam.googleapis.com/projects/…/subject/ns/<ns>/sa/<sa> і видають роль напряму. Токени обмінює GKE metadata server на вузлі. У Autopilot федерація ввімкнена за замовчуванням, у Standard її вмикають прапорцем --workload-pool.

Це не межа безпеки між подами

Workload identity обмежує права пода правами його ServiceAccount, але від зламаного пода не захищає. Контейнери ділять ядро вузла, тож вихід з контейнера відкриває сусідні поди. Поди різної довіри розводять по різних пулах або кластерах (модуль 12).

Як це в трьох хмарах

	AWS	Azure	GCP
Реєстр образів	Amazon ECR	Azure Container Registry	Artifact Registry
Платформа без Kubernetes	ECS + Fargate, ECS Express Mode	Azure Container Apps	Cloud Run
Керований Kubernetes	EKS	AKS	GKE
Плата за площину керування	$0.10/год	Free $0, Standard $0.10/год	$0.10/год, кредит $74.40 на акаунт
Вузли без вашої участі	EKS Auto Mode (Karpenter)	AKS Automatic (NAP на Karpenter)	GKE Autopilot
Gateway API	AWS Load Balancer Controller	application routing (Istio), Application Gateway for Containers	контролер Gateway від Google
Ідентичність пода	EKS Pod Identity (IRSA)	Microsoft Entra Workload ID	Workload Identity Federation for GKE

Чим відрізняється і що з цього випливає. Ядро Kubernetes у трьох хмарах однакове, тож Deployment і Service переносяться без змін. Усе на межі з хмарою різне: балансувальники, диски, ідентичність, мережа подів, оновлення. Швів багато, тому «Kubernetes прибирає прив’язку до постачальника» правдиве лише наполовину. Платформи без Kubernetes прив’язують до API сильніше, але тонше: образ OCI переїжджає між ними без змін, мігрувати доводиться конфігурацію.

Реєстр: вхід і завантаження

AWS

REGISTRY=$(aws sts get-caller-identity --query Account --output text).dkr.ecr.us-east-1.amazonaws.com

aws ecr get-login-password --region us-east-1 \
  | docker login --username AWS --password-stdin $REGISTRY

docker tag api:1.4.2 $REGISTRY/shop/api:1.4.2
docker push $REGISTRY/shop/api:1.4.2

Azure

az acr login --name shopregistry

docker tag api:1.4.2 shopregistry.azurecr.io/shop/api:1.4.2
docker push shopregistry.azurecr.io/shop/api:1.4.2

GCP

gcloud auth configure-docker us-central1-docker.pkg.dev

docker tag api:1.4.2 us-central1-docker.pkg.dev/$PROJECT_ID/shop/api:1.4.2
docker push us-central1-docker.pkg.dev/$PROJECT_ID/shop/api:1.4.2

Платформа без Kubernetes: сервіс на дві репліки

AWS

variable "image" {
  type = string
}

variable "subnet_ids" {
  type = list(string)
}

variable "execution_role_arn" {
  type = string
}

resource "aws_ecs_cluster" "main" {
  name = "shop"
}

resource "aws_ecs_task_definition" "api" {
  family                   = "api"
  requires_compatibilities = ["FARGATE"]
  network_mode             = "awsvpc"
  cpu                      = "512"
  memory                   = "1024"
  execution_role_arn       = var.execution_role_arn

  runtime_platform {
    operating_system_family = "LINUX"
    cpu_architecture        = "ARM64"
  }

  container_definitions = jsonencode([{
    name         = "api"
    image        = var.image
    essential    = true
    portMappings = [{ containerPort = 8080 }]
  }])
}

resource "aws_ecs_service" "api" {
  name            = "api"
  cluster         = aws_ecs_cluster.main.arn
  task_definition = aws_ecs_task_definition.api.arn
  desired_count   = 2
  launch_type     = "FARGATE"

  network_configuration {
    subnets          = var.subnet_ids
    assign_public_ip = false
  }
}

Azure

variable "image" {
  type = string
}

resource "azurerm_resource_group" "rg" {
  name     = "rg-shop"
  location = "eastus"
}

resource "azurerm_container_app_environment" "env" {
  name                = "env-shop"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
}

resource "azurerm_container_app" "api" {
  name                         = "api"
  container_app_environment_id = azurerm_container_app_environment.env.id
  resource_group_name          = azurerm_resource_group.rg.name
  revision_mode                = "Single"

  template {
    min_replicas = 2
    max_replicas = 10

    container {
      name   = "api"
      image  = var.image
      cpu    = 0.5
      memory = "1Gi"
    }

    http_scale_rule {
      name                = "http"
      concurrent_requests = "50"
    }
  }

  ingress {
    external_enabled = true
    target_port      = 8080

    traffic_weight {
      latest_revision = true
      percentage      = 100
    }
  }
}

GCP

variable "image" {
  type = string
}

resource "google_cloud_run_v2_service" "api" {
  name                = "api"
  location            = "us-central1"
  ingress             = "INGRESS_TRAFFIC_ALL"
  deletion_protection = false

  template {
    max_instance_request_concurrency = 80

    scaling {
      min_instance_count = 2
      max_instance_count = 10
    }

    containers {
      image = var.image

      ports {
        container_port = 8080
      }

      resources {
        limits = {
          cpu    = "1"
          memory = "1Gi"
        }
      }
    }
  }
}

На AWS сервіс складається з кластера, опису завдання й сервісу, а балансувальник, група безпеки та роль виконання додаються окремо. На Azure і GCP застосунок описує один ресурс, адресу й TLS дає платформа. У Cloud Run публічний доступ вмикається окремою політикою IAM (roles/run.invoker).

Кластер: створення

AWS

eksctl create cluster --name shop --region us-east-1 --enable-auto-mode
kubectl get nodes

Порожній кластер Auto Mode вузлів не має: перший з’явиться, коли Karpenter побачить под, для якого немає місця.

Azure

az group create --name rg-shop --location eastus
az aks create --resource-group rg-shop --name shop \
  --tier standard --node-count 2 --generate-ssh-keys \
  --enable-oidc-issuer --enable-workload-identity
az aks get-credentials --resource-group rg-shop --name shop

Для режиму Automatic замість --tier standard вказують --sku automatic.

GCP

gcloud container clusters create-auto shop --location us-central1
gcloud container clusters get-credentials shop --location us-central1

Gateway API: один маршрут у трьох хмарах

HTTPRoute в усіх хмарах однаковий, різниться лише шлюз.

AWS

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: aws-alb
spec:
  controllerName: gateway.k8s.aws/alb
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: shop
spec:
  gatewayClassName: aws-alb
  listeners:
    - name: http
      port: 80
      protocol: HTTP

Azure

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: shop
spec:
  gatewayClassName: approuting-istio
  listeners:
    - name: http
      port: 80
      protocol: HTTP

Клас з’являється після az aks update --enable-gateway-api --enable-app-routing-istio.

GCP

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: shop
spec:
  gatewayClassName: gke-l7-global-external-managed
  listeners:
    - name: http
      port: 80
      protocol: HTTP

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api
spec:
  parentRefs:
    - name: shop
  hostnames: ["shop.example.com"]
  rules:
    - matches:
        - path: { type: PathPrefix, value: /api }
      backendRefs:
        - name: api
          port: 8080

Ідентичність пода: доступ до сховища без ключа

AWS

variable "cluster_name" {
  type = string
}

data "aws_iam_policy_document" "trust" {
  statement {
    effect  = "Allow"
    actions = ["sts:AssumeRole", "sts:TagSession"]

    principals {
      type        = "Service"
      identifiers = ["pods.eks.amazonaws.com"]
    }
  }
}

resource "aws_iam_role" "api" {
  name               = "shop-api"
  assume_role_policy = data.aws_iam_policy_document.trust.json
}

resource "aws_iam_role_policy_attachment" "s3_read" {
  role       = aws_iam_role.api.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess"
}

resource "aws_eks_pod_identity_association" "api" {
  cluster_name    = var.cluster_name
  namespace       = "shop"
  service_account = "api"
  role_arn        = aws_iam_role.api.arn
}

Azure

variable "oidc_issuer_url" {
  type = string
}

variable "storage_account_id" {
  type = string
}

resource "azurerm_resource_group" "rg" {
  name     = "rg-shop"
  location = "eastus"
}

resource "azurerm_user_assigned_identity" "api" {
  name                = "id-shop-api"
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
}

resource "azurerm_federated_identity_credential" "api" {
  name                      = "aks-shop-api"
  user_assigned_identity_id = azurerm_user_assigned_identity.api.id
  issuer                    = var.oidc_issuer_url
  subject                   = "system:serviceaccount:shop:api"
  audience                  = ["api://AzureADTokenExchange"]
}

resource "azurerm_role_assignment" "read" {
  scope                = var.storage_account_id
  role_definition_name = "Storage Blob Data Reader"
  principal_id         = azurerm_user_assigned_identity.api.principal_id
}

Адресу видавця дає az aks show --query oidcIssuerProfile.issuerUrl. Ще потрібні ServiceAccount з анотацією azure.workload.identity/client-id (це client_id identity) і мітка azure.workload.identity/use: "true" у шаблоні пода.

GCP

variable "project_id" {
  type = string
}

variable "bucket_name" {
  type = string
}

data "google_project" "this" {
  project_id = var.project_id
}

resource "google_storage_bucket_iam_member" "api_read" {
  bucket = var.bucket_name
  role   = "roles/storage.objectViewer"
  member = "principal://iam.googleapis.com/projects/${data.google_project.this.number}/locations/global/workloadIdentityPools/${var.project_id}.svc.id.goog/subject/ns/shop/sa/api"
}

Сервісний акаунт GCP тут не створюється: роль видано ServiceAccount Kubernetes напряму. Для API, які не приймають федеровані токени, документація GKE радить імперсонацію сервісного акаунта.

Реєстри теж створюють Terraform-ресурсами (aws_ecr_repository, azurerm_container_registry, google_artifact_registry_repository); підхід той самий, що в модулі 10.

Скільки це коштує

Станом на вересень 2026, регіони us-east-1, eastus, us-central1, Linux, оплата за вимогою, місяць у 730 годин. Ціни взято зі сторінок цін провайдерів і їхніх публічних прайс-листів.

Реєстр. ECR $0.10 за ГБ на місяць. Artifact Registry $0.10 за ГіБ на місяць, перші 0.5 ГіБ безкоштовні. ACR Basic $0.1666 за добу (близько $5 на місяць) плюс $0.10 за ГБ понад включений обсяг.

Сервіс на дві репліки по 0.5 vCPU і 1 ГіБ, цілодобово.

Варіант	Місяць	Ставки
ECS Fargate, x86	$36.04	$0.04048 за vCPU-год, $0.004445 за ГБ-год
ECS Fargate, ARM	$28.84	$0.03238 і $0.00356
ALB для Fargate	+$16.43	$0.0225 за годину, плюс LCU
Container Apps, репліки активні	$78.84	$0.000024 за vCPU-с, $0.000003 за ГіБ-с
Container Apps, той самий сервіс у idle	$23.65	$0.000003 за vCPU-с і за ГіБ-с
Cloud Run, оплата за інстанс, 1 vCPU	$105.12	$0.000018 за vCPU-с, $0.000002 за ГіБ-с
Cloud Run, мінімальні інстанси в простої, 1 vCPU	$26.28	$0.0000025 за vCPU-с і за ГіБ-с
GKE Autopilot, лише поди	$39.67	$0.0445 за vCPU-год, $0.0049225 за ГіБ-год

Cloud Run порахований для 1 vCPU, як у Terraform-прикладі вище: менше за 1 vCPU він дозволяє лише з одним запитом на інстанс (concurrency 1) і лише з оплатою за запит, а тоді порівняння втрачає сенс. Зате при оплаті за запит простій між запитами не оплачується зовсім, і для сервісу з рідкісним трафіком Cloud Run стає найдешевшим рядком таблиці.

Безкоштовні квоти в таблицю не закладено: вони зменшують суму приблизно на $5 (Container Apps дає підписці щомісяця 180 000 vCPU-с і 360 000 ГіБ-с, Cloud Run при оплаті за інстанс 240 000 vCPU-с і 450 000 ГіБ-с). Ставка «активна» в Container Apps діє, поки репліка обробляє запит або запускається. Якщо запитів немає, а мінімальні репліки тримаються, вони переходять на ставку idle, тому сервіс із рідкісним трафіком коштує значно менше за верхню цифру.

Мінімальний кластер: площина керування і два вузли з 2 vCPU та 8 ГіБ.

Варіант	Площина	Два вузли	Разом
EKS, m7g.large ($0.0816/год)	$73.00	$119.14	$192.14
AKS Standard, D2s v5 ($0.096/год)	$73.00	$140.16	$213.16
AKS Free, ті самі вузли	$0	$140.16	$140.16
GKE Standard	$73 мінус кредит $74.40	за прайсом Compute Engine	не звірено

До цих сум не входять балансувальник, диски, NAT-шлюз і вихідний трафік. Сервіс type: LoadBalancer створює окремий балансувальник (від $16 на місяць) на кожен сервіс, а один шлюз Gateway API обслуговує багато маршрутів. Плата за площину ($73 на місяць) пояснює, чому один кластер на команду вигідніший за кластер на сервіс. AKS Automatic тарифікує площину й обчислення окремими лічильниками (в API цін: Automatic Hosted Control Plane $0.16 за годину та лічильники за типами обчислень).

Від 1 вересня 2026 року в API цін Container Apps з’явилися лічильники рівня середовища (Environment Management, Planned Maintenance, Private Endpoint) по $0.10 за годину, тобто близько $73 на місяць; документація з білінгу пов’язує такі плати з приватними ендпоінтами й запланованим обслуговуванням.

Розбір: команда з п’яти осіб і питання про Kubernetes

Команда з п’яти розробників тримає інтернет-магазин: API, адмінка, воркер, що обробляє замовлення з черги, і щоденне завдання зі звітом. Технічний директор пропонує «зробити нормально» і перейти на Kubernetes. Зважимо це за механізмами.

Що Kubernetes дає тут. Оновлення без простою, відкат, автомасштабування, розклад за зонами. Усе це вже вміють платформи: нова ревізія Cloud Run чи Container Apps отримує трафік поступово, ECS Express Mode налаштовує масштабування сам.

Що він коштує. Кластер на EKS або AKS від $190 на місяць, той самий набір сервісів на Fargate з балансувальником близько $50. Головна ціна в людях: хтось має щокілька місяців оновлювати кластер і аддони, стежити за сумісністю API, налаштовувати мережу подів, диски й ролі. Для п’яти осіб це або чверть ставки, або оновлення, які ніхто не встигає робити.

Що змінює відповідь. Її змінюють конкретні вимоги, а не загальна «серйозність»:

1. Потрібен оператор бази даних, черги чи кешу, що постачається як CRD.
2. Потрібен агент на кожному вузлі або service mesh з mTLS між десятками сервісів.
3. Сервісів уже понад двадцять-тридцять, і вони ділять мережеві та політичні правила.
4. Потрібне планування GPU та окремих пулів із чергами задач.
5. Є вимога працювати однаково на двох хмарах або в локальному дата-центрі.

Якщо жодного пункту немає, відповідь для цієї команди: платформа без Kubernetes і керована база даних. Якщо є один-два, варто спробувати режим із керованими вузлами (Autopilot, EKS Auto Mode, AKS Automatic): він лишає Kubernetes API, але знімає найбільше експлуатаційної роботи. Повний кластер із пулами виправданий, коли потрібен контроль над образом ОС, типами машин і налаштуваннями ядра.

Вибір не остаточний. Образ OCI без змін працює на всіх варіантах з цього модуля, тож початок із платформи не закриває шлях до кластера: переноситься конфігурація (маршрути, ідентичність, масштабування), застосунок лишається тим самим.

Типові помилки розуміння

«Kubernetes прибирає прив’язку до постачальника». Deployment переноситься, а Gateway, StorageClass, ідентичність, мережа подів і оновлення ні.

«Kubernetes сам додає вузли». Горизонтальний автомасштабувальник додає поди. Вузли додає окремий компонент: Cluster Autoscaler, Karpenter або режим із керованими вузлами. Без нього поди зависають у Pending.

«Autopilot дешевший, бо платиш за використання». Платиш за requests у маніфесті. Под, що просить 2 vCPU і використовує 0.1, оплачується за 2 vCPU.

«Керований кластер оновлюється сам». Провайдер оновлює площину за вашою командою або розкладом, а версії мають обмежений строк підтримки. У режимі пулів образи вузлів і аддони оновлюєте ви.

«Workload identity захищає від зламаного пода». Вона обмежує права пода, але контейнери ділять ядро вузла.

Перевір себе

1. Команда з чотирьох людей має API, воркер із черги й нічне завдання, стану на диску немає, база керована. Що розумніше вибрати?

Кластер EKS із пулами вузлів, щоб мати повний контрольДва кластери в різних регіонах для відмовостійкостіПлатформу без Kubernetes: ECS Fargate, Container Apps або Cloud RunВласні ВМ із Docker, бо це найдешевше

2. Чому в StorageClass для блочних дисків ставлять volumeBindingMode: WaitForFirstConsumer?

Щоб диск створювався після вибору вузла й опинився в тій самій зоніЩоб диск був дешевшимЩоб кілька подів могли писати в нього одночасноЩоб диск шифрувався ключем вузла

3. У GKE Autopilot под просить 2 vCPU, а використовує близько 0.1 vCPU. Що з рахунком?

Оплачується лише 0.1 vCPU, як у LambdaОплачується весь вузол, де працює подОплачується лише запитаний процесор, якщо под не перевищив лімітОплачується 2 vCPU, бо ціна рахується за requests із маніфесту

4. Под в EKS має читати обʼєкти S3 без ключів у Secret, і той самий набір прав потрібен у трьох кластерах. Що зручніше?

Роль вузла, спільна для всіх подівEKS Pod Identity: одна роль з довірою для pods.eks.amazonaws.com і асоціація в кожному кластеріIRSA з окремим OIDC-провайдером для кожного кластераКлюч доступу в Secret із ручною ротацією

5. Запити до вашого сервісу по 0.2 с чекають відповіді бази й майже не вантажать CPU. Чим Cloud Run тут відрізняється від Lambda?

Інстанс Cloud Run обробляє до 80 запитів одночасно, тож очікування різних запитів накладаютьсяCloud Run завжди дорожчий за LambdaУ Cloud Run немає холодного стартуСередовище Lambda обробляє багато запитів одночасно

6. У кластері з пулами вузлів без автомасштабування нові поди зависли в Pending з Insufficient cpu. Що робити?

Збільшити replicas у DeploymentОновити площину керуванняДодати вузли: увімкнути автомасштабувальник пулу або збільшити пулВидалити поди й створити їх заново

Джерела

• Ціни: EKS, Fargate, Container Apps, AKS, Cloud Run, GKE, Azure retail prices API, прайс-листи AWS (EC2, ELB)
• AWS: EKS Auto Mode, Pod Identity, ECS Express Mode, App Runner, Load Balancer Controller
• Azure: Container Apps billing, AKS Automatic, Workload ID, app routing і Gateway API
• GCP: Workload Identity Federation, Gateway controller
• Kubernetes: Gateway API, Ingress NGINX Retirement, Karpenter; курс ОС: Віртуалізація і контейнери