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 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.

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.

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.

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.

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.

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.

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.

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:

• Ograniczenia rozprzestrzeniania topologii zasobnika (zalecane — Kubernetes w wersji 1.19 lub nowszej)
• Anty-koligacja zasobnika

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_PROXYNO_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.

Dzienniki i metryki lokalne

Brama self-hosted wysyła dane telemetryczne do usługi Azure Monitor i aplikacja systemu Azure Szczegółowe informacje 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 Szczegółowe informacje kontenera usługi Azure Monitor do monitorowania kontenerów lub skonfigurowania lokalnego monitorowania w celu zapewnienia możliwości obserwowania ruchu interfejsu API i zapobiegania utracie danych telemetrycznych podczas awarii łą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ń

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

Następne kroki

• Aby dowiedzieć się więcej na temat własnej bramy, zobacz Omówienie własnej bramy.
• Dowiedz się , jak wdrożyć własną bramę usługi API Management w klastrach Kubernetes z obsługą usługi Azure Arc.