Microsoft AZ-400: Konteneryzacja i Kubernetes — Przewodnik do nauki

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Część Microsoft DevOps Engineer Expert AZ-400 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Microsoft, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Konteneryzacja i Kubernetes stanowią podstawę nowoczesnego DevOps na platformie Azure, łącząc powtarzalne procesy budowania, bezpieczną dystrybucję oraz deklaratywną, samonaprawiającą się orkiestrację w czasie rzeczywistym. Opanowanie tych technologii wymaga zrozumienia, jak obrazy są tworzone i optymalizowane, jak rejestry replikują i poświadczają zawartość, jak projektować i aktualizować AKS bez zakłóceń, jak wdrażać progresywne dostarczanie oraz jak kompleksowo zabezpieczać obciążenia robocze. Poza czystym Kubernetesem, wykorzystasz Helm do paczkowania, GitOps do uzgadniania stanu, a w obszarze bezserwerowym – Azure Container Apps z Dapr i KEDA, aby uprościć wzorce mikroserwisów i skalowanie oparte na zdarzeniach. Poniższe sekcje omawiają kluczowe decyzje platformowe i praktyki operacyjne, które są niezbędne do wdrożenia solidnych, zgodnych z wymogami pipeline’ów i odpornych klastrów produkcyjnych.

Podstawy budowania i rejestru: Docker i ACR

Wydajny obraz kontenera zaczyna się od deterministycznego pliku Dockerfile i zdyscyplinowanego kontekstu budowania. Budowanie wieloetapowe (multi-stage builds) pozwala oddzielić etapy kompilacji, wymagające wielu narzędzi, od małych obrazów uruchomieniowych. Na przykład, skompiluj plik binarny .NET lub Go w etapie budującym (builder stage), a następnie skopiuj tylko skompilowany artefakt do obrazu bazowego typu distroless lub minimalnego (np. mcr.microsoft.com/dotnet/runtime-deps lub gcr.io/distroless/base), co skutkuje mniejszą powierzchnią ataku i krótszym czasem pobierania obrazu. Każda instrukcja RUN, COPY i ADD tworzy nową warstwę; należy tak restrukturyzować pliki Dockerfile, aby zmaksymalizować trafienia w pamięci podręcznej warstw (layer cache), umieszczając rzadko zmieniające się kroki na końcu i agregując polecenia w logiczne grupy, zachowując przy tym czytelność. Zawsze dołączaj plik .dockerignore, aby wykluczyć bin/obj, node_modules, testy, dokumentację i sekrety; zbyt duży kontekst budowania spowalnia wysyłanie i zmniejsza skuteczność zdalnej pamięci podręcznej. Używaj deterministycznych instalacji pakietów (przypinanie wersji, pliki lock) i ostrożnie korzystaj z argumentów budowania; pliki specyficzne dla środowiska powinny być dostarczane poprzez konfigurację w czasie uruchomienia, a nie być częścią niezmiennych obrazów.

Azure Container Registry (ACR) to podstawa przechowywania i dystrybucji obrazów. Wykorzystaj zadania ACR (ACR Tasks), aby przenieść proces budowania do Azure: szybkie zadania do budowania na żądanie (az acr run), zadania zautomatyzowane wyzwalane przez commity Git, aktualizacje obrazu bazowego lub harmonogramy, oraz wieloetapowe pliki YAML zadań do tworzenia obrazów wieloarchitekturowych za pomocą Buildx. Replikacja geograficzna (warstwa Premium SKU) replikuje artefakty między regionami, minimalizując opóźnienia w pobieraniu i koszty transferu wychodzącego dla wdrożeń AKS/ACA w wielu regionach; połącz ją z prywatnymi punktami końcowymi i RBAC o zakresie repozytorium, aby stosować zasadę najmniejszych uprawnień. Włącz zaufanie do zawartości (content trust), aby podpisywać obrazy i weryfikować ich pochodzenie: mechanizmy takie jak Docker Content Trust/Notary i rozwijające się ekosystemy podpisów OCI (np. cosign) mogą być wymuszane na etapie przyjmowania do klastra (admission) za pomocą ograniczeń OPA Gatekeeper, które wymagają podpisów dla chronionych przestrzeni nazw. Zintegruj skanowanie podatności: Microsoft Defender for Cloud skanuje obrazy podczas operacji push oraz w spoczynku, ujawnia numery CVE wraz z zaleceniami dotyczącymi naprawy i może bramkować wdrożenia za pomocą Azure Policy i kontroli CI; wdróż automatyzację odświeżania obrazów bazowych, aby zredukować liczbę warstw ze znanymi podatnościami.

Produktywność deweloperów i kontenery bezserwerowe na Azure

Narzędzia integracji DevOps w AKS usprawniają wewnętrzne pętle deweloperskie (inner loops). Draft wykrywa frameworki językowe i tworzy szkielety dla plików Dockerfile, chartów Helm i konfiguracji uruchomieniowych, przyspieszając konteneryzację. Bridge to Kubernetes przekierowuje wywołania usług z działającego klastra na lokalną stację roboczą, pozwalając na iteracyjne rozwijanie i debugowanie pojedynczej mikrousługi lokalnie, podczas gdy reszta działa w klastrze z rzeczywistymi danymi i zależnościami. Usługa Azure Dev Spaces została wycofana; Bridge to Kubernetes jest wspieranym rozwiązaniem do lokalnego developmentu i integruje się z VS Code oraz Visual Studio.

Azure Container Apps (ACA) oferuje bezserwerowe, w pełni zarządzane środowisko uruchomieniowe dla mikrousług i zadań bez konieczności zarządzania Kubernetesem. Każde wdrożenie tworzy rewizję; można kierować ruch pomiędzy rewizjami procentowo, realizując wdrożenia typu blue-green lub canary za pomocą jednego polecenia lub zmiany w pliku YAML. Natywna integracja z Dapr umożliwia wywoływanie usług, pub/sub, powiązania (bindings), magazyny stanu i sekrety bez potrzeby tworzenia niestandardowych rozwiązań; a komponenty wtyczkowe (np. Azure Service Bus, Key Vault, Cosmos DB) przyspieszają wdrażanie spójnych funkcjonalności międzyusługowych. KEDA napędza automatyczne skalowanie sterowane zdarzeniami w oparciu o współbieżność HTTP i ponad 60 skalerów (m.in. Azure Queue/Service Bus, Kafka, Prometheus, niestandardowe), umożliwiając skalowanie do zera w celu optymalizacji kosztów. Użyj środowisk ACA (ACA Environments) do izolacji sieciowej i integracji z VNET, połącz ACR za pomocą tożsamości zarządzanej (managed identity) i zarządzaj konfiguracją poprzez pliki YAML containerapps, aby zachować deklaratywną zgodność z praktykami GitOps.

Praktyczny scenariusz problemowy

Firma Adobe musi zmodernizować wieloregionową usługę analityki klientów, zmniejszając ryzyko związane z wydaniami i jednocześnie wzmacniając bezpieczeństwo łańcucha dostaw oraz środowiska uruchomieniowego. Zespół musi ustandaryzować proces budowania aplikacji, zautomatyzować bezpieczne wdrożenia (rollouts) i zapewnić szybkie, zgodne z regulacjami dostarczanie oprogramowania w USA i UE.

1. Wdrożenie wieloetapowych plików Dockerfile i .dockerignore dla wszystkich usług

• Dlaczego: Minimalizuje rozmiar obrazu i powierzchnię ataku, poprawia trafienia w pamięć podręczną budowania (build cache) i zapobiega przypadkowemu dołączeniu do obrazu sekretów lub dużych zasobów testowych.

2. Budowanie i podpisywanie obrazów za pomocą ACR Tasks, wypychanie do geograficznie replikowanego ACR

• Dlaczego: Budowanie w chmurze eliminuje lokalne rozbieżności; wyzwalacze aktualizacji obrazu bazowego zmniejszają ekspozycję na CVE. Georeplikacja w ACR w wersji Premium umieszcza artefakty w tej samej lokalizacji co klastry AKS, redukując opóźnienia i ruch wychodzący (egress). Podpisy cyfrowe zapewniają możliwość śledzenia pochodzenia (provenance).

3. Włączenie skanowania obrazów przez Defender for Cloud i egzekwowanie polityk za pomocą bramek CI oraz OPA Gatekeeper

• Dlaczego: Skanowanie podczas wypychania (push) i w spoczynku (at rest) wcześnie wykrywa podatności CVE. Ograniczenia Gatekeepera wymuszają polityki takie jak „tylko zatwierdzone rejestry”, „wymagane podpisane obrazy” i limity zasobów, uniemożliwiając dopuszczenie do uruchomienia niebezpiecznych obciążeń.

4. Provisioning prywatnych klastrów AKS w każdym regionie z Azure CNI, politykami sieciowymi i tożsamością zarządzaną

• Dlaczego: Prywatne punkty końcowe (private endpoints) ograniczają ekspozycję płaszczyzny sterowania; Azure CNI integruje się z korporacyjnymi sieciami VNET; polityki sieciowe ograniczają ruch boczny (lateral movement); tożsamość zarządzana eliminuje rozprzestrzenianie się sekretów.

5. Utworzenie oddzielnych pul węzłów (node pools) systemowych i użytkownika, dodanie pul spot dla zadań wsadowych

• Dlaczego: Izoluje krytyczne pody platformy, zapewnia efektywną kosztowo pojemność dla mniej krytycznych obciążeń oraz upraszcza aktualizacje i zarządzanie SLO.

6. Zastosowanie Helm do pakowania aplikacji, z chartami przechowywanymi w ACR (OCI), wdrażanie za pomocą Azure Pipelines

• Dlaczego: Spójne, wersjonowane wydania z wartościami dla każdego środowiska. Potoki (Pipelines) uruchamiają helm lint, dry-run i diff przed wykonaniem helm upgrade, używając połączenia serwisowego Kubernetes do docelowych klastrów.

7. Wdrożenie Flux v2 do uzgadniania stanu w modelu GitOps i wykrywania dryfu, integracja z Flagger dla wdrożeń canary

• Dlaczego: Deklaratywna synchronizacja oparta na modelu pull zmniejsza liczbę poświadczeń w CI i zapewnia zbieżność stanu. Flagger automatyzuje wdrożenia canary z ważonym ruchem w oparciu o SLO, wykorzystując metryki z NGINX Ingress i wycofując zmiany w przypadku błędów lub skoków opóźnień.

8. Konfiguracja aktualizacji kroczących (rolling updates) z PDB i sondami gotowości/uruchomienia (readiness/startup probes); użycie wdrożeń blue-green dla ryzykownych komponentów

• Dlaczego: Aktualizacje kroczące zachowują pojemność; sondy chronią ruch użytkowników. Wdrożenie blue-green ze zmianą etykiety w usłudze (Service) umożliwia natychmiastowe wycofanie zmian dla komponentów wysokiego ryzyka, takich jak brama API.

9. Wprowadzenie siatki usług (service mesh) Istio z rygorystycznym mTLS, ponowieniami prób (retries) i limitami czasu (timeouts); eksport telemetrii do Application Insights

• Dlaczego: Szyfrowanie w całej siatce, solidne polityki ruchu i jednolita obserwowalność. Kolektory OpenTelemetry wysyłają ślady (traces) i metryki do centralnego magazynu w celu monitorowania SLO i analizy incydentów (incident triage).

10. Ustanowienie kontrolowanej strategii aktualizacji z kanałem automatycznych aktualizacji AKS i aktualizacjami obrazów węzłów

• Dlaczego: Regularne, przewidywalne aktualizacje platformy zmniejszają ryzyko związane z podatnościami zero-day. Max-surge i PDB zapewniają minimalne zakłócenia; aktualizacje oddzielnych pul węzłów użytkownika ograniczają promień rażenia (blast radius).

11. Użycie Bridge to Kubernetes do wewnętrznej pętli deweloperskiej (inner-loop); tworzenie szkieletów za pomocą Draft

• Dlaczego: Deweloperzy debugują lokalnie, korzystając z zależności w klastrze, bez potrzeby ich mockowania. Draft przyspiesza spójną konteneryzację i tworzenie szkieletów Helm w różnych zespołach.

12. Przeniesienie rzadziej używanych usług (long-tail services) do Azure Container Apps z Dapr i KEDA

• Dlaczego: Sterowane zdarzeniami mikrousługi skalujące się do zera (np. do pozyskiwania i wzbogacania danych) działają tanio, z wbudowanym podziałem ruchu dla wdrożeń canary; komponenty Dapr standaryzują wywołania międzyusługowe i pub/sub bez potrzeby pisania niestandardowego kodu.

Ten kompleksowy projekt łączy determinizm procesu budowania z bezpieczną dystrybucją, operacjami deklaratywnymi i progresywnym dostarczaniem (progressive delivery), zapewniając firmie Adobe szybkie wydania o niskim ryzyku oraz wzmocnione środowisko uruchomieniowe w różnych regionach.

← Infrastruktura jako kod i zarządzanie konfiguracją · Wszystkie domeny · Zarządzanie wydaniami i strategie wdrażania →

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

Przeglądaj Microsoft →