Criar um cluster Kubernetes de alta disponibilidade no Azure Stack Hub

Este artigo descreve como arquitetar e operar uma infraestrutura altamente disponível baseada no Kubernetes usando o Mecanismo do AKS (Serviço de Kubernetes do Azure) no Azure Stack Hub. A solução é baseada em um cenário que tem um conjunto estrito de restrições. O aplicativo deve ser executado no local e nenhum dado pessoal deve alcançar serviços de nuvem pública. O monitoramento e outros dados não PII podem ser enviados para o Azure e ser processados nele. Serviços externos, como um registro de contêiner público, podem ser acessados, mas podem ser filtrados por meio de um firewall ou um servidor proxy.

Helm e Let's Encrypt são marcas comerciais de suas respectivas empresas. Nenhum endosso está implícito pelo uso dessas marcas.

Arquitetura

Baixe um arquivo do Visio de todos os diagramas nesse artigo.

Workflow

O diagrama anterior ilustra a arquitetura do aplicativo de exemplo em execução no Kubernetes no Azure Stack Hub. O aplicativo consiste nestes componentes:

1. Um cluster do Kubernetes, baseado no mecanismo do AKS, no Azure Stack Hub.
2. cert-manager, que fornece um conjunto de ferramentas para gerenciamento de certificados no Kubernetes. Ele é usado para solicitar certificados do Let's Encrypt automaticamente.
3. Um namespace do Kubernetes que contém os componentes do aplicativo para:
   1. o front-end (ratings-web)
   2. a API (ratings-api)
   3. o banco de dados (ratings-mongodb)
4. O controlador de entrada que roteia o tráfego HTTP/HTTPS para pontos de extremidade no cluster do Kubernetes.

O aplicativo de exemplo é usado para ilustrar a arquitetura do aplicativo. Todos os componentes são exemplos. A arquitetura contém apenas uma implantação de aplicativo. Para obter alta disponibilidade, a implantação é executada pelo menos duas vezes em duas instâncias do Azure Stack Hub. Elas podem ser executadas em um único local ou em dois ou mais sites:

Serviços como o Registro de Contêiner do Azure e o Azure Monitor são hospedados fora do Azure Stack Hub no Azure ou no local. Esse design híbrido protege a solução contra a interrupção de uma instância individual do Azure Stack Hub.

Componentes

• O Azure Stack Hub é uma extensão do Azure que pode executar cargas de trabalho em um ambiente local fornecendo serviços do Azure no seu datacenter.
• O AKS Engine for Azure Stack fornece uma ferramenta de linha de comando para ajudar a provisionar um cluster Kubernetes autogerenciado no Azure Stack Hub. Ele usa o Gerenciador de Recursos do Azure para criar, destruir e manter clusters provisionados com recursos básicos de IaaS no Azure Stack Hub.
• A Rede Virtual fornece a infraestrutura de rede em cada instância do Hub de Pilha do Azure para as máquinas virtuais (VMs) que hospedam a infraestrutura de cluster do Kubernetes.
• O Azure Load Balancer é usado para o ponto de extremidade de API do Kubernetes e o controlador de entrada Nginx. O balanceador de carga roteia o tráfego externo (por exemplo, da Internet) para os nós e as VMs que oferecem um serviço específico.
• O Registro de Contêiner é usado para armazenar imagens particulares do Docker e gráficos do Helm, que são implantados no cluster. O Mecanismo do AKS pode se autenticar com o registro de contêiner por meio da identidade do Microsoft Entra. O Kubernetes não requer Registro de Contêiner. É possível usar outros registros de contêiner, como o Docker Hub.
• O Azure Repos é um conjunto de ferramentas de controle de versão que você pode usar para gerenciar seu código. Use também o GitHub ou outros repositórios baseados no Git.
• O Azure Pipelines é parte do Azure DevOps Services. Ele executa builds, testes e implantações automatizados. É também possível usar soluções de CI/CD de terceiros, como o Jenkins.
• O Azure Monitor coleta e armazena métricas e logs, incluindo a métrica de plataforma para os serviços do Azure na telemetria do aplicativo e da solução. Use esses dados para monitorar o aplicativo, configurar alertas e painéis e executar a análise da causa raiz de falhas. O Azure Monitor integra-se ao Kubernetes para coletar métricas de controladores, nós, contêineres, logs de contêiner e logs do nó do painel de controle.
• O Gerenciador de Tráfego do Azure é um balanceador de carga de tráfego baseado em DNS que possibilita distribuir o tráfego de maneira ideal para serviços em diferentes regiões do Azure ou implantações do Azure Stack Hub. O Gerenciador de Tráfego também fornece alta disponibilidade e capacidade de resposta. Os pontos de extremidade do aplicativo devem ser acessíveis de fora para serem adicionados como pontos de extremidade ao Gerenciador de Tráfego do Azure.
• Um controlador de entrada do Kubernetes expõe as rotas HTTP(S) aos serviços em um cluster do Kubernetes. É possível usar o NGINX ou qualquer controlador de entrada adequado.
• O Helm é um gerenciador de pacotes para implantação no Kubernetes. Ele fornece uma maneira de empacotar diferentes objetos do Kubernetes, como Deployments, Services e Secrets, em um único "pacote". É possível publicar, implantar, versionar e atualizar um objeto de gráfico. O Registro de Contêiner pode ser usado como um repositório para armazenar pacotes do Helm.

Alternativas

O Gerenciador de Tráfego do Azure é uma das opções para distribuir o tráfego entre dois pontos de extremidade acessíveis pela Internet. Outras soluções de balanceamento de carga também podem ser usadas para distribuir o tráfego entre instâncias do Hub de Pilha do Azure. Pode haver cenários em que os pontos de extremidade do aplicativo hospedados no Azure Stack Hub devem ser restritos apenas à sua rede privada. Os balanceadores de carga de terceiros podem ser usados nesses cenários para balancear a carga do tráfego entre instâncias do Azure Stack Hub em sua rede, estejam eles colocalizados no mesmo data center ou implantados em vários data centers.

Detalhes do cenário

O aplicativo de exemplo mostrado aqui foi projetado para usar soluções nativas do Kubernetes em vez de serviços nativos da plataforma sempre que possível. Esse design evita o bloqueio de fornecedor. Por exemplo, o aplicativo usa um back-end do banco de dados MongoDB auto-hospedado, em vez de um serviço de PaaS ou um serviço de banco de dados externo. Para obter mais informações, consulte o roteiro de aprendizagem Introdução ao Kubernetes no Azure.

Possíveis casos de uso

Muitas organizações estão desenvolvendo soluções nativas de nuvem que aproveitam serviços e tecnologias de ponta como o Kubernetes. Embora o Azure forneça datacenters na maioria das regiões do mundo, às vezes, há aplicativos comercialmente críticos que precisam ser executados em uma localização específica. As possíveis preocupações incluem:

• Confidencialidade da localização.
• Latência entre o aplicativo e os sistemas locais.
• Conservação da largura de banda.
• Conectividade.
• Requisitos regulatórios ou legais.

O Azure, em combinação com o Azure Stack Hub, resolve a maioria dessas preocupações. Este artigo fornece um amplo conjunto de opções, decisões e considerações para ajudá-lo a arquitetar com êxito soluções baseadas em Kubernetes altamente disponíveis no Azure Stack Hub.

O cenário descrito aqui é comum para as organizações com cargas de trabalho críticas em ambientes altamente restritos e regulamentados. É aplicável em domínios como finanças, defesa e governo.

Considerações

Essas 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, confira Microsoft Azure Well-Architected Framework.

Design

Essa solução incorpora algumas recomendações de alto nível que são explicadas com mais detalhes nas próximas seções desse artigo:

• Para evitar o bloqueio de fornecedor, o aplicativo usa soluções nativas do Kubernetes.
• Ele usa uma arquitetura de microsserviços.
• O Azure Stack Hub não precisa conectividade com a Internet de entrada. Ele permite a conectividade com a Internet de saída.

Essas práticas recomendadas também são aplicadas a cargas de trabalho e cenários do mundo real.

Confiabilidade

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

A escalabilidade ajuda a fornecer um acesso consistente, confiável e de bom desempenho ao aplicativo.

O cenário de exemplo implementa a escalabilidade em três camadas da pilha de aplicativos. Esta é uma visão geral de alto nível das diferentes camadas:

Nível de arquitetura	Afeta	Como posso fazer isso?
Aplicativo	Aplicativo	Escala horizontal com base no número de pods/réplicas/instâncias de contêiner.*
Cluster	Cluster do Kubernetes	Número de nós (entre 1 e 50), tamanhos de SKU de VM e, por meio do comando scale manual do Mecanismo do AKS, pools de nós.
Infraestrutura	Azure Stack Hub	Número de nós, capacidade e unidades de escala em uma implantação do Azure Stack Hub.

* Por meio do HorizontalPodAutoscaler do Kubernetes, que fornece escala automatizada baseada em métricas ou escala vertical por dimensionamento das instâncias de contêiner (CPU ou memória).

Azure Stack Hub (nível de infraestrutura)

Como o Azure Stack Hub é executado em hardware físico em um datacenter, a infraestrutura do Azure Stack Hub é a base dessa implementação. Ao selecionar o hardware do hub, é necessário escolher a CPU, densidade de memória, configuração de armazenamento e número de servidores. Para saber mais sobre a escalabilidade do Azure Stack Hub, consulte estes recursos:

• Visão geral do planejamento da capacidade para o Azure Stack Hub
• Adicionar nós de unidade de escala no Azure Stack Hub

Cluster do Kubernetes (nível de cluster)

O próprio cluster do Kubernetes é formado por componentes de IaaS do Azure Stack Hub e Azure, incluindo recursos de computação, armazenamento e rede, e é criado com base neles. As soluções do Kubernetes são compostas de nós do painel de controle e de trabalho, que são implantados como VMs no Azure e no Azure Stack Hub.

• Os nós do Painel de controle fornecem os principais serviços do Kubernetes e a orquestração de cargas de trabalho do aplicativo.
• Os nós de trabalho executam suas cargas de trabalho do aplicativo.

Ao escolher tamanhos de VM para sua implantação inicial, leve o seguinte em consideração:

• Custo. Ao planejar seus nós de trabalho, considere o custo geral por VM. Por exemplo, se as cargas de trabalho do aplicativo exigirem recursos limitados, planeje a implantação de VMs menores. O Azure Stack Hub, como o Azure, normalmente é cobrado de acordo com o consumo. Portanto, o dimensionamento adequado das VMs para as funções do Kubernetes é crucial para otimizar os custos de consumo.

• Escalabilidade. Você obterá a escalabilidade do cluster escalando e reduzindo o número de nós de plano de controle e de trabalho ou adicionando pools de nós. (No momento, não é possível adicionar pools de nós no Azure Stack Hub.) É possível escalar o cluster com base nos dados de desempenho coletados com insights de Contêiner (Azure Monitor e Log Analytics).

  Se o seu aplicativo precisar de mais ou menos recursos, escale ou reduza horizontalmente o número de nós, entre 1 e 50. Caso precise de mais de 50 nós, crie outro cluster em uma assinatura separada. Você não poderá escalar verticalmente as VMs reais para outro tamanho de VM sem reimplantar o cluster.

  Implemente a escala manualmente usando a VM auxiliar do Mecanismo do AKS que foi usada para implantar o cluster do Kubernetes. Para obter mais informações, confira Como escalar clusters do Kubernetes.

• Cotas. Considere as cotas que você configurou ao planejar uma implantação do AKS no Azure Stack Hub. Verifique se cada assinatura tem as cotas e os planos adequados configurados. A assinatura precisará acomodar a quantidade de computação, armazenamento e outros serviços necessários para seus clusters à medida que eles escalarem horizontalmente.

• Cargas de trabalho do aplicativo. Veja os conceitos de clusters e cargas de trabalho no artigo Principais conceitos do Kubernetes para o Serviço de Kubernetes do Azure. Este artigo ajudará você a definir o escopo do tamanho da VM com base nas necessidades de computação e memória do seu aplicativo.

Aplicativo (nível de aplicativo)

Na camada do aplicativo, a solução usa o HorizontalPodAutoscaler do Kubernetes. O HorizontalPodAutoscaler pode aumentar ou diminuir o número de réplicas (pod/instâncias de contêiner) na implantação com base em diferentes métricas, como utilização da CPU.

Outra opção é escalar as instâncias de contêiner verticalmente. Esse tipo de escala pode ser alcançado alterando a quantidade de CPU e memória solicitada e disponível para uma implantação específica. Para obter mais informações, confira Como gerenciar recursos para contêineres.

Rede e conectividade

A rede e a conectividade também afetam as três camadas discutidas anteriormente. A tabela a seguir mostra as camadas e os serviços que elas contêm.

Camada	Afeta	O quê?
Aplicativo	Aplicativo	Como o aplicativo pode ser acessado. Se está exposto ou não à Internet.
Cluster	Cluster do Kubernetes	API do Kubernetes, VM do Mecanismo do AKS, efetuar pull de imagens de contêiner (saída), envio de dados de monitoramento e telemetria (saída).
Infraestrutura	Azure Stack Hub	Acessibilidade dos pontos de extremidade de gerenciamento do Azure Stack Hub, como os pontos de extremidade do Azure Resource Manager e do portal.

Aplicativo

Para a camada do aplicativo, a consideração mais importante é se o aplicativo está exposto à Internet e pode ser acesso por ela. Da perspectiva do Kubernetes, o acesso à Internet requer a exposição de uma implantação ou um pod usando um Serviço de Kubernetes ou um controlador de entrada.

Um aplicativo pode ser exposto com um IP por meio de um balanceador de carga ou um controlador de entrada sem ser acessível pela Internet. O Azure Stack Hub pode ter um IP visível apenas na intranet local. Nem todos os IPs são realmente voltados para a Internet.

Além do tráfego de entrada para o aplicativo, é também necessário considerar o tráfego de saída. Estes são alguns casos de uso que exigem o tráfego de saída:

• Como efetuar pull de imagens de contêiner armazenadas no Docker Hub ou no Registro de Contêiner
• Como recuperar gráficos do Helm
• Como emitir de dados do Application Insights ou outros dados de monitoramento
• Conectando-se a aplicativos externos

Alguns ambientes corporativos podem exigir o uso de servidores proxy transparentes ou não transparentes. Esses servidores exigem uma configuração específica em vários componentes do cluster. A documentação do Mecanismo do AKS contém vários detalhes sobre como acomodar os proxies de rede. Para obter mais informações, confira Mecanismo do AKS e servidores proxy.

Por fim, o tráfego entre clusters precisa fluir entre as instâncias do Azure Stack Hub. A solução descrita aqui consiste em clusters individuais do Kubernetes que são executados em instâncias individuais do Azure Stack Hub. O tráfego entre elas, como o tráfego de replicação entre dois bancos de dados, é considerado tráfego externo. O tráfego externo deve ser roteado por meio de uma VPN site a site ou endereços IP públicos do Azure Stack Hub. VPN site a site oferece mais segurança para transferências de dados e é preferível.

Cluster

O cluster do Kubernetes não precisa necessariamente ser acessível pela Internet. A parte relevante é a API do Kubernetes usada para operar um cluster, por exemplo, por meio de kubectl. Todos que operam o cluster ou que implantam aplicativos e serviços com base nele devem poder acessar o ponto de extremidade da API do Kubernetes. Esse tópico é abordado mais detalhadamente da perspectiva de DevOps na seção Implantação (CI/CD) desse artigo.

No nível do cluster, também há algumas considerações sobre o tráfego de saída:

• Atualizações de nó (para o Ubuntu)
• Dados de monitoramento (enviados ao Log Analytics)
• Outros agentes que exigem o tráfego de saída (específico do ambiente de cada implantador)

Antes de implantar o cluster do Kubernetes usando o Mecanismo do AKS, planeje o design final da rede. Pode ser mais eficiente implantar um cluster em uma rede existente em vez de criar uma rede virtual dedicada. Por exemplo, você pode aproveitar uma conexão VPN site a site existente já configurada no seu ambiente do Azure Stack Hub.

Infraestrutura

A infraestrutura refere-se ao acesso aos pontos de extremidade de gerenciamento do Azure Stack Hub. Os pontos de extremidade incluem os portais do locatário e do administrador e os pontos de extremidade do administrador e do locatário do Resource Manager. Esses pontos de extremidade são necessários para operar o Azure Stack Hub e os serviços principais dele.

Dados e armazenamento

Duas instâncias do aplicativo serão implantadas em dois clusters individuais do Kubernetes, em duas instâncias do Azure Stack Hub. Para esse design, é necessário considerar como replicar e sincronizar dados entre as instâncias.

O Azure fornece a capacidade interna de replicar o armazenamento em várias regiões e zonas na nuvem. Atualmente, não há nenhuma maneira nativa de replicar o armazenamento em duas instâncias do Azure Stack Hub. Elas formam duas nuvens independentes e não há nenhuma maneira abrangente de gerenciá-las como um conjunto. Quando você planejar a resiliência dos aplicativos que são executados no Azure Stack Hub, considere essa independência no design e nas implantações do seu aplicativo.

Na maioria dos casos, a replicação de armazenamento não será necessária para um aplicativo resiliente e altamente disponível implantado no AKS. Porém, você deve considerar o armazenamento independente por instância do Azure Stack Hub no design do aplicativo. Se esse design for uma preocupação, considere as soluções de anexo de armazenamento oferecidas pelos parceiros da Microsoft. Os anexos de armazenamento fornecem uma solução de replicação de armazenamento entre várias instâncias do Azure Stack Hub e Azure. Para obter mais informações, consulte a seção Soluções de parceiros desse artigo.

Essa arquitetura leva estes elementos em consideração:

Configuração

Esta categoria inclui a configuração do Azure Stack Hub, do Mecanismo do AKS e do próprio cluster do Kubernetes. Automatize a configuração o máximo possível e armazene-a como uma infraestrutura como código em um sistema de controle de versão baseado no Git, como o Azure DevOps ou o GitHub. Essas configurações não podem ser sincronizadas com facilidade em várias implantações. Recomendamos armazenar e aplicar a configuração externamente e usando o pipeline do DevOps.

Aplicativo

O aplicativo deve ser armazenado em um repositório baseado no Git. Se for, sempre que houver uma nova implantação, alterações no aplicativo ou uma recuperação de desastre, será possível implantar o aplicativo com facilidade usando o Azure Pipelines.

Dados

Os dados são a consideração mais importante na maioria dos designs de aplicativos. Os dados do aplicativo precisam permanecer em sincronia entre as diferentes instâncias do aplicativo. É também necessária uma estratégia de backup e recuperação de desastre para os dados em caso de interrupção.

Se você estiver trabalhando com dados em várias localizações, a implementação de uma solução altamente disponível e resiliente será ainda mais complexa. Considerar:

• Latência e conectividade de rede entre instâncias do Azure Stack Hub.
• A disponibilidade de identidades para serviços e permissões. Cada instância do Azure Stack Hub se integra a um diretório externo. Durante a implantação, escolha se deseja usar o Microsoft Entra ID ou os AD FS (Serviços de Federação do Active Directory). Assim, há a opção de usar uma só identidade que pode interagir com várias instâncias independentes do Azure Stack Hub.

Continuidade dos negócios e recuperação de desastres

A BCDR (continuidade dos negócios e recuperação de desastres) é uma consideração importante para o Azure Stack Hub e o Azure. A principal diferença é que, no Azure Stack Hub, o operador precisa gerenciar todo o processo de BCDR. Para o Azure, algumas partes da BCDR são gerenciadas automaticamente pela Microsoft.

A BCDR afeta as mesmas áreas discutidas na seção anterior:

• Infraestrutura e configuração
• Disponibilidade do aplicativo
• Dados do aplicativo

Essas áreas são de responsabilidade do operador do Azure Stack Hub. Os detalhes podem variar, dependendo da organização. Planeje a BCDR de acordo com as ferramentas e os processos disponíveis.

Infraestrutura e configuração

Esta seção aborda a infraestrutura física e lógica e a configuração do Azure Stack Hub. Ela aborda ações nos espaços do administrador e do locatário.

O operador (ou o administrador) do Azure Stack Hub é responsável pela manutenção das instâncias do Azure Stack Hub. Essa manutenção inclui rede, armazenamento, identidade e outros elementos que estão fora do escopo desse artigo. Para saber mais sobre as especificações das operações do Azure Stack Hub, confira os seguintes recursos:

• Recuperar dados no Azure Stack Hub com o serviço Backup de Infraestrutura
• Habilitar o backup para o Azure Stack Hub pelo portal do administrador
• Recuperação da perda de dados catastrófica
• Práticas recomendadas do serviço de Backup de Infraestrutura

O Azure Stack Hub é a plataforma e a malha em que os aplicativos do Kubernetes são implantados. O proprietário do aplicativo do Kubernetes é um usuário do Azure Stack Hub que tem acesso para implantar a infraestrutura do aplicativo necessária para a solução. A infraestrutura do aplicativo, nesse caso, significa o cluster do Kubernetes, implantado por meio do Mecanismo do AKS, e os serviços relacionados.

Esses componentes são implantados no Azure Stack Hub. Os componentes são restringidos pela oferta do Azure Stack Hub. Verifique se a oferta aceita pelo proprietário do aplicativo do Kubernetes tem capacidade suficiente, expressa em cotas do Azure Stack Hub, para implantar a solução inteira. Conforme recomendado na seção anterior, a implantação do aplicativo deve ser automatizada com o uso de pipelines de infraestrutura como código e de implantação, como o Azure Pipelines.

Para obter mais informações sobre as ofertas e as cotas do Azure Stack Hub, confira Visão geral dos serviços, planos, ofertas e assinaturas do Azure Stack Hub.

É importante salvar e armazenar com segurança a configuração do Mecanismo do AKS, incluindo suas saídas. Esses arquivos contêm informações confidenciais usadas para acessar o cluster do Kubernetes. Portanto, elas precisam ser protegidas contra exposição a não administradores.

Disponibilidade do aplicativo

O aplicativo não deve depender de backups de uma instância implantada. Como uma prática padrão, reimplante o aplicativo por completo seguindo os padrões da infraestrutura como código. Por exemplo, reimplante-o usando o Azure Pipelines. O procedimento da BCDR deve envolver a reimplantação do aplicativo no mesmo ou em outro cluster do Kubernetes.

Dados do aplicativo

Os dados do aplicativo são o componente crítico da BCDR. As seções anteriores descrevem as técnicas para replicar e sincronizar dados entre duas ou mais instâncias de um aplicativo. Dependendo da infraestrutura de banco de dados (como MySQL, MongoDB ou SQL Server) usada para armazenar os dados, haverá técnicas diferentes de backup e disponibilidade de banco de dados disponíveis.

Para obter integridade, recomendamos usar uma das seguintes soluções:

• Uma solução de backup nativa para o banco de dados específico.
• Uma solução de backup que dê suporte ao backup e à recuperação do tipo de banco de dados usado pelo aplicativo.

Disponibilidade

O Kubernetes no Azure Stack Hub, quando implantado por meio do Mecanismo do AKS, não é um serviço gerenciado. É uma implantação e configuração automatizadas de um cluster do Kubernetes usando a IaaS (infraestrutura como serviço) do Azure. Assim, ele fornece a mesma disponibilidade da infraestrutura subjacente.

A infraestrutura do Azure Stack Hub já é resiliente a falhas e oferece funcionalidades como conjuntos de disponibilidade para distribuir componentes entre vários domínios de falha e atualização. Porém, a tecnologia subjacente (clustering de failover) ainda gera algum tempo de inatividade para as VMs em um servidor físico afetado, em caso de falha de hardware.

É uma boa prática implantar o cluster do Kubernetes de produção, bem como a carga de trabalho, em dois ou mais clusters. Esses clusters devem ser hospedados em diferentes localizações ou datacenters e usar tecnologias como o Gerenciador de Tráfego para rotear os usuários com base no tempo de resposta ou na geografia do cluster.

Os clientes que têm um só cluster do Kubernetes normalmente se conectam ao nome DNS ou ao IP de serviço de determinado aplicativo. Em uma implantação de vários clusters, os clientes devem se conectar a um nome DNS do Gerenciador de Tráfego que aponte para os serviços/o ingress em cada cluster do Kubernetes.

O próprio cluster do Kubernetes, implantado por meio do Mecanismo do AKS, deve consistir em, pelo menos, três nós do painel de controle e dois nós de trabalho.

Segurança

A segurança fornece garantias contra ataques deliberados e o abuso de seus dados e sistemas valiosos. Para saber mais, confira Visão geral do pilar de segurança.

A segurança e a identidade são especialmente importantes quando a solução abrange instâncias independentes do Azure Stack Hub. O Kubernetes e o Azure, incluindo o Azure Stack Hub, têm mecanismos distintos para o RBAC (controle de acesso baseado em função):

• O RBAC do Azure controla o acesso ao Azure e ao Azure Stack Hub, incluindo a capacidade de criar novos recursos do Azure. As permissões podem ser atribuídas a usuários, grupos ou entidades de serviço. (Uma entidade de serviço é uma identidade de segurança usada pelos aplicativos.)
• O RBAC do Kubernetes controla permissões para a API do Kubernetes. Por exemplo, a criação e a listagem de pods são ações que podem ser concedidas ou negadas a um usuário por meio de RBAC. Para atribuir permissões de Kubernetes aos usuários, crie funções e associações de função.

Identidade e RBAC do Azure Stack Hub

O Azure Stack Hub fornece duas opções de provedor de identidade. O provedor usado depende do ambiente e se ele está em execução em um ambiente conectado ou desconectado:

• O Microsoft Entra ID só pode ser usado em um ambiente conectado.
• Os AD FS para uma floresta tradicional do Active Directory podem ser usados em um ambiente conectado ou desconectado.

O provedor de identidade gerencia usuários e grupos, incluindo autenticação e autorização para acessar os recursos. O acesso pode ser concedido a recursos do Azure Stack Hub, como assinaturas, grupos de recursos e recursos individuais, como VMs ou balanceadores de carga. Para fins de consistência, considere o uso dos mesmos grupos, diretos ou aninhados, para todas as instâncias do Azure Stack Hub. Aqui está um exemplo de configuração:

Esse exemplo contém um grupo dedicado (usando Microsoft Entra ID ou AD FS) para uma finalidade específica, por exemplo, para fornecer permissões de Colaborador ao grupo de recursos que contém a infraestrutura de cluster do Kubernetes em uma instância específica do Azure Stack Hub (aqui, "Colaborador do Cluster do K8s Seattle"). Depois, esses grupos serão aninhados em um grupo geral que contém os subgrupos de cada instância do Azure Stack Hub.

Agora, nosso usuário de exemplo tem permissões de Colaborador nos grupos de recursos que contêm todo o conjunto de recursos da infraestrutura do Kubernetes. O usuário tem acesso aos recursos nas duas instâncias do Azure Stack Hub, porque elas compartilham o mesmo provedor de identidade.

Identidade e RBAC do Kubernetes

Por padrão, um cluster do Kubernetes não usa o mesmo provedor de identidade do Azure Stack Hub subjacente. As VMs que hospedam o cluster, o painel de controle e os nós de trabalho do Kubernetes usam a chave SSH especificada quando o cluster é implantado. Essa chave SSH é necessária para a conexão a esses nós por meio do SSH.

A API do Kubernetes (por exemplo, acessada por meio do kubectl) também é protegida por contas de serviço, incluindo uma conta de serviço padrão do administrador do cluster. As credenciais dessa conta de serviço são inicialmente armazenadas no arquivo .kube/config nos nós do painel de controle do Kubernetes.

Credenciais de aplicativo e gerenciamento de segredos

Há várias opções para armazenar segredos, como cadeias de conexão e credenciais de banco de dados, incluindo:

• Cofre de Chave do Azure
• Segredos do Kubernetes
• Soluções de terceiros como o HashiCorp Vault (em execução no Kubernetes)

Não armazene segredos nem credenciais em um texto sem formatação nos arquivos de configuração, no código do aplicativo ou em scripts. Não os armazene também em um sistema de controle de versão. Em vez disso, a automação da implantação deve recuperar os segredos conforme necessário.

Patch e atualização

O processo de patch e atualização no AKS é parcialmente automatizado. As atualizações de versão do Kubernetes são disparadas manualmente, enquanto as atualizações de segurança são aplicadas automaticamente. Essas atualizações podem incluir correções de segurança do sistema operacional ou atualizações de kernel. O AKS não reinicializa automaticamente esses nós do Linux para concluir o processo de atualização.

O processo de patch e atualização de um cluster do Kubernetes implantado por meio do Mecanismo do AKS no Azure Stack Hub não é gerenciado. É responsabilidade do operador do cluster.

O Mecanismo do AKS ajuda com as duas tarefas mais importantes:

• Atualização para uma versão mais recente da imagem base do sistema operacional e do Kubernetes
• Atualização somente da imagem base do sistema operacional

As imagens base mais recentes do sistema operacional contêm as últimas correções de segurança do sistema operacional e atualizações de kernel.

O utilitário de atualização autônoma instala automaticamente as atualizações de segurança que são lançadas antes de uma nova versão de imagem base do sistema operacional estar disponível no Marketplace do Azure Stack Hub. A atualização autônoma está habilitada por padrão e instala as atualizações de segurança automaticamente, mas não reinicializa os nós de cluster do Kubernetes. É possível automatizar a reinicialização dos nós com o uso do kured (Kubernetes Reboot Daemon) de código aberto. O daemon kured inspeciona os nós do Linux que exigem uma reinicialização e cuida automaticamente do reagendamento dos pods em execução e do processo de reinicialização dos nós.

Implantação (CI/CD)

O Azure e o Azure Stack Hub expõem as mesmas APIs REST do Resource Manager. Essas APIs são tratadas como em qualquer outra plataforma de nuvem do Azure (Azure, Azure China 21Vianet e Azure Governamental). As várias plataformas de nuvem podem usar diferentes versões de API, e o Azure Stack Hub fornece apenas um subconjunto de serviços. O URI do ponto de extremidade de gerenciamento também é diferente para cada plataforma de nuvem e cada instância do Azure Stack Hub.

Além das diferenças sutis mencionadas, as APIs REST do Resource Manager oferecem uma forma consistente de interagir com o Azure e o Azure Stack Hub. É possível usar o mesmo conjunto de ferramentas aqui como faria com qualquer outra plataforma de nuvem do Azure. Você pode usar o Azure DevOps, ferramentas como o Jenkins ou o PowerShell para implantar e orquestrar serviços no Azure Stack Hub.

Considerações

Uma das principais diferenças das implantações do Azure Stack Hub é a questão da implementação de acessibilidade da Internet. A acessibilidade da Internet determina se um agente de build auto-hospedado ou hospedado pela Microsoft deve ser escolhido para os trabalhos de CI/CD.

Um agente auto-hospedado pode ser executado no Azure Stack Hub (como uma VM IaaS) ou em uma sub-rede da rede que possa acessar o Azure Stack Hub. Para obter mais informações sobre as diferenças, consulte Agentes do Azure Pipelines.

O fluxograma a seguir pode ajudar você a decidir se precisará de um agente de build auto-hospedado ou hospedado pela Microsoft:

• Os pontos de extremidade de gerenciamento do Azure Stack Hub podem ser acessados pela Internet?
  • Sim: É possível usar o Azure Pipelines com agentes hospedados pela Microsoft para se conectar ao Azure Stack Hub.
  • Não: São necessários agentes auto-hospedados que possam se conectar aos pontos de extremidade de gerenciamento do Azure Stack Hub.
• O cluster do Kubernetes pode ser acessado pela Internet?
  • Sim: É possível usar o Azure Pipelines com agentes hospedados pela Microsoft para interagir diretamente com o ponto de extremidade da API do Kubernetes.
  • Não: São necessários agentes auto-hospedados que possam se conectar ao ponto de extremidade da API do cluster do Kubernetes.

Se os pontos de extremidade de gerenciamento do Azure Stack Hub e a API do Kubernetes puderem ser acessados pela Internet, a implantação poderá usar um agente hospedado pela Microsoft. Essa implantação resulta na seguinte arquitetura de aplicativo:

Se os pontos de extremidade do Resource Manager, a API do Kubernetes ou ambos não puderem ser acessados diretamente pela Internet, será possível aproveitar um agente de build auto-hospedado para executar as etapas do pipeline. Esse design requer menos conectividade. Ele pode ser implantado só com a conectividade de rede local com os pontos de extremidade do Resource Manager e a API do Kubernetes:

A solução pode usar um cluster do Kubernetes, implantado e orquestrado com o Mecanismo do AKS, em cada instância do Azure Stack Hub. Ele inclui um aplicativo que consiste em um front-end, uma camada intermediária e serviços de back-end (por exemplo, o MongoDB) e um controlador de entrada baseado no NGINX. Em vez de usar um banco de dados hospedado no cluster do Kubernetes, você pode usar armazenamentos de dados externos. As opções de banco de dados incluem o MySQL, o SQL Server ou qualquer tipo de banco de dados hospedado fora do Azure Stack Hub ou na IaaS. Essas configurações estão fora do escopo desse artigo.

Soluções de parceiros

É possível usar soluções de parceiros da Microsoft para estender as funcionalidades do Azure Stack Hub. Essas soluções podem ser úteis nas implantações de aplicativos que são executados nos clusters do Kubernetes.

Soluções de armazenamento e dados

Como observado anteriormente, ao contrário do Azure, o Azure Stack Hub atualmente não tem uma solução nativa para replicar o armazenamento em várias instâncias. No Azure Stack Hub, cada instância é a própria nuvem distinta. No entanto, é possível obter soluções parceiros da Microsoft que habilitam a replicação de armazenamento entre os Azure Stack Hubs e o Azure:

• O Scality fornece armazenamento em escala da Web. O armazenamento definido pelo software Scality RING transforma os servidores x86 de mercadoria em um pool de armazenamento ilimitado para qualquer tipo de dados em escala de petabytes.
• O Cloudian fornece armazenamento escalonável ilimitado que consolida grandes conjuntos de dados em um único ambiente.

Próximas etapas

• Visão geral do Azure Stack Hub
• Visão geral do Azure Repos
• Visão geral do Azure Pipelines
• Visão geral do Azure Monitor
• Escala entre nuvens no Azure Stack Hub
• Padrões de aplicativo distribuído geograficamente no Azure Stack Hub
• Treinamento: Azure Stack Hub

Recursos relacionados

• Arquitetura de microsserviços no AKS (Serviço de Kubernetes do Azure)
• Guia de implantação de cluster do Kubernetes de alta disponibilidade