Udostępnij za pośrednictwem

Wskazówki dotyczące uruchamiania własnej bramy na platformie Kubernetes w środowisku produkcyjnym

DOTYCZY: Developer | Premium

Aby uruchomić bramę hostowaną samodzielnie w środowisku produkcyjnym, należy wziąć pod uwagę różne aspekty. Na przykład należy ją wdrożyć w sposób o wysokiej dostępności, użyć kopii zapasowych konfiguracji do obsługi tymczasowych rozłączeń i wiele innych.

Ten artykuł zawiera wskazówki dotyczące uruchamiania własnej bramy na platformie Kubernetes na potrzeby obciążeń produkcyjnych w celu zapewnienia bezproblemowego i niezawodnego działania bramy.

Token dostępu

Bez prawidłowego tokenu dostępu, brama zainstalowana lokalnie nie może uzyskać dostępu do danych konfiguracji i pobrać je z punktu końcowego powiązanej usługi zarządzania API. Token dostępu może być ważny przez maksymalnie 30 dni. Należy go wygenerować ponownie i skonfigurować klaster przy użyciu nowego tokenu ręcznie lub za pomocą automatyzacji przed jego wygaśnięciem.

Podczas automatyzowania odświeżania tokenu użyj tej operacji interfejsu API zarządzania , aby wygenerować nowy token. Aby uzyskać informacje na temat zarządzania tajnymi danymi w Kubernetes, zobacz witrynę Kubernetes.

Wskazówka

Możesz również wdrożyć bramę własną hostowaną na platformie Kubernetes i w wystąpieniu usługi API Management włączyć uwierzytelnianie przy użyciu Microsoft Entra ID.

Skalowanie automatyczne

Chociaż udostępniamy wskazówki dotyczące minimalnej liczby replik dla bramy hostowanej samodzielnie, zalecamy użycie skalowania automatycznego dla bramy hostowanej samodzielnie, aby zaspokoić zapotrzebowanie ruchu bardziej proaktywnie.

Istnieją dwa sposoby automatycznego skalowania bramy hostowanej samodzielnie w poziomie:

  • Autoskalowanie na podstawie użycia zasobów (procesora CPU i pamięci)
  • Automatyczne skalowanie na podstawie liczby żądań na sekundę

Jest to możliwe za pomocą natywnych funkcji platformy Kubernetes lub przy użyciu skalowania automatycznego opartego na zdarzeniach (KEDA) platformy Kubernetes. KEDA to projekt inkubacji CNCF, który dąży do uproszczenia autoskalowania aplikacji.

Uwaga / Notatka

KEDA to technologia typu open source, która nie jest obsługiwana przez pomoc techniczną platformy Azure i musi być obsługiwana przez klientów.

Skalowanie automatyczne oparte na zasobach

Platforma Kubernetes umożliwia automatyczne skalowanie własnej bramy na podstawie użycia zasobów przy użyciu narzędzia Horizontal Pod Autoscaler. Umożliwia zdefiniowanie progów procesora CPU i pamięci oraz liczbę replik do skalowania w górę lub w dół.

Alternatywą jest użycie automatycznego skalowania opartego na zdarzeniach platformy Kubernetes (KEDA), umożliwiającego skalowanie obciążeń na podstawie różnych skalowalników, w tym procesora CPU i pamięci.

Wskazówka

Jeśli używasz już usługi KEDA do skalowania innych obciążeń, zalecamy użycie usługi KEDA jako ujednoliconego narzędzia do automatycznego skalowania aplikacji. Jeśli tak nie jest, zdecydowanie zalecamy poleganie na natywnej funkcjonalności platformy Kubernetes za pomocą narzędzia Horizontal Pod Autoscaler.

Skalowanie automatyczne oparte na ruchu

Platforma Kubernetes nie zapewnia gotowego mechanizmu skalowania automatycznego opartego na ruchu.

Narzędzie Kubernetes do automatycznego skalowania opartego na zdarzeniach (KEDA) oferuje kilka sposobów, które mogą pomóc w automatycznym skalowaniu opartym na ruchu:

  • Możesz skalować na podstawie metryk z wejścia Kubernetes, jeśli są one dostępne w Prometheus lub Azure Monitor przy użyciu gotowego skalowalnika.
  • Możesz zainstalować dodatek HTTP, który jest dostępny w wersji beta, i skalować na podstawie liczby żądań na sekundę.

Kopia zapasowa konfiguracji

Skonfiguruj wolumin magazynu lokalnego dla kontenera bramy hostowanej samodzielnie, aby można było zachować kopię zapasową najnowszej pobranej konfiguracji. Jeśli łączność nie działa, wolumin magazynu może używać kopii zapasowej po ponownym uruchomieniu. Ścieżka montowania woluminu musi być /apim/config i musi być własnością identyfikatora grupy 1001. Zobacz przykład w witrynie GitHub. Aby dowiedzieć się więcej o przechowywaniu w Kubernetes, odwiedź witrynę internetową Kubernetes. Aby zmienić własność zainstalowanej ścieżki, zobacz securityContext.fsGroup ustawienie w witrynie internetowej Platformy Kubernetes.

Uwaga / Notatka

Aby dowiedzieć się więcej o zachowaniu własnej bramy w obecności tymczasowej awarii łączności platformy Azure, zobacz Omówienie własnej bramy.

Tag obrazu kontenera

Plik YAML podany w witrynie Azure Portal używa najnowszego tagu. Ten tag zawsze odwołuje się do najnowszej wersji obrazu kontenera bramy zarządzanej samodzielnie.

Rozważ użycie określonego tagu wersji w środowisku produkcyjnym, aby uniknąć niezamierzonego uaktualnienia do nowszej wersji.

Możesz pobrać pełną listę dostępnych tagów.

Wskazówka

Podczas instalowania za pomocą programu Helm tagowanie obrazów jest zoptymalizowane pod kątem Ciebie. Wersja aplikacji pakietu Helm przypina bramę do danej wersji i nie korzysta z elementu latest.

Dowiedz się więcej na temat sposobu instalowania własnej bramy usługi API Management na platformie Kubernetes przy użyciu programu Helm.

Zasoby kontenera

Domyślnie plik YAML podany w witrynie Azure Portal nie określa żądań zasobów kontenera.

Nie można niezawodnie przewidzieć i zalecić ilość zasobów procesora CPU i pamięci na kontener oraz liczbę replik wymaganych do obsługi określonego obciążenia. Wiele czynników jest w grze, takich jak:

  • Określony sprzęt, na którym działa klaster.
  • Obecność i typ wirtualizacji.
  • Liczba i szybkość współbieżnych połączeń klienckich.
  • Częstotliwość żądań.
  • Rodzaj i liczba skonfigurowanych zasad.
  • Rozmiar ładunku oraz to, czy ładunki są buforowane czy przesyłane strumieniowo.
  • Opóźnienie usługi zaplecza.

Zalecamy ustawienie żądań zasobów na dwa rdzenie i 2 GiB jako punkt początkowy. Przeprowadź test obciążeniowy i przeprowadź skalowanie w górę/w poziomie lub w dół/w oparciu o wyniki.

Niestandardowe nazwy domen i certyfikaty SSL

Jeśli używasz niestandardowych nazw domen dla punktów końcowych usługi API Management, zwłaszcza jeśli używasz niestandardowej nazwy domeny dla punktu końcowego zarządzania, może być konieczne zaktualizowanie wartości config.service.endpoint w <pliku gateway-name.yaml>, aby zastąpić domyślną nazwę domeny niestandardową nazwą domeny. Upewnij się, że dostęp do punktu końcowego zarządzania można uzyskać z zasobnika bramy hostowanej samodzielnie w klastrze Kubernetes.

W tym scenariuszu, jeśli certyfikat SSL używany przez punkt końcowy zarządzania nie jest podpisany przez dobrze znany certyfikat urzędu certyfikacji, należy upewnić się, że certyfikat urzędu certyfikacji jest zaufany przez zasobnik bramy self-hosted.

Uwaga / Notatka

W przypadku własnej bramy w wersji 2 usługa API Management udostępnia nowy punkt końcowy konfiguracji: <apim-service-name>.configuration.azure-api.net. Niestandardowe nazwy hostów są obsługiwane dla tego punktu końcowego i mogą być używane zamiast domyślnej nazwy hosta.

Zasady DNS

Rozpoznawanie nazw DNS odgrywa kluczową rolę w możliwości samodzielnego nawiązywania połączenia z zależnościami na platformie Azure i wysyłania wywołań interfejsu API do usług zaplecza.

Plik YAML podany w witrynie Azure Portal stosuje domyślne zasady ClusterFirst . Ta polityka powoduje, że żądania rozpoznawania nazw, które nie zostały rozpoznane przez serwer DNS klastra, są przekazywane do nadrzędnego serwera DNS dziedziczonego z węzła.

Aby dowiedzieć się więcej o rozpoznawaniu nazw na platformie Kubernetes, zobacz witrynę internetową platformy Kubernetes. Rozważ dostosowanie zasad DNS lub konfiguracji DNS odpowiednio do konfiguracji.

Zasady ruchu zewnętrznego

Plik YAML podany w witrynie Azure Portal ustawia externalTrafficPolicy pole dla obiektu Usługi na wartość Local. Spowoduje to zachowanie adresu IP obiektu wywołującego (dostępnego w kontekście żądania) i wyłączenie równoważenia obciążenia między węzłami, eliminując przeskoki sieciowe spowodowane przez nie. Należy pamiętać, że to ustawienie może spowodować asymetryczny rozkład ruchu we wdrożeniach z nierówną liczbą zasobników bramy na węzeł.

Sondowanie kondycji

Użyj punktu końcowego sond HTTP dla sond gotowości i aktywności w wdrożeniach bramy. To pomaga kierować ruch wyłącznie do wdrożeń bramy, które zostały pomyślnie uruchomione i są gotowe do obsługi ruchu, lub wiadomo, że nadal reagują.

Bez kontrol sond zdrowia wdrożenie bramy może nastąpić szybciej, ale konfiguracja może nie być jeszcze w pełni załadowana, co spowoduje błędy 503 w ruchu płaszczyzny danych.

Wskazówka

Podczas instalowania za pomocą programu Helm sondy kondycji są domyślnie włączone.

Wysoka dostępność

Brama hostowana samodzielnie jest kluczowym składnikiem infrastruktury i musi być wysoce dostępna. Jednak awaria będzie i może się zdarzyć.

Rozważ ochronę własnej bramy przed zakłóceniami.

Wskazówka

Podczas instalacji przy użyciu programu Helm można z łatwością aktywować planowanie w trybie wysokiej dostępności, wybierając opcję konfiguracji highAvailability.enabled.

Dowiedz się więcej na temat sposobu instalowania własnej bramy usługi API Management na platformie Kubernetes przy użyciu programu Helm.

Ochrona przed awarią węzła

Aby zapobiec wystąpieniu problemu z powodu awarii centrum danych lub węzła, rozważ użycie klastra Kubernetes korzystającego ze stref dostępności w celu osiągnięcia wysokiej dostępności na poziomie węzła.

Strefy dostępności umożliwiają zaplanowanie zasobnika własnej bramy w węzłach rozmieszczonych w różnych strefach przy użyciu:

Uwaga / Notatka

Jeśli używasz usługi Azure Kubernetes Service, dowiedz się, jak używać stref dostępności w tym artykule.

Ochrona przed zakłóceniami działania zasobnika

Zasobniki mogą napotykać zakłócenia z różnych powodów, takich jak ręczne usuwanie zasobników, konserwacja węzła itp.

Rozważ użycie budżetów przestojowych zasobników, aby wymusić minimalną liczbę zasobników, które mają być dostępne w danym momencie.

Serwer proxy HTTP(S)

Brama hostowana samodzielnie zapewnia obsługę serwera proxy HTTP(S) przy użyciu tradycyjnych HTTP_PROXYzmiennych środowiskowych i HTTPS_PROXYNO_PROXY .

Po skonfigurowaniu, brama hostowana lokalnie automatycznie użyje serwera proxy do wszystkich wychodzących żądań HTTP(S) do usług backendowych.

Począwszy od wersji 2.1.5 lub nowszej, samodzielnie hostowana brama zapewnia obserwowalność związaną z proxyfikacją żądań.

  • Inspektor interfejsu API pokaże dodatkowe kroki, gdy używany jest serwer proxy HTTP(S) i jego powiązane interakcje.
  • Pełne dzienniki są udostępniane w celu wskazania zachowania serwera proxy żądania.

Uwaga / Notatka

Ze względu na znany problem z serwerami proxy HTTP wykorzystującymi uwierzytelnianie podstawowe, weryfikacja listy unieważnionych certyfikatów (CRL) nie jest możliwa. Dowiedz się więcej w naszej dokumentacji dotyczącej ustawieńSelf-Hosted Gateway, jak ją odpowiednio skonfigurować.

Ostrzeżenie

Upewnij się, że wymagania dotyczące infrastruktury zostały spełnione i że brama self-hosted nadal może się z nimi połączyć lub niektóre funkcje nie będą działać prawidłowo.

Dzienniki i metryki lokalne

Samodzielnie hostowana brama wysyła dane telemetryczne do Azure Monitor i Azure Application Insights zgodnie z ustawieniami konfiguracji w skojarzonej usłudze Zarządzanie API. Gdy łączność z platformą Azure zostanie tymczasowo utracona, przepływ danych telemetrycznych na platformę Azure zostanie przerwany i dane zostaną utracone przez czas przestoju.

Rozważ użycie usługi Azure Monitor Container Insights do monitorowania kontenerów lub skonfigurowania lokalnego monitorowania w celu zapewnienia możliwości obserwowania ruchu interfejsu API i zapobiegania utracie danych telemetrycznych podczas przestojów łączności platformy Azure.

Namespace

Namespaces w Kubernetes ułatwiają podział jednego klastra między wiele zespołów, projekty lub aplikacje. Przestrzenie nazw zapewniają obszar działania dla zasobów i nazw. Można je skojarzyć z zasadami limitu przydziału zasobów i kontroli dostępu.

Portal Azure udostępnia polecenia umożliwiające tworzenie zasobów bramy hostowanej lokalnie w domyślnej przestrzeni nazw. Ta przestrzeń nazw jest tworzona automatycznie, istnieje w każdym klastrze i nie można jej usunąć. Rozważ utworzenie i wdrożenie samodzielnie hostowanej bramy w oddzielnej przestrzeni nazw w środowisku produkcyjnym.

Liczba replik

Minimalna liczba replik odpowiednich do produkcji to trzy, najlepiej w połączeniu z wysoką dostępnością planowania wystąpień.

Domyślnie brama hostowana samodzielnie jest wdrażana przy użyciu strategii wdrażania RollingUpdate. Przejrzyj wartości domyślne i rozważ jawne ustawienie pól maxUnavailable i maxSurge , szczególnie w przypadku używania dużej liczby replik.

Wydajność

Zalecamy zmniejszenie liczby logów kontenera do ostrzeżeń (warn) w celu poprawy wydajności. Dowiedz się więcej w dokumentacji konfiguracji własnej bramy.

Ograniczanie żądań

Ograniczanie żądań w samodzielnie hostowanej bramie można włączyć przy użyciu polityki rate-limit lub rate-limit-by-key usługi API Management. Skonfiguruj liczniki limitowania szybkości, aby zsynchronizować między instancjami bramy w węzłach klastra, uwidaczniając następujące porty we wdrożeniu Kubernetes na potrzeby odnajdowania instancji:

  • Port 4290 (UDP) dla synchronizacji limitowania szybkości
  • Port 4291 (UDP) do wysyłania sygnałów kontrolnych do innych instancji

Uwaga / Notatka

Liczbę limitów szybkości w bramie hostowanej samodzielnie można skonfigurować do lokalnej synchronizacji (między wystąpieniami bramy w węzłach klastra), na przykład za pomocą wdrożenia wykresu Helm dla platformy Kubernetes lub szablonów wdrożeniowych w witrynie Azure Portal. Jednak wartości limitów szybkości nie są synchronizowane z innymi zasobami bramy skonfigurowanymi w wystąpieniu usługi API Management, w tym z bramą zarządzaną w chmurze.

Bezpieczeństwo

Samodzielnie hostowana brama może działać bez uprawnień superużytkownika w środowisku Kubernetes, umożliwiając klientom bezpieczne jej uruchamianie.

Oto przykład kontekstu zabezpieczeń dla kontenera bramy hostowanej samodzielnie:

securityContext:
  allowPrivilegeEscalation: false
  runAsNonRoot: true
  runAsUser: 1001       # This is a built-in user, but you can use any user ie 1000 as well
  runAsGroup: 2000      # This is just an example
  privileged: false
  capabilities:
    drop:
    - all

Ostrzeżenie

Uruchamianie bramy hostowanej lokalnie z systemem plików tylko do odczytu (readOnlyRootFilesystem: true) nie jest wspierane.

Ostrzeżenie

W przypadku korzystania z certyfikatów lokalnego urzędu certyfikacji brama hostowana samodzielnie musi działać z identyfikatorem użytkownika (UID), 1001 aby zarządzać certyfikatami urzędu certyfikacji. W przeciwnym razie brama nie zostanie uruchomiona.

Powiązana zawartość