Ein APISIX Service Mesh mit Istio und Amesh
June 16, 2023
Apache APISIX wird hauptsächlich zur Verarbeitung von Nord-Süd-Datenverkehr verwendet und befindet sich oft an der Grenze zwischen Client-Anwendungen und Backend-Diensten.
Mit dem APISIX Ingress Controller kann APISIX auch den Ein- und Ausgangsverkehr in Kubernetes-Clustern mit nativer Konfiguration steuern.
Doch mit der zunehmenden Verbreitung von Microservices entsteht eine neue Herausforderung: die Bewältigung des Ost-West-Datenverkehrs zwischen diesen Microservices.
Service-Meshes wie Istio lösen dieses Problem, indem sie die Netzwerkverantwortung von den Microservice-Entwicklern entfernen und eine zusätzliche L4/L7-Netzwerkschicht bereitstellen.
Mit der neuen Amesh-Bibliothek und Istio kann Apache APISIX auch als Service-Mesh verwendet werden, insbesondere als Datenebene für Istio, wodurch alle seine Verkehrsmanagement-Fähigkeiten für die Dienst-zu-Dienst-Kommunikation genutzt werden können.
In diesem Artikel werden wir untersuchen, was Amesh ist, wie es entwickelt wurde und wie es verwendet wird, um APISIX in ein Service-Mesh zu integrieren.
Istio und das xDS-Protokoll
Istio ist eines der am weitesten verbreiteten Service-Meshes.
Unter der Haube verwendet Istio Envoy als Reverse-Proxy in seinen Sidecar-Containern.
Istio verwaltet den Datenverkehr, indem es die Sidecars dynamisch über Envoy's xDS APIs konfiguriert.
Die xDS-APIs sind eine Möglichkeit, Envoy mit inkrementellen Änderungen zu konfigurieren, anstatt mit statischen Dateien.
Obwohl diese APIs ursprünglich für die Konfiguration von Envoy gedacht waren, haben sie sich zu einer universellen Datenebenen-API entwickelt. Jede Datenebenen-Proxy kann diese APIs implementieren, und jede Steuerungsebene kann diese API verwenden, um mit diesen Datenebenen-Proxys zu arbeiten.
In Istio bedeutet dies, dass Sie die standardmäßige Envoy-Datenebene durch jede Datenebene ersetzen können, die die xDS-APIs implementiert. So können Sie Envoy durch APISIX ersetzen, um dessen Verkehrsmanagement-Fähigkeiten in einem Service-Mesh zu nutzen.
Aber APISIX unterstützt die xDS-APIs nicht out-of-the-box. Und hier kommt Amesh ins Spiel.
Amesh
Amesh ist eine Bibliothek, die die Daten von Istios Steuerungsebene in die APISIX-Konfiguration übersetzt.
APISIX ersetzt Envoy als Datenebene für Istio.
Istio kommuniziert mit der Datenebene über die xDS-APIs. Amesh unterstützt diese APIs und wandelt sie dann in APISIX-Konfigurationen um.
Dies ähnelt der Funktionsweise von APISIX und dem APISIX Ingress Controller. Der Ingress Controller wandelt die mit der Ingress- oder Gateway-API definierten Konfigurationen in das APISIX-Format um.
Da die xDS-APIs von mehr Service-Meshes wie Linkerd und Open Service Mesh unterstützt werden, kann APISIX auch mit ihnen über die Amesh-Bibliothek arbeiten. Amesh befindet sich noch in der frühen Entwicklungsphase und funktioniert derzeit mit Istio v1.13.1.
Mit Amesh + APISIX können Sie Istio wie gewohnt verwenden. Sobald Sie Verkehrsregeln mit Istios virtuellem Dienst konfigurieren, kann APISIX diese Regeln implementieren.
Die erweiterten Fähigkeiten von APISIX kommen durch seine 80+ Plugins zum Tragen. Um APISIX-Plugins mit Istio zu verwenden, stellen wir eine Amesh-Steuerungsebenen-Komponente namens Amesh Controller bereit.
Der Amesh Controller nimmt eine Plugin-Konfiguration, die mit der AmeshPluginConfig CRD definiert ist, und wandelt sie in eine APISIX-Plugin-Konfiguration um.
All dies ermöglicht es uns, die vollen Fähigkeiten von APISIX innerhalb von Sidecar-Containern zu nutzen.
APISIX + Istio Mesh
Lassen Sie uns alles, was wir gelernt haben, in die Praxis umsetzen.
Wir werden die Amesh-Images erstellen, Istio so konfigurieren, dass es APISIX-Sidecars verwendet, Istio bereitstellen und alles testen, indem wir eine Beispielanwendung ausführen.
Erstellen der Images
Wir werden drei Images erstellen:
- amesh-iptables: wird verwendet, um einen Init-Container zu erstellen, der einige iptables-Regeln einrichtet. Diese Regeln sollen den gesamten Datenverkehr über APISIX leiten.
- amesh-sidecar: wird verwendet, um den Sidecar-Container zu erstellen.
- amesh-controller: wird verwendet, um die Amesh-Controller-Steuerungsebenen-Komponente zu erstellen. Dieser Controller wird verwendet, um APISIX-Plugins zu konfigurieren.
Klonen Sie zunächst das Amesh-Repo:
git clone https://github.com/api7/Amesh.git
cd Amesh
Sie können diese Images erstellen und in Ihre eigene Registry pushen.
Fügen Sie die Adresse Ihrer Registry in eine Umgebungsvariable ein, bevor Sie den Build ausführen, wie unten gezeigt:
export REGISTRY="docker.io/navendu"
make prepare-images
Wenn Sie keine eigenen Images erstellen möchten, können Sie diese Images verwenden:
docker pull navendup/amesh-iptables:dev
docker pull navendup/amesh-sidecar:dev
docker pull navendup/amesh-controller:latest
Bereitstellen des Amesh Controllers und Installieren der CRDs
Wir werden Helm verwenden, um alles im Kubernetes-Cluster bereitzustellen. Ich verwende in diesen Beispielen minikube.
Wir beginnen damit, einen neuen Namespace istio-system zu erstellen:
kubectl create namespace istio-system
Um den Amesh Controller bereitzustellen, führen Sie aus:
helm install amesh-controller -n istio-system \
./controller/charts/amesh-controller
Sie müssen auch CRDs installieren, um mit dem Amesh Controller zu arbeiten:
kubectl apply -k controller/config/crd/
Konfigurieren und Bereitstellen von Istio + APISIX
Bevor wir das Service-Mesh bereitstellen, setzen wir einige Umgebungsvariablen:
export ISTIO_RELEASE=1.13.1
export REGISTRY="docker.io/navendup"
Dann verwenden wir Helm, um das Service-Mesh bereitzustellen:
helm install amesh \
--namespace istio-system \
--set pilot.image=istio/pilot:"$ISTIO_RELEASE" \
--set global.proxy.privileged=true \
--set global.proxy_init.image="$REGISTRY"/amesh-iptables:dev \
--set global.proxy.image="$REGISTRY"/amesh-sidecar:dev \
--set global.imagePullPolicy=IfNotPresent \
--set global.hub="docker.io/istio" \
--set global.tag="$ISTIO_RELEASE" \
./charts/amesh
Jetzt haben wir das Service-Mesh und den Amesh Controller bereitgestellt. Als Nächstes stellen wir eine Beispielanwendung bereit, um unser Service-Mesh zu testen.
Bereitstellen von Bookinfo
Wir verwenden die Bookinfo-Beispielanwendung von Istio.
Zuerst fügen wir dem Standard-Namespace ein Label hinzu, um automatisch Sidecars in jeden Pod im Namespace zu injizieren:
kubectl label ns default istio-injection=enabled
Dann können wir Bookinfo bereitstellen, indem wir ausführen:
kubectl apply -f e2e/bookinfo/bookinfo.yaml
Dadurch wird die Bookinfo-Anwendung gestartet, und jeder der Pods wird APISIX-Sidecars haben:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
details-v1-79f774bdb9-cbn87 2/2 Running 0 55s
productpage-v1-6b746f74dc-tntc8 2/2 Running 0 55s
ratings-v1-b6994bb9-r5j45 2/2 Running 0 55s
reviews-v1-545db77b95-n657s 2/2 Running 0 55s
reviews-v2-7bf8c9648f-zn97s 2/2 Running 0 55s
reviews-v3-84779c7bbc-wn8k2 2/2 Running 0 55s
Testen des Meshes
Um auf die Bookinfo-Anwendung zuzugreifen, benötigen wir einen Ingress-Gateway.
Sie können APISIX für dieses Ingress-Gateway verwenden, aber das ist ein Thema für einen anderen Zeitpunkt. Für jetzt können wir einfach port-forward verwenden, um auf den product-page-Service zuzugreifen:
kubectl port-forward productpage-v1-6b746f74dc-tntc8 9080:9080
Wenn wir jetzt localhost:9080 öffnen, können wir unsere Beispielanwendung sehen.
Jedes Mal, wenn Sie die Seite aktualisieren, werden die Bewertungen von einer anderen Version des Bewertungsdienstes abgerufen (wir haben drei Versionen bereitgestellt).
Lassen Sie uns nun eine Regel mit virtuellen Diensten anwenden, die den gesamten Datenverkehr zu den v1-Versionen der Dienste leitet.
Die Regel ist selbsterklärend und würde so aussehen:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: productpage
spec:
hosts:
- productpage
http:
- route:
- destination:
host: productpage
subset: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings
spec:
hosts:
- ratings
http:
- route:
- destination:
host: ratings
subset: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: details
spec:
hosts:
- details
http:
- route:
- destination:
host: details
subset: v1
---
Sie können es in Ihrem Cluster anwenden, indem Sie ausführen:
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.18/samples/bookinfo/networking/virtual-service-all-v1.yaml
Wenn wir jetzt zu unserer Anwendung zurückkehren und die Seite aktualisieren, wird sie nicht mehr durch die verschiedenen Versionen des Bewertungsdienstes zyklisieren, sondern nur noch zur v1-Version leiten.
Beachten Sie, wie sich das Aussehen des Bewertungsabschnitts hier geändert hat. Es bleibt gleich, auch wenn Sie die Seite aktualisieren.
Zusammenfassend konfigurieren wir eine Regel in Istio, und Istio implementiert sie mit seinen Sidecar-Containern mit Apache APISIX. Geschickt!
Amesh Beyond
Amesh ist ein experimentelles Projekt und befindet sich noch in den Kinderschuhen.
Zukünftige Versionen des Projekts zielen darauf ab, mehr Funktionen durch virtuelle Dienste zu unterstützen.
Sie können zur Verbesserung des Projekts beitragen oder neue Versionen auf GitHub verfolgen.