Azure Kubernetes Service (AKS) w Produkcji: Lekcje z Prawdziwych Wdrożeń

1. Architektura Klastra

Produkcyjne klastry powinny obejmować wiele stref dostępności i używać wielu node pools dla różnych typów obciążeń.

az aks create \
  --resource-group production-rg \
  --name production-cluster \
  --location eastus \
  --node-count 3 \
  --zones 1 2 3 \
  --enable-managed-identity \
  --enable-cluster-autoscaler \
  --min-count 3 \
  --max-count 10 \
  --network-plugin azure \
  --service-cidr 10.0.0.0/16 \
  --dns-service-ip 10.0.0.10 \
  --docker-bridge-address 172.17.0.1/16 \
  --vnet-subnet-id /subscriptions/xxx/resourceGroups/xxx/providers/Microsoft.Network/virtualNetworks/xxx/subnets/aks-subnet

2. Strategia Node Pools

Używaj oddzielnych node pools dla różnych typów obciążeń: system pods, aplikacje, bazy danych, batch jobs.

az aks nodepool add \
  --resource-group production-rg \
  --cluster-name production-cluster \
  --name spotpool \
  --priority Spot \
  --eviction-policy Delete \
  --spot-max-price -1 \
  --enable-cluster-autoscaler \
  --min-count 0 \
  --max-count 10 \
  --node-count 0 \
  --node-vm-size Standard_D4s_v3 \
  --node-taints kubernetes.azure.com/scalesetpriority=spot:NoSchedule

Spot instances kosztują 70-80% mniej niż zwykłe VMy. Idealne do niekrytycznych obciążeń jak CI/CD builds, przetwarzanie danych, batch jobs. Mogą być wyrzucone w każdej chwili, więc nie używaj do krytycznych serwisów.

3. Konfiguracja Bezpieczeństwa

az aks update \
  --resource-group production-rg \
  --name production-cluster \
  --enable-aad \
  --aad-admin-group-object-ids <admin-group-id>

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

4. Persistent Storage

Dla aplikacji stanowych (bazy danych, file storage), użyj Azure Disk lub Azure Files z odpowiednimi storage classes.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-premium-retain
provisioner: kubernetes.io/azure-disk
parameters:
  storageaccounttype: Premium_LRS
  kind: Managed
reclaimPolicy: Retain
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer

5. Monitoring i Obserwowalność

Produkcyjne klastry potrzebują kompleksowego monitoringu: metryki, logi, distributed tracing.

az aks enable-addons \
  --resource-group production-rg \
  --name production-cluster \
  --addons monitoring \
  --workspace-resource-id /subscriptions/xxx/resourceGroups/xxx/providers/Microsoft.OperationalInsights/workspaces/xxx

6. Deployment z GitOps za pomocą Flux lub ArgoCD

Nigdy nie wdrażaj do produkcji za pomocą kubectl apply. Używaj GitOps: twoje repozytorium Git to single source of truth, zmiany są automatycznie aplikowane.

# Zainstaluj Flux
flux bootstrap github \
  --owner=myorg \
  --repository=k8s-manifests \
  --branch=main \
  --path=clusters/production \
  --personal

1. Right-Sizing: Zacznij od Małych, Skaluj w Górę

Większość zespołów over-provisionuje 2-3x "dla pewności". Zacznij od mniejszych VMów i użyj cluster autoscaler.

2. Spot Instances dla Niekrytycznych Obciążeń

Azure Spot VMs kosztują 70-80% mniej niż zwykłe VMy. Używaj ich do batch jobs, CI/CD, środowisk deweloperskich.

Uwaga: Spot instances mogą być wyrzucone z 30-sekundowym wyprzedzeniem. Nie używaj do produkcyjnych API czy baz danych.

3. Konfiguracja Cluster Autoscaler

Automatycznie skaluj węzły na podstawie zapotrzebowania na pody. Oszczędza pieniądze w nocy/weekendy gdy ruch jest niski.

# Parametry cluster autoscaler
--min-count=2              # Minimum węzłów (zawsze działające)
--max-count=10             # Maximum węzłów (limit skalowania)
--scale-down-delay-after-add=10m
--scale-down-unneeded-time=10m

Z autoscalerem, klaster używający 10 węzłów podczas szczytu może skalować się do 3 węzłów w nocy, oszczędzając 70% kosztów compute w godzinach poza szczytem.

4. Azure Reservations (30-40% Oszczędności)

Jeśli masz baseline capacity działające 24/7, kup Azure Reserved Instances na 1 lub 3 lata.

5. Prawdziwy Breakdown Kosztów (Przykład Produkcyjny)

Ile kosztuje typowy produkcyjny klaster AKS miesięcznie (na podstawie prawdziwego wdrożenia):

Ten klaster obsługuje 500k requestów/dzień, 99.9% uptime, auto-skaluje się 2-5 węzłów. Z rezerwacjami i spot instances, koszt może być zredukowany do ~$500/miesiąc.

Ile faktycznie kosztuje AKS?

Zależy od obciążenia, ale oto realistyczne oszacowania:

• Mały klaster produkcyjny (2-3 węzły, Standard_D2s_v3): $150-250/miesiąc
• Średni klaster produkcyjny (3-5 węzłów, Standard_D4s_v3): $400-700/miesiąc
• Duży klaster produkcyjny (10+ węzłów, mieszane rozmiary): $1,500-3,000/miesiąc

To obejmuje compute, storage, load balancer i monitoring. Control plane jest za darmo (zarządzany przez Azure). Użyj Azure Pricing Calculator dla twojego konkretnego scenariusza.

Czy naprawdę potrzebuję Kubernetes czy to przesada?

Szczera odpowiedź: Kubernetes to przesada dla większości małych aplikacji. Rozważ alternatywy najpierw:

• Azure App Service: Idealny dla web apps, APIs, prostych deploymentów. Dużo prostszy.
• Azure Container Apps: Serverless kontenery z auto-scalingiem. Kubernetes pod spodem, ale zarządzany.
• Azure VMs: Wciąż ważne dla wielu obciążeń. Mniej skomplikowane niż Kubernetes.

Potrzebujesz Kubernetes gdy: masz 10+ mikroserwisów, potrzebujesz zaawansowanej orkiestracji, wymagasz multi-cloud portability, lub masz złożone wymagania skalowania.

AKS vs EKS vs GKE - który wybrać?

Wszystkie trzy to świetne zarządzane serwisy Kubernetes. Wybieraj na podstawie istniejącego clouda:

Moja rekomendacja: Jeśli jesteś już na Azure, użyj AKS. Jeśli na AWS, użyj EKS. Jeśli jesteś cloud-agnostic lub Kubernetes-first, GKE ma najlepsze doświadczenie Kubernetes.

Jak migrować istniejące aplikacje do AKS?

Strategia migracji zależy od obecnego setupu:

Typowy timeline migracji: 2-4 tygodnie dla prostych aplikacji, 2-3 miesiące dla złożonych mikroserwisów. Nie śpiesz się.