Planowanie wdrożenia usługi Container Apps w usłudze Kubernetes z obsługą usługi Azure Arc

Skorzystaj z tego artykułu przed instalacją rozszerzenia Container Apps na klastrze produkcyjnym. Container Apps w Azure Arc korzysta z zasobów pojemnościowych i usług platformy udostępnianych przez klaster Kubernetes. Decyzje dotyczące węzłów, równoważenia obciążenia, DNS, łączności wychodzącej, przechowywania danych, tożsamości, logowania i aktualizacji wpływają na dostępność aplikacji.

Skorzystaj z sekcji w tym artykule, aby zidentyfikować wymagania wdrożenia i zweryfikować wymagania wstępne przed instalacją.

Zakres planowania

Container Apps on Azure Arc obejmuje zasoby Azure, istniejący klaster Kubernetes oraz wdrożone aplikacje. Zaplanuj następujące obszary:

Area	Planowanie danych wejściowych
Zasoby zarządzania platformą Azure	Połączony klaster, rozszerzenie klastra, niestandardowa lokalizacja, środowisko połączone, rejestracja dostawcy, Azure RBAC, organizacja zasobów, aplikacje kontenerowe i zadania
Klaster Kubernetes	Obsługiwana dystrybucja i wersje, węzły, pojemność, cykl życia Kubernetes i systemu, bezpieczeństwo klastra, kopie zapasowe oraz odzyskiwanie po awarii
Sieć	`LoadBalancer` implementacja, adresy IP, routing, zapory sieciowe, DNS, certyfikaty, łączność wychodząca oraz zależności aplikacji
Workloads	Obrazy, rewizje, skalowanie i konfiguracja zadań, dane, sondy zdrowotne, wpisy tajne oraz wymagania dotyczące zasobów
Observability	Diagnostyka Kubernetes, opcjonalna integracja z Log Analytics, dostęp, przechowywanie, alerty oraz koszty pozyskiwania danych

Obsługiwana topologia i macierz wersji

Skorzystaj z najnowszej aktualizacji Kubernetes wspieranej przez producenta, którą obsługuje również Kubernetes z Azure Arc. Dokumentacja Container Apps nie publikuje osobnego zakresu wersji Kubernetes dla każdej dystrybucji. Zweryfikowaj dokładną dystrybucję i wersję Kubernetes z pomocą Microsoft przed instalacją produkcyjną lub aktualizacją.

Poniższa macierz rejestruje obecnie opublikowane wsparcie dystrybucji. Przed każdą instalacją ponownie zweryfikuj to pod kątem Available extensions for Azure Arc-enabled Kubernetes clusters oraz Azure Container Apps on Azure Arc limitations.

Distribution	Wersja rozwiązania Kubernetes	Węzły	Moduł równoważenia obciążenia	Przygotowanie DNS	Zweryfikowany sterownik pamięci	Cykl wydawniczy rozszerzenia	Status	Ostatnia weryfikacja
Azure Kubernetes Service (AKS)	Aktualna wersja wspierana przez producenta; potwierdzam kompatybilność rozszerzeń	Linux `amd64`	Implementacja usług Kubernetes `LoadBalancer`	Weryfikacja generowanych i niestandardowych nazw aplikacji	SMB CSI driver 1.18.0 lub nowszy dla Azure Files SMB	`stable`	Supported	2026-09-03
Usługa AKS w środowisku lokalnym platformy Azure	Aktualna wersja wspierana przez producenta; potwierdzam kompatybilność rozszerzeń	Linux `amd64`	HAProxy lub inny obsługiwany balanser obciążenia skonfigurowany przed instalacją	Niestandardowy wymóg CoreDNS; weryfikacja generowanych i niestandardowych nazw aplikacji	SMB CSI driver 1.18.0 lub nowszy dla Azure Files SMB	`stable`	Supported	2026-09-03
Azure Red Hat OpenShift	Aktualna wersja wspierana przez producenta; potwierdzam kompatybilność rozszerzeń	Linux `amd64`	Implementacja platformy `LoadBalancer`	Weryfikacja generowanych i niestandardowych nazw aplikacji	SMB CSI driver 1.18.0 lub nowszy dla Azure Files SMB	`stable`	Supported	2026-09-03
Aparat Google Kubernetes	Aktualna wersja wspierana przez producenta; potwierdzam kompatybilność rozszerzeń	Linux `amd64`	Implementacja platformy `LoadBalancer`	Weryfikacja generowanych i niestandardowych nazw aplikacji	SMB CSI driver 1.18.0 lub nowszy dla Azure Files SMB	`stable`	Supported	2026-09-03
Platforma Kontenerowa OpenShift	Aktualna wersja wspierana przez producenta; potwierdzam kompatybilność rozszerzeń	Linux `amd64`	Implementacja platformy `LoadBalancer`	Weryfikacja generowanych i niestandardowych nazw aplikacji	SMB CSI driver 1.18.0 lub nowszy dla Azure Files SMB	`stable`	Supported	2026-09-03

Rozszerzenie nie jest obsługiwane na węzłach Windows ani klastrzach Arm64. Platforma rozszerzeń Arc wymaga co najmniej jednego odpowiedniego węzła linux/amd64, ale wdrożenie produkcyjne wymaga wystarczającej liczby odpowiednich węzłów na potrzeby rozszerzenia, obciążeń roboczych, aktualizacji oraz na wypadek awarii.

Na klastrze może działać tylko jedna obsługiwana instalacja KEDA. Określ, czy KEDA zostanie zainstalowana przez rozszerzenie Container Apps, czy już istnieje na klastrze. Jeśli KEDA już istnieje, zatrzymaj się i potwierdź obsługiwaną konfigurację współistnienia przed kontynuacją. Nie usuwaj istniejącej instalacji KEDA ani nie stosuj ustawień nieudokumentowanych rozszerzeń, bo inne obciążenia mogą od tego zależeć.

Wymagania pojemności

Zaplanuj wydajność dla:

Stałe komponenty oraz komponenty na węzeł rozszerzenia Container Apps wymienione w sekcji Zasoby utworzone przez rozszerzenie Container Apps.
Maksymalna oczekiwana liczba replik każdej aplikacji kontenerowej.
Jednoczesne wykonywanie zadań i serie powtórek.
Dapr sidecary i sidecary aplikacyjne.
Systemowe obciążenia Kubernetes i inni dzierżawcy klastra.
Stopniowe aktualizacje węzłów i rozszerzeń.
Przynajmniej jedna awaria węzła w wysoko dostępnym wdrożeniu.

Ustawienie maksymalnej liczby replik aplikacji nie zarezerwuje pojemności klastra.

Minimalna pojemność instalacyjna

Nie ma uniwersalnej minimalnej konfiguracji produkcyjnej, ponieważ różnią się rozmieszczenie rozszerzeń, włączone składniki, liczba węzłów, obciążenia daemonów, instalacja KEDA, usługa Log Analytics, korzystanie z Dapr oraz wymagania obciążeń. Użyj opublikowanych żądań komponentów rozszerzenia jako punktu wyjścia i mierz zasoby węzła przydzielalne, a nie całkowite. Rozmiar klastra ewaluacyjnego nie jest rekomendacją dotyczącą rozmiarów produkcji.

Przed instalacją zarejestruj:

Przydzielalne zasoby procesora i pamięci na kwalifikujących się linux/amd64 węzłach.
Liczba węzłów i rozmieszczenie w domenie awarii.
Dostępna pula adresów IP dla podów i usług.
Aktualne żądania systemu i tenantów oraz limity.
Zasoby są niedostępne z powodu taintów, afinity, limitów zasobów lub budżetów zakłóceń.

Oszacowanie zdolności obciążenia pracą

Dla każdego zastosowania oblicz:

peak capacity = maximum replicas x (application requests + sidecar requests)

Dodaj maksymalną liczbę równoczesnych zadań, dodatkową pojemność, rezerwę systemową, zapas na potrzeby aktualizacji oraz rezerwę na wypadek awarii. Upewnij się, że etykiety węzłów, zanieczyszczenia, reguły powinowactwa i fragmentacja zasobów nie sprawiają, że nominalnie wolna pojemność nie da się rozmieszczać.

Zweryfikowaj plan, planując reprezentatywne obciążenia i symulując odpływ węzłów. Potwierdź, że moduły rozszerzenia i wymagane repliki obciążenia pozostają gotowe.

Wymagania dotyczące sieci

Container Apps on Azure Arc wymagają kilku odrębnych ścieżek sieciowych:

Ścieżka	Kierunek	Requirement
Azure Arc agenci i zarządzanie rozszerzeniami	Wychodzące z klastra	HTTPS przez port TCP 443 do punktów końcowych wymaganych przez usługę Azure Arc, lokalizacje niestandardowe, tożsamość i pobieranie obrazów rozszerzeń. Dla wymaganych punktów końcowych usługi Service Bus musi być dozwolona obsługa protokołu WebSockets. Cluster Connect z Azure RBAC może również wymagać wychodzącego TCP 8084.
Wejście aplikacji	Przychodzące z zamierzonych sieci klienckich	Ruch klientów musi docierać do adresu IP przypisanego usłudze wejściowej rozszerzenia `LoadBalancer` na portach nasłuchiwania używanych przez wdrożenie, zwykle HTTP lub HTTPS.
Zależności aplikacji	Wychodzące z kapsuł aplikacyjnych	Dostęp przez system DNS i sieć do rejestrów, punktów końcowych usług tożsamości, magazynów danych, źródeł zdarzeń, usług certyfikatowych oraz wszelkich innych zależności aplikacji.
Wewnętrzny ruch klastra	W obrębie klastra	Pod-to-pod, pod-to-service, DNS, webhook do przyjęcia, sonda zdrowotna oraz ruch na płaszczyźnie sterowania wymagany przez dystrybucję i rozszerzenie.

Użyj wymagań sieciowych dla usługi Kubernetes z obsługą usługi Azure Arc jako oficjalnej listy punktów końcowych. Nie kopiuj listy punktów końcowych do zestawu reguł zapory bez wyboru odpowiedniej chmury Azure i włączonych funkcji Arc. Testuj każdą wymaganą w pełni kwalifikowaną domenę (FQDN) z sieci klastra. Wymagania Arc mówią, że punkty końcowe HTTPS używają oficjalnie podpisanych i weryfikowalnych certyfikatów. Potwierdź działanie serwera proxy i inspekcji TLS w klastrze nieprodukcyjnym; nieobsługiwane przechwytywanie lub niezaufany certyfikat zastępczy mogą uniemożliwić agentom i składnikom rozszerzeń nawiązywanie połączeń.

Wybrana LoadBalancer implementacja określa pulę adresów, sondy zdrowotne, trasowanie oraz wymaganą pojemność. Jeśli niestandardowy moduł równoważenia obciążenia wymaga zarezerwowanego adresu, najpierw zarezerwuj ten adres i podaj go w ustawieniu rozszerzenia loadBalancerIp podczas instalacji. Porty sondy kondycji i zakresy adresów źródłowych zależą od implementacji; należy je pobrać z wybranego modułu równoważenia obciążenia, zamiast zakładać, że obowiązują domyślne ustawienia usługi Azure Load Balancer.

Bazowy klaster Kubernetes z obsługą usługi Arc kontroluje ograniczenia sieciowe dla połączonego środowiska. Jeśli zależność aplikacji używa prywatnego punktu końcowego, sprawdź z poziomu poda aplikacji, czy klaster może rozpoznać jej nazwę DNS i kierować ruch do jej prywatnego adresu IP. Aplikacje potrzebujące informacji IP klienta powinny weryfikować nagłówki przekazywania generowane przez wybrany load balancer i łańcuch proxy oraz definiować, którym proxym ufać.

Weryfikowanie sieci

Wdroż usługę testową Kubernetes LoadBalancer i potwierdź, że otrzymuje adres dostępny z każdej docelowej sieci klienckiej.
Z odpowiedniego węzła klastra lub panelu diagnostycznego rozwiązuj i łącz się z każdym wymaganym punktem końcowym Azure Arc oraz zależnością obciążenia.
Potwierdź, że proxy pozwala na wymagany ruch HTTPS i WebSocket i nie zastępuje certyfikatów niezaufanym emitentem.
Potwierdź, że DNS klastra, ruch między podami, usługi, webhooki kontroli dostępu oraz sondy kondycji modułu równoważenia obciążenia działają zgodnie z zamierzonymi zasadami sieciowymi.
Po zainstalowaniu rozszerzenia potwierdź, że usługa Ingress otrzymała docelowy adres IP i jest dostępna, zanim utworzysz produkcyjne rekordy DNS.

Wymagania dotyczące systemu DNS

Po zainstalowaniu rozszerzenia wdroż aplikację testową, a następnie pobierz wygenerowaną dla niej nazwę FQDN. Sprawdź, czy FQDN rozwiązuje i dociera do rozszerzenia z każdej docelowej sieci klienckiej. Nazwa środowiska połączonego stanowi część wygenerowanej domeny aplikacji, więc wybierz ją świadomie.

W zastosowaniach wewnętrznych stosuj DNS z podziałem horyzontu, gdy klienci wewnętrzni i zewnętrzni wymagają różnych odpowiedzi. Zidentyfikuj autorytatywną strefę DNS, czas życia rekordu (TTL) oraz wymagania dotyczące odzyskiwania. Ustal, czy aplikacje korzystają z wygenerowanej domeny, domen niestandardowych, czy obu i innych, oraz zaplanuj wydawanie i odnawianie certyfikatów przed wdrożeniem.

Zweryfikuj DNS i ruch przychodzący z każdej zamierzonej sieci klienckiej:

nslookup <APPLICATION_FQDN>
curl --verbose https://<APPLICATION_FQDN>

Nazwa FQDN aplikacji musi wskazywać na adres IP ruchu przychodzącego i zwracać oczekiwaną odpowiedź aplikacji. Usuń nagłówki autoryzacji, ciasteczka i wrażliwe ciągi zapytań przed udostępnieniem szczegółowych wyników.

Tożsamość, sekrety i rejestry

Tożsamości zarządzane nie są obsługiwane w przypadku aplikacji kontenerowych w usłudze Azure Arc. Pobieranie obrazów z usługi Azure Container Registry przy użyciu tożsamości zarządzanej również nie jest obsługiwane.

Aby uzyskać dostęp do zasobów Azure, używaj dedykowanej rejestracji aplikacji i zasady usługi tylko wtedy, gdy docelowa usługa to obsługuje. Przyznawaj tylko wymagane role płaszczyzny danych w możliwie najwęższym praktycznym zakresie. Trzymaj identyfikator tenanta i ID klienta oddzielnie od poświadczenia, używaj certyfikatu, gdy aplikacja i usługa docelowa to wspierają, oraz planuj wygaśnięcie i rotację poświadczeń. Nie używaj ponownie tożsamości połączonego klastra Arc ani tożsamości administratora klastra do dostępu do aplikacji.

W przypadku prywatnych rejestrów używaj danych uwierzytelniających ograniczonych do rejestru, z uprawnieniami tylko do pobierania, jeśli rejestr to obsługuje. Unikaj używania poświadczeń administratora ACR dla obciążeń produkcyjnych. Przechowuj dane uwierzytelniające rejestru i aplikacji jako sekrety Container Apps i odwołuj się do nich po nazwie w konfiguracji aplikacji.

Sekrety Container Apps są ograniczone do zakresu aplikacji, a zmiana sekretu nie aktualizuje automatycznie istniejących wersji. Traktuj zarówno dostęp do płaszczyzny sterowania Azure, jak i uprzywilejowany dostęp do Kubernetes jako granice bezpieczeństwa. Ogranicz dostęp do przestrzeni nazw rozszerzenia i aplikacji zgodnie z wymaganiami bezpieczeństwa Kubernetes dla wdrożenia.

Użyj tej sekwencji obrotów:

Utwórz drugie prawidłowe poświadczenie u dostawcy tożsamości lub w rejestrze.
Aktualizuj sekret Container Apps i wdrażaj lub restartuj dotkniętą wersję w razie potrzeby.
Weryfikuj pobieranie zdjęć i uwierzytelnianie aplikacji za pomocą nowego poświadczenia.
Cofnij stare uprawnienia.
Potwierdź, że żadna aktywna rewizja ani zadanie nie odwołuje się już do starej wartości.

Nigdy nie umieszczaj wartości sekretów w historii poleceń, kontroli wersji, pakietach diagnostycznych, opisach kapsuł ani logach aplikacji. Ogranicz to, kto może czytać ustawienia chronione rozszerzeniami i sekrety Kubernetes.

Magazyn

Zaplanuj przechowywanie zgodnie z trwałością wymaganą przez obciążenie:

Magazyn	Zakres i trwałość	Wymóg planistyczny
System plików kontenerowych	Jeden pojemnik; usuwany po jego wymianie	Używaj wyłącznie do przechowywania danych tymczasowych.
`EmptyDir`	Kontenery w jednej repliki; usunięte razem z repliką	Używaj do tymczasowych danych współdzielonych w obrębie repliki.
Azure Files przez SMB	Trwała współdzielona pamięć plików	Zainstaluj sterownik SMB CSI w wersji 1.18.0 lub nowszej przed użyciem i sprawdź dostęp sieciowy do udostępnionego pliku. Skonfiguruj świadomie dostęp `ReadWrite` lub `ReadOnly`.

Obecnie ograniczenia usługi Azure Container Apps on Arc opisują usługę Azure Files SMB i wymagają sterownika CSI SMB. Nie zakładaj, że typ woluminu obsługiwany przez usługę Azure Container Apps hostowaną na platformie Azure jest obsługiwany w usłudze Arc. Zamiast tworzyć tu kolejną kopię, użyj poleceń instalacji SMB, do których prowadzi link w artykule Azure Container Apps na platformie Azure Arc.

Traktuj dane uwierzytelniające konta pamięci używane do montażu jako sekret. Tożsamości zarządzane nie są obsługiwane w usłudze Container Apps on Arc. Przetestuj wybrane opcje instalacji, uprawnienia do plików, współbieżny dostęp, zachowanie w przypadku awarii oraz rotację poświadczeń, używając dokładnie tych wersji sterownika CSI i usługi magazynu danych, które są używane w środowisku produkcyjnym.

Zaplanuj tworzenie kopii zapasowych danych, testy przywracania, przechowywanie i odbudowę po awarii. Sprawdź, jak rewizje i zadania raportują błędy montowania, oraz uwzględnij zdarzenia poda i logi sterownika CSI w procedurze diagnostycznej. Linux jest jedynym obsługiwanym systemem operacyjnym node w tym rozszerzeniu.

Obserwowalność planu

Integracja z Log Analytics jest opcjonalna. Jeśli planujesz go używać, skonfiguruj go przy instalacji rozszerzenia, bo nie możesz go później dodać do tej instancji.

Po skonfigurowaniu Log Analytics możesz znaleźć logi aplikacji w ContainerAppConsoleLogs_CL. Samouczek Tworzenie aplikacji kontenera w usłudze Azure Arc przedstawia TimeGenerated, ContainerAppName_s i Log_s; przed utworzeniem zapytań lub alertów sprawdź aktywną tabelę. Przed weryfikacją pierwszego spożycia odczekaj od 10 do 15 minut.

Zaplanuj dostęp do obszaru roboczego, retencję, alerty, eksport i koszt pozyskiwania danych. Przed włączeniem zbierania sprawdź, czy rejestrowanie przez aplikację nie obejmuje poświadczeń, danych osobowych ani wrażliwych adresów URL.

Jeśli nie skonfigurowano usługi Log Analytics lub podczas incydentu związanego z pozyskiwaniem danych użyj dzienników Kubernetes:

kubectl get pods -n <APPS_NAMESPACE> -o wide
kubectl logs -n <APPS_NAMESPACE> <POD_NAME> --all-containers=true --tail=200
kubectl get events -n <APPS_NAMESPACE> --sort-by=.lastTimestamp

Komponenty systemu zapisują logi do standardowego wyjścia. Domyślnie telemetria komponentów systemowych jest wysyłana do Microsoft, podczas gdy logi aplikacji nie są wysyłane, chyba że skonfigurujesz Log Analytics. Ustawienie logProcessor.enabled=false wyłącza przetwarzanie logów i ich przekazywanie do obszaru roboczego oraz może zwiększyć zakres materiałów diagnostycznych, o których ręczne zebranie może poprosić Cię pomoc techniczna.

Przed uruchomieniem przetestuj unikalną wiadomość w dzienniku aplikacji od początku do końca, stwórz alerty o stanie rozszerzeń i awariach aplikacji oraz popewnij, że zarówno diagnostyka Azure, jak i Kubernetes są dostępne.

Aktualizacja, kopia zapasowa i odzyskiwanie

Wybierz i udokumentuj cykl wydań rozszerzenia oraz politykę aktualizacji. Samouczek konfiguracji usługi Container Apps korzysta z cyklu wydań stable z automatycznymi aktualizacjami wersji pomocniczych. Rozszerzenia klastrów Azure Arc mogą korzystać z określonego kanału wydań z automatycznymi aktualizacjami albo być przypisane do konkretnej wersji i aktualizowane ręcznie. Przed zmianą wersji zapoznaj się z informacjami o wydaniu rozszerzenia Container Apps oraz zapewnij zapasowe zasoby, zgodne wersje Kubernetes, okna konserwacyjne i walidację aplikacji.

Przed rozszerzeniem lub aktualizacją Kubernetes:

Potwierdź, że stany aprowizacji połączonego klastra i rozszerzeń to Succeeded.
Potwierdź, że docelowa kombinacja Kubernetes i rozszerzenia jest obsługiwana.
Przejrzyj informacje o wydaniu i bieżącą konfigurację, w tym cykl wydawniczy, ustawienie automatycznej aktualizacji, instalację KEDA, przestrzenie nazw, Log Analytics oraz loadBalancerIp.
Sprawdź dostępną rezerwę zasobów na potrzeby stopniowej wymiany i potwierdź, że budżety zakłóceń umożliwiają kontynuowanie procesu.
Zweryfikować łączność z rejestrem obrazów oraz politykę wstępu dla obrazów docelowych.
Wykonaj kopię zapasową konfiguracji źródła aplikacji oraz wszystkich trwałych danych aplikacji.
Przeprowadzaj testy dymne aplikacji, wejścia, skalowania, zadań, magazynowania i logowania przed i po zmianie.

Nie traktuj kopii zapasowej w przestrzeni nazw Kubernetes jako kopię zapasową zasobów Azure. Połączony klaster, rozszerzenie, niestandardowa lokalizacja, środowisko połączone, aplikacje kontenerowe oraz zadania są reprezentowane w Azure Resource Manager i mają zależności od zasobów w klastrze. Zrób osobno kopię zapasową konfiguracji aplikacji deklaratywnej. Nie przywracaj ręcznie wdrożeń zarządzanych rozszerzeniami, niestandardowych zasobów ani sekretów na nowo zainstalowanym rozszerzeniu, chyba że wsparcie Microsoft zapewni taką procedurę odzyskiwania.

Obniżenie wersji rozszerzenia lub wycofanie do poprzedniej wersji nie jest ogólnym mechanizmem przywracania udokumentowanym dla usługi Container Apps on Arc. Nie zmieniaj kanału wydań, nie przypinaj do starszej wersji ani nie modyfikuj obciążeń zarządzanych przez rozszerzenie w odpowiedzi na incydent bez potwierdzenia obsługiwanej procedury przez pomoc techniczną firmy Microsoft.

Opracuj i przetestuj podręcznik do odzyskiwania, który uwzględnia infrastrukturę Kubernetes, sieć, DNS, równoważenie obciążenia, przechowywanie, agentów Azure Arc, rozszerzenie Container Apps, niestandardową lokalizację, środowisko połączone, konfigurację aplikacji, dane uwierzytelniające oraz trwałe dane aplikacji. Weryfikuj wejście, poprawki, skalowanie, zadania, magazyn i logi po odzyskaniu. Korzystaj z procedur odzyskiwania wspieranych przez topologię Kubernetes oraz produkty backupowe podczas wdrożenia.

Zaplanuj odłączenie od platformy Azure. Agenty Arc wymagają łączności, aby wykrywać zmiany w rozszerzeniach i przekazywać żądany stan. Chronione ustawienia nowo utworzonego zasobu rozszerzenia są zachowywane przez maksymalnie 48 godzin; jeśli klaster pozostaje odłączony w tym czasie, rozszerzenie może przejść z Pending do Failed. Testuj zachowanie obciążenia podczas utraty łączności z Azure, zamiast zakładać gwarancję ciągłości.

Opinia

Czy ta strona była pomocna?

Last updated on 2026-09-22