Yandex Managed Kubernetes: від архітектури до CI/CD у production

Інфраструктура Kubernetes у Yandex Cloud: від проєктування до CI/CD

Ми часто бачимо, як команди витрачають тижні на ручне налаштування Kubernetes у Yandex Cloud і стикаються з проблемами: невірна мережева топологія, витоки ресурсів, відсутність observability. Yandex Managed Kubernetes знімає частину головного болю, але без правильної архітектури кластер може стати джерелом збоїв. Наш досвід (5+ років, 50+ кластерів) показує: ключ до стабільної роботи — дотримання best practices на старті. Якщо вам потрібен production-grade кластер, зв'яжіться з нами для аудиту.

Переваги Yandex Managed Kubernetes

Yandex Managed Kubernetes — найбільш зрілий managed Kubernetes серед російських хмарних провайдерів. Глибока інтеграція з YC-екосистемою: Container Registry, Managed Databases, Object Storage, Application Load Balancer — все керується нативно через Kubernetes-ресурси. Для проєктів на Yandex Cloud це знімає значний операційний overhead порівняно з самостійно піднятим кластером. Ви отримуєте автоматичне оновлення control plane, інтеграцію з сервісними акаунтами та готові рішення для моніторингу.

Як ми проєктуємо архітектуру кластера?

Перше питання — зональний чи регіональний майстер. Зональний (один control plane в одній зоні) дешевший на 30%. Регіональний (три ноди майстра в трьох зонах) — HA. Для production використовуємо тільки регіональний: втрата однієї зони не роняє кластер.

Друге питання — версія Kubernetes. YC підтримує поточну minor і два попередніх (зазвичай 1.27–1.29). Release channel: STABLE — для production, REGULAR — якщо потрібні свіжіші версії, RAPID — для експериментів.

Третє — мережева топологія. Кластер має жити в private subnet, без публічного IP у майстра. Доступ до kubectl — тільки через VPN або bastion. Це знижує поверхню атаки.

Terraform: повна конфігурація кластера

# Сервисные аккаунты
resource "yandex_iam_service_account" "k8s_master" {
  name = "k8s-master-sa"
  folder_id = var.folder_id
}

resource "yandex_iam_service_account" "k8s_nodes" {
  name = "k8s-nodes-sa"
  folder_id = var.folder_id
}

# Роли для SA мастера
resource "yandex_resourcemanager_folder_iam_member" "k8s_master_roles" {
  for_each = toset(["k8s.clusters.agent", "vpc.publicAdmin", "load-balancer.admin"])
  folder_id = var.folder_id
  role = each.value
  member = "serviceAccount:${yandex_iam_service_account.k8s_master.id}"
}

# Роли для SA нод
resource "yandex_resourcemanager_folder_iam_member" "k8s_nodes_roles" {
  for_each = toset(["container-registry.images.puller", "monitoring.editor"])
  folder_id = var.folder_id
  role = each.value
  member = "serviceAccount:${yandex_iam_service_account.k8s_nodes.id}"
}

# Кластер
resource "yandex_kubernetes_cluster" "main" {
  name = "production-cluster"
  folder_id = var.folder_id
  network_id = yandex_vpc_network.main.id
  master {
    regional {
      region = "ru-central1"
      dynamic "location" {
        for_each = {
          a = yandex_vpc_subnet.private_a.id
          b = yandex_vpc_subnet.private_b.id
          d = yandex_vpc_subnet.private_d.id
        }
        content {
          zone = "ru-central1-${location.key}"
          subnet_id = location.value
        }
      }
    }
    version = "1.28"
    public_ip = false
    security_group_ids = [yandex_vpc_security_group.k8s_master.id]
    maintenance_policy {
      auto_upgrade = true
      maintenance_window {
        day = "sunday"
        start_time = "03:00"
        duration = "3h"
      }
    }
  }
  service_account_id = yandex_iam_service_account.k8s_master.id
  node_service_account_id = yandex_iam_service_account.k8s_nodes.id
  release_channel = "STABLE"
  network_policy_provider = "CALICO"
}

Node Groups: workers та спеціалізовані ноди

Для production рекомендуємо розділити ноди за призначенням через taints/labels:

# Общие worker ноды
resource "yandex_kubernetes_node_group" "workers" {
  cluster_id = yandex_kubernetes_cluster.main.id
  name = "workers"
  version = "1.28"

  instance_template {
    platform_id = "standard-v3"

    resources {
      cores = 4
      memory = 8
    }

    boot_disk {
      type = "network-ssd"
      size = 64
    }

    network_interface {
      subnet_ids = [
        yandex_vpc_subnet.private_a.id,
        yandex_vpc_subnet.private_b.id,
        yandex_vpc_subnet.private_d.id,
      ]
      nat = false
      security_group_ids = [yandex_vpc_security_group.k8s_nodes.id]
    }

    metadata = {
      ssh-keys = "ubuntu:${file("~/.ssh/id_rsa.pub")}"
    }
  }

  scale_policy {
    auto_scale {
      initial = 3
      min = 3
      max = 10
    }
  }

  allocation_policy {
    location {
      zone = "ru-central1-a"
    }
    location {
      zone = "ru-central1-b"
    }
    location {
      zone = "ru-central1-d"
    }
  }

  node_taints = []
  node_labels = {
    "node-type" = "worker"
  }
}

# Ноды для stateful workloads (БД-sidecar, кэш)
resource "yandex_kubernetes_node_group" "stateful" {
  cluster_id = yandex_kubernetes_cluster.main.id
  name = "stateful"
  version = "1.28"

  instance_template {
    platform_id = "standard-v3"

    resources {
      cores = 8
      memory = 32
    }

    boot_disk {
      type = "network-ssd"
      size = 100
    }

    network_interface {
      subnet_ids = [yandex_vpc_subnet.private_a.id]
      nat = false
      security_group_ids = [yandex_vpc_security_group.k8s_nodes.id]
    }
  }

  scale_policy {
    fixed_scale {
      size = 2
    }
  }

  allocation_policy {
    location {
      zone = "ru-central1-a"
    }
  }

  node_taints = ["dedicated=stateful:NoSchedule"]
  node_labels = {
    "node-type" = "stateful"
  }
}

Базові компоненти та інтеграції

ALB Ingress Controller

YC Application Load Balancer інтегрується з Kubernetes через ALB Ingress Controller. Це нативний L7-балансувальник Yandex Cloud, керований через Kubernetes Ingress ресурси. Встановлення:

helm upgrade --install yc-alb-ingress-controller \
  oci://cr.yandex/yc-marketplace/yandex-cloud/yc-alb-ingress-controller/chart \
  --version 0.1.x \
  --namespace yc-alb-ingress-controller-system \
  --create-namespace \
  --set-string folder_id=<folder-id> \
  --set-string cluster_id=<cluster-id>

ALB автоматично створюється в Yandex Cloud, TLS-термінація на рівні балансувальника. Альтернатива — ingress-nginx з Network Load Balancer (більш знайомий стек, менше YC-специфіки).

Secrets через Yandex Lockbox

YC Lockbox — managed secrets service. Інтеграція з Kubernetes через External Secrets Operator:

helm upgrade --install external-secrets external-secrets \
  --repo https://charts.external-secrets.io \
  --namespace external-secrets \
  --create-namespace

Приклад ExternalSecret для синхронізації пароля БД можна знайти в документації External Secrets Operator.

Моніторинг кластера

YC автоматично збирає системні метрики нод і кластера. Для повноцінного моніторингу додатків встановлюємо kube-prometheus-stack:

helm upgrade --install kube-prometheus-stack \
  prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --create-namespace \
  --set prometheus.prometheusSpec.retention=30d \
  --set grafana.adminPassword=$(openssl rand -base64 24) \
  --set alertmanager.config.global.slack_api_url=<webhook-url>

Метрики з Prometheus можна експортувати в Yandex Monitoring через yc-unified-agent — тоді алерти та дашборди живуть в одному місці з рештою інфраструктури YC.

NetworkPolicy з Calico

Вмикаємо на рівні кластера (network_policy_provider = "CALICO"). Базовий принцип: default deny для всього неймспейсу, явно дозволяємо тільки потрібні комунікації. Після заборони додаємо дозвільні політики за label.

Як налаштувати CI/CD?

Для безперервної поставки в кластер використовуємо GitOps-підхід з ArgoCD або звичні CI/CD-пайплайни GitLab CI / GitHub Actions. Налаштуйте kubectl через сервісний акаунт з роллю cluster-admin, і пайплайн зможе деплоїти маніфести. Ми інтегруємо все в рамках проєкту, включаючи автоматичне оновлення образів через Flux або ArgoCD Image Updater.

Що входить в роботу

• Проєктування архітектури кластера з урахуванням навантаження та бюджетних обмежень.
• Повна конфігурація через Terraform (кластер, node groups, security groups).
• Встановлення та налаштування базових компонентів: ALB Ingress Controller, External Secrets, kube-prometheus-stack.
• Реалізація Network Policy для ізоляції сервісів.
• Інтеграція з CI/CD (GitLab CI / GitHub Actions / ArgoCD) та документація.
• Навчання команди: як керувати кластером, deploy, моніторинг.
• Гарантійна підтримка протягом 1 місяця після запуску.

Етапи роботи

1. Проєктування — мережева топологія, кількість та типи node group, вибір Ingress, оцінка вартості.
2. Terraform — кластер, node groups, SA, security groups.
3. Базові компоненти — Ingress Controller, External Secrets, моніторинг.
4. Network Policy — ізоляція неймспейсів, default deny.
5. CI/CD інтеграція — налаштування деплою в кластер.
6. Документація та навчання — Runbook, архітектура, інструкції.

Строки та вартість

Вартість розраховується індивідуально після аудиту вашої інфраструктури. Ми завжди пропонуємо оптимальне співвідношення ціна/якість — середня економія порівняно з DIY складає 25–40% за рахунок автоматизації та кращих практик. Використання spot instances дозволяє економити до 60% на обчислювальних ресурсах. Замовте аудит вашого кластера — отримайте консультацію інженера з 5+ років досвіду в Kubernetes.

Хочете стабільний та безпечний кластер? Зв'яжіться з нами — оцінимо проєкт і запропонуємо строки.