Um Service Mesh APISIX com Istio e Amesh

Navendu Pottekkat

Navendu Pottekkat

June 16, 2023

Technology

Apache APISIX é usado principalmente para lidar com o tráfego norte-sul e frequentemente fica na fronteira entre aplicativos clientes e serviços de backend.

Com o APISIX Ingress Controller, o APISIX também pode controlar o tráfego de entrada e saída em clusters Kubernetes com configuração nativa.

Mas, à medida que as organizações adotam microsserviços, surge um novo desafio: lidar com o tráfego leste-oeste entre esses microsserviços.

Malhas de serviço como Istio resolvem isso removendo a responsabilidade de rede do desenvolvedor de microsserviços e fornecendo uma camada adicional de rede L4/L7.

Com a nova biblioteca Amesh e o Istio, o Apache APISIX também pode ser usado como uma malha de serviço, especificamente como um plano de dados para o Istio, trazendo todas as suas capacidades de gerenciamento de tráfego para a comunicação entre serviços.

Neste artigo, vamos examinar o que é o Amesh, como ele foi desenvolvido e como é usado para integrar o APISIX em uma malha de serviço.

Istio e o Protocolo xDS

Istio é uma das malhas de serviço mais amplamente utilizadas.

Nos bastidores, o Istio usa o Envoy como o proxy reverso em seus contêineres sidecar.

Malha de serviço Istio

O Istio gerencia o tráfego configurando dinamicamente os sidecars usando as APIs xDS do Envoy.

As APIs xDS são uma maneira de configurar o Envoy com alterações incrementais em vez de configurações simples com arquivos estáticos.

Embora essas APIs tenham sido inicialmente projetadas para configurar o Envoy, elas evoluíram para se tornarem uma API universal de plano de dados. Qualquer proxy de plano de dados pode implementar essas APIs, e qualquer plano de controle pode usar essa API para trabalhar com esses proxies de plano de dados.

No Istio, isso significa que você pode substituir o plano de dados padrão do Envoy por qualquer plano de dados que implemente as APIs xDS. Assim, você pode substituir o Envoy pelo APISIX para obter suas capacidades de gerenciamento de tráfego em uma malha de serviço.

Mas o APISIX não suporta as APIs xDS nativamente. E é aí que o Amesh entra.

Amesh

Amesh é uma biblioteca que traduz os dados do plano de controle do Istio para a configuração do APISIX.

Malha de serviço APISIX

O APISIX substitui o Envoy como o plano de dados do Istio.

O Istio se comunica com o plano de dados por meio das APIs xDS. O Amesh suporta essas APIs e as converte para a configuração do APISIX.

Isso é semelhante a como o APISIX e o controlador de Ingress do APISIX funcionam. O controlador de Ingress converte as configurações definidas usando o Ingress ou a API Gateway para o formato do APISIX.

Como as APIs xDS são suportadas por mais malhas de serviço como Linkerd e Open Service Mesh, o APISIX também pode trabalhar com elas usando a biblioteca Amesh. O Amesh ainda está nos estágios iniciais de desenvolvimento e atualmente funciona com o Istio v1.13.1.

Com o Amesh + APISIX, você pode usar o Istio como faria normalmente. Assim que você configurar as regras de tráfego com o serviço virtual do Istio, o APISIX pode implementar essas regras.

As capacidades estendidas do APISIX vêm por meio de seus 80+ plugins. Para usar os plugins do APISIX com o Istio, implantamos um componente do plano de controle do Amesh chamado controlador Amesh.

O controlador Amesh pega uma configuração de plugin definida com o CRD AmeshPluginConfig e a converte em uma configuração de plugin do APISIX.

Tudo isso nos permitirá aproveitar todas as capacidades do APISIX dentro dos contêineres sidecar.

APISIX + Istio Mesh

Vamos colocar em prática tudo o que aprendemos.

Vamos construir as imagens do Amesh, configurar o Istio para usar sidecars do APISIX, implantar o Istio e testar tudo executando um aplicativo de exemplo.

Construindo as Imagens

Vamos construir três imagens:

  • amesh-iptables: usado para criar um contêiner init para configurar algumas regras de iptables. Essas regras são para direcionar todo o tráfego através do APISIX.
  • amesh-sidecar: usado para criar o contêiner sidecar.
  • amesh-controller: usado para criar o componente do plano de controle do controlador Amesh. Este controlador é usado para configurar os plugins do APISIX.

Primeiro, clone o repositório do Amesh:

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

Você pode construir e enviar essas imagens para o seu próprio registro.

Adicione o endereço do seu registro em uma variável de ambiente antes de executar a construção, como mostrado abaixo:

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

Se você não quiser construir suas próprias imagens, pode usar estas imagens:

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

Implantando o Controlador Amesh e Instalando CRDs

Vamos usar o Helm para implantar tudo no cluster Kubernetes. Eu uso o minikube nestes exemplos.

Começaremos criando um novo namespace istio-system:

kubectl create namespace istio-system

Para implantar o controlador Amesh, execute:

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

Você também precisa instalar os CRDs para trabalhar com o controlador Amesh:

kubectl apply -k controller/config/crd/

Configurando e Implantando Istio + APISIX

Antes de implantar a malha de serviço, vamos definir algumas variáveis de ambiente:

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

Então usaremos o Helm para implantar a malha de serviço:

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

Agora temos a malha de serviço e o controlador Amesh implantados. Em seguida, vamos implantar um aplicativo de exemplo para testar nossa malha de serviço.

Implantando o Bookinfo

Vamos usar o aplicativo de exemplo Bookinfo do Istio.

Primeiro, vamos adicionar um rótulo ao namespace padrão para injetar automaticamente sidecars em qualquer pod no namespace:

kubectl label ns default istio-injection=enabled

Então podemos implantar o Bookinfo executando:

kubectl apply -f e2e/bookinfo/bookinfo.yaml

Isso irá iniciar o aplicativo Bookinfo, e cada um dos pods terá sidecars do 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

Testando a Malha

Para acessar o aplicativo Bookinfo, precisaríamos de um gateway de entrada.

Você pode usar o APISIX para esse gateway de entrada, mas isso é para outra hora. Por enquanto, podemos usar port-forward para acessar o serviço product-page:

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

Agora, se abrirmos o localhost:9080, poderemos ver nosso aplicativo de exemplo.

Página inicial do Bookinfo

Cada vez que você atualizar a página, as avaliações serão obtidas de uma versão diferente do serviço de avaliações (implantamos três versões).

Agora vamos aplicar uma regra usando serviços virtuais que roteia todo o tráfego para as versões v1 dos serviços.

A regra é autoexplicativa e ficaria assim:

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

Você pode aplicá-la ao seu cluster executando:

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

Agora, se voltarmos ao nosso aplicativo e atualizarmos a página, ele parará de alternar entre as várias versões do serviço de avaliações e roteará apenas para a versão v1.

Bookinfo apenas v1

Observe como a aparência da seção de avaliações mudou aqui. Ela permanecerá a mesma mesmo que você atualize a página.

Para resumir, configuramos uma regra no Istio, e o Istio a implementa usando seus contêineres sidecar com o Apache APISIX. Legal!

Amesh Além

O Amesh é um projeto experimental e ainda está em sua infância.

Versões futuras do projeto visam suportar mais recursos por meio de serviços virtuais.

Você pode contribuir para melhorar o projeto ou acompanhar novas versões no GitHub.

Tags: