Udostępnij za pośrednictwem


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

DOTYCZY: Developer | Premia

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 self-hosted nie może uzyskać dostępu do danych konfiguracji i pobrać ich z punktu końcowego skojarzonej usługi API Management. Token dostępu może być ważny przez maksymalnie 30 dni. Należy go wygenerować ponownie, a klaster skonfigurowany przy użyciu nowego tokenu ręcznie lub za pośrednictwem 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 wpisami tajnymi platformy Kubernetes, zobacz witrynę internetową platformy Kubernetes.

Napiwek

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

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

KEDA to technologia typu open source, która nie jest obsługiwana przez pomoc techniczna 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 poziomie lub w poziomie.

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

Napiwek

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ć metryki na podstawie danych przychodzących platformy Kubernetes, jeśli są one dostępne w usłudze Prometheus lub Azure Monitor przy użyciu gotowego modułu skalowania
  • 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 instalacji woluminu musi być /apim/config i musi być własnością identyfikatora 1001grupy . Zobacz przykład w witrynie GitHub. Aby dowiedzieć się więcej o magazynie na platformie Kubernetes, zobacz witrynę internetową platformy Kubernetes. Aby zmienić własność zainstalowanej ścieżki, zobacz securityContext.fsGroup ustawienie w witrynie internetowej Platformy Kubernetes.

Uwaga

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 własnej bramy.

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.

Napiwek

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 i określa, 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

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 systemu 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 . Te zasady powodują, że żądania rozpoznawania nazw nie są rozpoznawane przez serwer DNS klastra, który jest przekazywany 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ł.

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.

Napiwek

Podczas instalowania za pomocą programu Helm można łatwo włączyć planowanie o wysokiej dostępności, włączając highAvailability.enabled opcję konfiguracji.

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

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 zasobnika

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

Rozważ użycie budżetów zakłóceń 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_PROXY NO_PROXY .

Po skonfigurowaniu brama self-hosted automatycznie użyje serwera proxy dla wszystkich wychodzących żądań HTTP(S) do usług zaplecza.

Począwszy od wersji 2.1.5 lub nowszej, brama hostowana samodzielnie zapewnia wgląd w możliwości związane z żądaniami proxy:

  • 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

Ze względu na znany problem z serwerami proxy HTTP przy użyciu uwierzytelniania podstawowego sprawdzanie poprawności listy odwołania certyfikatów (CRL) nie jest obsługiwane. Dowiedz się więcej w naszych ustawieniach własnej bramy, aby dowiedzieć się, 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

Brama self-hosted wysyła dane telemetryczne do usługi Azure Monitor i aplikacja systemu Azure Insights zgodnie z ustawieniami konfiguracji w skojarzonej usłudze API Management. 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.

Przestrzeń nazw

Przestrzenie nazw platformy Kubernetes ułatwiają podzielenie jednego klastra między wiele zespołów, projektów lub aplikacji. Przestrzenie nazw zapewniają zakres zasobów i nazw. Można je skojarzyć z zasadami limitu przydziału zasobów i kontroli dostępu.

Witryna Azure Portal udostępnia polecenia umożliwiające tworzenie własnych zasobów bramy 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 własnej 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 dzienników kontenera do ostrzeżeń (warn), aby zwiększyć wydajność. Dowiedz się więcej w dokumentacji konfiguracji własnej bramy.

Ograniczanie żądań

Ograniczanie żądań w bramie hostowanej samodzielnie można włączyć przy użyciu zasad limitu szybkości usługi API Management lub rate-limit-by-key. Skonfiguruj liczbę limitów szybkości synchronizacji między wystąpieniami bramy w węzłach klastra, uwidaczniając następujące porty we wdrożeniu Kubernetes na potrzeby odnajdywania wystąpień:

  • Port 4290 (UDP) dla synchronizacji ograniczania szybkości
  • Port 4291 (UDP) do wysyłania pulsów do innych wystąpień

Uwaga

Liczbę limitów szybkości w bramie hostowanej samodzielnie można skonfigurować do synchronizowania lokalnie (między wystąpieniami bramy między węzłami klastra), na przykład za pomocą wdrożenia wykresu helm dla platformy Kubernetes lub szablonów wdrażania w witrynie Azure Portal. Jednak liczby 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.

Zabezpieczenia

Brama hostowana samodzielnie może działać jako nieuwzwiązana z katalogami głównymi na platformie Kubernetes, umożliwiając klientom bezpieczne uruchamianie bramy.

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 własnej bramy z systemem plików tylko do odczytu (readOnlyRootFilesystem: true) nie jest obsługiwane.

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.

Następne kroki