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. O monitoramento da integridade do aplicativo e das 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 geral de saúde, 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 saúde 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 de aplicativo no cluster de computação que fornece uma API para determinar a integridade de um carimbo.
Monitoramento - Coleta de contadores de desempenho e aplicativos que avaliam a integridade e o desempenho do aplicativo e da infraestrutura.
Alertas - Alertas acionáveis de problemas ou interrupções na infraestrutura e no aplicativo.
Análise de falhas - Avaria e análise de quaisquer falhas, incluindo documentação da causa raiz.
Estas tarefas constituem um modelo de saúde abrangente para a infraestrutura de missão crítica. O desenvolvimento de um modelo de saúde pode e deve ser uma parte exaustiva e integrante de qualquer implantação de missão crítica.
Para obter mais informações, consulte Modelagem de integridade e observabilidade de cargas de trabalho de missão crítica no Azure.
Serviço de Integridade do Aplicativo
O Serviço de Integridade do Aplicativo (HealthService) é 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 HealthService fornece uma API REST para o Azure Front Door chamar para determinar a integridade de um carimbo. O HealthService é 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 em relação aos seguintes componentes na infraestrutura:
Ele tenta fazer uma consulta no Azure Cosmos DB.
Ele tenta enviar uma mensagem para 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. Este arquivo pode ser usado para se comunicar com outros processos. Por exemplo, se o carimbo for desocupado para fins de manutenção, o arquivo pode ser excluído para forçar um estado insalubre 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 HealthService executa retornem com êxito. O Modelo de Integridade leva em conta uma visão mais completa do status de integridade.
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 deteção de interrupções, mas garante que nem todas as consultas HealthService 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 HealthService 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. O armazenamento em cache dos resultados reduz a carga extra do cluster gerada pelas verificações de integridade.
Configuração
O HealthService e o CatalogService têm definições de configuração comuns entre os componentes, exceto para as seguintes configurações usadas exclusivamente pelo HealthService:
| Definição | Value |
|---|---|
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 ficheiro de estado - a verificação de estado de funcionamento procurará este ficheiro. |
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 realizadas de forma assíncrona e em paralelo. Se qualquer um deles falhar, todo o carimbo será considerado indisponível.
Os resultados da verificação são armazenados em cache na memória, usando o ASP.NET Core MemoryCachepadrão, não distribuído. A expiração do cache é controlada por e é definida como SysConfig.HealthServiceCacheDurationSeconds 10 segundos por padrão.
Nota
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 chamadas downstream para os serviços dependentes.
A tabela a seguir detalha as verificações de integridade dos componentes na infraestrutura:
| Componente | Verificação de estado de funcionamento |
|---|---|
| Blob da conta de armazenamento | Atualmente, a verificação de blob serve a dois propósitos: 1. Teste se é possível alcançar o Armazenamento de Blobs. A conta de armazenamento é usada por outros componentes no carimbo e é considerada um recurso crítico. 2. "Desligue" 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 ficheiro não é processado. Há a possibilidade de configurar um sistema mais sofisticado que lê o conteúdo do arquivo e retornar status diferente com base no conteúdo do arquivo. Exemplos de conteúdo são HEALTHY, UNHEALTHY, e MAINTENANCE. A remoção do arquivo de estado desativará o carimbo. Verifique se o arquivo de integridade está presente após a implantação do aplicativo. A ausência do arquivo de saúde fará com que o serviço sempre responda com INSAUDÁVEL. O Front Door não reconhece o back-end como disponível. O arquivo é criado pela Terraform e deve estar presente após a implantação da infraestrutura. |
| Hub de Eventos | Os relatórios de integridade dos Hubs de Eventos são manipulados pelo EventHubProducerService. Este serviço reporta a integridade se for capaz de enviar uma nova mensagem para Hubs de Eventos. Para filtragem, esta mensagem tem uma propriedade de identificação adicionada a ela: HEALTHCHECK=TRUE Esta mensagem é ignorada na extremidade recetora. A AlwaysOn.BackgroundProcessor.EventHubProcessorService.ProcessEventHandlerAsync() definição de configuração verifica a HEALTHCHECK propriedade. |
| BD do Cosmos para o Azure | Os relatórios de integridade do CosmosDbServiceAzure Cosmos DB são manipulados pelo , 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 escrever um documento de teste no banco de dados. O documento de teste tem um curto conjunto de tempo de vida, o Azure Cosmos DB o remove automaticamente. O HealthService executa duas sondas separadas. 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 acionado. |
Consultas do Azure Cosmos DB
Para a consulta Somente leitura, está sendo usada a seguinte consulta, 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);
Monitorização
O Azure Log Analytics é usado como o repositório central de logs e métricas para todos os componentes de aplicativo e infraestrutura. O Azure Application Insights é usado para todos os dados de monitoramento de aplicativos. Cada carimbo na infraestrutura tem um espaço de trabalho dedicado do Log Analytics e uma instância do Application Insights. Um espaço de trabalho separado do Log Analytics é usado para os recursos compartilhados globalmente, como Front Door e Azure Cosmos DB.
Todos os selos são de curta duração e continuamente substituídos a cada novo lançamento. Os espaços de trabalho do Log Analytics por carimbo são implantados como um recurso global em um grupo de recursos de monitoramento separado como os recursos do Log Analytics de carimbo . Esses recursos não compartilham o ciclo de vida de um selo.
Para obter mais informações, consulte Coletor de dados unificado para análise correlacionada.
Monitorização: Fontes de dados
Configurações de diagnóstico: todos os serviços do Azure usados para o Azure Mission-Critical são configurados para enviar todos os seus dados de diagnóstico, incluindo logs e métricas, para o espaço de trabalho do Log Analytics específico da implantação (global ou de carimbo). Este 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 Kubernetes do Azure (AKS) para o Log Analytics. O AKS está configurado para usar o Container Insights. O Container Insights implanta o OMSAgentForLinus por meio de um DaemonSet Kubernetes em cada nó nos clusters AKS. O OMSAgentForLinux é capaz de coletar logs e métricas extras de dentro do cluster Kubernetes e enviá-los para seu espaço de trabalho correspondente do Log Analytics. 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 informações 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 raspagem do Prometheus. A raspagem do Prometheus configura o OMSAgentForLinux para coletar 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 selos 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 são usados para monitorar a disponibilidade dos selos. Esses testes visam diretamente os clusters e as contas de armazenamento estático dos selos. Para chamar os pontos de entrada dos clusters diretamente, as solicitações precisam ter o cabeçalho de ID da porta frontal correto, 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 são 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 página inicial do site.
Monitoramento: Consultas
O Azure Mission-Critical usa diferentes consultas KQL (Kusto Query Language) para implementar consultas personalizadas como funções para recuperar dados do Log Analytics. 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 do Log Analytics são chamadas diretamente do código, por exemplo, da API HealthService. 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 do Log Analytics, usamos o Grafana em nossa implementação de referência. O Grafana é usado para mostrar os resultados das consultas do Log Analytics 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 obter mais informações, consulte 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 levantem atenção imediata aos 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 insalubre/vermelho. Ao definir o alerta para o nó raiz do Modelo de Integridade, o operador está imediatamente ciente de qualquer efeito de nível de negócios no estado da solução: Afinal, esse nó raiz ficará amarelo ou vermelho se qualquer um dos fluxos de usuários ou recursos 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, consulte Resposta automatizada a incidentes.
Análise de falhas
Compor a análise de falhas é, na sua maioria, um exercício de planeamento teórico. Este exercício teórico deve ser usado como entrada para as injeções automáticas de falhas 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 | Indisponibilidade |
|---|---|---|---|
| Microsoft Entra ID | Microsoft Entra ID torna-se indisponível. | Atualmente, não existe qualquer atenuação possível. Uma abordagem de várias regiões não mitigará interrupções, pois é um serviço global. Este serviço é uma dependência difícil. O Microsoft Entra ID é usado para operações de 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 desovar. 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 |
| Azure DNS | O DNS do Azure torna-se indisponível e a resolução de DNS falha. | Se o DNS do Azure ficar indisponível, a resolução DNS para solicitações de usuário e entre diferentes componentes do aplicativo provavelmente falhará. Atualmente, não há mitigação possível em vigor para este cenário. Uma abordagem de várias regiões não mitigará interrupções, pois é um serviço global. O DNS do Azure é uma dependência difícil. Serviços DNS externos como backup não ajudariam, já que todos os componentes 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. | Total |
| Porta da frente | Interrupção geral da porta da frente. | Se a porta da frente cair completamente, não há mitigação. Este serviço é uma dependência difícil. | Sim |
| Porta da frente | Erros de configuração de roteamento/frontend/backend. | Pode acontecer devido a incompatibilidade na configuração durante a implantação. Deve ser apanhado em fases de teste. A configuração de frontend com DNS é específica para cada ambiente. Atenuaçã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. | Total |
| Porta da frente | O certificado TLS/SSL gerenciado é excluído. | Pode acontecer devido a incompatibilidade na configuração durante a implantação. Deve ser apanhado em fases de teste. Tecnicamente, o site ainda funcionaria, mas erros de certificado TLS/SSL impedirão os usuários de acessá-lo. Mitigação: a reemissão do certificado pode levar cerca de 20 minutos, além de corrigir e executar novamente o pipeline. | Total |
| BD do Cosmos para o Azure | O banco de dados/coleção é renomeado. | Pode acontecer devido a incompatibilidade na configuração durante a implantaçã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/coleta. O aplicativo não poderá acessar nenhum dado. A configuração do aplicativo precisa ser atualizada e os pods reiniciados. | Sim |
| BD do Cosmos para o Azure | Interrupção regional | O Azure Mission-Critical tem gravações em 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 permanentemente encaminhadas para a próxima região por ordem de preferência. Caso a lista de preferências tenha uma entrada (ou estivesse vazia), mas a conta tenha outras regiões disponíveis, ela será encaminhada para a próxima região na lista de contas. | Não |
| BD do Cosmos para o Azure | Limitação extensiva devido à falta de RUs. | Dependendo do número de RUs e do balanceamento de carga empregado no nível da Porta da Frente, certos carimbos podem ficar quentes 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 |
| BD do Cosmos para o Azure | 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 "Chave de partição atingiu o tamanho máximo". | Parcial (gravações de banco de dados desabilitadas) |
| Azure Container Registry | 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 automaticamente redirecionada para outra região. Na pior das hipóteses, as imagens do Docker não podem ser extraídas por alguns minutos pelos nós AKS enquanto o failover de DNS acontece. | Não |
| Azure Container Registry | Imagem(ns) apagada(s) | Nenhuma imagem pode ser puxada. Essa interrupção deve afetar apenas os nós recém-gerados/reinicializados. Os nós existentes devem ter as imagens armazenadas em cache. **Mitigação: Se detetado rapidamente, a reexecução dos pipelines de compilação mais recentes deve trazer as imagens de volta para o registro. | Não |
| Azure Container Registry | 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: Puxar 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 ACR SKU. | Não |
| Azure Kubernetes Service | Falha na atualização do cluster | As atualizações do nó AKS devem ocorrer em momentos diferentes nos selos. 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 |
| Azure Kubernetes Service | O pod de aplicação é morto ao atender a solicitação. | Isso pode resultar em erros enfrentados pelo usuário final e má experiência do usuário. Mitigação: o Kubernetes por padrão remove pods de forma graciosa. Os pods são removidos dos serviços primeiro e a carga de trabalho recebe um SIGTERM com um período de carência para concluir solicitações abertas e gravar dados antes de terminar. O código do aplicativo precisa entender o SIGTERM e o período de carência pode precisar ser ajustado se a carga de trabalho demorar mais para ser desligada. | Não |
| Azure Kubernetes Service | Capacidade de computação indisponível na região para adicionar mais nós. | As operações de expansão/redução falharão, mas não devem afetar os nós existentes e sua operação. Idealmente, o tráfego deve mudar automaticamente para outras regiões para balanceamento de carga. | Não |
| Azure Kubernetes Service | A assinatura atinge a cota principal da CPU para adicionar novos nós. | As operações de expansão/redução falharão, mas não devem afetar os nós existentes e sua operação. Idealmente, o tráfego deve mudar automaticamente para outras regiões para balanceamento de carga. | Não |
| Azure Kubernetes Service | Vamos criptografar certificados TLS/SSL que não podem ser emitidos/renovados. | Cluster deve relatar insalubridade em direção à porta da frente e o tráfego deve mudar para outros selos. Atenuação: investigue a causa raiz do problema/falha de renovação. | Não |
| Azure Kubernetes Service | Quando as solicitações/limites de recursos são configurados incorretamente, os pods podem atingir 100% de utilização da CPU e falhar solicitações. O mecanismo de repetição do aplicativo deve ser capaz de recuperar solicitações com falha. Repetições podem causar uma maior duração da solicitação, sem revelar o erro para o cliente. A carga excessiva acabará por causar falhas. | Não (se a carga não for excessiva) | |
| Azure Kubernetes Service | Imagens de contêiner de 3ª parte / 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 está armazenada em cache) podem não ser capazes de iniciar. Possível atenuação: em alguns cenários, pode fazer sentido importar imagens de contêiner de terceiros para o registro de contêiner por solução. Isto acrescenta complexidade adicional e deve ser planeado e operacionalizado cuidadosamente. | Parcialmente (durante operações de dimensionamento e atualização/atualização) |
| Hub de Eventos | Não é possível enviar mensagens para os Hubs de Eventos | O carimbo torna-se inutilizável para operações de escrita. O serviço de saúde deve detetar automaticamente isso e tirar o carimbo do rodízio. | Não |
| Hub de Eventos | As mensagens não podem ser lidas pelo BackgroundProcessor | As mensagens ficarão na fila. As mensagens não devem se perder, pois persistem. Atualmente, esta falha não é coberta pelo Serviço de Saúde. Deve haver monitoramento/alerta no trabalhador para detetar erros na leitura de mensagens. Atenuação: O carimbo deve ser desativado manualmente até que o problema seja corrigido. | Não |
| Conta de armazenamento | A conta de armazenamento torna-se inutilizável pelo trabalhador para o apontamento de verificação dos Hubs de Eventos | O carimbo não processará mensagens dos Hubs de Eventos. A conta de armazenamento também é usada pelo HealthService. Espera-se que problemas com o armazenamento sejam detetados pelo Serviço de Saúde e o carimbo seja retirado do rodízio. Pode-se esperar que outros serviços no selo sejam afetados simultaneamente. | Não |
| Conta de armazenamento | O site estático encontra problemas. | Se o serviço do site estático encontrar problemas, essa falha deve ser detetada pelo Front Door. O tráfego não será enviado para esta conta de armazenamento. O cache na Front Door também pode aliviar esse problema. | Não |
| Key Vault | Cofre de chaves indisponível para GetSecret operações. |
No início dos novos pods, o driver AKS CSI buscará todos os segredos do Key Vault e falhará. Os pods não poderão ser iniciados. Atualmente, há uma atualização automática a cada 5 minutos. A atualização falhará. Os erros devem aparecer, kubectl describe pod mas o pod continua funcionando. |
Não |
| Key Vault | Cofre de chaves indisponível para GetSecret ou SetSecret operações. |
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 Key Vault 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 selo. Possível atenuação: diminua ainda mais a frequência de atualização ou desative-a completamente. | Não |
| Aplicação | Configuração incorreta | Cadeias de conexão incorretas ou segredos injetados no aplicativo. Deve ser atenuado pela implantação automatizada (o pipeline lida com a configuração automaticamente) e pela distribuição azul-verde das atualizações. | Não |
| Aplicação | Credenciais expiradas (recurso de carimbo) | Se, por exemplo, o token SAS do hub de eventos ou a chave da conta de armazenamento foram alterados sem atualizá-los corretamente no Cofre da Chave para que os pods possam usá-los, o respetivo componente do aplicativo falhará. Esta falha deve então afetar o Serviço de Saúde, e o carimbo deve ser retirado do rodízio automaticamente. Atenuação: use a autenticação baseada em ID do Microsoft Entra para todos os serviços que a suportam. O AKS requer que os pods se autentiquem usando o ID de carga de trabalho do Microsoft Entra (visualização). O uso de 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 |
| Aplicação | Credenciais expiradas (recurso compartilhado globalmente) | Se, por exemplo, a chave da API do Azure Cosmos DB foi alterada sem atualizá-la corretamente em todos os Cofres de Chaves de carimbo para que os pods possam usá-los, os respetivos 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. | Total |
| 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óximos passos
Implante a implementação de referência para obter uma compreensão completa dos recursos e sua configuração usados nessa arquitetura.