Por que o Jiakaobaodian escolhe o APISIX Ingress Controller

Com a prevalência do Kubernetes (abreviado como K8s), temos mais opções além do controlador de Ingress NGINX padrão oficial para escolher, e o Apache APISIX Ingress Controller também se tornou uma escolha popular para muitas empresas. Cada vez mais empresas estão gradualmente substituindo seus controladores de Ingress pelo APISIX Ingress Controller.

Contexto

A Wuhan Mucang Technology Co., Ltd foi fundada em 2011, e seus principais produtos são dezenas de aplicativos para carros, como o Jiakaobaodian. Desde sua fundação há mais de 10 anos, a empresa acompanhou a tendência da tecnologia e começou a adotar a nuvem nativa em 2019, com vários projetos da empresa migrando para o Kubernetes.

Mas naquela época, como o K8s havia acabado de surgir, havia poucos portais de entrada de tráfego para escolher. Portanto, usamos o controlador de Ingress padrão – NGINX Ingress Controller – por quase 4 anos. No entanto, durante esse período, ficou cada vez mais claro que o NGINX Ingress Controller não atendia mais às nossas necessidades, forçando-nos a fazer uma nova seleção. Após comparar os principais controladores de Ingress, decidimos usar o Apache APISIX como o gateway de entrada da empresa.

O Problema com o NGINX Ingress Controller

Os serviços da empresa usam os protocolos HTTP e TCP, e apenas os engenheiros de operações e manutenção sabem exatamente como configurar o proxy TCP através do NGINX Ingress Controller. No entanto, a mão de obra de operações e manutenção é limitada. Seria ideal se pudéssemos repassar algumas das operações e configurações básicas do NGINX para a equipe de desenvolvimento, a fim de economizar custos de operações e manutenção.

Além disso, também enfrentamos os seguintes problemas:

Algumas alterações de configuração exigem recarregamento;
O proxy TCP tem um alto custo de uso e não cobre todos os cenários de tráfego;
O roteamento ou operações de tráfego só podem ser definidos por annotations, e não podemos definir e reutilizar configurações semanticamente;
Reescrever, interromper circuitos, transferir solicitações e outras operações são implementadas por meio de annotations;
Falta de uma plataforma de gerenciamento, e a equipe de operações e manutenção precisa operar por meio de YAML, o que é propenso a erros;
Baixa portabilidade;
Não é favorável à integração com plataformas de contêineres.

Por essas razões, decidimos substituir nosso antigo controlador de Ingress por um novo.

Por que o APISIX Ingress Controller

Investigamos o Apache APISIX e outros controladores de Ingress, comparando-os em termos de desempenho, facilidade de uso, escalabilidade e integração com plataformas, e finalmente selecionamos o APISIX Ingress Controller como o gateway de entrada de tráfego do K8s pelos seguintes motivos.

Boa escalabilidade;
Suporte a recarregamento de configuração em tempo real;
Alto desempenho;
Muitos plugins;
Suporte a CRD para integração com a plataforma de contêineres desenvolvida internamente.

Arquitetura Geral

Dito isso, vamos dar uma olhada na arquitetura completa do gateway. Em um cenário de negócios real, os usuários primeiro encaminham o tráfego por meio de um SLB (Server Load Balancer), e quando o tráfego entra no K8s, cada serviço é invocado por meio do cluster APISIX. Também implementamos muitas funções comuns (lançamento canário, controle de fluxo, interrupção de circuitos de API, controle de segurança de tráfego, controle de tráfego de solicitação/resposta, etc.) no lado do gateway para unificar o gerenciamento de serviços, reduzir a complexidade dos negócios e economizar custos.

Diagrama de Arquitetura

Método de Implantação

Nossos negócios são implantados em diferentes plataformas de nuvem (Huawei Cloud, Tencent Cloud, Alibaba Cloud), e podemos colocar nossos negócios online rapidamente por meio do Helm Chart, que é suportado pelo APISIX Ingress Controller. Ao usar o APISIX Ingress Controller, se encontrarmos recursos que podem ser melhorados, também enviamos PRs para ajudar a comunidade a atualizar e iterar os recursos. No processo de implantação real, personalizamos algumas configurações de acordo com as características do nosso negócio, como:

Criar NameSpace por meio do K8s, implantar o APISIX e o APISIX Ingress Controller em diferentes NameSpaces e segregar o tráfego de acordo com as linhas de produtos e a importância do serviço;
Otimizar os parâmetros do kernel TCP do Linux no initContainer do APISIX;
Como precisamos segregar o tráfego em termos de linhas de produtos e importância do serviço, as informações de ClassName do K8s precisam ser configuradas.

Ao isolar o tráfego por diferentes linhas de produtos e importância, você pode minimizar as perdas causadas por falhas de software.

Integração com Plataformas de Contêineres Desenvolvidas Internamente Usando CRD

O APISIX Ingress Controller atualmente suporta muitos recursos CRD, então podemos usar recursos CRD para integrar o APISIX Ingress Controller com nossa própria plataforma de contêineres. No entanto, como o APISIX não fornece um cliente Java, precisamos usar a ferramenta de geração de código fornecida pelo K8s para gerar o Model e usar CustomObjectApi para gerenciar o CRD. Os objetos ApisixRoute são associados a aplicativos da plataforma de contêineres e estruturados com objetos principais, permitindo que tanto a equipe de operações quanto os gerentes de projeto operem na plataforma de contêineres.

Cenários de Aplicação

Autenticação

Antes de usar o Apache APISIX, implementamos a autenticação com base no gateway Istio, e após migrar para o Apache APISIX, optamos por usar o plugin forward-auth, que move habilmente a lógica de autenticação e autorização para um serviço de autenticação externo. A solicitação do usuário é encaminhada para o serviço de autenticação por meio do gateway, e quando o serviço de autenticação responde com um status diferente de 20x, a solicitação original é bloqueada e o resultado é substituído. Dessa forma, é possível retornar um relatório de erro personalizado ou redirecionar o usuário para a página de autenticação se a autenticação falhar.

Quando um cliente envia uma solicitação para um aplicativo, ela é primeiro processada pelo plugin forward-auth do APISIX, e a solicitação é encaminhada para um serviço de autenticação externo via forward-auth, e o resultado é finalmente retornado ao gateway APISIX. Se a autenticação for bem-sucedida, o cliente pode solicitar o serviço normalmente. Se a autenticação falhar, um código de erro é retornado.

Controle de Fluxo

Devido às características do negócio da empresa, há cinco ou seis meses de pico de tráfego todos os anos. Uma vez que há muitas solicitações, precisamos expandir manualmente a capacidade, mas devido ao acúmulo de solicitações, o serviço pode não conseguir iniciar após a expansão, o que levará a uma quebra em cascata de todo o link, então precisamos limitar o fluxo e a velocidade do cluster.

Portanto, usamos os plugins limit-conn, limit-req e limit-count do APISIX para limitar solicitações e evitar quebras em cascata. É mais fácil limitar o fluxo e a velocidade modificando os plugins, e devido ao mecanismo de recarregamento em tempo real do APISIX, não há necessidade de reiniciar os plugins ao configurá-los, para que entrem em vigor imediatamente. Ao controlar o tráfego, também é possível parar alguns ataques maliciosos e proteger a segurança do sistema. Também implementamos o HPA (Horizontal Pod Autoscaler) na plataforma K8s, que escala automaticamente para cima e para baixo uma vez que a quantidade de tráfego é muito grande ou muito pequena, com plugins de limitação de fluxo e taxa do APISIX para evitar quebras massivas.

Observabilidade

Em termos de observabilidade, atualmente monitoramos o tráfego em toda a plataforma por meio do SkyWalking. O plugin SkyWalking do APISIX permite uma interface direta com a plataforma SkyWalking existente, e a interface do SkyWalking facilita a visualização dos nós de link que estão consumindo desempenho. Além disso, como os pontos de monitoramento estão no lado do gateway, mais próximos do usuário, é mais fácil verificar os pontos que consomem tempo.

Com o plugin kafka-logger, os logs de acesso e erro gerados pelo APISIX podem ser escritos diretamente no cluster Apache Kafka. Com essa vantagem, o cluster APISIX pode escalar de forma horizontal e sem estado, sem a necessidade de formatar discos, rotacionar logs ou realizar outras operações. Se os logs fossem armazenados localmente, precisaríamos fazer algumas operações adicionais e não poderíamos alcançar uma escalabilidade rápida. Ao enviar os logs para o cluster Apache Kafka, também podemos analisar os logs em tempo real e melhorar e otimizar o sistema com base nos resultados da análise.

Conclusão

Como o APISIX Ingress Controller acabou de ser lançado, ainda não há muitos cenários de aplicação. Continuaremos a explorar mais cenários de aplicação e trazer mais exemplos de uso para a comunidade.

Cada vez mais equipes estão usando o Apache APISIX Ingress Controller em ambientes de produção. Se você também está usando o APISIX Ingress Controller, incentivamos você a compartilhar seus casos de uso na comunidade.