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

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

A implantação e as atualizações são o processo central da arquitetura. As atualizações relacionadas à infraestrutura e ao aplicativo devem ser implantadas em carimbos totalmente independentes. Somente os componentes de infraestrutura global na arquitetura são compartilhados entre os carimbos. Os carimbos existentes na infraestrutura não são tocados. As atualizações de infraestrutura serão implantadas somente nesses novos carimbos. A nova versão do aplicativo será implantada somente nesses novos carimbos.

Os novos carimbos são adicionados ao Azure Front Door. O tráfego é transferido gradualmente para os novos carimbos. Quando se determina que o tráfego é servido a partir dos novos carimbos sem problemas, os carimbos anteriores são excluídos.

Testes de penetração, caos e estresse são recomendados para o ambiente implantado. O teste proativo da infraestrutura descobre pontos fracos e a forma 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 pipelines para a infraestrutura.

• Atualizações sem tempo de inatividade - As atualizações e upgrades são implantados no ambiente com zero tempo de inatividade para o aplicativo implantado.

• Ambientes - Ambientes de curta duração e permanentes utilizados para a arquitetura.

• Recursos compartilhados e dedicados - Recursos do Azure que são dedicados e compartilhados aos carimbos e à infraestrutura geral.

Para obter mais informações, confira 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 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 compilação, teste e versão.

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

Para obter mais informações sobre o Azure Pipelines, confira O que é o 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: atualizações sem tempo de inatividade

A estratégia de atualização de tempo de inatividade zero na arquitetura de referência é fundamental para o aplicativo crítico geral. A metodologia de substituir em vez de fazer upgrade dos carimbos garante uma nova instalação do aplicativo em um carimbo de infraestrutura. A arquitetura de referência utiliza uma abordagem azul/verde e permite ambientes separados de teste e desenvolvimento.

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

• Infraestrutura - Serviços e recursos do Azure. Implantado com o Terraform e a configuração associada.

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

Em muitos sistemas, existe o pressuposto de que as atualizações de aplicativos 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 mudanças podem acontecer em um ritmo mais rápido. Foi escolhido um único processo de implantação para atualizações de aplicativos e atualizações de infraestrutura. Uma única abordagem garante que as atualizações de infraestrutura e aplicativos estejam sempre sincronizadas. Esta abordagem permite:

• Um único processo consistente - Menos chances de erros se as atualizações de infraestrutura e aplicativos forem misturadas em uma versão, intencionalmente ou não.

• Habilita a implantação azul/verde - Cada atualização é implantada usando uma migração gradual do 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 revertido 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 azul/verde

Estratégia de ramificação

A base da estratégia de atualização é o uso de ramificações dentro do repositório Git. A arquitetura de referência usa três tipos de ramificações:

Branch	Descrição
feature/* e fix/*	Os pontos de entrada para qualquer alteração. Essas ramificações são criadas por desenvolvedores e devem ter um nome descritivo, como feature/catalog-update ou fix/worker-timeout-bug. Quando as alterações estiverem prontas para serem mescladas, uma solicitação pull (PR) em relação à ramificação main. Cada PR deve ser aprovada por pelo menos um revisor. Com exceções limitadas, cada alteração proposta em uma PR deve ser executada pelo 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	A ramificação em constante avanço e estável. Usado principalmente para testes de integração. As alterações a main são feitas somente por meio de solicitações pull. Uma política de ramificação proíbe gravações diretas. As liberações noturnas no ambiente permanente integration (int) são executadas automaticamente a partir da ramificação main. A ramificação main é considerada estável. Deve ser seguro presumir que, a qualquer momento, uma versão pode ser criada a partir dela.
release/*	As ramificações de versão são criadas somente a partir da ramificação main. As ramificações seguem o formato release/2021.7.X. As políticas de ramificação são usadas para que apenas os administradores de repositório tenham permissão para criar ramificações release/*. Somente estas ramificações são usadas para implantar no ambiente prod.

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

Hotfixes

Quando um hotfix for urgente devido a um bug ou outro problema e não for possível concluir o processo de versão regular, um caminho de hotfix estará disponível. Exemplos válidos de hotfixes são atualizações de segurança críticas e correções na experiência do usuário que não foram descobertas durante o teste inicial.

O hotfix deve ser criado em uma nova ramificação fix e, em seguida, mesclado para main usando uma PR regular. Em vez de criar uma nova ramificação de versão, o hotfix é "escolhido a dedo" em uma ramificação de versão existente. Essa ramificação já está implantada no ambiente prod. O pipeline de CI/CD que implantou originalmente a ramificação de versão com todos os testes é executado novamente e agora implantará o hotfix como parte do pipeline.

Para evitar problemas maiores, é importante que o hotfix contenha algumas confirmações isoladas que podem ser facilmente selecionadas e integradas à ramificação da versão. Se não for possível escolher commits isoladas a dedo para integrar à ramificação de versão, isso indica 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 seja possível implantar nova versão.

Ambientes de Implantação

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 pura para desenvolvedores. Os ambientes de validação podem ser criados a partir da ramificação feature/*, submetidos a testes e então destruídos se todos os testes forem bem-sucedidos. Os ambientes de depuração são implantados da mesma forma que os de validação, mas não são destruídos imediatamente. Esses ambientes não devem existir por mais do que alguns dias e devem ser excluídos quando a PR correspondente da ramificação do recurso for mesclado.

• Permanente - Nos ambientes permanentes existem versões integration (int) 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 realista da arquitetura de referência, um ambiente staging (pre-prod) deve ser adicionado. O ambiente staging é usado para implantar e validar ramificações release com o mesmo processo de atualização que prod (implantação azul/verde).

  • Integração (int) - A versão int é implantada todas as noites a partir da ramificação main com o mesmo processo que prod. A alternância de tráfego é mais rápida do que a unidade de versão anterior. Em vez de alternar gradualmente o tráfego ao longo de vários dias, como em prod, o processo para int é concluído em poucos minutos ou horas. Essa alternância mais rápida garante que o ambiente atualizado esteja pronto na manhã seguinte. Os carimbos antigos são excluídos automaticamente se todos os testes no pipeline forem bem-sucedidos.

  • Produção (prod) - A versão prod só é implantada a partir de ramificações release/*. A alternância de tráfego usa etapas mais granulares. Uma porta de aprovação manual está entre cada etapa. Cada versão cria novos carimbos regionais e implanta a nova versão do aplicativo nos carimbos. Os carimbos existentes na infraestrutura não são tocados. A consideração mais importante sobre prod é que ele deve estar "sempre ligado". 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. Um período 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 eles são compartilhados com toda a infraestrutura ou dedicados a um carimbo individual. Os recursos podem ser dedicados a uma versão específica e existem somente até que a próxima unidade de versão tenha sido implantada.

Unidades de versão

Uma unidade de lançamento são vários selos regionais por versão de lançamento específica. Os carimbos contêm todos os recursos que não são compartilhados com os outros carimbos. Esses recursos são redes virtuais, cluster do Serviço de Kubernetes do Azure, Hubs de Eventos e Azure Key Vault. 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 lançamento são definidos em um modelo do Terraform independente. Esses recursos são Front Door, Azure Cosmos DB, Registro de contêiner (ACR) e os espaços de trabalho do Log Analytics e outros recursos relacionados ao monitoramento. Esses recursos são implantados antes que o primeiro carimbo regional de uma unidade de lançamento seja implantado. Os recursos são referenciados nos modelos do Terraform para os carimbos.

Front Door

Embora o Front Door seja um recurso compartilhado globalmente entre carimbos, sua configuração é ligeiramente diferente dos outros recursos globais. É necessário reconfigurar o Front Door depois que um novo carimbo é implantado. O Front Door deve ser reconfigurado para alternar o tráfego gradativamente para os novos carimbos.

A configuração de back-end do Front Door não pode ser definida diretamente no modelo Terraform. A configuração é inserida com variáveis do Terraform. Os valores das variáveis 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 da 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 lançamento para mover o tráfego gradualmente para uma unidade mais nova. Cada origem de uma unidade de lançamento deve ter o mesmo peso atribuído.

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

• Regras de roteiro - Existem dois tipos de regras de roteiro:

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

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

  Se um lançamento apresentar uma nova versão das APIs de back-end, as alterações refletirão na interface do usuário implantada como parte do lançamento. Um lançamento específico 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. São necessárias regras de roteiros específicas para diferentes instâncias da versão da API. Essas regras estão ligadas aos grupos de origem correspondentes. Se uma nova API não tiver sido introduzida, todas as regras de roteiros 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 um lançamento diferente da API.

Implantação: processo de implantação

O objetivo do processo de implantação é uma implantação azul/verde. Um novo lançamento de uma ramificação release/* é implantado no ambiente prod. O tráfego de usuários é alternado gradualmente para os carimbos do novo lançamento.

Como primeira etapa no processo de implantação de uma nova versão, a infraestrutura para a nova unidade de lançamento é implantada com o Terraform. A execução do pipeline de implantação de infraestrutura implanta a nova infraestrutura a partir de uma ramificação de lançamento selecionada. Em paralelo ao provisionamento de infraestrutura, as imagens de contêiner são criadas ou importadas e enviadas por push para o registro de contêiner compartilhado globalmente (ACR). Quando os processos anteriores são concluídos, o aplicativo é implantado nos carimbos. Do ponto de vista da implementação, trata-se de 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.

É necessário planejar um switch/parâmetro que distingua entre lançamentos que introduzem e não introduzem uma nova versão da API. Com base em se o lançamento introduz ou não uma nova versão da API, será necessário criar um novo grupo de origem com os back-ends da API. 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. É necessário criar uma nova regra de roteiros, conforme descrito acima, que corresponda ao grupo de origem apropriado.

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

Desmontagem da unidade de lançamento

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

Listas de Verificação

Como parte da cadência de lançamento, 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 pré-lançamento - Antes de iniciar um lançamento, verifique o seguinte:

  • Verifique se o estado mais recente da ramificação de main foi implantado e testado com êxito no ambiente int.

  • Atualize o arquivo de log de alterações por meio de uma PR na ramificação main.

  • Crie uma ramificação release/ a partir da ramificação main.

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

  • 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 elevado - Ao lançar 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 sem tempo de inatividade depende do funcionamento correto.

• 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 mitigada com o processo de hotfix descrito na seção anterior.

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

A estratégia de atualização pode oferecer suporte a várias versões de uma API e componentes de trabalho em execução simultânea. Como o Azure Cosmos DB é compartilhado entre duas ou mais versões, existe 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 e os trabalhadores da API devem implementar o design de compatibilidade direta. Versões anteriores da API ou componentes de trabalho processam dados que foram inseridos por uma versão posterior da API ou do componente de trabalho. Ela ignora partes que não entende.

Testando

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

Esses testes incluem:

• Testes de unidade - Esses testes validam se 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 compilação 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 de uma determinada carga de trabalho ou pilha. A implementação de referência contém um gerador de carga de usuário para criar padrões de carga sintética 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.

• Testes de fumaça - Esses testes identificam se a infraestrutura e a carga de trabalho estão disponíveis e agem conforme o esperado. Os testes de fumaça são executados como parte de cada implantação.

• Testes 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 de missão crítica no Azure: validação e teste contínuos

Testes: estruturas

A implementação de referência online para recursos de teste atuais e estruturas 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 pelos Pipelines do Azure antes das compilações de contêiner.
JMeter com 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 código aberto escrito em Python.
Playwright	IU e Fumaça	Playwright é uma biblioteca de Node.js de código aberto para automatizar o Chromium, Firefox e WebKit com uma única API. A definição do teste do Playwright também pode ser usada independentemente da implementação de referência.
Azure Chaos Studio	Injetar falhas	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.

Testes: testes de Injeção de Falhas e Engenharia do Chaos

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

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

É possível realizar testes manuais e automáticos contra a infraestrutura para encontrar falhas e problemas na implementação.

Automático

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 de carimbo. 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 de injeção manual de falhas deve ser feito em um ambiente de validação E2E. Este ambiente garante testes totalmente representativos sem risco de interferência de outros ambientes. A maioria das falhas geradas com os testes pode ser observada diretamente em Métricas em tempo real do Application Insights. As falhas restantes estão disponíveis na visualização Falhas e nas tabelas de log correspondentes. Outras falhas exigem 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 realizados 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 do 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 consegue se conectar aos Hubs de Eventos.

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

  Os 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 de DNS dos Hubs de Eventos pode ser manipulada com uma zona de DNS Privado do Azure vinculada à rede virtual de um dos carimbos. 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 oferece 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 Bloqueio. 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 desovar. O driver CSI do 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 o kubectl describe po CatalogService-deploy-my-new-pod -n workload. Os pods existentes continuarão funcionando, embora a mesma mensagem de erro seja observada. A mensagem de erro é gerada pelos resultados da verificação de atualização periódica para segredos. Embora não tenha sido testado, presume-se que a execução de uma implantação não funcionará enquanto o Key Vault estiver inacessível. As tarefas do Terraform e da CLI do Azure na execução do pipeline fazem solicitações ao Key Vault.
  Hubs de Eventos	Quando o acesso aos Hubs de Eventos é bloqueado, novas mensagens enviadas pelo CatalogService e HealthService falharão. A recuperação de mensagens pelo BackgroundProcess lentamente falhará, com falha total em poucos 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 um 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 pelo 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 puxados e armazenados em cache anteriormente em um nó AKS continuará a funcionar. A criação ainda funciona devido ao sinalizador implantação k8spullPolicy=IfNotPresent. Os nós que não tiverem puxado e armazenado em cache uma imagem antes do bloco não poderão gerar um novo pod e falharão imediatamente com erros de ErrImagePull. kubectl describe pod exibe a mensagem correspondente 403 Forbidden.
  Balanceador de carga de entrada do AKS	A alteração das regras de entrada para HTTP(S)(portas 80 e 443) no NSG (Network Security Group) gerenciado pelo AKS para resultados de Negar no tráfego de teste de usuário ou investigação de integridade não alcançam o cluster. É difícil de identificar a causa raiz dessa falha por meio do teste, o que foi simulado 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.