Lekcja 4 · Dzień 4 · ich aktualny ból
Migracja ECS → EKS
Framework, nie magia. JD mówi wprost: Kubernetes na produkcji jest szczególnie cenny, bo planują migrację. Jeśli nie robiłeś EKS na produkcji — nie kłam.
Po co migrują (hipotezy, które wolno wygłosić)
Nie znasz ich dokumentu wewnętrznego. Wolno powiedzieć „typowy powód i jak bym to zweryfikował”:
- DevEx / hiring: Helm, Argo, sidecary, standard rynku. 20 zespołów Java łatwiej zatrudnić na K8s niż na niszowy ECS task def.
- Autoscaling: HPA + Karpenter (szybkie node’y, occupancy) vs. ECS service scaling, które jest grubsze.
- Sidecary: mesh, mTLS, OTel, secrets CSI — w ECS da się, w K8s jest to produkt.
- Multi-tenant cells: Head of Platform mówi o dziale. Cell/cluster factory to wzorzec na izolację PCI i na US regiony.
- Koszt control plane: EKS to ~72 USD/miesiąc za cluster plus operacja. Przy 20 serwisach w 3 środowiskach to 9 klastrów albo 3 z namespace’ami — trade-off, który masz umieć policzyć.
Pytanie, które zadajesz im: „W jakim punkcie jest migracja? Co już żyje na EKS, co blokuje resztę?” To nie filler — od tego zależy, czy w Q1 bierzesz factory, czy gaszenie pożaru.
Co zostaje na ECS / Lambda, co idzie na EKS
| Zostaje | Idzie na EKS |
|---|---|
| Lambdy operacyjne (rotacja sekretów, dispatch) — nie ma sensu opakowywać w Deployment | Długie Java/Kotlin mikroserwisy, 20+ sztuk o wspólnym kształcie |
| PCI issuance, jeśli blast radius i zakres audytu rosną od kubelet/etcd — osobna decyzja, nie automat | Non-PCI prod-app, staging, dev |
| Zadania burst / cron o czasie < 15 min, taniej jako Lambda | Workerzy z persistent connections (Kafka consumers) |
| Jednorazowe taski Fargate, które i tak są batch | Serwisy z sidecarem (mesh, auth) |
PCI workload isolation
AWS w whitepaperze o EKS + PCI: osobne konto, osobny cluster CDE, izolacja podów na node’ach, SG, ograniczone API. Wspólny cluster „z namespace pci” to słaba historia dla QSA, chyba że segmentacja jest udowodniona pentestem (Req 11.4.5). Domyślnie: osobny cluster w PCI account.
Networking: SG vs NetworkPolicy, ALB Ingress, service discovery
- ECS awsvpc: ENI + security group per task. Model, który znają. W EKS VPC CNI: pod dostaje IP z VPC, SG for pods (jeśli włączone) albo tylko node SG.
- NetworkPolicy (Calico/Cilium/AWS): L3/L4 w klastrze. Nie zastępuje SG na granicy VPC. Warstwy: SG na ENI + NP w klastrze + (opcjonalnie) mesh mTLS.
- ALB Ingress: AWS Load Balancer Controller. Target type IP (pod) a nie instance — ważne przy Fargate i przy SG for pods. WCS: annotations, WAFv2, cert z ACM.
- Service discovery: ECS: Cloud Map / SRV. EKS: DNS
svc.cluster.local+ ewentualnie Cloud Map dla cross-cluster. Podczas migracji: stary serwis na ECS, nowy na EKS, wspólny ALB weighted albo Cloud Map z dwoma zestawami IP.
Rollout: shadow, % traffic, rollback
- Parity: ten sam obraz (digest) na ECS i na EKS. Różni się tylko runtime.
- Shadow: lustro ruchu (telegraf / proxy) na EKS, odpowiedzi odrzucane. Porównaj latency i errory. Nie na CHD w plaintext — shadow PCI wymaga tej samej izolacji.
- Weighted ALB / Route53: 5% → 25% → 50% → 100%. SLO jako hamulec: error budget, nie data w kalendarzu.
- Rollback: waga wraca na ECS w minuty. Deploy na EKS nie kasuje task def ECS, dopóki nie minie soak (np. 2 tygodnie, 1–2 payroll/settlement cycle).
- Stop condition: wzrost p99, 5xx, saturacja node, błędy IRSA, utrata logów.
Bez tygodnia downtime i bez 20 snowflake’ów
To jest pytanie z raportu. Odpowiedź-framework:
- Factory, nie 20 projektów. Jeden Helm/Kustomize chart (albo Terraform moduł
service) + values per serwis. Onboarding = PR z values, nie ticket „zróbcie nam YAMLe”. - Strangler per serwis, ten sam playbook. Kolejność: najpierw bezstanowe, niskie ryzyko, non-PCI. Potem Kafka consumers (offset, rebalance). Na końcu CDE, jeśli w ogóle.
- CI: ten sam reusable workflow buduje obraz. Deploy job dostaje
runtime: eks. Nie forkuje się pipeline’u na 20 sposobów. - Data plane zostaje. RDS, Kafka, Redis — te same endpointy. Zmienia się tylko compute. Dual-write piekła nie otwierasz.
- Okno: zero-downtime przez weighted traffic, nie przez „sobota 3:00 wyłączamy karty”. Fintech kartowy nie ma tygodnia na maintenance.
Operacja klastra
- Upgrade: EKS wspiera N i N-1 (sprawdź aktualny program wersji). Plan: addony → node groups → control plane, albo odwrotnie zgodnie z AWS. Test na staging cluster tej samej minor.
- Node groups vs Karpenter: managed node group = prostszy, wolniejszy scale, łatwiejszy patch. Karpenter = szybki provisioning, mniej pustych node’ów, więcej krawędzi (interruption, drift, OS). Raport pyta „Karpenter vs managed”. Dorosła odpowiedź: prod non-PCI może Karpenter, CDE raczej managed + frozen AMI, dopóki QSA i Ty nie śpicie spokojnie.
- Addony in-scope: CNI, kube-proxy, CoreDNS, CSI, telemetry. Każdy addon to powierzchnia PCI, jeśli cluster jest w CDE.
Jeśli nie robiłeś EKS na produkcji
„ECS znam z [skala]. K8s znam z [staging / home lab / poprzednia praca bez prod]. Migrację umiem zaplanować: factory chart, shadow, weighted ALB, osobny cluster PCI, rollback przez wagi. Pierwsze 90 dni: jeden serwis-pilot, nie 20 naraz.” To jest zgodne z JD i z raportem. Kłamstwo o produkcji wyjdzie na whiteboardzie.
Ćwiczenie
Wybierz 3 fikcyjne serwisy: receipts (bezstanowy), ledger (Kafka consumer), issuer (PCI). Ułóż kolejność, kryterium stop, rollback. 8 minut na głos.