Implantação e teste para cargas de trabalho críticas no Azure

A implantação e o teste do ambiente crítico da missão são uma parte crucial da arquitetura de referência geral. Os selos de aplicativo individuais são implantados usando a infraestrutura como código de um repositório de código-fonte. Atualizações para a infraestrutura e o aplicativo na parte superior devem ser implantados sem tempo de inatividade para o aplicativo. Um pipeline de integração contínua do DevOps é recomendado para recuperar o código-fonte do repositório e implantar os selos individuais no Azure.

Implantação e atualizações são o processo central na arquitetura. As atualizações relacionadas à infraestrutura e ao aplicativo devem ser implantadas em selos totalmente independentes. Somente os componentes de infraestrutura global na arquitetura são compartilhados entre os selos. Os selos existentes na infraestrutura não são tocados. As atualizações de infraestrutura só serão implantadas nesses novos selos. Da mesma forma, a nova versão do aplicativo só será implantada nesses novos selos.

Os novos selos são adicionados ao Azure Front Door. O tráfego é movido gradualmente para os novos selos. Quando é determinado que o tráfego é servido dos novos selos sem problema, os selos anteriores são excluídos.

Os testes de penetração, caos e estresse são recomendados para o ambiente implantado. O teste proativo da infraestrutura descobre pontos fracos e como o aplicativo implantado se comportará se houver uma falha.

Implantação

A implantação da infraestrutura na arquitetura de referência depende dos seguintes processos e componentes:

• DevOps – o código-fonte do GitHub e os pipelines para a infraestrutura.

• Atualizações de tempo de inatividade zero – Atualizações e atualizações são implantadas no ambiente sem tempo de inatividade para o aplicativo implantado.

• Ambientes – ambientes de curta duração e permanentes usados para a arquitetura.

• Recursos compartilhados e dedicados – recursos do Azure dedicados e compartilhados com os selos e a infraestrutura geral.

Para obter mais informações, consulte Implantação e teste para cargas de trabalho críticas no Azure: considerações de design

Implantação: DevOps

Os componentes de DevOps fornecem o repositório de código-fonte e pipelines de CI/CD para implantação da infraestrutura e das atualizações. O GitHub e o Azure Pipelines foram escolhidos como componentes.

• GitHub – contém os repositórios de código-fonte para o aplicativo e a infraestrutura.

• Azure Pipelines – os pipelines usados pela arquitetura para todas as tarefas de build, teste e lançamento.

Um componente extra no design usado para a implantação são os agentes de build. Os agentes de build hospedados pela Microsoft são usados como parte do Azure Pipelines para implantar a infraestrutura e as atualizações. O uso de agentes de build hospedados pela Microsoft remove a carga de gerenciamento para os desenvolvedores manterem e atualizarem o agente de build.

Para obter mais informações sobre o Azure Pipelines, consulte O que é Azure DevOps Services?.

Para obter mais informações, consulte Implantação e teste para cargas de trabalho críticas no Azure: implantações de infraestrutura como código

Implantação: zero atualizações de tempo de inatividade

A estratégia de atualização de tempo de inatividade zero na arquitetura de referência é central para o aplicativo de missão crítica geral. A metodologia de substituição em vez da atualização dos selos garante uma nova instalação do aplicativo em um selo de infraestrutura. A arquitetura de referência utiliza uma abordagem azul/verde e permite ambientes de teste e desenvolvimento separados.

Há dois componentes main da arquitetura de referência:

• Infraestrutura – serviços e recursos do Azure. Implantado com o Terraform e sua configuração associada.

• Aplicativo – o serviço ou aplicativo hospedado que atende aos usuários. Com base em contêineres do Docker e artefatos criados por npm em HTML e JavaScript para a interface do usuário do SPA (aplicativo de página única).

Em muitos sistemas, há uma suposição de que as atualizações de aplicativo serão mais frequentes do que as atualizações de infraestrutura. Como resultado, diferentes procedimentos de atualização são desenvolvidos para cada um. Com uma infraestrutura de nuvem pública, as alterações podem ocorrer em um ritmo mais rápido. Um processo de implantação para atualizações de aplicativo e atualizações de infraestrutura foi escolhido. Uma abordagem garante que as atualizações de infraestrutura e de aplicativo estejam sempre em sincronia. Essa abordagem permite:

• Um processo consistente – menos chances de erros se as atualizações de infraestrutura e de aplicativo forem combinadas em uma versão, intencionalmente ou não.

• Habilita a implantação Azul/Verde – cada atualização é implantada usando uma migração gradual de tráfego para a nova versão.

• Implantação e depuração mais fáceis do aplicativo – o carimbo inteiro nunca hospedará várias versões do aplicativo lado a lado.

• Reversão simples – o tráfego pode ser alternado de volta para os carimbos que executam a versão anterior se forem encontrados erros ou problemas.

• Eliminação de alterações manuais e descompasso de configuração – cada ambiente é uma nova implantação.

Para obter mais informações, consulte Implantação e teste para cargas de trabalho críticas no Azure: implantações efêmeras azuis/verdes

Estratégia de ramificação

A base da estratégia de atualização é o uso de branches no repositório Git. A arquitetura de referência usa três tipos de branches:

Branch	Descrição
feature/* e fix/*	Os pontos de entrada para qualquer alteração. Esses branches são criados por desenvolvedores e devem receber um nome descritivo, como feature/catalog-update ou fix/worker-timeout-bug. Quando as alterações estiverem prontas para serem mescladas, uma PR (solicitação de pull) em relação ao main branch será criada. Cada PR deve ser aprovada por pelo menos um revisor. Com exceções limitadas, cada alteração proposta em uma PR deve ser executada por meio do pipeline de validação de ponta a ponta (E2E). O pipeline do E2E deve ser usado pelos desenvolvedores para testar e depurar alterações em um ambiente completo.
main	O branch móvel e estável continuamente em andamento. Usado principalmente para testes de integração. As alterações feitas main em são feitas somente por meio de solicitações de pull. Uma política de branch proíbe gravações diretas. As versões noturnas no ambiente permanente integration (int) são executadas automaticamente do main branch. O main branch é considerado estável. Deve ser seguro assumir que, a qualquer momento, uma versão pode ser criada com base nela.
release/*	Os branches de lançamento são criados somente a partir do main branch. Os branches seguem o formato release/2021.7.X. As políticas de branch são usadas para que somente os administradores de repositório possam criar release/* branches. Somente esses branches são usados para implantar no prod ambiente.

Para obter mais informações, consulte Implantação e teste para cargas de trabalho críticas no Azure: estratégia de ramificação

Hotfixes

Quando um hotfix é necessário urgentemente devido a um bug ou outro problema e não pode passar pelo processo de versão regular, um caminho de hotfix está disponível. Atualizações de segurança críticas e correções para a experiência do usuário que não foram descobertas durante o teste inicial são consideradas exemplos válidos de hotfixes.

O hotfix deve ser criado em um novo fix branch e, em seguida, mesclado em main usando uma PR regular. Em vez de criar um novo branch de lançamento, o hotfix é "escolhido por cereja" em um branch de lançamento existente. Esse branch já está implantado no prod ambiente. O pipeline de CI/CD que originalmente implantou o branch de lançamento com todos os testes é executado novamente e agora implantará o hotfix como parte do pipeline.

Para evitar problemas importantes, é importante que o hotfix contenha alguns commits isolados que podem ser facilmente escolhidos e integrados ao branch de lançamento. Se commits isolados não puderem ser escolhidos para integração ao branch de lançamento, é uma indicação de que a alteração não se qualifica como um hotfix. A alteração deve ser implantada como uma nova versão completa e potencialmente combinada com uma reversão para uma versão estável anterior até que a nova versão possa ser implantada.

Implantação: ambientes

A arquitetura de referência usa dois tipos de ambientes para a infraestrutura:

• Curta duração – o pipeline de validação do E2E é usado para implantar ambientes de curta duração. Ambientes de curta duração são usados para ambientes de validação ou depuração puros para desenvolvedores. Os ambientes de validação podem ser criados a feature/* partir do branch, submetidos a testes e, em seguida, destruídos se todos os testes foram bem-sucedidos. Os ambientes de depuração são implantados da mesma forma que a validação, mas não são destruídos imediatamente. Esses ambientes não devem existir por mais de alguns dias e devem ser excluídos quando a PR correspondente do branch de recurso for mesclada.

• Permanente – nos ambientes permanentes há integration (int) versões e production (prod) . Esses ambientes vivem continuamente e não são destruídos. Os ambientes usam nomes de domínio fixos como int.mission-critical.app. Em uma implementação real da arquitetura de referência, um staging ambiente (pré-prod) deve ser adicionado. O staging ambiente é usado para implantar e validar release branches com o mesmo processo prod de atualização que (implantação Azul/Verde).

  • Integração (int) – a int versão é implantada todos os dias do main branch com o mesmo processo que prod. A substituição do tráfego é mais rápida do que a unidade de versão anterior. Em vez de alternar gradualmente o tráfego em vários dias, como em prod, o processo para int é concluído dentro de alguns minutos ou horas. Essa substituição mais rápida garante que o ambiente atualizado esteja pronto até a manhã seguinte. Os selos antigos serão excluídos automaticamente se todos os testes no pipeline forem bem-sucedidos.

  • Produção (prod) – a prod versão só é implantada de release/* branches. A substituição de tráfego usa etapas mais granulares. Um portão de aprovação manual está entre cada etapa. Cada versão cria novos selos regionais e implanta a nova versão do aplicativo nos selos. Os selos existentes não são tocados no processo. A consideração mais importante para prod é que ela deve ser "sempre ativada". Nenhum tempo de inatividade planejado ou não planejado deve ocorrer. A única exceção são as alterações fundamentais na camada de banco de dados. Uma janela de manutenção planejada pode ser necessária.

Implantação: recursos compartilhados e dedicados

Os ambientes permanentes (int e prod) dentro da arquitetura de referência têm diferentes tipos de recursos, dependendo se forem compartilhados com toda a infraestrutura ou dedicados a um selo individual. Os recursos podem ser dedicados a uma versão específica e existir somente até que a próxima unidade de lançamento seja assumida.

Unidades de lançamento

Uma unidade de lançamento é vários selos regionais por versão de lançamento específica. Os selos contêm todos os recursos que não são compartilhados com os outros selos. Esses recursos são redes virtuais, cluster Serviço de Kubernetes do Azure, Hubs de Eventos e Key Vault do Azure. O Azure Cosmos DB e o ACR são configurados com fontes de dados do Terraform.

Recursos compartilhados globalmente

Todos os recursos compartilhados entre unidades de versão são definidos em um modelo independente do Terraform. Esses recursos são o Front Door, o Azure Cosmos DB, o ACR (Registro de Contêiner) e os workspaces do Log Analytics e outros recursos relacionados ao monitoramento. Esses recursos são implantados antes que o primeiro selo regional de uma unidade de lançamento seja implantado. Os recursos são referenciados nos modelos do Terraform para os selos.

Front Door

Embora o Front Door seja um recurso compartilhado globalmente entre selos, sua configuração é ligeiramente diferente dos outros recursos globais. O Front Door deve ser reconfigurado após a implantação de um novo selo. O Front Door deve ser reconfigurado para alternar gradualmente o tráfego para os novos selos.

A configuração de back-end do Front Door não pode ser definida diretamente no modelo do Terraform. A configuração é inserida com variáveis do Terraform. Os valores de variável são construídos antes da implantação do Terraform ser iniciada.

A configuração de componente individual para a implantação do Front Door é definida como:

• Front-end – a afinidade de sessão é configurada para garantir que os usuários não alternem entre diferentes versões de interface do usuário durante uma única sessão.

• Origens – o Front Door é configurado com dois tipos de grupos de origem:

  1. Um grupo de origem para armazenamento estático que atende à interface do usuário. O grupo contém as contas de armazenamento do site de todas as unidades de lançamento ativas no momento. Diferentes pesos podem ser atribuídos às origens de diferentes unidades de versão para mover gradualmente o tráfego para uma unidade mais recente. Cada origem de uma unidade de liberação deve ter o mesmo peso atribuído.

  2. Um grupo de origem para a API, que está hospedada no AKS. Se houver unidades de lançamento com diferentes versões de API, um grupo de origem da API existirá para cada unidade de versão. Se todas as unidades de versão oferecerem a mesma API compatível, todas as origens serão adicionadas ao mesmo grupo e receberão pesos diferentes.

• Regras de roteamento – há dois tipos de regras de roteamento:

  1. Uma regra de roteamento para a interface do usuário vinculada ao grupo de origem do armazenamento da interface do usuário.

  2. Uma regra de roteamento para cada API atualmente compatível com as origens. Por exemplo: /api/1.0/* e /api/2.0/*.

  Se uma versão introduzir uma nova versão das APIs de back-end, as alterações refletirão na interface do usuário implantada como parte da versão. Uma versão específica da interface do usuário sempre chamará uma versão específica da URL da API. Os usuários atendidos por uma versão da interface do usuário usarão automaticamente a respectiva API de back-end. Regras de roteamento específicas são necessárias para instâncias diferentes da versão da API. Essas regras estão vinculadas aos grupos de origem correspondentes. Se uma nova API não tiver sido introduzida, todas as regras de roteamento relacionadas à API serão vinculadas ao grupo de origem única. Nesse caso, não importa se um usuário recebe a interface do usuário de uma versão diferente da API.

Implantação: processo de implantação

Uma implantação azul/verde é a meta do processo de implantação. Uma nova versão de um release/* branch é implantada no prod ambiente. O tráfego do usuário é gradualmente deslocado para os selos da nova versão.

Como uma primeira etapa no processo de implantação de uma nova versão, a infraestrutura da nova unidade de lançamento é implantada com o Terraform. A execução do pipeline de implantação de infraestrutura implanta a nova infraestrutura de um branch de lançamento selecionado. Em paralelo ao provisionamento de infraestrutura, as imagens de contêiner são criadas ou importadas e enviadas por push para o ACR (Registro de Contêiner Compartilhado Global). Quando os processos anteriores são concluídos, o aplicativo é implantado nos selos. Do ponto de vista da implementação, é um pipeline com vários estágios dependentes. O mesmo pipeline pode ser executado novamente para implantações de hotfix.

Depois que a nova unidade de lançamento é implantada e validada, ela é adicionada ao Front Door para receber o tráfego do usuário.

Um comutador/parâmetro que distingue entre versões que fazem e não introduzem uma nova versão da API deve ser planejado. Com base em se a versão introduzir uma nova versão da API, um novo grupo de origem com os back-ends da API deverá ser criado. Como alternativa, novos back-ends de API podem ser adicionados a um grupo de origem existente. Novas contas de armazenamento de interface do usuário são adicionadas ao grupo de origem existente correspondente. Os pesos para novas origens devem ser definidos de acordo com a divisão de tráfego desejada. Uma nova regra de roteamento, conforme descrito acima, deve ser criada que corresponda ao grupo de origem apropriado.

Como parte da adição da nova unidade de versão, os pesos das novas origens devem ser definidos como o tráfego mínimo de usuário desejado. Se nenhum problema for detectado, a quantidade de tráfego do usuário deverá ser aumentada para o novo grupo de origem durante um período de tempo. Para ajustar os parâmetros de peso, as mesmas etapas de implantação devem ser executadas novamente com os valores desejados.

Remoção da unidade de versão

Como parte do pipeline de implantação de uma unidade de lançamento, há um estágio de destruição que remove todos os selos depois que uma unidade de lançamento não é mais necessária. Todo o tráfego é movido para uma nova versão de versão. Esse estágio inclui a remoção de referências de unidade de lançamento do Front Door. Essa remoção é essencial para habilitar o lançamento de uma nova versão em uma data posterior. O Front Door deve apontar para uma única unidade de lançamento para estar preparado para a próxima versão no futuro.

Checklists

Como parte da cadência de versão, uma lista de verificação pré e pós-lançamento deve ser usada. O exemplo a seguir é de itens que devem estar em qualquer lista de verificação no mínimo.

• Lista de verificação de pré-lançamento – antes de iniciar uma versão, marcar o seguinte:

  • Verifique se o estado mais recente do main branch foi implantado e testado com êxito no int ambiente.

  • Atualize o arquivo de log de alterações por meio de uma PR em relação ao main branch.

  • Crie um release/ branch do main branch.

• Lista de verificação pós-lançamento - Antes que os selos antigos sejam destruídos e suas referências sejam removidas do Front Door, marcar que:

  • Os clusters não estão mais recebendo tráfego de entrada.

  • Os Hubs de Eventos e outras filas de mensagens não contêm mensagens não processadas.

Implantação: limitações e riscos da estratégia de atualização

A estratégia de atualização descrita nesta arquitetura de referência tem algumas limitações e riscos que devem ser mencionados:

• Custo mais alto – ao liberar atualizações, muitos dos componentes de infraestrutura ficam ativos duas vezes durante o período de lançamento.

• Complexidade do Front Door – O processo de atualização no Front Door é complexo de implementar e manter. A capacidade de executar implantações azuis/verdes eficazes com zero tempo de inatividade depende de ele funcionar corretamente.

• Pequenas alterações demoradas – o processo de atualização resulta em um processo de lançamento mais longo para pequenas alterações. Essa limitação pode ser parcialmente atenuada com o processo de hotfix descrito na seção anterior.

Implantação: considerações de compatibilidade de encaminhamento de dados de aplicativo

A estratégia de atualização pode dar suporte a várias versões de uma API e componentes de trabalho em execução simultaneamente. Como o Azure Cosmos DB é compartilhado entre duas ou mais versões, há a possibilidade de que os elementos de dados alterados por uma versão nem sempre correspondam à versão da API ou aos trabalhadores que a consomem. As camadas de API e os trabalhos devem implementar o design de compatibilidade de encaminhamento. Versões anteriores da API ou dos componentes de trabalho processam dados que foram inseridos por uma versão posterior da API ou do componente de trabalho. Ele ignora partes que não entende.

Teste

A arquitetura de referência contém diferentes testes usados em diferentes estágios na implementação do teste.

Esses testes incluem:

• Testes de unidade – esses testes validam que a lógica de negócios do aplicativo funciona conforme o esperado. A arquitetura de referência contém um conjunto de exemplos de testes de unidade executados automaticamente antes de cada build de contêiner pelo Azure Pipelines. Se algum teste falhar, o pipeline será interrompido. A compilação e a implantação não continuarão.

• Testes de carga – esses testes ajudam a avaliar a capacidade, a escalabilidade e os possíveis gargalos para uma determinada carga de trabalho ou pilha. A implementação de referência contém um gerador de carga do usuário para criar padrões de carga sintéticos que podem ser usados para simular o tráfego real. O gerador de carga também pode ser usado independentemente da implementação de referência.

• Smoke tests – esses testes identificam se a infraestrutura e a carga de trabalho estão disponíveis e atuam conforme o esperado. Os smoke tests são executados como parte de cada implantação.

• Testes de interface do usuário – esses testes validam que a interface do usuário foi implantada e funciona conforme o esperado. A implementação atual captura apenas capturas de tela de várias páginas após a implantação sem nenhum teste real.

• Testes de injeção de falha – esses testes podem ser automatizados ou executados manualmente. O teste automatizado na arquitetura integra o Azure Chaos Studio como parte dos pipelines de implantação.

Para obter mais informações, consulte Implantação e teste para cargas de trabalho críticas no Azure: validação e teste contínuos

Teste: Estruturas

A implementação de referência online de recursos e estruturas de teste existentes sempre que possível.

Estrutura	Teste	Descrição
NUnit	Unidade	Essa estrutura é usada para testar a parte do .NET Core da implementação. Os testes de unidade são executados automaticamente pelo Azure Pipelines antes do build do contêiner.
JMeter com o Teste de Carga do Azure	Carregar	O Teste de Carga do Azure é um serviço gerenciado usado para executar definições de teste de carga do Apache JMeter .
Locust	Carregar	Locust é uma estrutura de teste de carga de software livre escrita em Python.
Playwright	Interface do usuário e Smoke	O Playwright é uma biblioteca código aberto Node.js para automatizar Chromium, Firefox e WebKit com uma única API. A definição de teste do Dramaturgo também pode ser usada independentemente da implementação de referência.
Azure Chaos Studio	Injeção de falha	A implementação de referência usa o Azure Chaos Studio como uma etapa opcional no pipeline de validação do E2E para injetar falhas para validação de resiliência.

Teste: Teste de injeção de falha e Engenharia do Caos

Os aplicativos distribuídos devem ser resilientes a interrupções de serviço e componente. O teste de injeção de falhas (também conhecido como Injeção de Falhas ou Engenharia do Caos) é a prática de submeter aplicativos e serviços a estresses e falhas do mundo real.

Resiliência é uma propriedade de um sistema inteiro e injetar falhas ajuda a encontrar problemas no aplicativo. Resolver esses problemas ajuda a validar a resiliência do aplicativo para condições não confiáveis, dependências ausentes e outros erros.

Testes manuais e automáticos podem ser executados na infraestrutura para encontrar falhas e problemas na implementação.

Automática

A arquitetura de referência integra o Azure Chaos Studio para implantar e executar um conjunto de experimentos do Azure Chaos Studio para injetar várias falhas no nível do selo. Os experimentos do Chaos podem ser executados como uma parte opcional do pipeline de implantação do E2E. Quando os testes são executados, o teste de carga opcional sempre é executado em paralelo. O teste de carga é usado para criar carga no cluster para validar o efeito das falhas injetadas.

Manual

O teste manual de injeção de falha deve ser feito em um ambiente de validação E2E. Esse ambiente garante testes representativos completos sem risco de interferência de outros ambientes. A maioria das falhas geradas com os testes pode ser observada diretamente na exibição de métricas do Application Insights Live. As falhas restantes estão disponíveis na exibição Falhas e nas tabelas de log correspondentes. Outras falhas exigem uma depuração mais profunda, como o uso de kubectl para observar o comportamento dentro do AKS.

Dois exemplos de testes de injeção de falha executados na arquitetura de referência são:

• Injeção de falha baseada em DNS – um caso de teste que pode simular vários problemas. Falhas de resolução de DNS devido à falha de um servidor DNS ou DNS do Azure. O teste baseado em DNS pode ajudar a simular problemas gerais de conexões entre um cliente e um serviço, por exemplo, quando o BackgroundProcessor não pode se conectar aos Hubs de Eventos.

  Em cenários de host único, você pode modificar o arquivo local hosts para substituir a resolução DNS. Em um ambiente maior com vários servidores dinâmicos, como o AKS, um hosts arquivo não é viável. As Zonas de DNS privado do Azure podem ser usadas como uma alternativa para testar cenários de falha.

  Hubs de Eventos do Azure e o Azure Cosmos DB são dois dos serviços do Azure usados na implementação de referência que podem ser usados para injetar falhas baseadas em DNS. A resolução DNS dos Hubs de Eventos pode ser manipulada com uma zona de DNS privado do Azure vinculada à rede virtual de um dos selos. O Azure Cosmos DB é um serviço replicado globalmente com pontos de extremidade regionais específicos. A manipulação dos registros DNS para esses pontos de extremidade pode simular uma falha para uma região específica e testar o failover de clientes.

• Bloqueio de firewall – a maioria dos serviços do Azure dá suporte a restrições de acesso de firewall com base em redes virtuais e/ou endereços IP. Na infraestrutura de referência, essas restrições são usadas para restringir o acesso ao Azure Cosmos DB ou aos Hubs de Eventos. Um procedimento simples é remover regras de permissão existentes ou adicionar novas regras de bloco . Esse procedimento pode simular configurações incorretas de firewall ou interrupções de serviço.

  Os seguintes serviços de exemplo na implementação de referência podem ser testados com um teste de firewall:

  Serviço	Resultado
  Key Vault	Quando o acesso ao Key Vault é bloqueado, o efeito mais direto foi a falha de novos pods para gerar. O driver csi Key Vault que busca segredos na inicialização do pod não pode executar suas tarefas e impede que o pod seja iniciado. As mensagens de erro correspondentes podem ser observadas com kubectl describe po CatalogService-deploy-my-new-pod -n workload. Os pods existentes continuarão a funcionar, embora a mesma mensagem de erro seja observada. A mensagem de erro é gerada pelos resultados da atualização periódica marcar para segredos. Embora não tenha sido testado, supõe-se que a execução de uma implantação não funcionará enquanto Key Vault estiver inacessível. As tarefas do Terraform e da CLI do Azure na execução do pipeline fazem solicitações para Key Vault.
  Hubs de Evento	Quando o acesso aos Hubs de Eventos for bloqueado, novas mensagens enviadas pelo CatalogService e pelo HealthService falharão. A recuperação de mensagens pelo BackgroundProcess falhará lentamente, com falha total dentro de alguns minutos.
  Azure Cosmos DB	A remoção da política de firewall existente para uma rede virtual faz com que o Serviço de Integridade comece a falhar com o atraso mínimo. Este procedimento simula apenas um caso específico, uma interrupção inteira do Azure Cosmos DB. A maioria dos casos de falha que ocorrem em um nível regional deve ser atenuada automaticamente por failover transparente do cliente para uma região diferente do Azure Cosmos DB. O teste de injeção de falha baseado em DNS descrito anteriormente é um teste mais significativo para o Azure Cosmos DB.
  Registro de contêiner (ACR)	Quando o acesso ao ACR é bloqueado, a criação de novos pods que foram extraídos e armazenados em cache anteriormente em um nó do AKS continuará funcionando. A criação ainda funciona devido ao sinalizador pullPolicy=IfNotPresentde implantação k8s . Nós que não efetuam pull e armazenaram uma imagem em cache antes que o bloco não possa gerar um novo pod e falham imediatamente com ErrImagePull erros. kubectl describe pod exibe a mensagem correspondente 403 Forbidden .
  Entrada do AKS Load Balancer	A alteração das regras de entrada para HTTP(S)(portas 80 e 443) no NSG (Grupo de Segurança de Rede) gerenciado pelo AKS para Negar resulta em falha no tráfego de investigação de integridade ou usuário ao acessar o cluster. O teste dessa falha é difícil de identificar a causa raiz, que foi simulada como bloqueio entre o caminho de rede do Front Door e um carimbo regional. O Front Door detecta imediatamente essa falha e tira o carimbo da rotação.