Implantação azul-verde de clusters do AKS

AKS (Serviço de Kubernetes do Azure)

Gateway de Aplicativo do Azure

Registro de Contêiner do Azure

Porta da frente do Azure

DNS do Azure

Este artigo fornece orientação sobre como implementar uma estratégia de implantação azul-verde para testar uma nova versão de um cluster do Serviço de Kubernetes do Azure (AKS) enquanto continua a executar a versão atual. Depois que a nova versão é validada, uma alteração de roteamento alterna o tráfego do usuário para ela. A implantação dessa forma aumenta a disponibilidade ao fazer alterações, incluindo atualizações, em clusters do AKS. Este artigo descreve o design e a implementação de uma implantação azul-verde do AKS que usa serviços gerenciados do Azure e recursos nativos do Kubernetes.

Arquitetura

Esta seção descreve arquiteturas para implantação azul-verde de clusters do AKS. Existem dois casos:

Os aplicativos e APIs são voltados para o público.
Os aplicativos e APIs são para uso privado.

Há também um caso híbrido, não discutido aqui, em que há uma mistura de aplicativos e APIs voltados para o público e para uso privado no cluster.

O diagrama a seguir mostra a arquitetura do caso voltado para o público:

Baixe um Arquivo Visio dessa arquitetura.

O Azure Front Door e o DNS do Azure fornecem o mecanismo de roteamento que alterna o tráfego entre os clusters azul e verde. Para obter mais informações, consulte Implantação azul-verde com o Azure Front Door. Usando o Azure Front Door, é possível implementar um switch completo ou um switch mais controlado com base em pesos. Essa técnica é a mais confiável e eficiente em um ambiente do Azure. Se você quiser usar seu próprio DNS e balanceador de carga, precisa garantir que estão configurados para fornecer um switch seguro e confiável.

O Gateway de Aplicativo do Azure fornece os front-ends, que são dedicados aos pontos de extremidade públicos.

Este diagrama é para uso privado:

Baixe um Arquivo Visio dessa arquitetura.

Para esse caso, uma única instância do DNS do Azure implementa a alternância de tráfego entre os clusters azul e verde. Isso é feito usando os registros A e CNAME. Para obter detalhes, consulte a seção T3: Alternar o tráfego para o cluster verde.

O Gateway de Aplicativo fornece os front-ends, que são dedicados aos pontos de extremidade privados.

Workflow

Em uma implantação azul-verde, há cinco estágios para atualizar a versão atual do cluster para a nova versão. Na nossa descrição, o cluster azul é a versão atual e o cluster verde é a nova.

As etapas são:

T0: O cluster azul está ativado.
T1: Implante o cluster verde.
T2: Sincronize o estado do Kubernetes entre os clusters azul e verde.
T3: Alterne o tráfego para o cluster verde.
T4: Destrua o cluster azul.

Quando a nova versão estiver no ar, ele se torna o cluster azul para qualquer mudança ou atualização que venha a seguir.

Os clusters azul e verde funcionam ao mesmo tempo, mas apenas por um período limitado, o que otimiza custos e esforços operacionais.

Gatilhos de transição

Os gatilhos da transição de estágio podem ser automatizados. Até que isso aconteça, alguns ou todos os gatilhos serão manuais. Os gatilhos estão relacionados a:

Métricas específicas de carga de trabalho, SLOs (objetivos de nível de serviço) e contratos de nível de serviço (SLAs): são usados principalmente no estágio T3 para validar o estado geral do cluster do AKS antes de alternar o tráfego.
Métricas da plataforma do Azure: são usadas para avaliar o status e a integridade das cargas de trabalho e do cluster do AKS. São utilizadas em todas as transições.

Capacidade de descoberta de rede dos clusters

Você pode fornecer a capacidade de descoberta de rede para os clusters das seguintes maneiras:

Tenha registros DNS que apontem para os clusters. Por exemplo:
- aks-blue.contoso.com aponta para o IP privado ou público do cluster azul.
- aks-green.contoso.com aponta para o IP privado ou público do cluster verde.
Em seguida, você pode usar esses nomes de host diretamente ou na configuração do pool de back-end do gateway de aplicativo que está na frente de cada cluster.
Tenha registros DNS que apontem para os gateways de aplicativo. Por exemplo:
- aks-blue.contoso.com aponta para o IP privado ou público do gateway de aplicativo, que tem como pool de back-end o IP privado ou público do cluster azul.
- aks-green.contoso.com aponta para o IP privado ou público do gateway de aplicativo, que tem como pool de back-end o IP privado ou público do cluster verde.

T0: O cluster azul está ativado

O estágio inicial, T0, tem o cluster azul ativo. Este estágio prepara a nova versão do cluster para implantação.

A condição de gatilho para o estágio T1 é o lançamento de uma nova versão do cluster, o cluster verde.

T1: Implante o cluster verde

Nesta etapa, inicia-se a implantação do novo cluster verde. O cluster azul permanece ligado, e o tráfego ao vivo ainda é roteado para ele.

O gatilho para passar para o estágio T2 é a validação do cluster do AKS verde no nível da plataforma. A validação usa métricas do Azure Monitor e comandos da CLI para verificar a integridade da implantação. Para obter mais informações, consulte as referências Monitoramento do Serviço de Kubernetes do Azure (AKS) e Monitoramento dos dados do AKS.

O monitoramento do AKS pode ser dividido em diferentes níveis, como mostrado no diagrama a seguir:

A integridade do cluster é avaliada nos níveis 1 e 2 e em alguns do nível 3. Para o nível 1, você pode usar a exibição multicluster nativa do Monitor para validar a integridade, conforme mostrado aqui:

No nível 2, garanta que o servidor de API do Kubernetes e o Kubelet funcionem corretamente. Você pode usar a pasta de trabalho Kubelet no Monitor, especificamente, as duas grades da pasta de trabalho que mostram as principais estatísticas operacionais dos nós:

A visão geral por grade de nós resume a operação total, os erros totais e as operações bem-sucedidas por porcentagem e tendência para cada nó.
A grade de visão geral por tipo de operação fornece, para cada tipo de operação, o número de operações, erros e operações bem-sucedidas por porcentagem e tendência.

O nível 3 é dedicado aos objetos e aplicativos do Kubernetes que são implantados por padrão no AKS, como omsagent, kube-proxy e assim por diante. Para essa verificação, você pode usar a visualização Insights do Monitor para verificar o status das implantações do AKS:

Como alternativa, você pode usar a pasta de trabalho dedicada documentada em Métricas de HPA e de implantação com insights de contêiner. Veja um exemplo:

Depois que a validação for bem-sucedida, você poderá fazer a transição para o estágio T2.

T2: Sincronize o estado do Kubernetes entre os clusters azul e verde.

Neste estágio, aplicativos, operadores e recursos do Kubernetes ainda não estão implantados no cluster verde, ou pelo menos nem todos eles são aplicáveis e são implantados quando o cluster do AKS é provisionado. O objetivo final deste estágio é que, no final da sincronização, o cluster verde seja compatível com o azul. Nesse caso, é possível validar o status do novo cluster antes de alternar o tráfego para o cluster verde.

Há várias maneiras de sincronizar o estado do Kubernetes entre clusters:

Reimplantação via integração e entrega contínua (CI/CD). Normalmente, basta usar os mesmos pipelines de CI/CD que são usados para a implantação normal dos aplicativos. As ferramentas comuns para fazer isso são: GitHub Actions, Azure DevOps e Jenkins.
GitOps, com soluções que são divulgadas no site da Cloud Native Computing Foundation (CNCF), como Flux e ArgoCD.
Uma solução personalizada que armazena as configurações e os recursos do Kubernetes em um armazenamento de dados. Normalmente, essas soluções são baseadas em geradores de manifesto do Kubernetes que começam a partir de definições de metadados e, em seguida, armazenam os manifestos gerados do Kubernetes em um armazenamento de dados como o Azure Cosmos DB. Essas geralmente são soluções personalizadas baseadas na estrutura de descrição do aplicativo que está em uso.

O diagrama a seguir mostra o processo de sincronização do estado do Kubernetes:

Normalmente, durante a sincronização, a implantação de novas versões de aplicativos não é permitida no cluster ativo. Esse período de tempo começa com a sincronização e termina quando a mudança para o cluster verde é concluída. A maneira de desabilitar implantações no Kubernetes pode variar. As duas soluções possíveis são:

Desativar os pipelines de implantação.
Desativar a conta de serviço do Kubernetes que executa implantações.

É possível automatizar a desativação da conta de serviço usando o Open Policy Agent (OPA). Ainda não é possível usar os recursos nativos do AKS para isso porque eles ainda estão em versão prévia.

O período de sincronização pode ser evitado usando mecanismos avançados que gerenciam o estado do Kubernetes em vários clusters.

Quando a sincronização for concluída, a validação do cluster e dos aplicativos será necessária. Isso inclui:

Uma verificação das plataformas de monitoramento e registro para validar a integridade do cluster. Você pode considerar replicar as ações do estágio T1: implantar o estágio de cluster.
Teste funcional do aplicativo com base na cadeia de ferramentas que está em uso no momento.

Recomendamos que você também execute uma sessão de teste de carga para comparar o desempenho dos aplicativos de cluster verde com uma linha de base de desempenho. Você pode usar sua ferramenta preferida ou o Teste de Carga do Azure.

Normalmente, o cluster verde é exposto no gateway de aplicativo ou no balanceador de carga externo com uma URL interna que não é visível para usuários externos.

Quando o novo cluster é validado, você pode prosseguir para o próximo estágio para alternar o tráfego para o novo cluster.

T3: Alterne o tráfego para o cluster verde

Depois que a sincronização for concluída e o cluster verde for validado nos níveis de plataforma e aplicativo, ele poderá para ser promovido a cluster primário e começar a receber o tráfego ao vivo. A alternância é executada no nível de rede. Muitas vezes, as cargas de trabalho são sem estado. No entanto, se as cargas de trabalho estiverem com estado, uma solução adicional deverá ser implementada para manter o estado e o armazenamento em cache durante a alternância.

Aqui está um diagrama que mostra o estado de destino depois que a opção é aplicada:

As técnicas descritas neste artigo implementam alternâncias completas: 100% do tráfego é roteado para o novo cluster. Isso ocorre porque o roteamento é aplicado no nível DNS com uma atribuição de registro A ou CNAME atualizada para apontar para o cluster verde, e há um gateway de aplicativo para cada cluster.

Aqui está um exemplo de configuração para alternar pontos de extremidade para uso privado. A solução proposta usa registros A para fazer a troca. De uma perspectiva de mapeamento de DNS e IP, a situação é a seguinte antes da mudança:

A registro aks.priv.contoso.com aponta para o IP privado do gateway de aplicativo azul.
A registro aks-blue.priv.contoso.com aponta para o IP privado do gateway de aplicativo azul.
A registro aks-green.priv.contoso.com aponta para o IP privado do gateway de aplicativo verde.

A opção é reconfigurada para o seguinte:

A registro aks.priv.contoso.com aponta para o IP privado do gateway de aplicativo verde.
A registro aks-blue.priv.contoso.com aponta para o IP privado do gateway de aplicativo azul.
A registro aks-green.priv.contoso.com aponta para o IP privado do gateway de aplicativo verde.

Os usuários dos clusters verão a opção após a vida útil (TTL) e a propagação DNS dos registros.

Para pontos de extremidade voltados para o público, a abordagem recomendada usa o Azure Front Door e o DNS do Azure. Aqui está a configuração antes da mudança:

CNAME registro official-aks.contoso.com aponta para um registro do domínio do Azure Front Door gerado automaticamente. Para saber mais, confira Tutorial: Adicionar um domínio personalizado ao seu Front Door.
A registro aks.contoso.com aponta para o IP público do gateway de aplicativo azul.
A configuração de origem do Azure Front Door aponta para o nome do host aks.contoso.com. Para obter mais informações sobre como configurar os pools de back-end, consulte Origens e grupos de origem no Azure Front Door.
- A registro aks-blue.contoso.com aponta para o IP público do gateway de aplicativo azul.
- A registro aks-green.contoso.com aponta para o IP público do gateway de aplicativo verde.

A opção é reconfigurada para o seguinte:

CNAME registro official-aks.contoso.com aponta para um registro do domínio do Azure Front Door gerado automaticamente.
A registro aks.contoso.com aponta para o IP público do gateway de aplicativo verde.
A configuração de origem do Azure Front Door aponta para o nome do host aks.contoso.com.
- A registro aks-blue.contoso.com aponta para o IP público do gateway de aplicativo azul.
- A registro aks-green.contoso.com aponta para o IP público do gateway de aplicativo verde.

Técnicas de comutação alternativas, como comutadores parciais para versões canárias, são possíveis com serviços adicionais do Azure, como o Azure Front Door ou o Gerenciador de Tráfego. Para obter uma implementação de uma alternância de tráfego azul-verde no nível do Azure Front Door, consulte Implantação azul-verde com o Azure Front Door.

Conforme descrito no exemplo, de uma perspectiva de rede, essa técnica é baseada na definição de quatro nomes de host:

Nome oficial do host voltado para o público: o nome oficial do host público que é usado por usuários finais e consumidores.
Nome do host do cluster: o nome oficial do host usado pelos consumidores das cargas de trabalho hospedadas nos clusters.
Nome do host do cluster azul: o nome do host dedicado para o cluster azul.
Nome do host do cluster verde: o nome do host dedicado para o cluster verde.

O nome do host do cluster é aquele configurado no nível do gateway de aplicativo para gerenciar o tráfego de entrada. O nome do host também faz parte da configuração de entrada do AKS para gerenciar o Transport Layer Security (TLS) corretamente. Esse host é usado apenas para transações e solicitações em tempo real.

Se o Azure Front Door também fizer parte da implantação, ele não será afetado pelo switch, pois gerencia apenas o nome oficial do host do cluster. Ele fornece a abstração adequada para os usuários do aplicativo, que não são afetados pela opção, porque o registro CNAME DNS sempre aponta para o Azure Front Door.

Os nomes de host de cluster azul e verde são usados principalmente para testar e validar os clusters. Para esses fins, os nomes de host são expostos no nível do gateway de aplicativo com pontos de extremidade dedicados e também no nível do controlador de entrada do AKS para gerenciar o TLS corretamente.

Nesta etapa, a validação é baseada nas métricas de monitoramento de infraestrutura e aplicativos e em SLO e SLA oficiais, quando disponíveis. Se a validação for bem-sucedida, faça a transição para o estágio final para destruir o cluster azul.

T4: Destrua o cluster azul

Mudar o tráfego com sucesso nos leva ao estágio final, no qual ainda está acontecendo a validação e o monitoramento para garantir que o cluster verde funcione conforme o esperado com o tráfego ao vivo. A validação e o monitoramento abrangem tanto o nível da plataforma quanto o nível do aplicativo.

Depois que essa validação for concluída, o cluster azul poderá ser destruído. A destruição é uma etapa altamente recomendada para reduzir custos e fazer uso adequado da elasticidade que o Azure fornece, particularmente o AKS.

Aqui está a situação depois que o cluster azul é destruído:

Componentes

O Gateway de Aplicativo é um balanceador de carga de tráfego da Web (camada 7 OSI) que permite que você gerencie o tráfego para seus aplicativos Web. Nesta solução, ele é usado como gateway para tráfego HTTP para acessar os clusters AKS.
O AKS (Serviço de Kubernetes do Azure) é um serviço de Kubernetes gerenciado que você pode usar para implantar e gerenciar aplicativos conteinerizados. Esta plataforma de aplicação é o principal componente deste padrão.
O Registro de Contêiner do Azure é um serviço gerenciado usado para armazenar e gerenciar imagens de contêiner e artefatos relacionados. Nesta solução é usado para armazenar e distribuir imagens de contêiner e artefatos, como gráficos Helm, nos clusters AKS.
O Azure Monitor é uma solução de monitoramento para coletar, analisar e responder à dados de monitoramento dos seus ambientes de nuvem e no local. Ele fornece os principais recursos de monitoramento necessários para executar a implantação verde azul. É usado nesta arquitetura devido à sua integração com o AKS e sua capacidade de fornecer recursos de registro, monitoramento e alerta que podem ser usados para gerenciar as transições de estágio.
O Cofre de Chaves do Azure ajuda a resolver os seguintes problemas:Gerenciamento de Segredos, Gerenciamento de Chaves e Gerenciamento de Certificados; ele é usado para armazenar e gerenciar os segredos e certificados necessários no nível de plataforma e aplicativo para esta solução.
O Azure Front Door é um balanceador de carga global e um sistema de gerenciamento de ponto de extremidade de aplicativo. Ele é usado nesta solução como o ponto de extremidade público para aplicativos HTTP hospedados no AKS. Nesta solução, ele tem a responsabilidade crítica de gerenciar a mudança de tráfego entre os gateways de aplicativo azul e verde.
O DNS do Azure é um serviço de hospedagem para domínios DNS que fornece a resolução de nomes usando a infraestrutura do Microsoft Azure. Ele gerencia os nomes de host usados na solução para clusters azul e verde e desempenha um papel importante nas opções de tráfego, especialmente para pontos de extremidade privados.

Alternativas

Existem técnicas alternativas para implementar os interruptores de tráfego que podem fornecer mais controle. Por exemplo, é possível fazer uma mudança parcial usando regras de tráfego baseadas em um ou mais dos seguintes:
- Porcentagem de tráfego de entrada
- Cabeçalhos HTTP
- Cookies
Outra alternativa que fornece maior proteção contra problemas causados por alterações é ter implantações baseadas em anel. Em vez de apenas aglomerados azuis e verdes, é possível ter mais clusters, chamados de anéis. Cada anel tem o tamanho suficiente para suportar o número de usuários que têm acesso à nova versão do AKS. Quanto à implantação azul-verde descrita aqui, os anéis podem ser removidos para ter a otimização e o controle de custo adequados.
Possíveis alternativas ao Gateway de Aplicativo são NGINX e HAProxy.
Uma possível alternativa ao Registro de Contêiner é o Harbor.
Em algumas circunstâncias, é possível usar diferentes serviços de DNS e balanceamento de carga para fazer as alternâncias de tráfego, em vez do Azure Front Door e do DNS do Azure.
Esta solução é baseada nas APIs Kubernetes do controlador de entrada padrão. Se sua solução se beneficiar da API do Gateway, então use o Gateway de Aplicativo para Containers. Ele pode ajudar a gerenciar o balanceamento de carga e lidar com o gerenciamento de tráfego de entrada entre o Gateway de Aplicativo e os pods. O Gateway de Aplicativo para Containers controla as configurações dos gateways de aplicativo.

Detalhes do cenário

Os benefícios principais da solução são:

Tempo de inatividade minimizado durante a implantação.
Estratégia de reversão planejada.
Melhor controle e operações durante o lançamento e implantação de alterações e atualizações do AKS.
Teste da necessidade de executar procedimentos de recuperação de desastres (DR).

Os princípios-chave e os aspectos fundamentais da implantação azul-verde são discutidos nestes artigos:

Do ponto de vista da automação e CI/CD, a solução pode ser implementada de várias maneiras. Nossa sugestão:

Bicep ou Terraform for IaC.
Pipelines do Azure ou GitHub Actions para CI/CD.

Possíveis casos de uso

A implantação azul-verde possibilita fazer alterações em clusters sem afetar os aplicativos e cargas de trabalho em execução. Exemplos de mudanças são:

Mudanças operacionais
Ativar novos recursos do AKS
Alterações em recursos compartilhados nos clusters
Atualizar a versão do Kubernetes
Modificar os recursos e objetos do Kubernetes, como o gateway de entrada, a malha de serviço, operadores, políticas de rede e assim por diante
Reverter para a versão anterior de um cluster do AKS que ainda está implantado, sem afetar as cargas de trabalho em execução no cluster

Considerações

Estas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios de orientação que podem ser usados para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.

A implantação azul-verde pode ser totalmente automatizada, como uma implantação sem toque. Normalmente, uma implementação inicial possui gatilhos manuais para ativar as etapas. Ao longo do caminho e com os recursos adequados de maturidade e monitoramento, é possível automatizar os gatilhos. Isso significa que há testes automatizados e métricas específicas, SLA e SLO para automatizar os gatilhos.
É importante ter nomes de host dedicados para os clusters azul e verde e também ter configurações de ponto de extremidade dedicadas nos gateways e balanceadores de carga que estão na frente dos clusters. Isso é fundamental para melhorar a confiabilidade e validade da implantação do novo cluster. Dessa forma, a validação da implantação acontece com a mesma arquitetura e configurações de um cluster de produção padrão.
Considere uma situação em que os clusters do AKS são recursos compartilhados para vários aplicativos gerenciados por unidades de negócios diferentes. Nesses casos, é comum que a própria plataforma do AKS seja gerenciada por uma equipe dedicada responsável pela operação geral e pelo ciclo de vida dos clusters e que haja pontos de extremidade nos clusters para fins de administração e operações. Sugerimos que esses pontos de extremidade tenham um controlador de entrada dedicado nos clusters do AKS para separação adequada de preocupações e confiabilidade.
A implantação azul-verde é útil para implementar e testar soluções de continuidade de negócios e recuperação de desastres (BC/DR) para AKS e cargas de trabalho relacionadas. Em particular, fornece as estruturas fundamentais para gerenciar vários clusters, incluindo casos em que os clusters estão espalhados entre várias regiões.
O sucesso com a implantação azul-verde depende da aplicação de todos os aspectos da implementação, como automação, monitoramento e validação, não apenas à plataforma do AKS, mas também às cargas de trabalho e aplicativos que são implantados na plataforma. Isso ajuda você a obter o máximo benefício da implantação azul-verde.
Na solução proposta existem dois Gateways de Aplicativo por cada cenário, público e privado, portanto, no total quatro. Essa decisão é aplicar a implantação verde azul no nível do Gateway de Aplicativo do Azure para evitar tempo de inatividade causado por configuração incorreta dos gateways. A principal desvantagem dessa decisão é o custo, já que existem quatro instâncias do Gateway de Aplicativo. Eles são executados em paralelo somente no período de tempo em que há alterações relevantes nas configurações do Gateway de Aplicativo, como políticas WAF ou uma configuração de dimensionamento. Para otimização adicional de custos, você pode optar por um único Gateway de Aplicativo por cada cenário, isso significa dois Gateways de Aplicativo no total. Isso exigirá que você mova a lógica azul/verde para o gateway de aplicativo, em vez do Azure Front Door. Portanto, em vez de o Azure Front Door ser imperativamente controlado, o Gateway de Aplicativo é.

Confiabilidade

A confiabilidade garante que seu aplicativo possa cumprir os compromissos que você deve assumir com seus clientes. Para obter mais informações, confira Visão geral do pilar de confiabilidade.

A implantação azul-verde tem um efeito direto e positivo na disponibilidade da plataforma do AKS e das cargas de trabalho. Em particular, isso aumenta a disponibilidade durante a implantação de mudanças na plataforma do AKS. Haverá pouco tempo de inatividade se as sessões do usuário forem bem gerenciadas.
A implantação azul-verde fornece cobertura para confiabilidade durante a implantação porque, por padrão, há a opção de reverter para a versão anterior do cluster do AKS se algo der errado na nova versão do cluster.

Otimização de custo

A otimização de custos consiste em buscar maneiras de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, confira Visão geral do pilar de otimização de custo.

A implantação azul-verde é amplamente adotada no Azure devido à elasticidade nativa fornecida pela nuvem. Isso possibilita a otimização de custos em termos de operações e consumo de recursos. A maior parte da economia resulta da remoção do cluster que não é mais necessário após a implantação bem-sucedida de uma nova versão do cluster.
Quando uma nova versão é implantada, é comum hospedar os clusters azul e verde na mesma sub-rede, para continuar a ter a mesma referência de custo. Todas as conexões de rede e acesso aos recursos e serviços são iguais para os dois clusters, e todos os serviços e recursos do Azure permanecem os mesmos.

Excelência operacional

A excelência operacional abrange os processos de operações que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, confira Visão geral do pilar de excelência operacional.

A implantação azul-verde, implementada corretamente, fornece automação, entrega contínua e implantação resiliente.
Um dos principais aspectos da entrega contínua é que ela fornece iterativamente incrementos de mudanças de plataforma e carga de trabalho. Com a implantação azul-verde do AKS, você alcança a entrega contínua no nível da plataforma, de forma controlada e segura.
A resiliência é fundamental para a implantação azul-verde, pois inclui a opção de reverter para o cluster anterior.
A implantação azul-verde fornece o nível adequado de automação para reduzir o esforço relacionado à estratégia de continuidade de negócios.
Monitorar a plataforma e os aplicativos é crucial para uma implementação bem-sucedida. Para a plataforma, é possível usar os recursos nativos de monitoramento do Azure. Para os aplicativos, o monitoramento precisa ser projetado e implementado.

Implantar este cenário

Para obter um exemplo implementado de uma implantação azul-verde descrita neste guia, consulte Acelerador de zona de destino do AKS.

Essa implementação de referência é baseada no Gateway de Aplicativo e no Acelerador de zona de destino do AKS (AGIC). Cada cluster tem seu próprio gateway de aplicativo e a troca de tráfego é feita via DNS, em particular via configuração CNAME.

Importante

Para cargas de trabalho de missão crítica, é importante combinar implantações azul/verde, conforme descrito neste guia, com automação de implantação e validação contínua para alcançar implantações de tempo de inatividade zero. Mais informações e orientações estão disponíveis na metodologia de projeto de missão crítica.

Considerações sobre as regiões

Você pode implantar os clusters azul e verde em regiões separadas ou na mesma região. Os princípios de design e operação não são afetados por essa escolha. No entanto, certos tipos de configurações de rede adicionais podem ser afetados, como:

Uma rede virtual dedicada e uma sub-rede para AKS e o gateway de aplicativo.
Conexão com serviços de suporte como Monitor, Registro de Contêiner e Cofre de Chaves.
Visibilidade do Azure Front Door do gateway de aplicativo.

Há pré-requisitos para implantar na mesma região:

As redes virtuais e sub-redes devem ser dimensionadas para hospedar dois clusters.
A assinatura do Azure deve fornecer capacidade suficiente para os dois clusters.

Implantação do controlador de entrada e balanceadores de carga externos

Existem diferentes abordagens para a implantação do controlador de entrada e dos balanceadores de carga externos:

Você pode ter um único controlador de entrada com um balanceador de carga externo dedicado como a implementação de referência da arquitetura descrita neste guia. AGIC é um aplicativo Kubernetes que possibilita usar o balanceador de carga do Gateway de Aplicativo L7 para expor o software em nuvem à Internet. Em determinados cenários, há pontos de extremidade de administração nos clusters do AKS, além dos pontos de extremidade do aplicativo. Os pontos de extremidade de administração são para executar tarefas operacionais nos aplicativos ou para tarefas de configuração, como atualizar mapas de configuração, segredos, políticas de rede e manifestos.
Você pode ter um único balanceador de carga externo que atenda a vários controladores de entrada implantados no mesmo cluster ou em vários clusters. Essa abordagem não é mencionada na implementação de referência. Nesse cenário, recomendamos que você tenha gateways de aplicativo separados para pontos de extremidade voltados para o público e privados.
A arquitetura resultante proposta e descrita neste guia é baseada em um controlador de entrada padrão implantado como parte do cluster do AKS, como NGINX e Envoy. Na implementação de referência, usamos o AGIC, o que significa que há uma conexão direta entre o gateway de aplicativo e os pods do AKS, mas isso não afeta a arquitetura azul-verde geral.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Principais autores:

Vincenzo Morra | Arquiteto de Incubação SAO

Outros colaboradores:

Oscar Pla Alvarez | Arquiteto de Soluções de Domínio

Para ver perfis não públicos do LinkedIn, entre no LinkedIn.

Compartilhar via

Implantação azul-verde de clusters do AKS