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 1001
grupy . 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:
- Ograniczenia rozprzestrzeniania topologii zasobnika (zalecane — Kubernetes w wersji 1.19 lub nowszej)
- Anty-koligacja zasobnika
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_PROXY
zmiennych ś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
- 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.