Migracja aplikacji do Azure AKS — co musisz wiedzieć przed startem

Wprowadzenie

Migracja aplikacji do Azure Kubernetes Service (AKS) to projekt, który przy dobrym przygotowaniu może przebiec bez przestoju. Przy złym — może kosztować kilka nieprzespanych nocy. W tym artykule omówimy co musisz sprawdzić, zaplanować i przygotować zanim przeniesiesz pierwszą linię kodu do chmury.

Krok 1 — Audyt istniejącej aplikacji

Czy aplikacja jest gotowa na kontenery?

✓ Aplikacja jest bezstanowa (stateless)?
✓ Konfiguracja pochodzi ze zmiennych środowiskowych?
✓ Logi trafiają na stdout/stderr?
✓ Aplikacja obsługuje sygnał SIGTERM do graceful shutdown?
✓ Health check endpoint istnieje (/health lub /ready)?

Dobór strategii migracji (model 6R)

Strategia	Kiedy stosować	Nakład pracy
Rehost (lift & shift)	VM → Azure VM, bez zmian	Niski
Replatform	Minimalne zmiany, np. baza → Azure SQL	Średni
Refactor	Przepisanie na mikroserwisy / kontenery	Wysoki

Krok 2 — Zaplanuj architekturę AKS

Internet → Azure Load Balancer → Ingress Controller (nginx)
         → AKS Cluster [Node 1: app-pod, Node 2: app-pod]
         → Azure SQL DB + Azure Blob Storage

Node pools

az aks nodepool add \
  --cluster-name my-aks \
  --resource-group my-rg \
  --name apppool \
  --node-count 2 \
  --node-vm-size Standard_D2s_v3 \
  --mode User

Krok 3 — Przygotuj infrastrukturę (Terraform)

resource "azurerm_kubernetes_cluster" "main" {
  name                = "myapp-aks"
  location            = azurerm_resource_group.main.location
  resource_group_name = azurerm_resource_group.main.name
  dns_prefix          = "myapp"
  kubernetes_version  = "1.29"

  default_node_pool {
    name                = "system"
    node_count          = 2
    vm_size             = "Standard_D2s_v3"
    enable_auto_scaling = true
    min_count           = 2
    max_count           = 5
  }

  identity {
    type = "SystemAssigned"
  }

  network_profile {
    network_plugin    = "azure"
    load_balancer_sku = "standard"
  }
}

terraform init && terraform plan -out=tfplan && terraform apply tfplan
az aks get-credentials --resource-group myapp-rg --name myapp-aks

Krok 4 — Manifesty Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  namespace: production
spec:
  replicas: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    spec:
      containers:
      - name: myapp
        image: myregistry.azurecr.io/myapp:v1.0.0
        resources:
          requests:
            memory: "128Mi"
            cpu: "100m"
          limits:
            memory: "256Mi"
            cpu: "500m"
        livenessProbe:
          httpGet:
            path: /health
            port: 8000
        readinessProbe:
          httpGet:
            path: /ready
            port: 8000

Krok 5 — Strategia migracji bazy danych

Faza 1: Uruchom nową bazę (Azure SQL) równolegle ze starą
Faza 2: Synchronizuj dane (replikacja lub ETL)
Faza 3: Przełącz aplikację na nową bazę
Faza 4: Monitoruj przez 24-48h
Faza 5: Wyłącz starą bazę

# PostgreSQL → Azure Database for PostgreSQL
pg_dump -h old-server -U user dbname | \
  psql "host=new-server.postgres.database.azure.com user=admin dbname=mydb sslmode=require"

Krok 6 — Checklist przed Go-Live

INFRASTRUKTURA
✓ Klaster AKS z min. 2 węzłami (HA)
✓ Autoskalowanie węzłów skonfigurowane
✓ Monitoring (Azure Monitor / Grafana) aktywny
✓ Alerty na CPU/memory/pod restarts

APLIKACJA
✓ Health checks działają (/health, /ready)
✓ Zasoby requests/limits ustawione
✓ Secrets w Azure Key Vault (nie w yaml)
✓ NetworkPolicy skonfigurowane

DNS I SSL
✓ Ingress Controller zainstalowany
✓ Cert-manager z Let's Encrypt skonfigurowany
✓ DNS przełączony (TTL obniżony do 60s)

Typowe pułapki

Image Pull Secrets — AKS musi mieć uprawnienia do prywatnego rejestru:

az aks update --name myapp-aks --resource-group myapp-rg --attach-acr myregistry

Limity zasobów — bez requests i limits jeden pod może zagłodzić cały węzeł.

Podsumowanie

Udana migracja do AKS to kwestia planowania, nie szczęścia. Kluczowe zasady: najpierw dostosuj aplikację, używaj Terraform do infrastruktury, zadbaj o bazę danych i testuj disaster recovery zanim będziesz go potrzebować.