Por que a AISpeech escolhe o Apache APISIX em vez do NGINX como controlador de Ingress no k8s

Prefácio

Olá a todos, sou Jin Wei da AISpeech, uma empresa de alta tecnologia especializada em reconhecimento e análise de fala computacional, e estou aqui para falar sobre a integração do Apache APISIX com o K8s em vez do ingress nativo.

No momento em que este artigo foi escrito, o Apache APISIX já foi aplicado ao nosso ambiente de produção e assumiu parte do tráfego de entrada dos negócios. Estamos gradualmente migrando o tráfego do ingress nativo, conforme mostrado na figura abaixo.

Na verdade, o APISIX-ingress-controller registra o IP do pod no nó upstream, permitindo que o tráfego de negócios acesse o pod diretamente e contorne o DNS do kube. Você pode implementar algumas políticas de balanceamento de carga específicas por meio de plugins com base nisso. Portanto, por um lado, dependemos dessa capacidade de roteamento dinâmico do Apache APISIX para distribuição de tráfego. Por outro lado, adicionamos alguns plugins personalizados para atender às necessidades dos negócios.

Pelo diagrama acima, o APISIX-ingress-controller parece repetitivo em relação ao ingress nativo. Neste artigo, explicaremos brevemente por que abandonamos o ingress nativo e construímos nosso próprio controlador de ingress baseado no Apache APISIX.

O Que É Ingress

Em poucas palavras, o Ingress é uma forma do Kubernetes lidar com tráfego externo.

Qual Problema o Ingress Resolve

Como os serviços dentro de um cluster Kubernetes são redes virtuais, o tráfego externo requer pelo menos um IP público e uma porta mapeada corretamente para acessar os serviços internos do cluster.

O Kubernetes tem várias maneiras (NodePort, LoadBalancer, Ingress, …) de expor interfaces para acessar os serviços internos do Kubernetes. Em comparação, o Ingress é definitivamente uma maneira mais econômica de alcançar um proxy reverso, expondo um número limitado de IPs públicos.

Falando em proxy reverso, também poderíamos construir um NGINX diretamente para fazer isso, mas é significativamente mais difícil manter a sincronização do estado dos serviços, que mudam frequentemente no Kubernetes, no NGINX.

A boa notícia é que o Kubernetes fornece e mantém oficialmente um controlador de ingress NGINX para ajudar a resolver o proxy reverso. Com esse controlador de ingress NGINX, podemos redirecionar todo o tráfego que deseja acessar o Kubernetes e apontá-lo corretamente para os serviços de backend.

Problemas com o Controlador de Ingress Nativo do Kubernetes

O controlador de ingress NGINX nos ajuda a manter a sincronização de estado entre o cluster Kubernetes e o NGINX, além de fornecer capacidades básicas de proxy reverso. Então, por que construímos nosso próprio ingress? Esperamos mais do controlador de ingress para atender a mais necessidades dos negócios.

Após usar o controlador de ingress nativo do Kubernetes, identificamos os seguintes problemas como os mais proeminentes:

1. Problema de Recarregamento

   O ingress nativo do Kubernetes foi projetado para passar arquivos de configuração YAML para o controlador de ingress, convertê-los em arquivos de configuração do NGINX e, em seguida, acionar o recarregamento para que a configuração entre em vigor.

   Isso é inaceitável, especialmente quando o tráfego usa conexões de longa duração, o que pode levar a acidentes.

   Em contraste, o Apache APISIX suporta recarregamento de configuração em tempo real, permitindo que você defina e modifique rotas a qualquer momento sem acionar um recarregamento do NGINX.

2. Escrever scripts e preencher parâmetros em anotações

   O controlador de ingress nativo suporta trechos de script definidos por anotações no arquivo YAML, o que parece uma solução temporária para suportar funcionalidades avançadas e, francamente, é realmente difícil de gerenciar. O grande número de scripts de anotação causa problemas para a equipe de DevOps.

   No Apache APISIX, podemos escrever lógica por meio de código de plugin para expor uma interface de configuração simples que facilita a manutenção da configuração e evita a interferência de scripts na equipe de DevOps.

3. Falta de suporte para balanceamento de carga com estado

   Políticas avançadas de balanceamento de carga não são suportadas, como "persistência de sessão", etc. O Kubernetes é um sistema de gerenciamento de aplicações em contêineres orientado para operações, o que pode ter a ver com o fato de que o Kubernetes promove uma abordagem de implantação sem estado, então o Kubernetes não suportará oficialmente essas políticas de balanceamento de carga contraditórias no futuro próximo. Na verdade, o Google já tentou resolver esses problemas com sua solução de malha de serviço (Istio). A arquitetura do Istio é perfeita, mas às custas do desempenho, o que pode ser resolvido com o mixer v2.

   Como o Kubernetes suporta escalonamento, também podemos estender o Apache APISIX para atender às nossas necessidades avançadas de balanceamento de carga, já que o Apache APISIX não apenas suporta "persistência de sessão" e outros balanceamentos de carga nativamente, mas também tem a capacidade de escalar a fase de balanceamento.

4. Pesos dinâmicos

   Serviços de negócios frequentemente precisam controlar o tráfego por porcentagem, o que se torna um problema no Kubernetes.

   Embora o Kubernetes suporte IPVS (IP Virtual Server) após a versão 1.8, nem os parâmetros de inicialização do “kube-proxy” nem as anotações do “kube-route” são tão fáceis de usar quanto o Apache APISIX, que internamente abstrai rota, serviço, consumidor, upstream, plugin e outros objetos principais. Ajustar o peso de tais operações é naturalmente suportado, simplesmente modificando o “peso do nó” em “upstream”.

5. Capacidades de extensão inflexíveis

   Embora o Ingress tenha sido originalmente projetado para lidar com tráfego externo, não há menos demanda para tráfego externo do que para tráfego interno.

   Liberação canário no nível de serviço, interrupção de circuito, controle de fluxo, autenticação, controle de tráfego e outros requisitos são mais comumente implementados no Ingress.

   O Apache APISIX fornece suporte a plugins para escalabilidade, e além dos plugins oficiais, você pode personalizar plugins para atender às suas próprias características.

   Também há alguns problemas de configuração causados por ConfigMap e Namespaces, que estão relacionados à forma como os usamos e não são genéricos, então não vou entrar neles aqui.

Controlador de Ingress do Apache APISIX

Devido às poderosas capacidades de roteamento e escalabilidade do Apache APISIX, usar o Apache APISIX como uma implementação do Ingress pode facilmente resolver os pontos de dor mencionados acima e fornecer à comunidade uma opção adicional de controlador de ingress. O diagrama de tempo é o seguinte:

Para implementar o controlador de ingress do Apache APISIX, precisamos resolver dois tipos de problemas fundamentais: um é resolver a sincronização entre o cluster Kubernetes e o estado do Apache APISIX; o outro é definir os objetos no Apache APISIX no Kubernetes (CRD).

Para integrar rapidamente o Apache APISIX e aproveitar seus benefícios, criamos o projeto Apache APISIX ingress controller (todos são bem-vindos a participar), que atualmente implementa o primeiro tipo de problema básico: sincronizar as informações do pod do Kubernetes para o upstream do Apache APISIX, enquanto implementa um backup primário para resolver seus próprios problemas de alta disponibilidade.

Como o Kubernetes usa YAML para definir o estado do cluster de forma declarativa, precisamos definir CRD (Custom Resource Definitions) para os objetos (rota/serviço/upstream/plugin) no Apache APISIX para serem integrados ao Kubernetes.

Além disso, para facilitar a migração de usuários existentes do ingress do Kubernetes, tentaremos ser compatíveis com os itens de configuração existentes do ingress.

Esses recursos serão o objetivo dos nossos próximos esforços, e convidamos você a participar.