Compartilhar via

Diretrizes para executar o gateway auto-hospedado em Kubernetes em produção

  • Artigo

APLICA-SE A: Desenvolvedor | Premium

Para executar o gateway auto-hospedado em produção, há vários aspectos a serem levados em conta. Por exemplo, ele deve ser implantado de maneira altamente disponível, usar backups de configuração para lidar com desconexões temporárias e muito mais.

Este artigo fornece orientação sobre como executar o gateway auto-hospedado em Kubernetes para cargas de trabalho de produção para garantir que ele seja executado de maneira tranquila e confiável.

Token de acesso

Sem um token de acesso válido, um gateway auto-hospedado não pode acessar nem baixar dados de configuração do ponto de extremidade do serviço de Gerenciamento de API associado. O token de acesso pode ser válido por um máximo de 30 dias. Ele deve ser regenerado e o cluster configurado com um token atualizado, seja manualmente ou por meio da automação antes de expirar.

Quando você estiver automatizando a atualização de token, use esta operação de API de gerenciamento para gerar um novo token. Para obter informações sobre como gerenciar segredos do Kubernetes, confira o site do Kubernetes.

Dica

Você também pode implantar o gateway auto-hospedado no Kubernetes e habilitar a autenticação para a instância de Gerenciamento de API usando Microsoft Entra ID.

Dimensionamento automático

Embora forneçamos diretrizes sobre o número mínimo de réplicas para o gateway auto-hospedado, recomendamos que você use o dimensionamento automático para o gateway auto-hospedado para atender à demanda de seu tráfego de forma mais proativa.

Há duas maneiras de dimensionar automático o gateway auto-hospedado horizontalmente:

  • Dimensionamento automático com base no uso de recursos (CPU e memória)
  • Dimensionamento automático com base no número de solicitações por segundo

Isso é possível por meio da funcionalidade nativa do Kubernetes ou usando KEDA (Dimensionamento automático controlado por evento). O KEDA é um projeto de incubação de CNCF que se esforça para tornar o dimensionamento automático do aplicativo simples.

Observação

KEDA é uma tecnologia de código aberto que não é abrangido suporte do Azure e precisa ser operada pelos clientes.

Dimensionamento automático baseado em recursos

O Kubernetes permite que você dimensione automaticamente o gateway auto-hospedado com base no uso de recursos usando um Horizontal Pod Autoscaler. Ele permite que você defina limites de CPU e memória e o número de réplicas para dimensionar ou escalar horizontalmente.

Uma alternativa é usar o KEDA (Dimensionamento Automático Baseado em Eventos) do Kubernetes, permitindo que você dimensione cargas de trabalho com base em uma variedade de dimensionadores, incluindo CPU e memória.

Dica

Se você já estiver usando KEDA para dimensionar outras cargas de trabalho, recomendamos usar KEDA como um dimensionador automático de aplicativo unificado. Se esse não for o caso, sugerimos fortemente contar com a funcionalidade nativa do Kubernetes por meio do Horizontal Pod Autoscaler.

Dimensionamento automático baseado em tráfego

O Kubernetes não fornece um mecanismo pronto para uso para o dimensionamento automático baseado em tráfego.

O KEDA (Dimensionamento Automático Baseado em Eventos) do Kubernetes fornece algumas maneiras que podem ajudar com o dimensionamento automático baseado em tráfego:

  • Você poderá fazer o dimensionamento com base nas métricas de uma entrada do Kubernetes se elas estiverem disponíveis no Prometheus ou no Azure Monitor usando um dimensionador pronto para uso
  • Você pode instalar o complemento HTTP, que está disponível em beta, e dimensiona com base no número de solicitações por segundo.

Backup de configuração

Configure um volume de armazenamento local para o contêiner de gateway auto-hospedado, de modo que ele possa persistir uma cópia de backup da última configuração baixada. Se a conectividade estiver inativa, o volume de armazenamento poderá usar a cópia de backup após a reinicialização. O caminho de montagem de volume precisa ser /apim/config e pertencer à ID do grupo 1001. Confira um exemplo no GitHub. Para saber mais sobre o armazenamento no Kubernetes, confira o site do Kubernetes. Para alterar a propriedade de um caminho montado, confira a configuração securityContext.fsGroup no site do Kubernetes.

Observação

Para saber mais sobre o comportamento do gateway auto-hospedado na presença de uma interrupção de conectividade temporária do Azure, confira Visão geral do gateway auto-hospedado.

Marca de imagem de contêiner

O arquivo YAML fornecido no portal do Azure usa a marca mais recente. Essa marca sempre faz referência à versão mais recente da imagem de contêiner do gateway auto-hospedado.

Considere usar uma marca de versão específica na produção para evitar a atualização não intencional para uma versão mais recente.

Você pode baixar uma lista completa de marcas disponíveis.

Dica

Ao instalar o com o Helm, a marcação de imagem é otimizada para você. A versão do aplicativo do Pacote do Helm fixa o gateway a uma determinada versão e não depende de latest.

Saiba mais sobre como instalar um gateway de Gerenciamento de API auto-hospedado em Kubernetes com o Helm.

Recursos do contêiner

Por padrão, o arquivo YAML fornecido no portal do Azure não especifica solicitações de recurso de contêiner.

É impossível prever e recomendar de forma confiável a quantidade de recursos de memória e CPU por contêiner e o número de réplicas necessárias para dar suporte a uma carga de trabalho específica. Muitos fatores estão em jogo, como:

  • Hardware específico em que o cluster está sendo executado.
  • Presença e tipo de virtualização.
  • Número e taxa de conexões de cliente simultâneas.
  • Taxa de solicitação.
  • Tipo e número de políticas configuradas.
  • Tamanho do payload e se os payloads são armazenados em buffer ou transmitidos.
  • Latência do serviço de back-end.

Recomendamos definir solicitações de recursos para dois núcleos e 2 GiB como um ponto de partida. Realize um teste de carga e escale ou reduza verticalmente ou horizontalmente com base nos resultados.

Nomes de domínio personalizados e certificados SSL

Caso você use nomes de domínio personalizados para os pontos de extremidade de Gerenciamento de API, especialmente um nome de domínio personalizado para o ponto de extremidade de Gerenciamento, talvez seja necessário atualizar o valor de config.service.endpoint no arquivo <gateway-name>.yaml para substituir o nome de domínio padrão pelo nome de domínio personalizado. Verifique se o ponto de extremidade de Gerenciamento pode ser acessado do pod do gateway auto-hospedado no cluster do Kubernetes.

Nesse cenário, se o certificado SSL usado pelo ponto de extremidade de Gerenciamento não estiver assinado por um certificado de CA (autoridade de certificação) conhecido, você deverá verificar se o certificado de CA é da confiança do pod do gateway auto-hospedado.

Observação

Com o gateway auto-hospedado v2, o Gerenciamento de API fornece um novo ponto de extremidade de configuração: <apim-service-name>.configuration.azure-api.net. Nomes de host personalizados também são compatíveis e podem ser usados em vez do nome do host padrão.

Política de DNS

A resolução de nomes DNS desempenha uma função crítica na capacidade de um gateway auto-hospedado de se conectar a dependências no Azure e expedir chamadas de API para serviços de back-end.

O arquivo YAML fornecido no portal do Azure aplica a política de ClusterFirst padrão. Essa política faz com que as solicitações de resolução de nomes não resolvidas pelo DNS do cluster sejam encaminhadas para o servidor DNS upstream herdado do nó.

Para saber mais sobre a resolução de nomes no Kubernetes, confira o site do Kubernetes. Considere a personalização da política DNS ou da configuração de DNS conforme apropriado para sua configuração.

Política de tráfego externo

O arquivo YAML fornecido no portal do Azure define o campo externalTrafficPolicy no objeto externalTrafficPolicy para Local. Isso preserva o endereço IP do chamador (acessível no contexto da solicitação) e desabilita o balanceamento de carga entre nós, eliminando os saltos de rede causados por ele. Essa configuração pode levar à distribuição assimétrica de tráfego em implantações com um número desigual de pods de gateway por nó.

Alta disponibilidade

O gateway auto-hospedado é um componente crucial na infraestrutura e precisa estar altamente disponível. No entanto, falhas poderão e irão ocorrer.

Considere proteger o gateway auto-hospedado contra interrupções.

Dica

Ao instalar o com o Helm, habilite facilmente o agendamento de alta disponibilidade habilitando a opção de configuração highAvailability.enabled.

Saiba mais sobre como instalar um gateway de Gerenciamento de API auto-hospedado em Kubernetes com o Helm.

Proteção contra falha de nó

Para evitar o impacto de falhas de data center ou de nó, considere usar um cluster Kubernetes que use zonas de disponibilidade para obter alta disponibilidade no nível de nó.

As zonas de disponibilidade permitem que você agende o pod do gateway auto-hospedado em nós espalhados pelas zonas, usando:

Observação

Se você estiver usando o Serviço de Kubernetes do Azure, saiba como usar zonas de disponibilidade neste artigo.

Proteger contra interrupções de pod

Os pods podem sofrer interrupções devido a vários motivos, como exclusão de pod manual, manutenção de nó etc.

Considere o uso de Orçamentos de Interrupção de Pod para impor que um número mínimo de pods esteja disponível em um determinado momento.

Proxy HTTP(S)

O gateway auto-hospedado fornece suporte para o proxy HTTP(S) usando as variáveis de ambiente tradicionais HTTP_PROXY, HTTPS_PROXY e NO_PROXY.

Depois de configurado, o gateway auto-hospedado usará automaticamente o proxy para todas as solicitações HTTP(S) de saída para os serviços de back-end.

A partir da versão 2.1.5 ou superior, o gateway auto-hospedado fornece observabilidade relacionada à solicitação de proxy:

  • O Inspetor de API mostrará as etapas adicionais e as interações relacionadas quando o proxy HTTP(S) estiver sendo usado.
  • São fornecidos logs detalhados para dar uma indicação do comportamento do proxy de solicitação.

Observação

Devido a um problema conhecido com proxies HTTP usando autenticação básica, não há suporte para a validação da lista de certificados revogados (CRL). Saiba mais em nossa referência de configurações de Gateway Auto-Hospedado sobre como configurá-lo adequadamente.

Aviso

Verifique se os requisitos de infraestrutura foram atendidos e se o gateway auto-hospedado ainda pode se conectar a eles ou algumas funcionalidades não funcionarão corretamente.

Métricas e logs locais

O gateway auto-hospedado envia telemetria para o Azure Monitor e Application Insights do Azure de acordo com as definições de configuração no serviço de Gerenciamento de API associado. Quando a conectividade com o Azure é temporariamente perdida, o fluxo de telemetria para o Azure é interrompido e os dados são perdidos durante a interrupção.

Considere usar Insights de Contêineres do Azure Monitor para monitorar seus contêineres ou configurar monitoramento local para garantir a capacidade de observar o tráfego de API e evitar perda de telemetria durante interrupções de conectividade do Azure.

Namespace

Os namespaces de Kubernetes ajudam a dividir um único cluster entre várias equipes, projetos ou aplicativos. Os namespaces fornecem um escopo para recursos e nomes. Eles podem ser associados a uma cota de recursos e a políticas de controle de acesso.

O portal do Azure fornece comandos para criar recursos de gateway auto-hospedado no namespace padrão. Esse namespace é criado automaticamente, existe em cada cluster e não pode ser excluído. Considere criar e implantar um gateway auto-hospedado em um namespace separado na produção.

Número de réplicas

O número mínimo de réplicas adequadas para a produção é de três, preferencialmente combinado com agendamento de alta disponibilidade das instâncias.

Por padrão, um gateway auto-hospedado é implantado com uma estratégia de implantação RollingUpdate. Examine os valores padrão e considere definir explicitamente os campos maxUnavailable e maxSurge, especialmente quando você estiver usando uma alta contagem de réplicas.

Desempenho

É recomendável reduzir os logs de contêiner para avisos (warn) para aprimorar o desempenho. Saiba mais em nossa referência de configuração de gateway auto-hospedado.

Limitação de solicitação

A limitação de solicitação em um gateway auto-hospedado pode ser habilitada usando a política rate-limit ou rate-limit-by-key do Gerenciamento de API. Configure as contagens de limite de taxa para sincronizar entre as instâncias de gateway em todos os nós de cluster, expondo as seguintes portas na implantação do Kubernetes para descoberta de instância:

  • Porta 4290 (UDP), para a sincronização de limitação de taxa
  • Porta 4291 (UDP), para o envio de pulsações para outras instâncias

Observação

As contagens de limite de taxa em um gateway auto-hospedado podem ser configuradas para sincronizar localmente (entre instâncias de gateway em todos os nós de cluster), por exemplo, por meio da implantação do gráfico do Helm para Kubernetes ou usando os modelos de implantação do portal do Azure. No entanto, as contagens de limite de taxa não são sincronizadas com os outros recursos de gateway configurados na instância de Gerenciamento de API, incluindo o gateway gerenciado na nuvem.

Segurança

O gateway auto-hospedado é capaz de ser executado como não raiz no Kubernetes, permitindo que os clientes executem o gateway com segurança.

Veja um exemplo do contexto de segurança do contêiner de gateway auto-hospedado:

securityContext:
  allowPrivilegeEscalation: false
  runAsNonRoot: true
  runAsUser: 1001       # This is a built-in user, but you can use any user ie 1000 as well
  runAsGroup: 2000      # This is just an example
  privileged: false
  capabilities:
    drop:
    - all

Aviso

Não há suporte para executar o gateway auto-hospedado com sistema de arquivos somente leitura (readOnlyRootFilesystem: true).

Aviso

Ao usar certificados de AC locais, o gateway auto-hospedado precisa ser executado com a UID (ID de usuário) 1001 para gerenciar os certificados de AC. Caso contrário, o gateway não será iniciado.

Próximas etapas