Używanie usługi Azure API Management z mikrousługami wdrożonym w usłudze Azure Kubernetes Service

  • Artykuł

DOTYCZY: Wszystkie warstwy usługi API Management

Mikrousługi doskonale nadają się do tworzenia interfejsów API. Usługa Azure Kubernetes Service (AKS) umożliwia szybkie wdrażanie i obsługę architektury opartej na mikrousługach w chmurze. Następnie możesz użyć usługi Azure API Management (API Management ), aby opublikować mikrousługi jako interfejsy API do użytku wewnętrznego i zewnętrznego. W tym artykule opisano opcje wdrażania usługi API Management za pomocą usługi AKS. Zakłada ona podstawową wiedzę na temat platformy Kubernetes, usługi API Management i sieci platformy Azure.

Tło

Podczas publikowania mikrousług jako interfejsów API do użycia może być trudne zarządzanie komunikacją między mikrousługami a klientami korzystającymi z nich. Istnieje wiele zagadnień krzyżowych, takich jak uwierzytelnianie, autoryzacja, ograniczanie przepustowości, buforowanie, przekształcanie i monitorowanie. Te problemy są ważne niezależnie od tego, czy mikrousługi są widoczne dla klientów wewnętrznych lub zewnętrznych.

Wzorzec bramy interfejsu API rozwiązuje te problemy. Brama interfejsu API służy jako brama frontonu dla mikrousług, odłącza klientów od mikrousług, dodaje dodatkową warstwę zabezpieczeń i zmniejsza złożoność mikrousług, usuwając obciążenie związane z obsługą problemów z wycinaniami krzyżowymi.

Usługa Azure API Management to gotowe rozwiązanie do rozwiązywania potrzeb bramy interfejsu API. Możesz szybko utworzyć spójną i nowoczesną bramę dla mikrousług i opublikować je jako interfejsy API. Jako rozwiązanie do zarządzania interfejsem API w pełnym cyklu życia udostępnia również dodatkowe funkcje, w tym portal dla deweloperów samoobsługi na potrzeby odnajdywania interfejsów API, zarządzania cyklem życia interfejsu API i analizy interfejsów API.

W połączeniu usługi AKS i API Management zapewniają platformę do wdrażania, publikowania, zabezpieczania, monitorowania i zarządzania interfejsami API opartymi na mikrousługach. W tym artykule omówimy kilka opcji wdrażania usługi AKS w połączeniu z usługą API Management.

Usługi i interfejsy API platformy Kubernetes

W klastrze Kubernetes kontenery są wdrażane w zasobnikach, które są efemeryczne i mają cykl życia. Po śmierci węzła procesu roboczego zasobniki uruchomione w węźle zostaną utracone. W związku z tym adres IP zasobnika może ulec zmianie w dowolnym momencie. Nie możemy polegać na nim, aby komunikować się z zasobnikiem.

Aby rozwiązać ten problem, platforma Kubernetes wprowadziła koncepcję usług. Usługa Kubernetes Service to warstwa abstrakcji, która definiuje grupę logiki zasobników i umożliwia zewnętrzne narażenie na ruch, równoważenie obciążenia i odnajdywanie usług dla tych zasobników.

Gdy jesteśmy gotowi do opublikowania naszych mikrousług jako interfejsów API za pośrednictwem usługi API Management, musimy zastanowić się, jak mapować nasze usługi na platformę Kubernetes na interfejsy API w usłudze API Management. Nie ma żadnych ustawionych reguł. Zależy to od sposobu projektowania i partycjonowania możliwości lub domen biznesowych w mikrousługi na początku. Jeśli na przykład zasobniki za usługą są odpowiedzialne za wszystkie operacje w danym zasobie (na przykład Klient), usługa może zostać zamapowana na jeden interfejs API. Jeśli operacje na zasobie są podzielone na wiele mikrousług (na przykład GetOrder, PlaceOrder), wiele usług może być logicznie zagregowanych w jednym interfejsie API w usłudze API Management (zobacz Rysunek 1).

Mapowania mogą również ewoluować. Ponieważ usługa API Management tworzy fasadę przed mikrousługami, umożliwia refaktoryzację i odpowiedni rozmiar naszych mikrousług w czasie.

Mapuj usługi na interfejsy API

Wdrażanie usługi API Management przed usługą AKS

Istnieje kilka opcji wdrażania usługi API Management przed klastrem usługi AKS.

Mimo że klaster usługi AKS jest zawsze wdrażany w sieci wirtualnej, wystąpienie usługi API Management nie jest wymagane do wdrożenia w sieci wirtualnej. Gdy usługa API Management nie znajduje się w sieci wirtualnej klastra, klaster usługi AKS musi publikować publiczne punkty końcowe usługi API Management w celu nawiązania połączenia. W takim przypadku istnieje potrzeba zabezpieczenia połączenia między usługą API Management i usługą AKS. Innymi słowy, musimy upewnić się, że klaster może być dostępny wyłącznie za pośrednictwem usługi API Management. Przyjrzyjmy się opcjom.

Opcja 1. Publiczne uwidacznianie usług

Usługi w klastrze usługi AKS można uwidocznić publicznie przy użyciu typów usług NodePort, LoadBalancer lub ExternalName. W takim przypadku usługi są dostępne bezpośrednio z publicznego Internetu. Po wdrożeniu usługi API Management przed klastrem musimy upewnić się, że cały ruch przychodzący przechodzi przez usługę API Management, stosując uwierzytelnianie w mikrousługach. Na przykład usługa API Management może zawierać token dostępu w każdym żądaniu przekazanym do klastra. Każda mikrousługa jest odpowiedzialna za weryfikowanie tokenu przed przetworzeniem żądania.

Może to być najprostsza opcja wdrożenia usługi API Management przed usługą AKS, zwłaszcza jeśli masz już zaimplementowaną logikę uwierzytelniania w mikrousługach.

Bezpośrednie publikowanie usług

Zalety:

  • Łatwa konfiguracja po stronie usługi API Management, ponieważ nie musi być wstrzykiwana do sieci wirtualnej klastra
  • Brak zmian po stronie usługi AKS, jeśli usługi są już uwidocznione publicznie i logika uwierzytelniania już istnieje w mikrousługach

Wady:

  • Potencjalne zagrożenie bezpieczeństwa spowodowane publicznym widocznością punktów końcowych
  • Brak pojedynczego punktu wejścia dla ruchu klastra przychodzącego
  • Komplikuje mikrousługi z zduplikowaną logiką uwierzytelniania

Opcja 2. Instalowanie kontrolera ruchu przychodzącego

Chociaż opcja 1 może być łatwiejsza, ma istotne wady, jak wspomniano powyżej. Jeśli wystąpienie usługi API Management nie znajduje się w sieci wirtualnej klastra, wzajemne uwierzytelnianie TLS (mTLS) jest niezawodnym sposobem zapewnienia bezpieczeństwa ruchu i zaufania w obu kierunkach między wystąpieniem usługi API Management i klastrem usługi AKS.

Wzajemne uwierzytelnianie TLS jest natywnie obsługiwane przez usługę API Management i można je włączyć na platformie Kubernetes, instalując kontroler ruchu przychodzącego (Rysunek 3). W związku z tym uwierzytelnianie zostanie wykonane w kontrolerze ruchu przychodzącego, co upraszcza mikrousługi. Ponadto można dodać adresy IP usługi API Management do listy dozwolonych przez ruch przychodzący, aby upewnić się, że tylko usługa API Management ma dostęp do klastra.

Publikowanie za pośrednictwem kontrolera ruchu przychodzącego

Zalety:

  • Łatwa konfiguracja po stronie usługi API Management, ponieważ nie musi być wstrzykiwana do sieci wirtualnej klastra, a biblioteka mTLS jest natywnie obsługiwana
  • Centralizuje ochronę ruchu przychodzącego klastra w warstwie kontrolera ruchu przychodzącego
  • Zmniejsza ryzyko zabezpieczeń, minimalizując publicznie widoczne punkty końcowe klastra

Wady:

  • Zwiększa złożoność konfiguracji klastra ze względu na dodatkową pracę w celu zainstalowania, skonfigurowania i obsługi kontrolera ruchu przychodzącego oraz zarządzania certyfikatami używanymi w usłudze mTLS
  • Zagrożenie bezpieczeństwa spowodowane publicznym widocznością punktów końcowych kontrolera ruchu przychodzącego

Podczas publikowania interfejsów API za pomocą usługi API Management łatwo i powszechnie zabezpieczać dostęp do tych interfejsów API przy użyciu kluczy subskrypcji. Deweloperzy, którzy muszą korzystać z opublikowanych interfejsów API, muszą uwzględnić prawidłowy klucz subskrypcji w żądaniach HTTP podczas wykonywania wywołań do tych interfejsów API. W przeciwnym razie wywołania są natychmiast odrzucane przez bramę usługi API Management. Nie są one przekazywane do usług zaplecza.

Aby uzyskać klucz subskrypcji na potrzeby uzyskiwania dostępu do interfejsów API, wymagana jest subskrypcja. Subskrypcja jest zasadniczo nazwanym kontenerem dla pary kluczy subskrypcji. Deweloperzy, którzy muszą korzystać z opublikowanych interfejsów API, mogą uzyskiwać subskrypcje. Nie potrzebują zatwierdzenia od wydawców interfejsu API. Wydawcy interfejsów API mogą również tworzyć subskrypcje bezpośrednio dla użytkowników interfejsu API.

Opcja 3. Wdrażanie usługi APIM wewnątrz sieci wirtualnej klastra

W niektórych przypadkach klienci z ograniczeniami prawnymi lub rygorystycznymi wymaganiami dotyczącymi zabezpieczeń mogą znaleźć rozwiązania opcji 1 i 2, które nie są realne z powodu publicznie uwidocznionych punktów końcowych. W innych usługach klaster usługi AKS i aplikacje, które korzystają z mikrousług, mogą znajdować się w tej samej sieci wirtualnej, dlatego nie ma powodu, aby uwidocznić klaster publicznie, ponieważ cały ruch interfejsu API pozostanie w sieci wirtualnej. W tych scenariuszach można wdrożyć usługę API Management w sieci wirtualnej klastra. Usługi API Management Developer i Premium obsługują wdrażanie sieci wirtualnej.

Istnieją dwa tryby wdrażania usługi API Management w sieci wirtualnej — zewnętrzne i wewnętrzne.

Jeśli użytkownicy interfejsu API nie znajdują się w sieci wirtualnej klastra, należy użyć trybu zewnętrznego (rysunek 4). W tym trybie brama usługi API Management jest wstrzykiwana do sieci wirtualnej klastra, ale dostępna z publicznego Internetu za pośrednictwem zewnętrznego modułu równoważenia obciążenia. Pomaga całkowicie ukryć klaster, jednocześnie umożliwiając klientom zewnętrznym korzystanie z mikrousług. Ponadto można użyć funkcji sieciowych platformy Azure, takich jak sieciowe grupy zabezpieczeń, aby ograniczyć ruch sieciowy.

Tryb zewnętrznej sieci wirtualnej

Jeśli wszyscy użytkownicy interfejsu API znajdują się w sieci wirtualnej klastra, można użyć trybu wewnętrznego (rysunek 5). W tym trybie brama usługi API Management jest wprowadzana do sieci wirtualnej klastra i dostępna tylko z tej sieci wirtualnej za pośrednictwem wewnętrznego modułu równoważenia obciążenia. Nie ma możliwości dotarcia do bramy usługi API Management lub klastra usługi AKS z publicznego Internetu.

Wewnętrzny tryb sieci wirtualnej

W obu przypadkach klaster usługi AKS nie jest widoczny publicznie. W porównaniu z opcją 2 kontroler ruchu przychodzącego może nie być konieczny. W zależności od scenariusza i konfiguracji uwierzytelnianie może być nadal wymagane między usługą API Management i mikrousługami. Jeśli na przykład usługa Service Mesh zostanie przyjęta, zawsze wymaga wzajemnego uwierzytelniania TLS.

Zalety:

  • Najbezpieczniejsza opcja, ponieważ klaster usługi AKS nie ma publicznego punktu końcowego
  • Upraszcza konfigurację klastra, ponieważ nie ma publicznego punktu końcowego
  • Możliwość ukrycia zarówno usługi API Management, jak i usługi AKS wewnątrz sieci wirtualnej przy użyciu trybu wewnętrznego
  • Możliwość kontrolowania ruchu sieciowego przy użyciu funkcji sieciowych platformy Azure, takich jak sieciowe grupy zabezpieczeń

Wady:

  • Zwiększa złożoność wdrażania i konfigurowania usługi API Management do pracy w sieci wirtualnej

Następne kroki