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

  • Artigo

APLICA-SE A: Developer | Prémio

Para executar o gateway auto-hospedado na produção, há vários aspetos a ter em mente. 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 no Kubernetes para cargas de trabalho de produção para garantir que ele seja executado sem problemas e de forma confiável.

Importante

O suporte para imagens de contêiner de gateway auto-hospedado do Azure API Management versão 0 e versão 1 termina em 1º de outubro de 2023, juntamente com sua API de Configuração v1 correspondente. Use nosso guia de migração para usar o gateway auto-hospedado v2.0.0 ou superior com a API de configuração v2. Saiba mais em nossa documentação de substituição

Token de acesso

Sem um token de acesso válido, um gateway auto-hospedado não pode acessar e 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 período máximo de 30 dias. Ele deve ser regenerado e o cluster configurado com um novo token, manualmente ou por meio de automação antes de expirar.

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

Gorjeta

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 o Microsoft Entra ID.

Dimensionamento automático

Embora forneçamos orientação 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 do seu tráfego de forma mais proativa.

Há duas maneiras de dimensionar automaticamente 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 o Kubernetes Event-driven Autoscaling (KEDA). KEDA é um projeto de incubação CNCF que se esforça para tornar o dimensionamento automático de aplicativos simples.

Nota

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

Dimensionamento automático baseado em recursos

O Kubernetes permite dimensionar automaticamente o gateway auto-hospedado com base no uso de recursos usando um Horizontal Pod Autoscaler. Ele permite definir limites de CPU e memória e o número de réplicas a serem dimensionadas ou ampliadas.

Uma alternativa é usar o Kubernetes Event-driven Autoscaling (KEDA), permitindo dimensionar cargas de trabalho com base em uma variedade de escaladores, incluindo CPU e memória.

Gorjeta

Se você já estiver usando o KEDA para dimensionar outras cargas de trabalho, recomendamos usar o KEDA como um autoscaler de aplicativo unificado. Se esse não for o caso, então sugerimos fortemente confiar na funcionalidade nativa do Kubernetes através do Horizontal Pod Autoscaler.

Dimensionamento automático baseado em tráfego

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

O Kubernetes Event-driven Autoscaling (KEDA) fornece algumas maneiras que podem ajudar com o dimensionamento automático baseado em tráfego:

  • Você pode dimensionar com base em 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 versão 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, para que ele possa manter uma cópia de backup da configuração baixada mais recente. 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 do volume deve ser /apim/config e deve ser de propriedade da ID 1001do grupo. Veja um exemplo no GitHub. Para saber mais sobre o armazenamento no Kubernetes, consulte o site do Kubernetes. Para alterar a propriedade de um caminho montado, consulte a securityContext.fsGroup configuração no site do Kubernetes.

Nota

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

Tag de imagem de contêiner

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

Considere o uso de uma tag 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 tags disponíveis.

Gorjeta

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

Saiba mais sobre como instalar um gateway auto-hospedado do Gerenciamento de API no 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 recursos de contêiner.

É impossível prever e recomendar de forma confiável a quantidade de recursos de CPU e memória 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, tais como:

  • Hardware específico no qual o cluster está sendo executado.
  • Presença e tipo de virtualização.
  • Número e taxa de conexões simultâneas de clientes.
  • Taxa de solicitação.
  • Tipo e número de políticas configuradas.
  • Tamanho da carga útil e se as cargas úteis são armazenadas em buffer ou transmitidas.
  • Latência do serviço de back-end.

Recomendamos definir as solicitações de recursos para dois núcleos e 2 GiB como ponto de partida. Execute um teste de carga e aumente ou diminua a escala com base nos resultados.

Nomes de domínio personalizados e certificados SSL

Se você usar nomes de domínio personalizados para os pontos de extremidade de Gerenciamento de API, especialmente se usar um nome de domínio personalizado para o ponto de extremidade de Gerenciamento, talvez seja necessário atualizar o valor de no <arquivo gateway-name.yaml> para substituir o nome de domínio padrão pelo nome de config.service.endpoint domínio personalizado. Certifique-se de que o ponto de extremidade de gerenciamento possa ser acessado a partir 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 for assinado por um certificado de autoridade de certificação conhecido, você deverá certificar-se de que o certificado de autoridade de certificação é confiável pelo pod do gateway auto-hospedado.

Nota

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 são suportados para este ponto de extremidade e podem ser usados em vez do nome de host padrão.

Política DNS

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

O arquivo YAML fornecido no portal do Azure aplica a política 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, consulte o site do Kubernetes. Considere personalizar a política de DNS ou a configuração de DNS conforme apropriado para sua configuração.

Política de tráfego externo

O arquivo YAML fornecido no campo Conjuntos externalTrafficPolicy de portal do Azure no objeto Service como 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. Esteja ciente de que essa configuração pode causar uma distribuição assimétrica do tráfego em implantações com número desigual de pods de gateway por nó.

Elevada disponibilidade

O gateway auto-hospedado é um componente crucial na infraestrutura e deve estar altamente disponível. No entanto, o fracasso vai e pode acontecer.

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

Gorjeta

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

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

Proteção contra falha de nó

Para evitar ser afetado devido a falhas de data center ou nó, considere o uso de um cluster Kubernetes que usa zonas de disponibilidade para obter alta disponibilidade no nível do nó.

As zonas de disponibilidade permitem agendar o pod do gateway auto-hospedado em nós espalhados pelas zonas usando:

Nota

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

Proteção contra interrupções do pod

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

Considere o uso de Orçamentos de interrupção de pods para impor um número mínimo de pods a serem disponibilizados a qualquer momento.

Proxy HTTP(S)

O gateway auto-hospedado fornece suporte para proxy HTTP(S) usando as variáveis tradicionais HTTP_PROXYe HTTPS_PROXYNO_PROXY de ambiente.

Uma vez 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 ao proxy de solicitação:

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

Nota

Devido a um problema conhecido com proxies HTTP que usam autenticação básica, não há suporte para o uso da validação de lista de revogação de certificados (CRL). Saiba mais em nossa referência de configurações do Self-Hosted Gateway 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 determinada funcionalidade não funcionará corretamente.

Logs e métricas locais

O gateway auto-hospedado envia telemetria para o Azure Monitor e o Azure Application Insights 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 o Azure Monitor Container Insights para monitorar seus contêineres ou configurar o monitoramento local para garantir a capacidade de observar o tráfego de API e evitar a perda de telemetria durante interrupções de conectividade do Azure.

Espaço de Nomes

Os namespaces do 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 políticas de controle de acesso.

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

Número de réplicas

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

Por padrão, um gateway auto-hospedado é implantado com uma estratégia de implantação RollingUpdate. Revise 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

Recomendamos reduzir os logs de contêiner a avisos (warn) para melhorar o desempenho. Saiba mais em nossa referência de configuração de gateway auto-hospedado.

Limitação de pedidos

A limitação de solicitações em um gateway auto-hospedado pode ser habilitada usando a política de limite de taxa de Gerenciamento de API ou de limite de taxa por chave. Configure contagens de limite de taxa para sincronizar entre instâncias de gateway entre 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 enviar pulsações para outras instâncias

Nota

As contagens de limite de taxa em um gateway auto-hospedado podem ser configuradas para sincronizar localmente (entre instâncias de gateway entre nós de cluster), por exemplo, por meio da implantação de gráfico de leme 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 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-root no Kubernetes, permitindo que os clientes executem o gateway com segurança.

Aqui está um exemplo do contexto de segurança para o 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 a execução do gateway auto-hospedado com sistema de arquivos somente leitura (readOnlyRootFilesystem: true).

Aviso

Ao usar certificados de autoridade de certificação locais, o gateway auto-hospedado deve ser executado com ID de usuário (UID) 1001 para gerenciar os certificados de autoridade de certificação, caso contrário, o gateway não será iniciado.

Próximos passos