Planeie uma implementação de Container Apps no Kubernetes com Azure Arc

Use este artigo antes de instalar a extensão Container Apps num cluster de produção. As Aplicações Container no Azure Arc utilizam 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, registo e atualizações afetam a disponibilidade das aplicações.

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

Âmbito do planeamento

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

Topologia suportada e matriz de versões

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

A matriz seguinte regista o suporte de distribuição atualmente publicado. Revalide-o em relação a extensões disponíveis para clusters do Kubernetes ativados pelo Azure Arc e limitações do Azure Container Apps no Azure Arc antes de cada instalação.

A extensão não é suportada em nós Windows nem em clusters Arm64. A estrutura de extensões do Arc requer pelo menos um nó linux/amd64 adequado, mas uma implementação de produção requer nós adequados em número suficiente para suportar a extensão, as cargas de trabalho, as atualizações e as falhas.

Apenas uma instalação KEDA suportada pode correr 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 removas a instalação KEDA existente nem apliques definições de extensão não documentadas porque outras tarefas podem depender disso.

Requisitos de capacidade

Capacidade planeada para:

• Os componentes fixos e por cada nó da extensão Container Apps indicados em Recursos criados pela extensão Container Apps.
• O número máximo esperado de réplicas de cada aplicação de contentor.
• Execuções simultâneas de tarefas e picos de novas tentativas.
• Sidecars Dapr e sidecars de aplicação.
• Cargas de trabalho do sistema do Kubernetes e outros utilizadores do cluster.
• Atualizações faseadas de nós e extensões.
• Pelo menos uma falha de nó numa implementação altamente disponível.

Definir o número máximo 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 a colocação de extensões, componentes ativados, número de nós, cargas de trabalho de daemons, instalação KEDA, Log Analytics, uso de DAPR e pedidos de carga de trabalho variam. Utilize os pedidos publicados dos componentes de extensão como base de referência e meça os recursos alocáveis do nó, 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, registe:

• CPU e memória alocáveis em nós elegíveis linux/amd64 .
• Número de nós e distribuição por domínio de falha.
• Pod e capacidade IP de serviço gratuita.
• Sistema atual, pedidos e limites dos inquilinos.
• Capacidade indisponível devido a contaminações, afinidade, quotas ou orçamentos de perturbaçã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 tarefas simultâneas, a capacidade de expansão, a reserva do sistema, a sobrecapacidade para atualização e a reserva para falhas. Garanta que as etiquetas dos nós, as manchas, as regras de afinidade e a fragmentação de recursos não tornem impossível calendarizar a capacidade nominalmente livre.

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

Requisitos de rede

As Aplicações Container no Azure Arc requerem vários caminhos de rede distintos:

Utilize os requisitos de rede do Kubernetes com Azure Arc ativado como a lista canónica de pontos finais. Não copie a lista de endpoints para um conjunto de regras de firewall sem selecionar a nuvem do Azure correta e as funcionalidades do Arc ativadas. Teste todos os nomes de domínio totalmente qualificados (FQDN) necessários da rede cluster. Os requisitos do Arc indicam que os endpoints HTTPS utilizam certificados oficialmente assinados e verificáveis. Confirmar o comportamento de proxy e inspeção TLS num cluster não produtivo; a interceção não suportada ou um certificado de substituição não confiável podem impedir a ligação de agentes e componentes de extensão.

A implementação selecionada LoadBalancer determina o conjunto de endereços, as sondas de saúde, o encaminhamento e a capacidade necessária. Se um balanceador de carga personalizado exigir um endereço reservado, reserve primeiro o endereço e passe-o pela definição de extensão loadBalancerIp durante a instalação. As portas e os intervalos de origem do health-probe são específicos da implementação; obtém-nos do balanceador de carga selecionado em vez de assumir os padrões do Balanceador de Carga do Azure.

O cluster Kubernetes subjacente, compatível com Arc, controla as restrições de rede para o ambiente conectado. Se uma dependência da aplicação usar um endpoint privado, verifique, a partir de um pod da aplicação, que o cluster consegue resolver o respetivo nome DNS e encaminhar o tráfego para o respetivo IP privado. As aplicações que necessitem de informação 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 de confiança.

Validar a rede

1. Implemente um serviço de teste Kubernetes LoadBalancer e confirme que recebe um endereço acessível a partir de todas as redes cliente pretendidas.
2. A partir de um nó elegível do cluster ou de um pod de diagnóstico, resolva e estabeleça ligação a cada ponto final necessário do Azure Arc e a cada dependência da carga de trabalho.
3. Confirme que o proxy permite o tráfego HTTPS e WebSocket necessário e não substitui os certificados por outros emitidos por uma entidade emissora não fidedigna.
4. Confirme que 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 previstas.
5. Após a instalação da extensão, confirme que o serviço de entrada recebe o IP planeado e está acessível antes de criar registos DNS de produção.

Requisitos de DNS

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

Para aplicações internas, use DNS de horizonte dividido quando os clientes internos e externos requerem respostas diferentes. Identificar a zona DNS autoritativa, o tempo de vida do registo (TTL) e os requisitos de recuperação. Determine se as aplicações utilizam o domínio gerado, domínios personalizados ou ambos, e planeie a emissão e renovação do certificado antes da implementação.

Validar o DNS e o acesso de entrada a partir 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 da aplicação. Remova cabeçalhos de autorização, cookies e strings de consulta sensíveis antes de partilhar resultados verbosos.

Identidade, segredos e registos

Identidades geridas não são suportadas para aplicações de contentores no Azure Arc. Extrair imagens do Azure Container Registry usando identidade gerida também não é suportado.

Para aceder aos recursos do Azure, utilize um registo de aplicação dedicado e um principal de serviço apenas quando o serviço alvo o suportar. Atribua apenas as funções necessárias do plano de dados com o âmbito mais restrito possí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 o suportarem, e planeie a expiração e rotação das credenciais. Não reutilize a identidade do cluster-conectado Arc nem a identidade de administrador do cluster para aceder à aplicação.

Para registos privados, utilize uma credencial associada ao registo com acesso apenas para extração, sempre que o registo o suporte. Evite credenciais de administrador do ACR para cargas de trabalho em produção. Armazene as credenciais do registo e da aplicação como segredos das Aplicações Container e referencia-as pelo nome a partir da configuração da aplicação.

Os segredos das Aplicações Container têm âmbito de aplicação, e alterar um segredo não atualiza automaticamente as revisões existentes. Trate tanto o acesso ao plano de controlo do Azure como o acesso privilegiado ao Kubernetes como limites de segurança. Restringa o acesso às extensões e namespaces de aplicações de acordo com os requisitos de segurança do Kubernetes para a implementação.

Use esta sequência de rotação:

1. Crie uma segunda credencial válida no fornecedor de identidade ou registo.
2. Atualize o segredo das Aplicações Container e implemente ou reinicie a revisão afetada conforme necessário.
3. Verifique a extração de imagens e a autenticação da aplicação com a nova credencial.
4. Revoga a credencial antiga.
5. Confirma que nenhuma revisão ou tarefa ativa ainda faz referência ao valor antigo.

Nunca guarde segredos no histórico de comandos, no controlo de código-fonte, em pacotes de diagnóstico, nas descrições dos pods ou nos registos de aplicações. Restrinja quem pode ler definições protegidas da extensão e segredos do Kubernetes.

Armazenamento

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

As limitações do Container Apps no Arc documentam atualmente o Ficheiros do Azure SMB e requerem o driver CSI SMB. Não assuma que um tipo de volume suportado pelas Container Apps alojadas no Azure é suportado no Arc. Utilize os comandos de instalação SMB indicados em Azure Container Apps on Azure Arc em vez de manter aqui outra cópia.

Trate as credenciais da conta de armazenamento utilizadas para uma montagem como informação confidencial. Identidades geridas não são suportadas para Aplicações Container no Arc. Teste as opções de montagem selecionadas, permissões de ficheiros, 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.

Planeie backups persistentes de dados, testes de restauração, retenção e recuperação de desastres. Teste como as revisões e as tarefas reportam falhas de montagem e inclua os eventos do pod e os registos dos controladores CSI no procedimento de diagnóstico. O Linux é o único sistema operativo de nó suportado para a extensão.

Observabilidade do Plano

A integração com Log Analytics é opcional. Se planeias usá-la, configura-a quando instalares a extensão porque não podes adicioná-la a essa instância mais tarde.

Quando configura o Log Analytics, pode encontrar registos de aplicações em ContainerAppConsoleLogs_CL. O tutorial Criar uma aplicação de contentor no Azure Arc demonstra TimeGenerated, ContainerAppName_s, e Log_s; inspecionar a tabela em tempo real antes de criar consultas ou alertas. Espere entre 10 a 15 minutos ao validar a ingestão inicial.

Planeie o acesso ao espaço de trabalho, retenção, alertas, exportação e custos de ingestão. Revise o registo da aplicação para credenciais, dados pessoais e URLs sensíveis antes de ativar a recolha.

Se não configurar o Log Analytics, ou durante um incidente de ingestão, use os registos 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

Os componentes do sistema escrevem registos na saída padrão. Por defeito, a telemetria dos componentes do sistema é enviada para a Microsoft enquanto os registos da aplicação não são enviados a menos que configure o Log Analytics. Definir logProcessor.enabled=false desativa o processamento de registos e o encaminhamento para o espaço de trabalho e pode aumentar a informação de diagnóstico que a equipa de suporte lhe pede que recolha manualmente.

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

Atualização, backup e recuperação

Selecione e documente uma cadência de lançamentos das extensões e uma política de atualização. O tutorial de configuração de Aplicações do Container utiliza o stable sistema de lançamentos com atualizações automáticas de versões menores. As extensões do cluster Azure Arc podem seguir um ciclo de lançamento com atualizações automáticas ou ser fixadas e atualizadas manualmente. Consulte as notas de lançamento da extensão Container Apps antes de mudar de versão, e forneça capacidade extra, versões Kubernetes compatíveis, 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 aprovisionamento 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. Reveja as notas de lançamento e a configuração atual, incluindo o canal de lançamento, a definição de atualização automática, a instalação do KEDA, os namespaces, o Log Analytics e loadBalancerIp.
4. Verifique a capacidade disponível para uma substituição faseada e confirme que os orçamentos de indisponibilidade permitem avançar.
5. Verifique a conectividade do registo 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. Executar testes de aplicação, entrada, escalação, trabalho, armazenamento e registo de fumo antes e depois da alteração.

Não trate o backup do namespace Kubernetes como um backup dos recursos do Azure. O cluster conectado, extensão, localização personalizada, ambiente conectado, aplicações container e jobs estão representados no Azure Resource Manager e têm dependências dos recursos dentro do cluster. Faz backup da configuração declarativa da aplicação separadamente. Não restaure manualmente implementações geridas 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.

Uma reversão ou reposição para uma versão anterior de uma extensão não é um mecanismo geral de recuperação documentado para o Container Apps no Arc. Não altere o canal de lançamento, não fixe uma versão anterior nem modifique cargas de trabalho geridas por extensões como resposta a um incidente sem confirmar junto do suporte da Microsoft que existe um procedimento suportado.

Desenvolver e testar um runbook de recuperação que tenha em conta a infraestrutura Kubernetes, rede, DNS, balanceamento de carga, armazenamento, agentes Azure Arc, a extensão Container Apps, localização personalizada, ambiente conectado, configuração da aplicação, credenciais e dados persistentes da aplicação. Validar entradas, revisões, escalabilidade, trabalhos, armazenamento e registos após a recuperação. Utilize procedimentos de recuperação suportados pela topologia Kubernetes e pelos produtos de backup na implementação.

Planeie a desconexão do Azure. Os agentes arc requerem conectividade para descobrir alterações nas extensões e propagar o estado desejado. As definições protegidas para um recurso de extensão recém-criado são mantidas até 48 horas; se o cluster permanecer desligado durante esse período, a extensão pode passar de Pending para Failed. Testar o comportamento da carga de trabalho durante a perda da conectividade 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 Azure Container Apps
• Criar um aplicativo de contêiner no Azure Arc
• Resolver problemas de Azure Container Apps no Azure Arc-enabled Kubernetes
• Requisitos de rede do Kubernetes habilitado para Azure Arc
• Localizações personalizadas no Kubernetes com Azure Arc
• Extensões de cluster no Kubernetes compatível com o Azure Arc