Modelagem de integridade para cargas de trabalho de missão crítica
O monitoramento de aplicativos e infraestrutura é uma parte importante de qualquer implantação de infraestrutura. Para uma carga de trabalho de missão crítica, o monitoramento é uma parte crítica da implantação. Monitorar a integridade do aplicativo e as principais métricas dos recursos do Azure ajuda você a entender se o ambiente está funcionando conforme o esperado.
Para entender completamente essas métricas e avaliar a integridade geral de uma carga de trabalho, é necessária uma compreensão holística de todos os dados monitorados. Um modelo de integridade pode ajudar na avaliação do estado de integridade geral, exibindo uma indicação clara da integridade da carga de trabalho em vez de métricas brutas. O status é frequentemente apresentado como indicadores de "semáforo", como vermelho, verde ou amarelo. A representação de um modelo de integridade com indicadores claros torna intuitivo para um operador entender a integridade geral da carga de trabalho e responder rapidamente aos problemas que surgem.
A modelagem de integridade pode ser expandida para as seguintes tarefas operacionais para a implantação de missão crítica:
Serviço de Integridade do Aplicativo - Componente do aplicativo no cluster de computação que fornece uma API para determinar a integridade de um carimbo.
Monitoramento - Coleta de contadores de desempenho e de aplicativos que avaliam a integridade e o desempenho do aplicativo e da infraestrutura.
Alertas - Alertas acionáveis de problemas ou paralisações na infraestrutura e no aplicativo.
Análise de falhas - Detalhamento e análise de eventuais falhas incluindo documentação de causa raiz.
Essas tarefas compõem um modelo de integridade abrangente para a infraestrutura de missão crítica. O desenvolvimento de um modelo de integridade pode e deve ser uma parte exaustiva e integral de qualquer implantação de missão crítica.
Para obter mais informações, confira Modelagem de integridade e observabilidade de cargas de trabalho críticas no Azure.
Serviço de integridade do aplicativo
O Serviço de Integridade do Aplicativo (Serviço de Integridade) é um componente de aplicativo que reside com o Serviço de Catálogo (CatalogService) e o Processador em Segundo Plano (BackgroundProcessor) dentro do cluster de computação. O Serviço de Integridade fornece uma API REST para o Azure Front Door chamar para determinar a integridade de um carimbo. O Serviço de Integridade é um componente complexo que reflete o estado das dependências, além do seu próprio.
Quando o cluster de computação estiver inativo, o serviço de integridade não responderá. Quando os serviços estão em funcionamento, ele executa verificações periódicas nos seguintes componentes na infraestrutura:
Ele tenta fazer uma consulta no Azure Cosmos DB.
Ele tenta enviar uma mensagem para os Hubs de Eventos. A mensagem é filtrada pelo trabalhador em segundo plano.
Ele procura um arquivo de estado na conta de armazenamento. Esse arquivo pode ser usado para desativar uma região, mesmo enquanto as outras verificações ainda estão funcionando corretamente. Esse arquivo pode ser usado para se comunicar com outros processos. Por exemplo, se o carimbo for desocupado para fins de manutenção, o arquivo poderá ser excluído para forçar um estado não íntegro e redirecionar o tráfego.
Ele consulta o modelo de integridade para determinar se todas as métricas operacionais estão dentro dos limites predeterminados. Quando o modelo de integridade indica que o carimbo não está íntegro, o tráfego não deve ser roteado para o carimbo mesmo que os outros testes que o Serviço de Integridade executa retornem com êxito. O Modelo de Integridade leva em conta uma visão mais completa do estado de saúde.
Todos os resultados da verificação de integridade são armazenados em cache na memória por um número configurável de segundos, por padrão 10. Essa operação potencialmente adiciona uma pequena latência na detecção de interrupções, mas garante que nem todas as consultas do Serviço de Integridade exijam chamadas de back-end, reduzindo assim a carga no cluster e nos serviços downstream.
Esse padrão de cache é importante, porque o número de consultas do Serviço de Integridade cresce significativamente ao usar um roteador global como o Azure Front Door: cada nó de borda em cada datacenter do Azure que atende solicitações chamará o Serviço de Integridade para determinar se ele tem uma conexão de back-end funcional. Armazenar em cache os resultados reduz a carga extra de cluster gerada por verificações de integridade.
Configuração
O Serviço de Integridade e o CatalogService têm definições de configuração comuns entre os componentes, exceto para as seguintes configurações usadas exclusivamente pelo Serviço de Integridade:
| Configuração | Valor |
|---|---|
HealthServiceCacheDurationSeconds |
Controla o tempo de expiração do cache de memória, em segundos. |
HealthServiceStorageConnectionString |
Cadeia de conexão para a Conta de Armazenamento onde o arquivo de status deve estar presente. |
HealthServiceBlobContainerName |
Contêiner de armazenamento onde o arquivo de status deve estar presente. |
HealthServiceBlobName |
Nome do arquivo de status - a verificação de integridade procurará esse arquivo. |
HealthServiceOverallTimeoutSeconds |
Tempo limite para toda a verificação - o padrão é de 3 segundos. Se a verificação não for concluída nesse intervalo, o serviço relatará não estar íntegro. |
Implementação
Todas as verificações são feitas de forma assíncrona e em paralelo. Se alguma delas falhar, todo o carimbo será considerado indisponível.
Os resultados da verificação são armazenados em cache na memória, usando o padrão ASP.NET Core não distribuídoMemoryCache. A expiração do cache é controlada e SysConfig.HealthServiceCacheDurationSeconds definida como 10 segundos por padrão.
Observação
A SysConfig.HealthServiceCacheDurationSeconds definição de configuração reduz a carga adicional gerada pelas verificações de integridade, pois nem todas as solicitações resultarão em chamada downstream para os serviços dependentes.
A tabela a seguir detalha as verificações de integridade dos componentes na infraestrutura:
| Componente | Verificação de integridade |
|---|---|
| Blob de conta de armazenamento | Atualmente, o cheque blob serve a dois propósitos: 1. Teste se é possível acessar o Armazenamento de Blobs. A conta de armazenamento é usada por outros componentes no carimbo e é considerada um recurso crítico. 2. "Desativar" manualmente uma região excluindo o arquivo de estado. Foi tomada uma decisão de design de que a verificação procuraria apenas a presença de um arquivo de estado no contêiner de blob especificado. O conteúdo do arquivo não é processado. Existe a possibilidade de configurar um sistema mais sofisticado que lê o conteúdo do arquivo e retorna status diferente com base no conteúdo do arquivo. Exemplos de conteúdo são ÍNTEGRO, NÃO ÍNTEGRO e MANUTENÇÃO. A remoção do arquivo de estado desabilitará o carimbo. Verifique se o arquivo de integridade está presente após a implantação do aplicativo. A ausência do arquivo de integridade fará com que o serviço sempre responda com NÃO ÍNTEGRO. O Front Door não reconhece o back-end como disponível. O arquivo é criado pelo Terraform e deve estar presente após a implantação da infraestrutura. |
| Hub de Evento | O relatório de integridade dos Hubs de Eventos é tratado pelo EventHubProducerService. Esse serviço relata integridade se puder enviar uma nova mensagem para os Hubs de Eventos. Para filtragem, essa mensagem tem uma propriedade de identificação adicionada a ela: HEALTHCHECK=TRUE Essa mensagem é ignorada na extremidade de recebimento. A AlwaysOn.BackgroundProcessor.EventHubProcessorService.ProcessEventHandlerAsync() definição de configuração verifica a HEALTHCHECK propriedade. |
| Azure Cosmos DB | Os relatórios de integridade do Azure Cosmos DB são manipulados pelo CosmosDbService, que relata íntegro se for: 1. Capaz de se conectar ao banco de dados do Azure Cosmos DB e executar uma consulta. 2. Capaz de gravar um documento de teste no banco de dados. O documento de teste tem um conjunto de tempo de vida curto, o Azure Cosmos DB o remove automaticamente. O Serviço de Integridade executa dois testes separados. Se o Azure Cosmos DB estiver em um estado em que as leituras funcionam e as gravações não, os dois testes garantem que um alerta seja disparado. |
Consultas do Azure Cosmos DB
Para a consulta somente leitura, a seguinte consulta está sendo usada, que não busca dados e não tem um grande efeito na carga geral:
SELECT GetCurrentDateTime ()
A consulta de gravação cria um manequim ItemRating com conteúdo mínimo:
var testRating = new ItemRating()
{
Id = Guid.NewGuid(),
CatalogItemId = Guid.NewGuid(), // Create some random (=non-existing) item id
CreationDate = DateTime.UtcNow,
Rating = 1,
TimeToLive = 10 // will be auto-deleted after 10sec
};
await AddNewRatingAsync(testRating);
Monitoramento
O Azure Log Analytics é usado como um armazenamento central para armazenar logs e métricas de todos os componentes de aplicativos e infraestrutura. O Azure Application Insights é usado para todos os dados de monitoramento de aplicativos. Cada carimbo na infraestrutura tem um workspace dedicado da Análise de Logs e uma instância do Application Insights. Um workspace separado da Análise de Logs é usado para os recursos compartilhados globalmente, como o Front Door e o Azure Cosmos DB.
Todos os selos são de curta duração e continuamente substituídos a cada nova versão. Os workspaces da Análise de Logs por carimbo são implantados como um recurso global em um grupo de recursos de monitoramento separado como os recursos da Análise de Logs de carimbo. Esses recursos não compartilham o ciclo de vida de um carimbo.
Para obter mais informações, consulte Coletor de dados unificado para análise correlacionada.
Monitorando: fontes de dados
Configurações de diagnóstico: todos os serviços do Azure usados para a Missão Crítica do Azure são configurados para enviar todos os seus dados de diagnóstico, incluindo logs e métricas, para o Workspace de Análise de Log específico da implantação (global ou carimbo). Esse processo acontece automaticamente como parte da implantação do Terraform. Novas opções serão identificadas automaticamente e adicionadas como parte do
terraform apply.Monitoramento do Kubernetes: as configurações de diagnóstico são usadas para enviar logs e métricas do Serviço de Kubernetes do Azure (AKS) para a Análise de Logs. O AKS está configurado para usar o Container Insights. O Container Insights implanta o OMSAgentForLinus por meio de um Kubernetes DaemonSet em cada nó nos clusters AKS. O OMSAgentForLinux é capaz de coletar logs e métricas extras de dentro do cluster do Kubernetes e enviá-los para seu espaço de trabalho correspondente da Análise de Logs. Esses logs e métricas extras contêm dados mais granulares sobre pods, implantações, serviços e a integridade geral do cluster. Para obter mais insights dos vários componentes, como ingress-nginx, cert-manager e outros componentes implantados no Kubernetes ao lado da carga de trabalho de missão crítica, é possível usar a extração do Prometheus. A extração do Prometheus configura o OMSAgentForLinux para raspar as métricas do Prometheus de vários pontos de extremidade dentro do cluster.
Telemetria do Application Insights: o Application Insights é usado para coletar dados de telemetria do aplicativo. O código foi instrumentado para coletar dados sobre o desempenho do aplicativo com o SDK do Application Insights. Informações críticas, como o código de status resultante e a duração das chamadas de dependência e contadores para exceções não tratadas, são coletadas. Essas informações são usadas no Modelo de Integridade e estão disponíveis para alertas e solução de problemas.
Monitoramento: testes de disponibilidade do Application Insights
Para monitorar a disponibilidade dos carimbos individuais e da solução geral de um ponto de vista externo, os Testes de Disponibilidade do Application Insights são configurados em dois locais:
Testes de disponibilidade regional: esses testes são configurados nas instâncias regionais do Application Insights e usados para monitorar a disponibilidade dos carimbos. Esses testes visam diretamente os clusters e as contas de armazenamento estático dos carimbos. Para chamar os pontos de entrada dos clusters diretamente, as solicitações precisam carregar o cabeçalho correto do Front Door ID, caso contrário, elas serão rejeitadas pelo controlador de entrada.
Teste de disponibilidade global: esses testes são configurados na instância global do Application Insights e usados para monitorar a disponibilidade da solução geral executando ping no Front Door. Dois testes são usados: um para testar uma chamada de API em relação ao CatalogService e outro para testar a home page do site.
Monitoramento: Consultas
O Azure Mission-Critical usa diferentes consultas KQL (Linguagem de Consulta Kusto) para implementar consultas personalizadas como funções para recuperar dados da Análise de Logs. Essas consultas são armazenadas como arquivos individuais em nosso repositório de código, separados para implantações globais e de carimbo. Eles são importados e aplicados automaticamente via Terraform como parte de cada pipeline de infraestrutura executado.
Essa abordagem separa a lógica de consulta da camada de visualização. As consultas da Análise de Logs são chamadas diretamente do código, por exemplo, da API Serviço de Integridade. Outro exemplo é de uma ferramenta de visualização, como Painéis do Azure, Pastas de Trabalho do Monitor ou Grafana.
Monitoramento: Visualização
Para visualizar os resultados de nossas consultas de integridade da Análise de Logs, usamos o Grafana em nossa implementação de referência. O Grafana é usado para mostrar os resultados das consultas da Análise de Logs e não contém nenhuma lógica em si. A pilha Grafana não faz parte do ciclo de vida de implantação da solução, mas é lançada separadamente.
Para saber mais, confira Visualização.
Alertas
Os alertas são uma parte importante da estratégia geral de operações. O monitoramento proativo, como o uso de painéis, deve ser usado com alertas que chamem a atenção imediata para os problemas.
Esses alertas formam uma extensão do modelo de integridade, alertando o operador sobre uma mudança no estado de integridade, seja para o estado degradado/amarelo ou para o estado não íntegro/vermelho. Ao definir o alerta para o nó raiz do Modelo de Integridade, o operador fica imediatamente ciente de qualquer efeito no nível de negócios para o estado da solução: afinal, esse nó raiz ficará amarelo ou vermelho se qualquer um dos fluxos ou recursos de usuário subjacentes relatar métricas amarelas ou vermelhas. O operador pode direcionar sua atenção para a visualização do Modelo de Integridade para solução de problemas.
Para obter mais informações, confira Resposta automatizada a incidentes.
Análise de falha
Compor a análise de falhas é, em sua maioria, um exercício teórico de planejamento. Este exercício teórico deve ser usado como entrada para as injeções automáticas de falha que fazem parte do processo de validação contínua. Ao simular os modos de falha definidos aqui, podemos validar a resiliência da solução contra essas falhas para garantir que elas não levem a interrupções.
A tabela a seguir lista exemplos de casos de falha dos vários componentes da implementação de referência de Missão Crítica do Azure.
| Serviço | Risco | Impacto/Mitigação/Comentário | Interrupção |
|---|---|---|---|
| Microsoft Entra ID | O Microsoft Entra ID fica indisponível. | Atualmente não há mitigação possível em vigor. Uma abordagem de várias regiões não atenuará nenhuma interrupção, pois é um serviço global. Este serviço é uma dependência difícil. O Microsoft Entra ID é usado para operações do plano de controle, como a criação de novos nós AKS, extração de imagens de contêiner do ACR ou para acessar o Cofre de Chaves na inicialização do pod. Espera-se que os componentes existentes em execução possam continuar em execução quando o Microsoft Entra ID tiver problemas. É provável que novos pods ou nós AKS não consigam gerar. Em operações de escala são necessárias durante esse tempo, isso pode levar a uma diminuição da experiência do usuário e, potencialmente, a interrupções. | Parcial |
| DNS do Azure | O DNS do Azure fica indisponível e a resolução DNS falha. | Se o DNS do Azure ficar indisponível, a resolução DNS para solicitações do usuário e entre diferentes componentes do aplicativo provavelmente falhará. No momento, não há mitigação possível para esse cenário. Uma abordagem de várias regiões não atenuará nenhuma interrupção, pois é um serviço global. O DNS do Azure é uma dependência difícil. Os serviços DNS externos como backup não ajudariam, já que todos os componentes de PaaS usados dependem do DNS do Azure. Ignorar o DNS mudando para IP não é uma opção. Os serviços do Azure não têm endereços IP estáticos e garantidos. | Completo |
| Front Door | Interrupção geral da Front Door | Se a Front Door cair totalmente, não há mitigação. Este serviço é uma dependência difícil. | Sim |
| Front Door | Erros de configuração de roteamento/front-end/back-end. | Pode acontecer devido a incompatibilidade na configuração durante a implantação. Deve ser pego em fases de testes. A configuração de front-end com DNS é específica para cada ambiente. Mitigação: reverter para a configuração anterior deve corrigir a maioria dos problemas.. Como as alterações levam alguns minutos no Front Door para serem implantadas, isso causará uma interrupção. | Completo |
| Front Door | O certificado TLS/SSL gerenciado é excluído. | Pode acontecer devido a incompatibilidade na configuração durante a implantação. Deve ser pego em fases de testes. Tecnicamente, o site ainda funcionaria, mas erros de certificado TLS/SSL impedirão que os usuários o acessem. Mitigação: a reemissão do certificado pode levar cerca de 20 minutos, além de corrigir e executar novamente o pipeline. | Completo |
| Azure Cosmos DB | O banco de dados/coleção é renomeado. | Pode acontecer devido a incompatibilidade na configuração durante a implantação – o Terraform substituiria todo o banco de dados, o que poderia resultar em perda de dados. A perda de dados pode ser evitada usando bloqueios de nível de banco de dados/coleção. O aplicativo não poderá acessar nenhum dado. A configuração do aplicativo precisa ser atualizada e os pods reiniciados. | Sim |
| Azure Cosmos DB | Interrupção regional | O Azure Mission-Critical tem gravações de várias regiões habilitadas. Se houver uma falha em uma leitura ou gravação, o cliente tentará novamente a operação atual. Todas as operações futuras são roteadas permanentemente para a próxima região em ordem de preferência. Caso a lista de preferências tenha apenas uma entrada (ou esteja vazia), mas a conta tenha outras regiões disponíveis, ela será roteada para a próxima região na lista da conta. | Não |
| Azure Cosmos DB | Limitação excessiva devido à falta de RUs (unidades de solicitação). | Dependendo do número de RUs e do balanceamento de carga empregado no nível do Front Door, determinados carimbos podem ser executados na utilização do Azure Cosmos DB, enquanto outros carimbos podem atender a mais solicitações. Mitigação: Melhor distribuição de carga ou mais RUs. | Não |
| Azure Cosmos DB | Partição cheia | O limite de tamanho da partição lógica do Azure Cosmos DB é de 20 GB. Se os dados de uma chave de partição dentro de um contêiner atingirem esse tamanho, solicitações de gravação adicionais falharão com o erro "A chave de partição atingiu o tamanho máximo". | Parcial (gravações de banco de dados desabilitadas) |
| Registro de Contêiner do Azure | Interrupção regional | O Registro de contêiner usa o Gerenciador de Tráfego para failover entre regiões de réplica. Qualquer solicitação deve ser redirecionada automaticamente para outra região. Na pior das hipóteses, as imagens do Docker não podem ser extraídas por alguns minutos por nós AKS enquanto o failover de DNS acontece. | Não |
| Registro de Contêiner do Azure | Imagens excluídas | Nenhuma imagem pode ser puxada. Essa interrupção deve afetar apenas nós recém-gerados/reinicializados. Os nós existentes devem ter as imagens armazenadas em cache. **Mitigação: Se detectado rapidamente, a reexecução dos pipelines de compilação mais recentes deve trazer as imagens de volta para o registro. | Não |
| Registro de Contêiner do Azure | Limitação | A limitação pode atrasar as operações de expansão, o que pode resultar em um desempenho temporariamente degradado. Mitigação: o Azure Mission-Critical usa a SKU Premium que fornece 10 mil operações de leitura por minuto. As imagens de contêiner são otimizadas e têm apenas um pequeno número de camadas. ImagePullPolicy é definido como IfNotPresent para usar versões armazenadas em cache localmente primeiro. Comentário: A extração de uma imagem de contêiner consiste em várias operações de leitura, dependendo do número de camadas. O número de operações de leitura por minuto é limitado e depende do tamanho do SKU do ACR. | Não |
| Serviço de Kubernetes do Azure | Falha ao atualizar o cluster | As atualizações do nó AKS devem ocorrer em momentos diferentes nos carimbos. Se uma atualização falhar, o outro cluster não deverá ser afetado. As atualizações de cluster devem ser implantadas de forma contínua entre os nós para evitar que todos os nós fiquem indisponíveis. | Não |
| Serviço de Kubernetes do Azure | O pod do aplicativo é morto ao atender a solicitação. | Isso pode resultar em erros do usuário final enfrentando erros e experiência ruim do usuário. Mitigação: o Kubernetes por padrão remove pods de maneira graciosa. Os pods são removidos dos serviços primeiro e a carga de trabalho recebe um SIGTERM com um período de cortesia para concluir solicitações abertas e gravar dados antes de encerrar. O código do aplicativo precisa entender o SIGTERM e o período de cortesia pode precisar ser ajustado se a carga de trabalho demorar mais para ser encerrada. | Não |
| Serviço de Kubernetes do Azure | Capacidade de computação indisponível na região para adicionar mais nós. | As operações de expansão/saída falharão, mas não devem afetar os nós existentes e sua operação. O ideal é que o tráfego mude automaticamente para outras regiões para balanceamento de carga. | Não |
| Serviço de Kubernetes do Azure | A assinatura atinge a cota principal da CPU para adicionar novos nós. | As operações de expansão/saída falharão, mas não devem afetar os nós existentes e sua operação. O ideal é que o tráfego mude automaticamente para outras regiões para balanceamento de carga. | Não |
| Serviço de Kubernetes do Azure | Vamos criptografar certificados TLS/SSL não pode ser emitido/renovado. | O cluster deve relatar não íntegro em direção à Front Door e o tráfego deve mudar para outros carimbos. Mitigação: investigue a causa raiz da falha de emissão/renovação. | Não |
| Serviço de Kubernetes do Azure | Quando as solicitações/limites de recursos são configurados incorretamente, os pods podem atingir 100% de utilização da CPU e solicitações de falha. O mecanismo de repetição de aplicativo deve ser capaz de recuperar solicitações com falha. As novas tentativas podem causar uma duração de solicitação maior, sem exibir o erro para o cliente. A carga excessiva acabará por causar falhas. | Não (se a carga não for excessiva) | |
| Serviço de Kubernetes do Azure | Imagens de contêiner de terceiros / registro indisponível | Alguns componentes, como cert-manager e ingress-nginx, exigem o download de imagens de contêiner e gráficos de leme de registros de contêineres externos (tráfego de saída). Caso um ou mais desses repositórios ou imagens não estejam disponíveis, novas instâncias em novos nós (onde a imagem ainda não esteja armazenada em cache) talvez não consigam ser iniciadas. Possível mitigação: em alguns cenários, pode fazer sentido importar imagens de contêiner de terceiros para o registro de contêiner por solução. Isso adiciona complexidade adicional e deve ser planejado e operacionalizado cuidadosamente. | Parcialmente (durante operações de escala e atualização) |
| Hub de Evento | As mensagens não podem ser enviadas para os Hubs de Eventos | O carimbo torna-se inutilizável para operações de gravação. O serviço de integridade deve detectar isso automaticamente e tirar o carimbo da rotação. | Não |
| Hub de Evento | As mensagens não podem ser lidas pelo BackgroundProcessor | As mensagens entrarão na fila. As mensagens não devem se perder, pois são persistentes. Atualmente, essa falha não é coberta pelo Serviço de Integridade. Deve haver monitoramento/alerta no trabalhador para detectar erros na leitura de mensagens. Mitigação: O carimbo deve ser desabilitado manualmente até que o problema seja corrigido. | Não |
| Conta de armazenamento | A conta de armazenamento torna-se inutilizável pelo trabalhador para o Check Point dos Hubs de Eventos | O carimbo não processará mensagens dos Hubs de Eventos. A conta de armazenamento também é usada pelo Serviço de Integridade. Espera-se que problemas com o armazenamento sejam detectados pelo Serviço de Integridade e o carimbo seja retirado da rotação. Pode-se esperar que outros serviços do selo sejam afetados simultaneamente. | Não |
| Conta de armazenamento | O site estático encontra problemas. | Se a veiculação do site estático encontrar problemas, essa falha deverá ser detectada pelo Front Door. O tráfego não será enviado para essa conta de armazenamento. O armazenamento em cache no Front Door também pode aliviar esse problema. | Não |
| Key Vault | Cofre de chaves indisponível para operações GetSecret. |
No início dos novos pods, o driver AKS CSI buscará todos os segredos do Cofre de chaves e falhará. Os pods não poderão iniciar. Atualmente, há uma atualização automática a cada 5 minutos. Haverá falha na atualização. Os erros devem aparecer em kubectl describe pod mas o pod continua funcionando. |
Não |
| Key Vault | Cofre de chaves indisponível para operações GetSecret ou SetSecret. |
Novas implantações não podem ser executadas. Atualmente, essa falha pode fazer com que todo o pipeline de implantação pare, mesmo que apenas uma região seja afetada. | Não |
| Key Vault | Limitação do Cofre de chaves | O Cofre de chaves tem um limite de 1000 operações por 10 segundos. Por causa da atualização automática de segredos, você poderia, em teoria, atingir esse limite se tivesse muitos (milhares) de pods em um carimbo. Possível mitigação: diminua ainda mais a frequência de atualização ou desative-a completamente. | Não |
| Aplicativo | Configuração incorreta | Cadeias de conexão incorretas ou segredos injetados no aplicativo. Deve ser atenuado pela implantação automatizada (o pipeline manipula a configuração automaticamente) e pela distribuição azul-verde das atualizações. | Não |
| Aplicativo | Credenciais expiradas (recurso de carimbo) | Se, por exemplo, o token SAS do hub de eventos ou a chave da conta de armazenamento tiver sido alterada sem atualizá-los corretamente no Cofre de chaves para que os pods possam usá-los, o respectivo componente do aplicativo falhará. Essa falha deve afetar o Serviço de Integridade e o carimbo deve ser retirado da rotação automaticamente. Mitigação: use a autenticação baseada no Microsoft Entra ID para todos os serviços que oferecem suporte a ela. O AKS requer pods para autenticação usando o Microsoft Entra Workload ID (pré-visualização). O uso do Pod Identity foi considerado na implementação de referência. Descobriu-se que o Pod Identity não era estável o suficiente atualmente e foi decidido contra o uso para a arquitetura de referência atual. A identidade do pod pode ser uma solução no futuro. | Não |
| Aplicativo | Credenciais expiradas (recurso compartilhado globalmente) | Se, por exemplo, a chave da API do Azure Cosmos DB tiver sido alterada sem atualizá-la corretamente em todos os Cofres de chaves de carimbo para que os pods possam usá-los, os respectivos componentes do aplicativo falharão. Essa falha derrubaria todos os carimbos ao mesmo tempo e causaria uma interrupção em toda a carga de trabalho. Para uma possível maneira de contornar a necessidade de chaves e segredos usando o Microsoft Entra Auth, consulte o item anterior. | Completo |
| Rede virtual | Espaço de endereço IP da sub-rede esgotado | Se o espaço de endereço IP em uma sub-rede estiver esgotado, nenhuma operação de expansão, como a criação de novos nós ou pods AKS, poderá acontecer. Isso não levará a uma interrupção, mas pode diminuir o desempenho e afetar a experiência do usuário. Mitigação: aumentar o espaço IP (se possível). Se isso não for uma opção, pode ajudar a aumentar os recursos por nó (SKUs de VM maiores) ou por pod (mais CPU/memória), para que cada pod possa lidar com mais tráfego, diminuindo assim a necessidade de expansão. | Não |
Próximas etapas
Implante a implementação de referência para obter uma compreensão completa dos recursos e sua configuração usados nessa arquitetura.