AKS Cilium NetworkPolicy: Migrace z Calico bez výpadku produkce

Když Microsoft na Build 2026 oznámil Azure CNI Powered by Cilium jako default pro nové AKS clustery, otevřela se otázka, kterou jsme v Creditas odkládali přes rok: kdy a jak migrovat existující produkční clustery z Calico. Tento článek je destilát toho, co jsme udělali, kde jsme se zasekli a co bych příště udělal jinak.

Proč Cilium a ne Calico

Calico v AKS funguje dobře, ale architektonicky stojí na iptables. To znamená:

• CPU overhead roste lineárně s počtem network policies – nad 50 politik začíná být měřitelný
• Conntrack table je single point of bottleneck při vysokém throughputu
• L7 filtering vyžaduje samostatný sidecar (Envoy přes Calico Enterprise)

Cilium místo iptables používá eBPF programy přímo v kernelu. Výsledek:

V mých Creditas measurements (8 nodes, ~200 podů, ~30 000 connections/s peak) byl výsledek jednoznačný:

p50 latency service-to-service:
  Calico:  1.8 ms
  Cilium:  1.2 ms  (-33%)
 
p99 latency:
  Calico:  18 ms
  Cilium:  11 ms   (-39%)
 
Worker node CPU (idle network policy load):
  Calico:  14% baseline
  Cilium:  8% baseline   (-43% relative)

Architektura migrace: nový cluster vs in-place

V AKS neexistuje přímý upgrade path z Calico na Cilium. Mám dvě možnosti:

Možnost A – in-place migrace (oficiálně podporovaná od léta 2024):

1. az aks update --network-policy cilium – povolí Cilium control plane
2. Vytvořte nové node pooly s --enable-cilium-dataplane
3. Drain starých nodes
4. Odstraňte stará nodepools

Problém: každý node pool musíte recreate. Pro cluster s 10 specializovanými pooly to jsou 3 týdny opatrných operací. A během migrace běží Cilium i Calico souběžně, což přidává nečekanou složitost.

Možnost B – paralelní nový cluster (co jsme udělali v Creditas):

1. Provisioning nového AKS clusteru s Cilium od začátku
2. GitOps (Flux) zkopíruje workloady do nového clusteru
3. Postupný cutover trafficu (DNS + Front Door)
4. Smazat starý cluster

V Creditas trval cutover 6 týdnů s nulovým výpadkem produkce. Doporučuji opci B pro kohokoliv s GitOps – je čistší a vratná.

Nový cluster s Cilium: Bicep template

resource aks 'Microsoft.ContainerService/managedClusters@2024-09-01' = {
  name: 'aks-prod-cilium'
  location: location
  identity: { type: 'SystemAssigned' }
  sku: {
    name: 'Base'
    tier: 'Standard'
  }
  properties: {
    kubernetesVersion: '1.31.0'
    dnsPrefix: 'aksprodcil'
    networkProfile: {
      networkPlugin: 'azure'
      networkPluginMode: 'overlay'
      networkDataplane: 'cilium'      // KLÍČOVÉ – Cilium dataplane
      networkPolicy: 'cilium'          // Cilium NetworkPolicy enforcement
      loadBalancerSku: 'standard'
      serviceCidr: '10.0.0.0/16'
      dnsServiceIP: '10.0.0.10'
      podCidr: '10.244.0.0/16'        // overlay pod CIDR
    }
    agentPoolProfiles: [
      {
        name: 'system'
        count: 3
        vmSize: 'Standard_D4s_v5'
        osSKU: 'AzureLinux'
        mode: 'System'
        availabilityZones: ['1', '2', '3']
      }
    ]
    addonProfiles: {
      azureKeyvaultSecretsProvider: {
        enabled: true
        config: { enableSecretRotation: 'true' }
      }
    }
    securityProfile: {
      workloadIdentity: { enabled: true }
    }
    oidcIssuerProfile: { enabled: true }
  }
}

Tři kritické vlastnosti:

1. networkDataplane: 'cilium' – aktivuje Cilium eBPF dataplane (vs 'azure' = iptables)
2. networkPolicy: 'cilium' – musí být cilium (ne calico, ne prázdné)
3. networkPluginMode: 'overlay' – Cilium podporuje overlay i bez overlay; overlay je doporučená pro nové clustery (oddělí pod CIDR od VNet)

Migrace stávajících NetworkPolicy

Dobrá zpráva: stávající kind: NetworkPolicy manifesty fungují beze změny. Cilium plně implementuje Kubernetes NetworkPolicy API.

# Existující Calico policy – funguje na Cilium beze změny
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allow-frontend
  namespace: prod
spec:
  podSelector:
    matchLabels: { app: api }
  policyTypes: [Ingress]
  ingress:
  - from:
    - podSelector:
        matchLabels: { app: frontend }
    ports:
    - protocol: TCP
      port: 8080

Migration check je triviální – kubectl apply na nový cluster a cilium policy get v cilium-cli.

Přidání CiliumNetworkPolicy pro pokročilé use cases

Tady začíná zábava. Standardní NetworkPolicy je L3/L4 (IP + port). Cilium přidává L7 (HTTP method, path, headers):

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-l7-restrictions
  namespace: prod
spec:
  endpointSelector:
    matchLabels: { app: api }
  ingress:
  - fromEndpoints:
    - matchLabels: { app: frontend }
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: GET
          path: "/api/v1/.*"
        - method: POST
          path: "/api/v1/items"
          headers:
          - "X-Tenant-ID: .+"

Co tahle politika vynutí:

• Frontend smí volat API přes HTTP
• Pouze GET /api/v1/* a POST /api/v1/items
• POST musí mít X-Tenant-ID header (multi-tenancy)
• Vše ostatní (PUT, DELETE, jiné paths) blokováno na úrovni kernelu, ne aplikační

Žádná aplikační změna, žádný Envoy sidecar, žádný API gateway. eBPF program v kernelu rozhoduje na L7 vrstvě.

Identity-aware policies (game changer)

Druhá killer feature Cilium pro nás v Creditas: policy podle ServiceAccount identity, ne podle pod labels.

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: db-access-by-sa
  namespace: prod
spec:
  endpointSelector:
    matchLabels: { app: postgres }
  ingress:
  - fromEndpoints:
    - matchLabels:
        # Cilium-specific: ServiceAccount jako identity
        io.cilium.k8s.policy.serviceaccount: api-sa
    toPorts:
    - ports: [{ port: "5432", protocol: TCP }]

Proč to je důležité: pod labels lze podvrhnout (kompromitovaný pod, RBAC díra). ServiceAccount identity je vázán na Kubernetes auth subsystem a nelze ho spoofovat z compromised podu. Pro regulovaný workload (PCI, GDPR) zásadní rozdíl.

Cutover plan: 6 týdnů Creditas

Klíčové: Front Door routing rules s percentage-based split umožnily granulární cutover bez DNS TTL pain. Pokud nepoužíváte Front Door, lze stejnou strategii realizovat přes Application Gateway nebo external load balancer.

Tři pasti, kde jsme se zasekli

1. CoreDNS v Cilium clusteru nezapneme NodeLocal DNS Cache automaticky – v existujícím clusteru jsme to měli enabled, v novém ne. Detekováno po týdnu – některé DNS lookups byly o 5–8 ms pomalejší. Fix: az aks update --enable-node-local-dns
2. Cilium Hubble (observability) není default-on – musíte explicitně povolit --enable-hubble. Bez Hubble nemáte flow visibility, což ztěžuje debug policy issues
3. CiliumNetworkPolicy syntax error blokuje deploy – Calico je benevolentnější. CiliumNetworkPolicy striktní validation – jakákoliv chyba v CRD nasazení selže. Doporučuju cilium policy validate jako pre-commit hook

Závěr

Migrace AKS z Calico na Cilium není trivialita, ale 2026 je rok, kdy se vyplatí. 35% snížení p99 latence a 10% snížení CPU na worker nodes ospravedlní 6týdenní migraci v každém prostředí s vážným trafficem. CiliumNetworkPolicy s L7 a identity-aware filteringem otevírá use cases, které jsme dosud řešili Istio sidecars.

Pokud plánujete podobnou migraci nebo nový AKS cluster v 2026, podívejte se na naše služby cloudové architektury nebo se ozvěte pro Cilium migration walkthrough.