Planeje uma implantação do Container Apps no Kubernetes habilitado para o Azure Arc

Use este artigo antes de instalar a extensão Container Apps em um cluster de produção. Os Apps de Contêineres no Azure Arc utilizam os serviços de capacidade e plataforma fornecidos pelo seu cluster Kubernetes. Decisões sobre nós, balanceamento de carga, DNS, conectividade de saída, armazenamento, identidade, registro e atualizações afetam a disponibilidade das aplicações.

Use as seções deste artigo para identificar requisitos de implantação e validar pré-requisitos antes da instalação.

Escopo do planejamento

O Container Apps no Azure Arc abrange recursos do Azure, um cluster Kubernetes existente e aplicações implantadas. Planeje para as seguintes áreas:

Topologia suportada e matriz de versões

Use a última versão de patch do Kubernetes suportada por fornecedores, que também suporta o Kubernetes com Azure Arc. A documentação do Container Apps não publica uma faixa separada de versões do Kubernetes para cada distribuição. Valide a distribuição exata e a versão do Kubernetes com suporte da Microsoft antes de uma instalação ou atualização em produção.

A matriz a seguir registra o suporte de distribuição atualmente publicado. Valide novamente em relação a Extensões disponíveis para clusters do Kubernetes habilitados pelo Azure Arc e Limitações do Aplicativos de Contêiner do Azure no Azure Arc antes de cada instalação.

A extensão não é suportada em nós do Windows ou clusters Arm64. O framework de extensão do Arc requer pelo menos um nó linux/amd64 adequado, mas uma implantação de produção requer nós adequados em quantidade suficiente para a extensão, as cargas de trabalho, as atualizações e as falhas.

Apenas uma instalação KEDA suportada pode rodar no cluster. Determine se o KEDA será instalado pela extensão Container Apps ou se já existe no cluster. Se o KEDA já existir, pare e confirme a configuração de coexistência suportada antes de continuar. Não remova a instalação existente do KEDA nem aplique configurações de extensão não documentadas porque outras cargas de trabalho podem depender disso.

Requisitos de capacidade

Capacidade planejada para:

• Os componentes fixos e por nó da extensão de Aplicativos de Contêiner listados em Recursos criados pela extensão de Aplicativos de Contêiner.
• O número máximo esperado de réplicas de cada aplicativo de contêiner.
• Execuções simultâneas de tarefas e picos de tentativas de repetição.
• Sidecars Dapr e sidecars de aplicativo.
• Cargas de trabalho do sistema do Kubernetes e outros locatários do cluster.
• Atualizações contínuas de nó e extensão.
• Falha de pelo menos um nó em uma implantação de alta disponibilidade.

Definir a contagem máxima de réplicas de uma aplicação não reserva a capacidade do cluster.

Capacidade mínima de instalação

Não existe um mínimo universal de produção porque posicionamento de extensões, componentes habilitados, número de nós, cargas de trabalho de daemons, instalação KEDA, Log Analytics, uso de Dapr e solicitações de carga de trabalho variam. Use as solicitações publicadas de componentes de extensão como base e meça os recursos alocáveis do nó, e não os totais. O tamanho do cluster de avaliação não é uma recomendação de dimensionamento de produção.

Antes da instalação, registre:

• CPU e memória alocáveis em nós linux/amd64 elegíveis.
• Contagem de nós e posicionamento do domínio de falha.
• Pod e capacidade IP de serviço gratuita.
• Sistema atual, pedidos e limites dos inquilinos.
• Capacidade indisponível devido a manchas, afinidades, cotas ou orçamentos de interrupção.

Estimar a capacidade de carga de trabalho

Para cada aplicação, calcule:

peak capacity = maximum replicas x (application requests + sidecar requests)

Adicione a capacidade máxima de trabalhos simultâneos, a capacidade de expansão, a reserva do sistema, a capacidade extra para atualização e a reserva para falhas. Garanta que rótulos de nós, taints, regras de afinidade e a fragmentação de recursos não façam com que a capacidade nominalmente livre não possa ser escalonada.

Valide o plano agendando cargas de trabalho representativas e simulando a drenagem de um nó. Confirme que os pods de extensão e as réplicas de carga de trabalho necessárias permanecem prontos.

Requisitos de rede

Aplicativos de Contêineres no Azure Arc requerem vários caminhos de rede distintos:

Use os requisitos de rede do Kubernetes habilitados pelo Azure Arc como a lista canônica de pontos de extremidade. Não copie a lista de endpoints para um conjunto de regras de firewall sem selecionar a nuvem Azure correta e os recursos do Arc ativados. Teste todos os nomes de domínio totalmente qualificados (FQDN) necessários da rede do cluster. Os requisitos do Arc afirmam que os endpoints HTTPS utilizam certificados oficialmente assinados e verificáveis. Confirme o comportamento do proxy e da inspeção de TLS em um cluster de não produção; uma interceptação não suportada ou um certificado substituto não confiável podem impedir que agentes e componentes de extensão se conectem.

A implementação selecionada LoadBalancer determina o pool de endereços, sondas de saúde, roteamento e capacidade necessária. Se um balanceador de carga personalizado exigir um endereço reservado, reserve o endereço primeiro e passe pela configuração de extensão loadBalancerIp durante a instalação. As portas de sondagem de integridade e os intervalos de origem são específicos da implementação; obtenha essas informações com o balanceador de carga selecionado em vez de presumir os valores padrão do Azure Load Balancer.

O cluster Kubernetes subjacente habilitado para Arc controla as restrições de rede para o ambiente conectado. Se uma dependência de um aplicativo usa um endpoint privado, verifique, a partir de um pod do aplicativo, se o cluster consegue resolver seu nome DNS e encaminhar para seu IP privado. Aplicações que precisam de informações de IP do cliente devem validar os cabeçalhos de encaminhamento produzidos pelo balanceador de carga e cadeia de proxy selecionados e definir quais proxies são confiáveis.

Validar a rede

1. Implante um serviço de teste Kubernetes LoadBalancer e confirme que ele recebe um endereço acessível de todas as redes clientes pretendidas.
2. A partir de um nó de cluster ou pod de diagnóstico elegível, resolva e conecte-se a todos os endpoints e dependências de carga de trabalho do Azure Arc necessários.
3. Confirme que o proxy permite o tráfego necessário de HTTPS e WebSocket e não substitui certificados por uma autoridade emissora não confiável.
4. Confirme se o DNS do cluster, o tráfego entre pods, os serviços, os webhooks de admissão e as sondas de integridade do balanceador de carga funcionam com as políticas de rede desejadas.
5. Após a instalação da extensão, confirme que o serviço de entrada recebe o IP planejado e está acessível antes de criar registros DNS de produção.

Requisitos de DNS

Após a instalação da extensão, implante uma aplicação de teste e recupere sua FQDN gerada. Verifique se o FQDN se resolve e alcança a entrada de extensão de todas as redes clientes pretendidas. O nome ambiente conectado faz parte do domínio de aplicação gerado, então escolha-o deliberadamente.

Para aplicações internas, use DNS de horizonte dividido quando clientes internos e externos exigem respostas diferentes. Identifique a zona DNS autoritativa, registre o tempo de vida e os requisitos de recuperação. Determine se as aplicações utilizam o domínio gerado, domínios personalizados ou ambos, e planeje a emissão e renovação do certificado antes da implantação.

Valide o DNS e a entrada de cada rede de cliente prevista:

nslookup <APPLICATION_FQDN>
curl --verbose https://<APPLICATION_FQDN>

O FQDN da aplicação deve resolver para o IP de ingresso e retornar a resposta esperada. Remova cabeçalhos de autorização, cookies e parâmetros de consulta sensíveis antes de compartilhar a saída verbosa.

Identidade, segredos e registros

Identidades gerenciadas não são suportadas para apps de contêineres no Azure Arc. Puxar imagens do Registro de Contêiner do Azure usando identidade gerenciada também não é suportado.

Para acesso aos recursos do Azure, use um registro de aplicação dedicado e um principal de serviço apenas quando o serviço alvo o suportar. Atribua apenas as funções de plano de dados necessárias no escopo mais restrito viável. Mantenha o ID do inquilino e o ID do cliente separados da credencial, use um certificado quando a aplicação e o serviço alvo suportarem isso, e planeje a expiração e rotação das credenciais. Não reutilize a identidade do cluster conectado Arc ou a identidade de administrador do cluster para acesso à aplicação.

Para registros privados, use uma credencial com escopo de registro e acesso apenas de extração, onde o registro a suporta. Evite credenciais de administrador do ACR para cargas de trabalho em produção. Armazene as credenciais do registro e do aplicativo como segredos do Container Apps e faça referência a elas pelo nome na configuração do aplicativo.

Os segredos do Container Apps têm escopo no nível do aplicativo, e alterar um segredo não atualiza automaticamente as revisões existentes. Trate tanto o acesso ao plano de controle do Azure quanto o acesso privilegiado ao Kubernetes como limites de segurança. Restringa o acesso aos namespaces de extensão e aplicações de acordo com os requisitos de segurança do Kubernetes para a implantação.

Use esta sequência de rotação:

1. Crie uma segunda credencial válida no provedor de identidade ou no registro.
2. Atualize o segredo do Container Apps e implante ou reinicie a revisão afetada conforme necessário.
3. Verifique o download de imagens e a autenticação da aplicação com a nova credencial.
4. Revogar a credencial antiga.
5. Confirme que nenhuma revisão ou tarefa ativa ainda faz referência ao valor antigo.

Nunca armazene valores secretos no histórico de comandos, no controle de código-fonte, em bundles de diagnóstico, em descrições de pods ou nos logs do aplicativo. Limite quem pode ler configurações protegidas por extensões e segredos do Kubernetes.

Armazenamento

Planeje o armazenamento de acordo com a persistência exigida pela carga de trabalho:

As limitações do Container Apps no Arc atualmente documentam o Arquivos do Azure SMB e exigem o driver CSI do SMB. Não suponha que um tipo de volume com suporte no Aplicativos de Contêiner do Azure também tenha suporte no Arc. Use os comandos de instalação do SMB indicados em Aplicativos de Contêiner do Azure no Azure Arc, em vez de manter outra cópia aqui.

Considere as credenciais da conta de armazenamento usadas em uma montagem como segredos. Identidades gerenciadas não são suportadas para Apps de Contêineres no Arc. Teste as opções selecionadas de montagem, permissões de arquivo, acesso concorrente, comportamento de falha e rotação de credenciais com as versões exatas do driver CSI e do serviço de armazenamento usadas em produção.

Planeje backup persistente de dados, testes de restauração, retenção e recuperação em caso de desastres. Teste como revisões e tarefas relatam falhas de montagem e inclua eventos do pod e logs do driver CSI no procedimento de diagnóstico. Linux é o único sistema operacional de nós suportado para a extensão.

Observabilidade do Plano

A integração com Log Analytics é opcional. Se você pretende usá-la, configure-a quando instalar a extensão porque não poderá adicioná-la a essa instância depois.

Quando você configura o Log Analytics, pode encontrar logs do aplicativo em ContainerAppConsoleLogs_CL. O tutorial Criar um aplicativo de contêiner no Azure Arc demonstra TimeGenerated, ContainerAppName_s, e Log_s; inspecione a tabela ativa antes de construir consultas ou alertas. Espere de 10 a 15 minutos ao validar a ingestão inicial.

Planeje o acesso ao espaço de trabalho, retenção, alertas, exportação e custos de ingestão. Revise o registro de aplicações para credenciais, dados pessoais e URLs sensíveis antes de ativar a coleta.

Se você não configurar o Log Analytics, ou durante um incidente de ingestão, use os logs do Kubernetes:

kubectl get pods -n <APPS_NAMESPACE> -o wide
kubectl logs -n <APPS_NAMESPACE> <POD_NAME> --all-containers=true --tail=200
kubectl get events -n <APPS_NAMESPACE> --sort-by=.lastTimestamp

Componentes do sistema gravam logs para saída padrão. Por padrão, a telemetria dos componentes do sistema é enviada para a Microsoft enquanto os logs de aplicação não são enviados, a menos que você configure o Log Analytics. Definir logProcessor.enabled=false desativa o processamento e o encaminhamento dos logs para o espaço de trabalho e pode aumentar as informações de diagnóstico que o suporte solicita que você colete manualmente.

Antes da produção, teste uma mensagem única de log de aplicação de ponta a ponta, crie alertas para saúde de extensões e falhas de aplicação, e confirme se tanto os diagnósticos do Azure quanto do Kubernetes estão acessíveis.

Atualização, backup e recuperação

Selecione e documente uma cadência de lançamentos de extensões e uma política de atualização. O tutorial de configuração de Aplicativos de Contêiner usa o ciclo de lançamentos stable com atualizações automáticas de versões secundárias. Extensões de cluster do Azure Arc podem seguir um sistema de lançamento com atualizações automáticas ou ser fixadas e atualizadas manualmente. Revise as notas de lançamento da extensão Container Apps antes de mudar de versão, e forneça capacidade extra, versões compatíveis do Kubernetes, janelas de manutenção e validação de aplicações.

Antes de uma extensão ou atualização do Kubernetes:

1. Confirme que os estados de provisionamento do cluster conectado e da extensão são Succeeded.
2. Confirme que a combinação de Kubernetes e extensão de destino é suportada.
3. Analise as notas de lançamento e a configuração atual, incluindo o canal de lançamento, a configuração de atualização automática, a instalação do KEDA, namespaces, Log Analytics e loadBalancerIp.
4. Verifique a capacidade disponível para substituição contínua e confirme que os orçamentos de interrupção permitem o progresso.
5. Verifique a conectividade do registro de imagens e as políticas de admissão para as imagens-alvo.
6. Faça backup da configuração da fonte da aplicação e de todos os dados persistentes da aplicação.
7. Execute testes de fumaça de aplicação, entrada, escalonamento, trabalho, armazenamento e registro antes e depois da mudança.

Não trate o backup de namespace do Kubernetes como um backup dos recursos do Azure. O cluster conectado, extensão, localização personalizada, ambiente conectado, aplicativos de contêineres e jobs estão representados no Azure Resource Manager e têm dependências dos recursos dentro do cluster. Faça backup da configuração declarativa da aplicação separadamente. Não restaure manualmente implantações gerenciadas por extensões, recursos personalizados ou segredos sobre uma extensão recém-instalada, a menos que o suporte da Microsoft forneça esse procedimento de recuperação.

Um downgrade ou rollback de extensões não é um mecanismo geral de recuperação documentado para Apps de Contêineres no Arc. Não mude o trem de releases, fixe uma versão mais antiga ou modifique cargas de trabalho gerenciadas por extensões como resposta a incidentes sem confirmar um caminho suportado com o suporte da Microsoft.

Desenvolva e teste um runbook de recuperação que considere infraestrutura Kubernetes, rede, DNS, balanceamento de carga, armazenamento, agentes Azure Arc, extensão Container Apps, localização personalizada, ambiente conectado, configuração de aplicações, credenciais e dados persistentes da aplicação. Valide entrada, revisões, dimensionamento, trabalhos, armazenamento e logs após a recuperação. Use procedimentos de recuperação suportados pela topologia Kubernetes e pelos produtos de backup na implantação.

Planeje a desconexão do Azure. Agentes de arco requerem conectividade para descobrir mudanças de extensão e propagar o estado desejado. Configurações protegidas para um recurso de extensão recém-criado são mantidas por até 48 horas; se o cluster permanecer desconectado durante esse período, a extensão pode se mover de Pending para Failed. Teste o comportamento da carga de trabalho durante a perda da conectividade do Azure, em vez de assumir uma garantia de continuidade.

Conteúdo relacionado

• Aplicativos de Contêiner do Azure no Azure Arc
• Configurar um cluster Kubernetes habilitado para Azure Arc para executar Aplicativos de Contêiner do Azure
• Criar um aplicativo de contêiner no Azure Arc
• Solucionar problemas do Aplicativos de Contêiner do Azure no Kubernetes habilitado para Azure Arc
• Requisitos de rede do Kubernetes com suporte pelo Azure Arc
• Localizações personalizadas no Kubernetes habilitado para Azure Arc
• Extensões de cluster no Kubernetes habilitado pelo Azure Arc