3 Dicas para Implantar o APISIX no Kubernetes (Parte 2)

A era da computação nativa em nuvem tem visto a adoção generalizada do Kubernetes como uma plataforma de orquestração de contêineres, com o Apache APISIX emergindo como um gateway de API dinâmico de alto desempenho e nativo em nuvem. A implantação do Apache APISIX no Kubernetes tem se tornado cada vez mais comum. No entanto, apesar do processo de implantação do Apache APISIX no Kubernetes ser relativamente simples, ainda há alguns pontos-chaveis a serem considerados. Nesta série de artigos, vamos nos aprofundar nos seguintes tópicos:

1. Considerações sobre métodos de implantação
2. Verificações de saúde, registro de logs e monitoramento
3. Tratamento de plugins e configurações personalizadas

No artigo anterior, discutimos o primeiro ponto. Este artigo se concentrará no segundo ponto: considerações sobre verificações de saúde, registro de logs e monitoramento.

Verificações de Saúde

Ao implantar o APISIX no Kubernetes, as verificações de saúde são particularmente importantes, pois representam um requisito fundamental para aplicações no Kubernetes. No Kubernetes, ao configurar Liveness e Readiness Probes, é possível garantir o status de saúde e a disponibilidade das instâncias do APISIX.

• O Liveness Probe é utilizado para determinar se a aplicação está em execução. Se a aplicação for considerada não saudável, o Kubernetes reiniciará a instância.

• O Readiness Probe é empregado para verificar se a aplicação está pronta para receber tráfego. Se a aplicação ainda não estiver pronta, ela não receberá nenhum tráfego. Isso ajuda a evitar que o tráfego seja enviado para instâncias que não estão totalmente iniciadas ou que estão danificadas.

Ao configurar corretamente os Liveness e Readiness Probes, o Kubernetes pode gerenciar automaticamente instâncias de Pod não saudáveis. Isso implica que, quando as instâncias encontram problemas, o Kubernetes as reiniciará automaticamente ou parará de enviar tráfego para instâncias não saudáveis, aumentando assim a disponibilidade e a estabilidade do sistema.

Exemplo de Configuração YAML:

apiVersion: v1
kind: Deployment
metadata:
  name: my-apisix-pod
spec:
  containers:
  - name: my-apisix-container
    image: my-apisix-image
    livenessProbe:
      httpGet:
        path: /healthz
        port: 9080
      initialDelaySeconds: 15
      periodSeconds: 10
    readinessProbe:
      httpGet:
        path: /readyz
        port: 9080
      initialDelaySeconds: 10
      periodSeconds: 5

Este exemplo define os Liveness e Readiness Probes para o contêiner. O Liveness Probe envia uma requisição HTTP GET para o caminho /healthz a cada 10 segundos para verificar o status de saúde do contêiner. Se o contêiner não responder ou retornar um código de status diferente de 200, o Kubernetes considera o contêiner não saudável e tenta reiniciá-lo. O Readiness Probe é semelhante, mas é usado para verificar se o contêiner está pronto para receber tráfego.

Monitoramento

Existem vários métodos para monitorar o APISIX em tempo de execução, sendo a integração com o Prometheus uma abordagem recomendada. Na verdade, o Prometheus continua sendo o componente de monitoramento mais amplamente utilizado até hoje.

A integração com o Prometheus ajuda a coletar e monitorar métricas para o APISIX e os serviços que ele faz proxy. Essas métricas podem incluir taxas de requisição, taxas de erro, latência e outros indicadores críticos de desempenho. Ao monitorar essas métricas, é possível identificar problemas rapidamente e realizar ajustes de desempenho e solução de problemas. Certifique-se de configurar corretamente as métricas e as regras de alerta para agir prontamente quando problemas surgirem.

Habilitar o plugin do Prometheus no APISIX é simples. Primeiro, defina o export_uri no config.yaml.

plugin_attr:
  prometheus:
    export_uri: /apisix/metrics

Em seguida, habilite o plugin na API ou serviço que precisa ser analisado estatisticamente pelo Prometheus.

curl http://127.0.0.1:9180/apisix/admin/routes/1  -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "uri": "/hello",
    "plugins": {
        "prometheus":{}
    },
    "upstream": {
        ...
    }
}'

Finalmente, o servidor Prometheus pode puxar periodicamente as configurações do export_uri.

scrape_configs:
  - job_name: "apisix"
    scrape_interval: 15s
    metrics_path: "/apisix/prometheus/metrics"
    static_configs:
      - targets: ["127.0.0.1:9091"]

No uso prático, o Prometheus também precisa ser implantado de forma altamente disponível, como usando soluções de código aberto como o Thanos. A integração com o APISIX pode ser alcançada usando o modo sidecar do Thanos.

Registro de Logs

No APISIX, os logs importantes são amplamente categorizados em dois tipos: logs de tráfego e logs de auditoria.

• Os logs de tráfego referem-se ao registro de cada requisição quando o APISIX atua como um proxy reverso. Esses logs, contendo tanto o tráfego de requisição quanto as informações retornadas, juntamente com os logs de operação interna do APISIX, são cruciais para rastreamento e solução de problemas. Normalmente, níveis e formatos de log apropriados são definidos para registro. Em cenários práticos, considere enviar os logs para um sistema de log centralizado, como ELK (Elasticsearch, Logstash e Kibana), Fluentd ou Splunk. O APISIX fornece plugins de log para seleção.

• Os logs de auditoria referem-se principalmente aos logs gerados ao gerenciar as configurações do APISIX. Eles não apenas ajudam a atender aos requisitos de conformidade, mas também servem para análise de segurança. Ao analisar os logs de auditoria, é possível identificar riscos de segurança potenciais e configurações ou comportamentos de gerenciamento inadequados, e tomar medidas correspondentes para melhorar a segurança do sistema.

O APISIX de código aberto fornece uma API Admin para facilitar a distribuição de configurações, mas carece de configurações relacionadas a logs de auditoria. Normalmente, os usuários precisam registrar esses logs por conta própria ou usar a edição empresarial do APISIX.

Não há muitas diferenças na configuração de logs entre o Kubernetes e outros ambientes. Vale ressaltar que, ao configurar informações de upstream e relacionadas no APISIX, a descoberta de serviços do Kubernetes é comumente usada. Recomenda-se registrar o nome do serviço nos logs para facilitar a solução de problemas em questões subsequentes.

Conclusão

Ao configurar mecanismos de verificação de saúde para detectar instâncias não saudáveis do APISIX, o Kubernetes pode agir prontamente para migrar o tráfego e facilitar a recuperação, garantindo assim a continuidade e a estabilidade dos serviços de API. O APISIX também suporta integração com ferramentas avançadas de monitoramento, como o Prometheus, permitindo o monitoramento do desempenho e da estabilidade da API, incluindo métricas-chave como taxas de requisição, taxas de erro e latência. Essa capacidade de monitoramento permite que as organizações identifiquem rapidamente problemas potenciais e realizem ajustes e otimizações de desempenho em tempo hábil, garantindo a operação eficiente dos serviços de API.