Un maillage de services APISIX avec Istio et Amesh

Apache APISIX est principalement utilisé pour gérer le trafic nord-sud et se situe souvent à la frontière entre les applications clientes et les services backend.

Avec le APISIX Ingress Controller, APISIX peut également contrôler le trafic d'entrée-sortie dans les clusters Kubernetes avec une configuration native.

Mais à mesure que les organisations adoptent les microservices, un nouveau défi se présente pour gérer le trafic est-ouest entre ces microservices.

Les maillages de services comme Istio résolvent ce problème en retirant la responsabilité réseau des développeurs de microservices et en fournissant une couche réseau supplémentaire L4/L7.

Avec la nouvelle bibliothèque Amesh et Istio, Apache APISIX peut également être utilisé comme un maillage de services, spécifiquement comme un plan de données pour Istio, apportant toutes ses capacités de gestion de trafic à la communication entre services.

Dans cet article, nous examinerons ce qu'est Amesh, comment il a été développé et comment il est utilisé pour intégrer APISIX dans un maillage de services.

Istio et le protocole xDS

Istio est l'un des maillages de services les plus largement utilisés.

Sous le capot, Istio utilise Envoy comme proxy inverse dans ses conteneurs sidecar.

Maillage de services Istio

Istio gère le trafic en configurant dynamiquement les sidecars à l'aide des API xDS d'Envoy.

Les API xDS sont un moyen de configurer Envoy avec des modifications incrémentielles au lieu de configurations simples avec des fichiers statiques.

Bien que ces API aient été initialement conçues pour configurer Envoy, elles ont évolué pour devenir une API universelle de plan de données. Tout proxy de plan de données peut implémenter ces API, et tout plan de contrôle peut utiliser cette API pour travailler avec ces proxies de plan de données.

Dans Istio, cela signifie que vous pouvez remplacer le plan de données Envoy par défaut par tout plan de données qui implémente les API xDS. Ainsi, vous pouvez remplacer Envoy par APISIX pour bénéficier de ses capacités de gestion de trafic dans un maillage de services.

Mais APISIX ne prend pas en charge les API xDS nativement. Et c'est là qu'intervient Amesh.

Amesh

Amesh est une bibliothèque qui traduit les données du plan de contrôle d'Istio en configuration APISIX.

Maillage de services APISIX

APISIX remplace Envoy comme plan de données pour Istio.

Istio communique avec le plan de données via les API xDS. Amesh prend en charge ces API et les convertit ensuite en configuration APISIX.

Cela ressemble à la façon dont APISIX et le contrôleur APISIX Ingress fonctionnent. Le contrôleur Ingress convertit les configurations définies à l'aide de l'API Ingress ou Gateway en format APISIX.

Étant donné que les API xDS sont prises en charge par d'autres maillages de services comme Linkerd et Open Service Mesh, APISIX peut également fonctionner avec eux en utilisant la bibliothèque Amesh. Amesh en est encore aux premiers stades de développement et fonctionne actuellement avec Istio v1.13.1.

Avec Amesh + APISIX, vous pouvez utiliser Istio comme vous le feriez normalement. Une fois que vous avez configuré les règles de trafic avec le service virtuel d'Istio, APISIX peut implémenter ces règles.

Les capacités étendues d'APISIX passent par ses 80+ plugins. Pour utiliser les plugins d'APISIX avec Istio, nous déployons un composant du plan de contrôle Amesh appelé le contrôleur Amesh.

Le contrôleur Amesh prend une configuration de plugin définie avec le CRD AmeshPluginConfig et la convertit en une configuration de plugin APISIX.

Tout cela nous permettra de tirer parti des capacités complètes d'APISIX dans les conteneurs sidecar.

APISIX + Maillage Istio

Mettons en pratique tout ce que nous avons appris.

Nous allons construire les images Amesh, configurer Istio pour utiliser les sidecars APISIX, déployer Istio et tester le tout en exécutant une application exemple.

Construction des images

Nous allons construire trois images :

amesh-iptables : utilisée pour créer un conteneur init afin de configurer certaines règles iptables. Ces règles visent à diriger tout le trafic via APISIX.
amesh-sidecar : utilisée pour créer le conteneur sidecar.
amesh-controller : utilisée pour créer le composant du plan de contrôle Amesh. Ce contrôleur est utilisé pour configurer les plugins APISIX.

Tout d'abord, clonez le dépôt Amesh :

git clone https://github.com/api7/Amesh.git
cd Amesh

Vous pouvez construire et pousser ces images vers votre propre registre.

Ajoutez l'adresse de votre registre dans une variable d'environnement avant d'exécuter la construction, comme indiqué ci-dessous :

export REGISTRY="docker.io/navendu"
make prepare-images

Si vous ne souhaitez pas construire vos propres images, vous pouvez utiliser ces images :

docker pull navendup/amesh-iptables:dev
docker pull navendup/amesh-sidecar:dev
docker pull navendup/amesh-controller:latest

Déploiement du contrôleur Amesh et installation des CRDs

Nous utiliserons Helm pour déployer tout cela dans le cluster Kubernetes. J'utilise minikube dans ces exemples.

Nous commencerons par créer un nouvel espace de noms istio-system :

kubectl create namespace istio-system

Pour déployer le contrôleur Amesh, exécutez :

helm install amesh-controller -n istio-system \
./controller/charts/amesh-controller

Vous devez également installer les CRDs pour travailler avec le contrôleur Amesh :

kubectl apply -k controller/config/crd/

Configuration et déploiement d'Istio + APISIX

Avant de déployer le maillage de services, nous allons définir quelques variables d'environnement :

export ISTIO_RELEASE=1.13.1
export REGISTRY="docker.io/navendup"

Ensuite, nous utiliserons Helm pour déployer le maillage de services :

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

Maintenant que nous avons déployé le maillage de services et le contrôleur Amesh, déployons une application exemple pour tester notre maillage de services.

Déploiement de Bookinfo

Nous utiliserons l'application exemple Bookinfo d'Istio.

Tout d'abord, nous allons ajouter un label à l'espace de noms par défaut pour injecter automatiquement des sidecars dans tout pod de l'espace de noms :

kubectl label ns default istio-injection=enabled

Ensuite, nous pouvons déployer Bookinfo en exécutant :

kubectl apply -f e2e/bookinfo/bookinfo.yaml

Cela lancera l'application Bookinfo, et chacun des pods aura des sidecars APISIX :

$ 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

Test du maillage

Pour accéder à l'application Bookinfo, nous aurons besoin d'une passerelle d'entrée.

Vous pouvez utiliser APISIX pour cette passerelle d'entrée, mais cela sera pour une autre fois. Pour l'instant, nous pouvons simplement utiliser port-forward pour accéder au service product-page :

kubectl port-forward productpage-v1-6b746f74dc-tntc8 9080:9080

Maintenant, si nous ouvrons localhost:9080, nous pourrons voir notre application exemple.

Page d'accueil de Bookinfo

Chaque fois que vous actualisez la page, les avis sont tirés d'une version différente du service des avis (nous avons déployé trois versions).

Appliquons maintenant une règle utilisant les services virtuels qui route tout le trafic vers les versions v1 des services.

La règle est explicite, et elle ressemblerait à ceci :

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

Vous pouvez l'appliquer à votre cluster en exécutant :

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.18/samples/bookinfo/networking/virtual-service-all-v1.yaml

Maintenant, si nous retournons à notre application et actualisons la page, elle cessera de parcourir les multiples versions du service des avis et ne routera que vers la version v1.

Bookinfo v1 uniquement

Remarquez comment l'apparence de la section des avis a changé ici. Elle restera la même même si vous actualisez la page.

Pour résumer, nous configurons une règle dans Istio, et Istio l'implémente en utilisant ses conteneurs sidecar avec Apache APISIX. Sympa !

Amesh au-delà

Amesh est un projet expérimental, et il en est encore à ses débuts.

Les versions futures du projet visent à prendre en charge plus de fonctionnalités via les services virtuels.

Vous pouvez contribuer à l'amélioration du projet ou suivre les nouvelles versions sur GitHub.