Розгортаємо AKS Automatic: Повна автоматизація з Terraform та Helm

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Світ Kubernetes в Azure стрімко рухається в бік спрощення. AKS Automatic — це режим, де Azure бере на себе ще більше рутинної роботи: керування нодами, їх оновлення, масштабування та безпеку. Це чудово, але як DevOps-інженери, ми не хочемо створювати ресурси «наклацуванням» у порталі. Нам потрібна відтворюваність та код.

Сьогодні ми об’єднаємо найкраще з обох світів: ми розгорнемо кластер AKS у режимі «Automatic» (максимально керований Azure) за допомогою Terraform, а потім одразу розгорнемо туди тестовий додаток за допомогою Helm. І все це — в одному пайплайні Terraform.

Що таке AKS Automatic?

Уявіть, що ви пересіли з механічної коробки передач на Tesla з увімкненим автопілотом. AKS Automatic — це саме така еволюція: режим роботи сервісу, створений для того, щоб максимально знизити операційне навантаження (Day 2 operations). Якщо у стандартному SKU ви все ще змушені «жонглювати» версіями нод, їх розмірами та патчами ОС, то AKS Automatic бере це на себе. Azure автоматично керує життєвим циклом кластера, динамічно підбирає ресурси під навантаження (використовуючи Node Autoprovisioning), застосовує суворі політики безпеки (secure-by-default) та налаштовує інтеграції з моніторингом «з коробки». Для нас, як для інженерів платформи, це означає кінець епохи мікроменеджменту інфраструктури та повний фокус на доставці цінності бізнесу.

Передумови

Перед початком переконайтеся, що у вас налаштовано:

1. Azure CLI (і ви залогінені через az login).
2. Terraform (версії 1.5+).
3. Базове розуміння того, як працюють TF-провайдери.

Крок 1: Налаштування провайдерів та базової інфраструктури

Ми будемо використовувати два провайдери Terraform: azurerm для створення самого кластера та helm для деплою додатків всередину нього.

Створіть файл main.tf. Нам потрібна ресурсна група, де житиме наш кластер.

# main.tf
terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.0" # Використовуйте актуальну версію
    }
    helm = {
      source  = "hashicorp/helm"
      version = "~> 2.0"
    }
  }
}
provider "azurerm" {
  features {}
}
# Змінні для зручності
variable "location" {
  default = "northeurope"
  description = "Регіон Azure"
}
variable "rg_name" {
  default = "rg-aks-automatic-demo"
  description = "Ім'я ресурсної групи"
}
variable "cluster_name" {
  default = "aks-auto-demo"}
# Створення ресурсної групи
resource "azurerm_resource_group" "rg" {
  name     = var.rg_name
  location = var.location
}

Крок 2: Визначаємо кластер AKS Automatic

Ось тут відбувається магія. Щоб отримати досвід «Automatic», ми маємо налаштувати кластер певним чином: використовувати Managed Identity, увімкнути RBAC та дозволити Azure керувати оновленнями.

Створіть файл aks.tf.

# aks.tf
resource "azurerm_kubernetes_cluster" "aks" {
  name                = var.cluster_name
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  dns_prefix          = "${var.cluster_name}-dns"
  # Використовуємо Managed Identity (System Assigned)
  identity {
    type = "SystemAssigned"
  }
  # Конфігурація "Automatic" передбачає, що Azure керує нодами.
  # Ми створюємо лише дефолтний node pool, решту робить Azure.
  default_node_pool {
    name       = "default"
    node_count = 2
    vm_size    = "Standard_D2s_v3"
    
    # Важливо для автоматизації: увімкнути автоскейлінг
    enable_auto_scaling = true
    min_count           = 2
    max_count           = 5
  }
  
  # Увімкнення Azure RBAC для авторизації Kubernetes
  azure_active_directory_role_based_access_control {
    managed                = true
    azure_rbac_enabled     = true
  }
  # Налаштування мережі (використовуємо Azure CNI Overlay для простоти)
  network_profile {
    network_plugin    = "azure"
    network_policy    = "azure"
    network_plugin_mode = "overlay"
    load_balancer_sku = "standard"
  }
  # Автоматичне оновлення каналу (Ключова фіча Automatic)
  automatic_channel_upgrade = "stable"
  
  tags = {
    Environment = "Demo"
    Type        = "AKS Automatic"
  }
}

Крок 3: Налаштування провайдера Helm

Щоб Terraform міг щось деплоїти всередину кластера, провайдеру helm потрібні облікові дані. Ми не будемо хардкодити їх, а візьмемо динамічно з виводу ресурсу кластера.

Створіть файл helm_config.tf:

# helm_config.tf
# Отримуємо конфіг кластера для підключення
data "azurerm_kubernetes_cluster" "credentials" {
  name                = azurerm_kubernetes_cluster.aks.name
  resource_group_name = azurerm_resource_group.rg.name
  
  # Цей блок гарантує, що ми чекаємо створення кластера перед спробою отримати дані
  depends_on = [azurerm_kubernetes_cluster.aks]
}
provider "helm" {
  kubernetes {
    host                   = data.azurerm_kubernetes_cluster.credentials.kube_config.0.host
    client_certificate     = base64decode(data.azurerm_kubernetes_cluster.credentials.kube_config.0.client_certificate)
    client_key             = base64decode(data.azurerm_kubernetes_cluster.credentials.kube_config.0.client_key)
    cluster_ca_certificate = base64decode(data.azurerm_kubernetes_cluster.credentials.kube_config.0.cluster_ca_certificate)
    
    # Якщо використовується Azure RBAC, можливо, знадобиться використання kubelogin або
    # отримання токена через exec-плагін, але для базового прикладу сертифікатів достатньо.
  }
}

Крок 4: Деплой тестового додатка (Nginx) через Helm

Тепер найцікавіше. Ми використаємо ресурс helm_release, щоб розгорнути простий Nginx чарт одразу після того, як кластер підніметься.

Додайте це у helm_config.tf або створіть новий файл apps.tf:

# apps.tf
resource "helm_release" "nginx_ingress" {
  name       = "nginx-ingress-controller"
  repository = "https://kubernetes.github.io/ingress-nginx"
  chart      = "ingress-nginx"
  namespace  = "ingress-basic"
  create_namespace = true
  # Чекаємо, поки кластер буде готовий
  depends_on = [azurerm_kubernetes_cluster.aks]
  set {
    name  = "controller.service.annotations.service\\.beta\\.kubernetes\\.io/azure-load-balancer-health-probe-request-path"
    value = "/healthz"
  }
  
  # Встановлюємо репліки для демонстрації
  set {
      name  = "controller.replicaCount"
      value = 2
  }
}

Запуск!

Настав час об’єднати все це разом.

1. Ініціалізація:
   terraform init<br>
2. Планування: Перевірте, що Terraform збирається створити (групу, кластер, і хелм-реліз).
   terraform plan -out=tfplan<br>
3. Застосування: Ідіть пити каву, це займе хвилин 10-15.
   terraform apply tfplan<br>

Перевірка результату

Після завершення terraform apply ваш кластер готовий, і Nginx Ingress Controller вже має працювати в ньому.

Давайте перевіримо це за допомогою kubectl. Спочатку отримаємо доступи:

Тепер подивимося на наші поди в неймспейсі ingress-basic:

Ви повинні побачити щось подібне:

А також перевіримо сервіс, щоб побачити зовнішню IP-адресу:

Висновок

Ми щойно створили повністю керований кластер AKS Automatic та розгорнули в нього інфраструктурний компонент (Ingress Controller), використовуючи єдиний підхід Infrastructure as Code з Terraform.

Цей підхід дозволяє вам версіонувати не тільки саму інфраструктуру Kubernetes, але й базові додатки, які мають там жити, забезпечуючи повну відтворюваність середовища.

Успіхів в автоматизації!