Amazon ANS-C01: Sieci kontenerowe i bezserwerowe — Przewodnik do nauki

By Laurynas Brazys · 3 August 2026 · #amazon #ans-c01 #certification #exam-prep #study-guide

Część AWS Advanced Networking Specialty ANS-C01 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Amazon, albo rozwiąż testy na czas na ExamRoll.io.

Sieć w EKS (CNI, sieć podów)

Sieć podów w Amazon EKS jest zdominowana przez wtyczkę Amazon VPC CNI (amazon-vpc-cni-k8s), która nadaje każdemu podowi adres IP z VPC i umieszcza ruch podów bezpośrednio w sieci VPC. Taka architektura zapewnia przewidywalną kontrolę bezpieczeństwa na poziomie VPC (security groups, NACL) i routing o niskim opóźnieniu, ale wymaga starannego planowania pojemności adresów IP i ENI, ponieważ liczba dodatkowych adresów IPv4 na ENI oraz liczba ENI na typ instancji są ograniczone sprzętowo. DaemonSet aws-node zarządza alokacją adresów IP oraz operacjami dołączania/odłączania (attach/detach); jego ConfigMap jest edytowany za pomocą kubectl w celu dostrojenia zachowania (na przykład ustawienia WARM_IP_TARGET, WARM_ENI_TARGET lub ENABLE_PREFIX_DELEGATION). Delegacja prefiksów (prefix delegation) i tryby pod ENI zmniejszają ryzyko wyczerpania adresów IP na węzeł, pozwalając węzłowi na alokację całych prefiksów /28 do jednego ENI (ENABLE_PREFIX_DELEGATION=true) lub przez przypisanie dedykowanego ENI do każdego poda (co jest przydatne dla izolacji o wysokim poziomie bezpieczeństwa).

Alternatywy dla Amazon VPC CNI, takie jak Cilium (eBPF) lub Calico, mogą oferować inne kompromisy. Cilium może zastąpić kube-proxy i zaimplementować wysokowydajne przekierowywanie L3/L4 przy użyciu eBPF, włączyć transparentne szyfrowanie między węzłami (WireGuard lub IPsec) oraz zmniejszyć presję na adresy IP na poziomie węzła poprzez zastosowanie podejść typu overlay lub masquerading. Z Cilium nadal integrujesz się z routingiem VPC dla ruchu wychodzącego (egress) i przychodzącego (ingress), ale unikasz częstych operacji dołączania/odłączania ENI; ma to znaczenie przy wysokim wskaźniku rotacji podów (pod churn). Dla bardzo dużej liczby połączeń i ścisłego zachowania na warstwie L7, należy również rozważyć dostrojenie trybu kube-proxy (IPVS) oraz ustawień jądra systemu operacyjnego węzła: dostosuj conntrack_max, tcp_tw_recycle/tcp_tw_reuse i ip_local_port_range, i udostępnij je przez kubelet lub skrypty inicjalizacyjne daemonset, aby uniknąć wyczerpania portów efemerycznych przy tysiącach jednoczesnych, długotrwałych połączeń gRPC.

Tryby sieciowe ECS i integracja Lambda z VPC

Sieć zadań (task) w ECS ma trzy główne tryby: bridge, host i awsvpc. Tryb awsvpc jest najbardziej porównywalny do sieci podów w Kubernetes, ponieważ dołącza ENI do każdego zadania (lub grupy zadań) i przypisuje prywatny adres IP oraz security groups bezpośrednio do zadania. Tryb awsvpc konfiguruje się, podając awsvpcConfiguration z parametrami subnets i securityGroups w wywołaniach API RunTask lub CreateService. Fargate wymusza użycie trybu awsvpc, dzięki czemu zapewnia izolację sieciową na poziomie zadania i integruje się z AWS Cloud Map w celu odnajdywania usług (service discovery). Używaj trybu awsvpc, gdy potrzebujesz filtrowania ruchu na podstawie security groups dla każdego zadania lub gdy musisz udostępnić standardowy routing i metryki VPC.

Funkcje Lambda, które potrzebują dostępu do VPC, są dołączane do VPC za pomocą ENI w skonfigurowanych dla funkcji podsieciach i security groups. Te ENI są tworzone i zarządzane przez płaszczyznę sterowania Lambda, ale provisionowanie ENI może zwiększać opóźnienie zimnego startu (cold-start latency) i historycznie ograniczało szybkie skalowanie w górę, chyba że zostało to złagodzone przez provisioned concurrency lub przez użycie VPC endpoints (AWS PrivateLink) i starannie zaprojektowaną architekturę podsieci. Umieszczając wiele funkcji Lambda w VPC, upewnij się, że podsieci mają dostępne adresy IP, w razie potrzeby użyj NAT Gateway lub instancji NAT dla ruchu wychodzącego (egress) i preferuj VPC endpoints (punkty końcowe com.amazonaws.* przez AWS::EC2::VPCEndpoint), aby w miarę możliwości unikać kierowania ruchu wychodzącego przez internet. Monitoruj operacje dołączania/odłączania ENI za pomocą CloudWatch Logs i VPC Flow Logs, aby obserwować zachowanie podczas skalowania i rozwiązywać problemy z dławieniem (throttling) związanym ze współbieżnością.

App Mesh i odnajdywanie usług

AWS App Mesh używa kontenerów sidecar z Envoy jako płaszczyzny danych (data plane) i zapewnia obserwowalność L3–L7, kształtowanie ruchu (traffic shaping), ponawianie prób (retries) oraz kontrolę inicjowania/kończenia sesji TLS (origination/termination). Definiuj siatki (meshes), wirtualne węzły (virtual nodes) i wirtualne usługi (virtual services) za pomocą App Mesh API (CreateMesh, CreateVirtualNode, CreateVirtualService) lub kontrolera App Mesh dla Kubernetes. App Mesh obsługuje mTLS poprzez konfigurację bloku TLS listenera VirtualNode z clientPolicy i urzędem certyfikacji (certificate authority), a do dystrybucji certyfikatów można zintegrować go z AWS Certificate Manager (ACM) lub SDS. Należy jednak pamiętać, że kontenery sidecar App Mesh z założenia kończą i ponownie szyfrują ruch; jeśli wymóg nakazuje, aby ruch aplikacji pozostał zaszyfrowany end-to-end między klientem a podem aplikacji (bez deszyfracji w proxy sieciowym), musisz upewnić się, że TLS jest kończony tylko w podzie i unikać kończenia go na wejściu do siatki (mesh ingress) lub na load balancerze.

Odnajdywanie usług (service discovery) jest powszechnie realizowane za pomocą Kubernetes Services i CoreDNS dla EKS, za pomocą Cloud Map (CreateService, RegisterInstance) dla rozwiązań wieloplatformowych oraz za pomocą prywatnych stref hostowanych (private hosted zones) w Route 53 dla wyszukiwania opartego na DNS. AWS Cloud Map integruje się bezpośrednio z ECS i App Mesh, umożliwiając tworzenie rekordów SRV lub A oraz przeprowadzanie kontroli stanu (health checks) sterowanych przez API. W dynamicznych środowiskach, gdzie instancje szybko się skalują, połącz krótkie czasy życia DNS (TTL) z kontrolami stanu Cloud Map, aby uniknąć nieaktualnych odpowiedzi (stale resolution); jeśli potrzebujesz natychmiastowej spójności, użyj API płaszczyzny sterowania siatki usług (service mesh control-plane), aby pobierać punkty końcowe, zamiast polegać na buforowaniu DNS (DNS caching).

Wzorce projektowe i kompromisy

Projektując gRPC na dużą skalę z użyciem TLS i mTLS, musisz zdecydować, gdzie nastąpi zakończenie (terminacja) TLS. Zakończenie TLS na load balancerze (ALB) pozwala na odciążenie go z obsługi certyfikatów dzięki ACM i upraszcza ich rotację, ale narusza szyfrowanie end-to-end i nie może zapewnić wzajemnego TLS (mTLS) dla podów w backendzie, chyba że backend ponownie nawiąże połączenie TLS, wykorzystując przesłane dalej informacje o certyfikacie klienta. Aby uzyskać prawdziwe szyfrowanie mTLS end-to-end, w którym punkty końcowe aplikacji bezpośrednio uwierzytelniają klientów, użyj bramy L4 typu passthrough, takiej jak Network Load Balancer, i pozwól, aby to pod/aplikacja obsługiwały TLS/mTLS. Połącz typ celu NLB ip z adnotacją AWS Load Balancer Controller service.beta.kubernetes.io/aws-load-balancer-target-type: "ip", aby bezpośrednio rejestrować adresy IP podów; ten wzorzec dobrze się skaluje, ponieważ NLB jest zaprojektowany do obsługi milionów połączeń i wspiera długotrwałe sesje TCP/gRPC bez kończenia TLS.

W przypadku ruchu przychodzącego (ingress) i routingu opartego na ścieżce z terminacją HTTPS, Application Load Balancer jest bardziej odpowiedni, ponieważ obsługuje reguły oparte na hoście/ścieżce, przekierowania oraz integrację z WAF. Aby zachować adresy IP klientów, gdy ALB kończy sesję TLS, polegaj na nagłówkach X-Forwarded-For; serwery webowe w backendzie muszą odczytywać i logować X-Forwarded-For, a w celu weryfikacji należy włączyć logi dostępowe ALB. Jeśli na warstwie serwera potrzebujesz rzeczywistego adresu gniazda (socket) klienta (np. dla starszego oprogramowania), użyj NLB z proxy protocol v2 i upewnij się, że usługi backendowe wspierają ten protokół.

Łączność między usługami w wielu kontach AWS i sieciach VPC skaluje się różnie w zależności od zastosowanego wzorca. VPC peering jest prosty, ale jego zarządzanie rośnie w skali N^2; Transit Gateway centralizuje routing i lepiej skaluje się dla wielu sieci VPC dzięki segregacji tablic routingu; AWS PrivateLink (Interface VPC Endpoints) zapewnia najbardziej szczegółowy, świadomy tożsamości model dostępu dla poszczególnych usług, ponieważ usługa punktu końcowego jest udostępniana przez NLB, a konsumenci tworzą interfejsowe punkty końcowe w swoich sieciach VPC. W przypadku współdzielonych usług obejmujących wiele kont, z rygorystyczną kontrolą dostępu i skalowalnym wdrażaniem (onboarding), preferuj AWS PrivateLink, ponieważ izoluje on routing (brak zmian w tablicach routingu w sieciach VPC konsumentów) i wykorzystuje grupy bezpieczeństwa (security groups) do szczegółowej kontroli.

Częste pułapki i kryteria decyzyjne

Powtarzającą się pułapką jest zakładanie, że ten sam model sieciowy pasuje do wszystkich obciążeń. Obciążenia z połączeniami stanowymi lub długotrwałymi (gRPC, bazy danych) preferują przekazywanie na poziomie L4 (passthrough) za pomocą NLB z kończeniem TLS na poziomie poda lub wzorce hostPort/hostNetwork, aby uniknąć opóźnień wprowadzanych przez proxy. Z kolei mikrousługi HTTP, które wymagają routingu opartego na ścieżce, WAF lub kończenia połączeń WebSocket, odnoszą korzyści z funkcji ALB i App Mesh. Innym błędem jest nieuwzględnianie limitów ENI/IP podczas skalowania węzłów EKS lub zadań ECS w trybie awsvpc: zawsze należy sprawdzać tabelę typów instancji EC2 pod kątem liczby ENI i adresów IP na ENI oraz używać delegacji prefiksów lub nakładek Cilium, gdy potrzebna jest wysoka gęstość podów.

Monitorowanie i debugowanie wymagają wielu źródeł: VPC Flow Logs i metryk ENI, aby obserwować ruch wychodzący/przychodzący, metryk CloudWatch dla AWS Load Balancers (ActiveFlowCount, ProcessedBytes) oraz telemetrii na poziomie aplikacji z Envoy/App Mesh lub agenta AWS X-Ray. W przypadku Lambda i Fargate należy pamiętać, że zimne starty związane z operacjami na ENI można łagodzić za pomocą provisioned concurrency lub przez przeprojektowanie wzorców dostępu w celu użycia VPC endpoints i PrivateLink, aby funkcje nie potrzebowały szerokiego dostępu do sieci zewnętrznej.

Praktyczny problem: Scenariusz użycia

Nazwa firmy: Acme Payments Inc. Wyzwanie: Acme Payments uruchamia usługę gRPC na Amazon EKS, która musi obsługiwać tysiące jednoczesnych połączeń TLS na porcie TCP 443, używać wzajemnego TLS (mTLS), aby certyfikat klienta był weryfikowany przez usługę backendową, oraz umożliwiać automatyczne skalowanie klastra EKS za pomocą Cluster Autoscaler i HPA bez przerywania łączności i bez konieczności kończenia TLS na load balancerze.

Podejście w krokach:

1. Wdróż usługę z TLS na poziomie poda i wzajemnym uwierzytelnianiem zaimplementowanym w aplikacji lub w kontenerze sidecar, który nie kończy szyfrowania TLS end-to-end dla klientów zewnętrznych. Przechowuj certyfikaty serwera/klienta w AWS Secrets Manager i montuj je za pomocą Kubernetes CSI secrets store lub użyj mechanizmu dystrybucji certyfikatów, który współpracuje z cyklem życia poda.
2. Użyj AWS Load Balancer Controller do stworzenia Network Load Balancer poprzez adnotację usługi (service.beta.kubernetes.io/aws-load-balancer-type: “nlb”) i ustaw typ celu na IP (service.beta.kubernetes.io/aws-load-balancer-target-type: “ip”), a następnie utwórz listener TCP na porcie 443. Zapewni to, że NLB będzie realizował przekazywanie na poziomie L4 (passthrough) i nie będzie kończył szyfrowania TLS.
3. Skonfiguruj grupę docelową NLB z protokołem TCP i dynamicznie rejestruj adresy IP podów (Load Balancer Controller wywoła CreateTargetGroup i RegisterTargets). Upewnij się, że sprawdzanie stanu (health checks) jest ustawione na TCP lub niestandardową sondę opartą na TCP z krótkim interwałem, aby cele były szybko oznaczane jako zdrowe podczas autoskalowania (aws elbv2 create-target-group –protocol TCP –port 443 –target-type ip; aws elbv2 create-listener –protocol TCP –port 443 …).
4. Dostosuj Amazon VPC CNI, aby wspierał wysoką gęstość podów i zmniejszył rotację ENI: włącz delegację prefiksów, jeśli jest obsługiwana (ustaw ENABLE_PREFIX_DELEGATION=true w ConfigMap aws-node), skonfiguruj WARM_IP_TARGET, aby utrzymywać zapasowe adresy, i monitoruj metryki aws-node (logi daemonsetu w kube-system i niestandardowe metryki CloudWatch). Jeśli limity IP na poziomie węzła są problemem, rozważ użycie Cilium z eBPF dla wyższej gęstości podów i mniejszej liczby operacji na ENI.
5. Bezpieczne skalowanie klastra: upewnij się, że Cluster Autoscaler ma odpowiednie tagi grup węzłów i uprawnienia IAM, ustaw PodDisruptionBudgets i sprawdź, czy sprawdzanie stanu grupy docelowej oraz opróżnianie połączeń (connection draining) NLB są skonfigurowane tak, aby uniknąć zrywania długotrwałych połączeń gRPC podczas zmniejszania skali.
6. Zabezpieczenie rotacji i zaufania certyfikatów: zautomatyzuj rotację certyfikatów za pomocą ACM Private CA lub Secrets Manager i upewnij się, że pody pobierają zaktualizowane pakiety zaufanych certyfikatów (trust bundles) bez konieczności rekonfiguracji NLB. Użyj sond gotowości/żywotności (readiness/liveness probes) Kubernetes, które odzwierciedlają gotowość do uzgadniania mTLS.

Uzasadnienie ze strony AWS: Network Load Balancer w trybie celu IP zachowuje szyfrowanie TLS aż do poda (prawdziwe szyfrowanie end-to-end) i obsługuje miliony trwałych połączeń TCP, co czyni go odpowiednim dla tysięcy jednoczesnych sesji gRPC. Bezpośrednia rejestracja adresów IP podów pozwala uniknąć złożoności związanej z hostPort na każdym węźle lub rejestracją celów na poziomie instancji i bezproblemowo współpracuje z Cluster Autoscaler/HPA, ponieważ AWS Load Balancer Controller będzie rejestrował i wyrejestrowywał adresy IP podów w miarę ich skalowania. Dostosowanie VPC CNI lub przyjęcie płaszczyzny danych opartej na eBPF zapobiega wyczerpaniu adresów IP i zmniejsza opóźnienia związane z dołączaniem/odłączaniem ENI, co jest kluczowe dla szybkiego autoskalowania i obciążeń o dużej liczbie połączeń. Przechowywanie i dostarczanie artefaktów mTLS za pomocą Secrets Manager lub dostawcy CSI sprawia, że cykl życia certyfikatów jest łatwy w zarządzaniu bez ingerencji w load balancer.

← Automatyzacja · Wszystkie domeny

Przećwicz te pytania → · Testy na czas na ExamRoll.io →

Przeglądaj Amazon →