Implantação azul-verde de clusters AKS

Azure Kubernetes Service (AKS)

Azure Application Gateway

Azure Container Registry

Azure Front Door

Azure DNS

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 Kubernetes do Azure (AKS) enquanto continua a executar a versão atual. Depois que a nova versão é validada, uma alteração de roteamento muda o tráfego do usuário para ela. A implantação dessa maneira aumenta a disponibilidade ao fazer alterações, incluindo atualizações, em clusters 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 AKS. Existem dois casos:

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

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

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

Transfira um ficheiro do Visio desta arquitetura.

O Azure Front Door e o Azure DNS 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 baseado 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, você precisa ter certeza de que eles 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 o caso privado:

Transfira um ficheiro do Visio desta arquitetura.

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

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

Fluxo de trabalho

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 é o novo.

As etapas são:

T0: O cluster azul está ligado.
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 aglomerado azul.

Uma vez que a nova versão está no ar, torna-se 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 de tempo, o que otimiza os custos e os esforços operacionais.

Gatilhos de transição

Os gatilhos para a transição de estágio para estágio podem ser automatizados. Até que isso seja alcançado, alguns ou todos eles são manuais. Os fatores de desencadeamento estão relacionados com:

Métricas de carga de trabalho específicas, SLOs (objetivos de nível de serviço) e SLAs (contratos de nível de serviço): são usados principalmente no estágio T3 para validar o estado geral do cluster AKS antes de alternar o tráfego.
Métricas da plataforma Azure: são usadas para avaliar o status e a integridade das cargas de trabalho e do cluster AKS. Eles são usados 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:

Ter registos 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.
Ter registros DNS que apontem para os gateways de aplicativos. 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á ligado

A etapa inicial, T0, é que o aglomerado azul está vivo. Esta etapa 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: Implantar o cluster verde

Esta etapa inicia a implantação do novo cluster verde. O cluster azul permanece ligado e o tráfego ao vivo ainda é encaminhado para ele.

O gatilho para passar para o estágio T2 é a validação do cluster 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 Monitorando o Serviço Kubernetes do Azure (AKS) com a referência de dados do Monitor e Monitoramento do AKS.

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

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

No nível 2, certifique-se de que o servidor da 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ó resume a operação total, o total de erros e as operações bem-sucedidas por porcentagem e tendência para cada nó.
A visão geral por grade de 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 Deployment & HPA metrics with Container insights. Eis um exemplo:

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

T2: Sincronizar 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 implantados quando o cluster AKS é provisionado. O objetivo final desta etapa é que, no final da sincronização, o cluster verde seja retrocompatível com o azul. Em caso afirmativo, é 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 contínua 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: Ações do GitHub, Azure DevOps e Jenkins.
GitOps, com soluções que são promovidas 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 do Kubernetes gerados em um armazenamento de dados como o Azure Cosmos DB. Normalmente, essas são soluções personalizadas baseadas na estrutura de descrição do aplicativo 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 ao vivo. 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. Duas soluções possíveis são:

Desative os pipelines de implantação.
Desative 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 recursos nativos do AKS para isso porque eles ainda estão em visualização.

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 é concluída, a validação do cluster e dos aplicativos é necessária. O que está incluído:

Uma verificação das plataformas de monitoramento e registro em log para validar a integridade do cluster. Você pode considerar fazer o que faz no T1: implantar o estágio de cluster verde.
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 for validado, você poderá prosseguir para o próximo estágio para alternar o tráfego para o novo cluster.

T3: Alternar 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 estará pronto para ser promovido para ser o cluster principal e começar a receber o tráfego ao vivo. O switch é executado no nível de rede. Muitas vezes, as cargas de trabalho são apátridas. No entanto, se as cargas de trabalho tiverem monitoração de estado, uma solução adicional deverá ser implementada para manter o estado e o cache durante a mudança.

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

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

Aqui está um exemplo de configuração para alternar pontos de extremidade voltados para privados. A solução proposta usa A registros para fazer a mudança. De uma perspetiva de mapeamento de DNS e IP, a situação é a seguinte antes do switch:

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

O switch é reconfigurado para o seguinte:

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

Os usuários dos clusters verão o switch após o tempo de vida (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 do switch:

CNAME registro official-aks.contoso.com aponta para um registro do domínio Azure Front Door gerado automaticamente. Para obter mais informações, veja Tutorial: Adicionar um domínio personalizado ao Front Door.
A registrar aks.contoso.com aponta para o IP público do gateway de aplicativo azul.
A configuração de origem da Porta da Frente do Azure 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 na Porta da Frente do Azure.
- A registrar aks-blue.contoso.com aponta para o IP público do gateway de aplicativo azul.
- A registrar aks-green.contoso.com aponta para o IP público do gateway de aplicativo verde.

O switch é reconfigurado para o seguinte:

CNAME registro official-aks.contoso.com aponta para um registro do domínio Azure Front Door gerado automaticamente.
A registrar aks.contoso.com aponta para IP público do gateway de aplicativo verde.
A configuração de origem da Porta da Frente do Azure aponta para o nome do host aks.contoso.com.
- A registrar aks-blue.contoso.com aponta para IP público do gateway de aplicativo azul.
- A registrar aks-green.contoso.com aponta para 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 Traffic Manager. Para obter uma implementação de um switch de tráfego azul-verde no nível da Porta da Frente do Azure, consulte Implantação azul-verde com a Porta da Frente do Azure.

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

Nome de host público oficial: o nome de host público oficial usado por usuários finais e consumidores.
Nome do host do cluster: o nome do host oficial 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. Este host é usado apenas para transações e solicitações ao vivo.

Se o Azure Front Door também fizer parte da implantação, ele não será afetado pelo switch, porque gerencia apenas o nome oficial do host do cluster. Ele fornece a abstração adequada para os usuários do aplicativo. Eles não são afetados pelo switch, porque o registro DNS CNAME 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 AKS para gerenciar o TLS corretamente.

Nesta etapa, a validação é baseada nas métricas de monitoramento de infraestrutura e aplicativo, e no 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 aglomerado azul

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

Após a conclusão dessa validação, o cluster azul pode ser destruído. A destruição é uma etapa altamente recomendada para reduzir custos e fazer uso adequado da elasticidade que o Azure oferece, particularmente o AKS.

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

Componentes

O Application Gateway é um gateway e balanceador de carga para os clusters AKS.
O AKS fornece clusters Kubernetes gerenciados.
O Registro de Contêiner do Azure armazena e distribui imagens e artefatos de contêiner, como gráficos Helm, nos clusters AKS.
O Monitor monitoriza os clusters AKS. É altamente recomendável usá-lo, 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 Azure Key Vault protege os segredos e certificados que os recursos do Azure e os aplicativos usam.
O Azure Front Door é usado nesta solução quando há pontos de extremidade voltados para o público e aplicativos hospedados no AKS e em outros serviços de computação do Azure. Nesta solução, tem a responsabilidade crítica de gerir a mudança de tráfego entre os clusters azul e verde.
O DNS do Azure gerencia os nomes de host usados na solução e desempenha um papel importante nos comutadores 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ânsito baseadas em um ou mais dos seguintes itens:
- Percentagem de tráfego de entrada
- Cabeçalhos de HTTP
- Cookies
Outra alternativa que oferece 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 aglomerados, chamados anéis. Cada anel é grande o suficiente para 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 custos adequados.
Possíveis alternativas ao Application Gateway são NGINX e HAProxy.
Uma possível alternativa ao Registro de Contêineres é o Harbor.
Em algumas circunstâncias, é possível usar diferentes serviços de balanceamento de carga e DNS para fazer as opções de tráfego, em vez do Azure Front Door e do Azure DNS.

Detalhes do cenário

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

Tempo de inatividade minimizado durante a implantação.
Estratégia de reversão planejada.
Controle e operações aprimorados durante o lançamento e implantação de alterações e upgrades do AKS.
Testando a necessidade de executar procedimentos de recuperação de desastres (DR).

Os princípios-chave e os aspetos 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. Sugerimos:

Bíceps ou Terraform para IaC.
Pipelines do Azure ou ações do GitHub para CI/CD.

Potenciais casos de utilização

A implantação azul-verde torna possível fazer alterações em clusters sem afetar os aplicativos e cargas de trabalho em execução. São exemplos de alterações:

Alterações operacionais
Ativando novos recursos do AKS
Alterações nos recursos compartilhados nos clusters
Atualizando a versão do Kubernetes
Modificando 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 AKS que ainda está implantado, sem afetar as cargas de trabalho que estão sendo executadas no cluster

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que podem ser usados para melhorar 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 tem gatilhos manuais para ativar os estágios. 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 azuis e verdes 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 a 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 AKS são recursos compartilhados para vários aplicativos que são gerenciados por diferentes unidades de negócios. Nesses casos, é comum que a própria plataforma AKS seja gerenciada por uma equipe dedicada que é responsável pela operação geral e pelo ciclo de vida dos clusters, e que existam pontos de extremidade nos clusters para fins de administração e operações. Sugerimos que esses endpoints tenham um controlador de entrada dedicado nos clusters 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 a gestão de múltiplos agrupamentos, incluindo os casos em que os agrupamentos estão distribuídos por várias regiões.
O sucesso com a implantação azul-verde depende da aplicação de todos os aspetos da implementação, como automação, monitoramento e validação, não apenas à plataforma AKS, mas também às cargas de trabalho e aplicativos implantados na plataforma. Isso ajuda você a obter o máximo benefício da implantação azul-verde.

Fiabilidade

A confiabilidade garante que seu aplicativo possa atender aos compromissos que você assume com seus clientes. Para obter mais informações, consulte Visão geral do pilar de confiabilidade.

A implantação azul-verde tem um efeito direto e positivo na disponibilidade da plataforma AKS e das cargas de trabalho. Em particular, aumenta a disponibilidade durante a implantação das mudanças na plataforma AKS. Há 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 AKS se algo der errado na nova versão do cluster.

Otimização de custos

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

A implantação azul-verde é amplamente adotada no Azure devido à elasticidade nativa fornecida pela nuvem. Isso torna possível otimizar os 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 linha de base de custo. Todas as conexões de rede e acesso aos recursos e serviços são os mesmos 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 operacionais que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, consulte Visão geral do pilar de excelência operacional.

A implantação verde-azul, implementada corretamente, fornece automação, entrega contínua e implantação resiliente.
Um dos principais aspetos da entrega contínua é que ela fornece iterativamente incrementos de alterações de plataforma e carga de trabalho. Com a implantação azul-verde do AKS, você alcança uma 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.

Implementar este cenário

Para obter um exemplo implementado de uma implantação azul-verde descrita neste guia, consulte AKS Landing Zone Accelerator.

Essa implementação de referência é baseada no Application Gateway e no Application Gateway Ingress Controller (AGIC). Cada cluster tem seu próprio gateway de aplicativo e a mudança de tráfego é feita via DNS, em particular via CNAME configuração.

Importante

Para cargas de trabalho de missão crítica, é importante combinar implantações azuis/verdes, conforme descrito neste guia, com automação de implantação e validação contínua para obter implantações sem tempo de inatividade. Estão disponíveis mais informações e orientações na metodologia de conceção de missão crítica.

Considerações sobre a região

Você pode implantar os clusters azul e verde em regiões separadas ou na mesma região. O design e os princípios operacionais 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 o AKS e o gateway de aplicação.
Conexão com serviços de backup 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 torna possível usar o balanceador de carga L7 do Application Gateway para expor o software em nuvem à internet. Em determinados cenários, há pontos de extremidade admin nos clusters AKS, além dos pontos de extremidade do aplicativo. Os pontos de extremidade admin 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 é abordada na implementação de referência. Neste cenário, recomendamos que você tenha gateways de aplicativos separados para pontos de extremidade públicos e privados.
A arquitetura resultante proposta e descrita neste guia é baseada em um controlador de entrada padrão que é implantado como parte do cluster AKS, como NGINX e Envoy. Na implementação de referência, usamos AGIC, o que significa que há uma conexão direta entre o gateway de aplicativo e os pods AKS, mas isso não afeta a arquitetura azul-verde geral.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

Vincenzo Morra - Brasil | Arquiteto de Incubação SAO

Outros contribuidores:

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

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

Share via

Implantação azul-verde de clusters AKS