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.

Хотите стабильный и безопасный кластер? Свяжитесь с нами — оценим проект и предложим сроки.