Criar um cluster Kubernetes de alta disponibilidade no Azure Stack Hub

Este artigo descreve como arquitetar e operar uma infraestrutura baseada em Kubernetes altamente disponível usando o mecanismo do Serviço Kubernetes do Azure (AKS) no Azure Stack Hub. A solução baseia-se num cenário que tem um conjunto rigoroso de restrições. A aplicação deve ser executada no local e os dados pessoais não devem chegar aos serviços de nuvem pública. O monitoramento e outros dados não PII podem ser enviados para o Azure e processados lá. Serviços externos, como um registro de contêiner público, podem ser acessados, mas podem ser filtrados por meio de um firewall ou servidor proxy.

Helm e Let's Encrypt são marcas comerciais de suas respetivas empresas. O uso destas marcas não implica qualquer endosso.

Arquitetura

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

Fluxo de Trabalho

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

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

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

Serviços como o Azure Container Registry e o Azure Monitor são hospedados fora do Azure Stack Hub no Azure ou localmente. Esse design híbrido protege a solução contra a interrupção de uma única instância 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 em 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 Azure Resource Manager 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 Azure Stack Hub para as máquinas virtuais (VMs) que hospedam a infraestrutura de cluster do Kubernetes.
• O Azure Load Balancer é usado para o ponto de extremidade da API do Kubernetes e o Nginx Ingress Controller. O balanceador de carga roteia o tráfego externo (por exemplo, internet) para nós e VMs que fornecem um serviço específico.
• O Registro de Contêiner é usado para armazenar imagens privadas do Docker e gráficos Helm, que são implantados no cluster. O mecanismo AKS pode se autenticar com o registro de contêiner usando uma identidade do Microsoft Entra. O Kubernetes não requer Registro de Contêiner. Você pode 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. Você também pode usar o GitHub ou outros repositórios baseados em Git.
• O Azure Pipelines faz parte dos Serviços de DevOps do Azure. Ele executa compilações, testes e implantações automatizados. Você também pode usar soluções de CI/CD de terceiros, como Jenkins.
• O Azure Monitor coleta e armazena métricas e logs, incluindo métricas de plataforma para os serviços do Azure na solução e telemetria de aplicativos. Use esses dados para monitorar o aplicativo, configurar alertas e painéis e executar a análise de 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 de nó de plano de controle.
• O Azure Traffic Manager é um balanceador de carga de tráfego baseado em DNS que você pode usar para distribuir o tráfego de forma otimizada para serviços em diferentes regiões do Azure ou implantações do Azure Stack Hub. O Traffic Manager também oferece alta disponibilidade e capacidade de resposta. Os pontos de extremidade do aplicativo devem estar acessíveis do lado de fora para serem adicionados como pontos de extremidade ao Gerenciador de Tráfego do Azure.
• Um controlador de entrada do Kubernetes expõe rotas HTTP(S) para serviços em um cluster Kubernetes. Você pode usar NGINX ou qualquer controlador de entrada adequado.
• Helm é um gerenciador de pacotes para implantação do Kubernetes. Ele fornece uma maneira de agrupar diferentes objetos do Kubernetes, como Deployments, Services, e Secrets, em um único "gráfico". Você pode publicar, implantar, versionar e atualizar um objeto de gráfico. Você pode usar o Registro de contêiner como um repositório para armazenar gráficos Helm empacotados.

Alternativas

O Gerenciador de Tráfego do Azure é uma das opções para distribuir o tráfego entre dois pontos finais 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 Azure Stack Hub. Pode haver cenários em que os pontos finais do aplicativo hospedados no Azure Stack Hub devem ser restritos apenas à sua rede privada. 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 elas colocalizadas no mesmo data center ou implantadas 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 a dependência do fornecedor. Por exemplo, o aplicativo usa um back-end de banco de dados MongoDB auto-hospedado em vez de um serviço PaaS ou serviço de banco de dados externo. Para obter mais informações, consulte a Introdução ao Kubernetes no caminho de aprendizado do Azure .

Potenciais casos de utilização

Muitas organizações estão desenvolvendo soluções nativas da nuvem que aproveitam serviços e tecnologias de última geração, como o Kubernetes. Embora o Azure forneça datacenters na maioria das regiões do mundo, às vezes os aplicativos críticos para os negócios devem ser executados em um local específico. As potenciais preocupações incluem:

• Sensibilidade à localização.
• Latência entre o aplicativo e os sistemas locais.
• Conservação da largura de banda.
• Conectividade.
• Requisitos regulamentares ou estatutários.

O Azure, em combinação com o Azure Stack Hub, aborda 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 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 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.

Estruturar

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

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

Essas práticas recomendadas também se aplicam a cargas de trabalho e cenários do mundo real.

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 escalabilidade ajuda a fornecer acesso consistente, confiável e de bom desempenho ao aplicativo.

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

Nível de arquitetura	Afetos	Como?
Aplicação	Aplicação	Dimensionamento 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, através do comando manual scale AKS Engine, 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.

* Através do Kubernetes HorizontalPodAutoscaler, que fornece dimensionamento automatizado baseado em métricas, ou escalonamento vertical dimensionando as 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 escolher o hardware do hub, você precisa escolher a CPU, a densidade de memória, a configuração de armazenamento e o número de servidores. Para saber mais sobre a escalabilidade do Azure Stack Hub, consulte estes recursos:

• Visão geral do planejamento de 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 cluster Kubernetes em si consiste e é construído sobre os componentes IaaS do Azure e do Azure Stack Hub, incluindo recursos de computação, armazenamento e rede. As soluções Kubernetes são compostas por nós de plano de controle e nós de trabalho, que são implantados como VMs no Azure e no Azure Stack Hub.

• Os nós do plano de controle fornecem os principais serviços do Kubernetes e orquestração de cargas de trabalho de aplicativos.
• Os nós de trabalho executam as cargas de trabalho do aplicativo.

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

• Custo. Ao planejar os nós de trabalho, considere o custo geral por VM. Por exemplo, se as cargas de trabalho do aplicativo exigirem recursos limitados, você deve planejar a implantação de VMs menores. O Azure Stack Hub, como o Azure, normalmente é cobrado com base no consumo, portanto, dimensionar adequadamente as VMs para funções do Kubernetes é crucial para otimizar os custos de consumo.

• Escalabilidade. Você obtém escalabilidade do cluster dimensionando e reduzindo o número de nós de trabalho e do plano de controle ou adicionando pools de nós. (No momento, não é possível adicionar pools de nós no Azure Stack Hub.) Você pode dimensionar o cluster com base nos dados de desempenho coletados com informações de contêiner (Azure Monitor e Log Analytics).

  Se seu aplicativo precisar de mais ou menos recursos, você poderá dimensionar o número de nós para fora ou horizontalmente, entre 1 e 50 nós. Se precisar de mais de 50 nós, você pode criar outro cluster em uma assinatura separada. Não é possível dimensionar as VMs reais verticalmente para outro tamanho de VM sem reimplantar o cluster.

  Implemente o dimensionamento manualmente usando a VM auxiliar do mecanismo AKS que você usou para implantar o cluster do Kubernetes. Para obter mais informações, consulte Dimensionamento de clusters Kubernetes.

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

• Cargas de trabalho de aplicativos. Consulte os conceitos de clusters e cargas de trabalho no artigo Conceitos principais do Kubernetes para o Serviço Kubernetes do Azure. Esse artigo pode ajudá-lo a definir o escopo do tamanho da VM com base nas necessidades de computação e memória do aplicativo.

Aplicação (nível de aplicação)

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

Outra opção é dimensionar instâncias de contêiner verticalmente. Você pode realizar esse tipo de dimensionamento alterando a quantidade de CPU e memória solicitada e disponível para uma implantação específica. Para obter mais informações, consulte Gerenciando 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	Afetos	O quê?
Aplicação	Aplicação	Como o aplicativo pode ser acessado. Se está exposto à internet.
Cluster	Cluster do Kubernetes	API do Kubernetes, VM do mecanismo AKS, extração 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 o portal e os pontos de extremidade do Azure Resource Manager.

Aplicação

Na camada de aplicação, a consideração mais importante é se a aplicação está exposta à Internet e pode ser acedida a partir da Internet. Do ponto de vista do Kubernetes, o acesso à Internet requer a exposição de uma implantação ou pod usando um Serviço Kubernetes ou um controlador de entrada.

Uma aplicação pode ser exposta com um IP público através de um balanceador de carga ou de um controlador de entrada sem estar acessível através da Internet. O Azure Stack Hub pode ter um endereço IP público visível apenas na intranet local. Nem todos os IPs públicos são verdadeiramente voltados para a Internet.

Além do tráfego de entrada no aplicativo, você também precisa considerar o tráfego de saída ou saída. Aqui estão alguns casos de uso que exigem tráfego de saída:

• Extraindo imagens de contêiner armazenadas no Docker Hub ou no Registro de Contêiner
• Recuperando gráficos do Helm
• Emissão 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 configuração específica em vários componentes do cluster. A documentação do AKS Engine contém detalhes sobre como acomodar proxies de rede. Para obter mais informações, consulte Mecanismo AKS e servidores proxy.

Por fim, o tráfego entre clusters deve fluir entre instâncias do Azure Stack Hub. A solução descrita aqui consiste em clusters Kubernetes individuais que são executados em instâncias individuais do Azure Stack Hub. O tráfego entre eles, 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. A VPN site a site oferece mais segurança para transferências de dados e é preferida.

Cluster

O cluster Kubernetes não precisa necessariamente estar acessível via internet. A parte relevante é a API do Kubernetes que é usada para operar um cluster, por exemplo, via kubectl. Todos que operam o cluster ou implantam aplicativos e serviços sobre ele devem ser capazes de acessar o ponto de extremidade da API do Kubernetes. Este tópico é abordado com mais detalhes de uma perspetiva de DevOps na seção Implantação (CI/CD) deste artigo.

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

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

Antes de implantar seu cluster Kubernetes usando o AKS Engine, 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 usar uma conexão VPN site a site existente que já esteja configurada em seu ambiente do Azure Stack Hub.

Infraestrutura

Infraestrutura refere-se ao acesso aos pontos de extremidade de gerenciamento do Azure Stack Hub. Os pontos de extremidade incluem os portais de locatário e de administração e os pontos de extremidade de administrador e locatário do Gerenciador de Recursos. Esses pontos de extremidade são necessários para operar o Azure Stack Hub e seus serviços principais.

Dados e armazenamento

Duas instâncias do aplicativo são implantadas, em dois clusters Kubernetes individuais, em duas instâncias do Azure Stack Hub. Para esse design, você precisa 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. Eles formam duas nuvens independentes, e não há uma maneira abrangente de gerenciá-los como um conjunto. Ao planejar a resiliência de aplicativos executados no Azure Stack Hub, considere essa independência no design e nas implantações de aplicativos.

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

Esta arquitetura leva estes elementos em consideração:

Configuração

Esta categoria inclui a configuração do Azure Stack Hub, do AKS Engine e do próprio cluster Kubernetes. Você deve automatizar a configuração tanto quanto possível e armazená-la como infraestrutura como código em um sistema de controle de versão baseado em Git, como o Azure DevOps ou o GitHub. Não é possível sincronizar facilmente essas configurações em várias implantações. Recomendamos que você armazene e aplique a configuração do lado de fora e use o pipeline de DevOps.

Aplicação

Você deve armazenar o aplicativo em um repositório baseado em Git. Se você fizer isso, sempre que houver uma nova implantação, alterações no aplicativo ou recuperação de desastres, poderá implantar o aplicativo facilmente usando o Azure Pipelines.

Dados

Os dados são a consideração mais importante na maioria dos projetos de aplicativos. Os dados do aplicativo devem permanecer sincronizados entre as diferentes instâncias do aplicativo. Você também precisa de uma estratégia de backup e recuperação de desastres para os dados no caso de haver uma interrupção.

Se você estiver trabalhando com dados em vários locais, implementar uma solução altamente disponível e resiliente é ainda mais complexo. Considere:

• 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 integra-se a um diretório externo. Durante a implantação, você opta por usar a ID do Microsoft Entra ou os Serviços de Federação do Ative Directory (AD FS). Portanto, você tem a opção de usar uma única identidade que pode interagir com várias instâncias independentes do Azure Stack Hub.

Continuidade de negócio e recuperação após desastre

A continuidade de negócios e a recuperação de desastres (BCDR) são uma consideração importante para o Azure Stack Hub e o Azure. A principal diferença é que, para o Azure Stack Hub, o operador deve gerenciar todo o processo BCDR. Para o Azure, partes do 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 de aplicação

Essas áreas são de responsabilidade do operador do Azure Stack Hub. Os detalhes podem variar, dependendo da organização. Planeje o BCDR de acordo com suas ferramentas e 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. Abrange ações nos espaços de administração e inquilino.

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

• Recupere dados no Azure Stack Hub com o Serviço de Backup de Infraestrutura
• Habilitar o backup para o Azure Stack Hub no portal do administrador
• Recover from catastrophic data loss (Recuperar de uma perda de dados catastrófica)
• Infrastructure Backup Service best practices (Melhores práticas do Infrastructure Backup Service)

O Azure Stack Hub é a plataforma e a malha na qual os aplicativos Kubernetes são implantados. O proprietário do aplicativo Kubernetes é um usuário do Azure Stack Hub que tem acesso para implantar a infraestrutura de aplicativo necessária para a solução. A infraestrutura do aplicativo, neste caso, é o cluster Kubernetes, implantado via AKS Engine e os serviços ao redor.

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 Kubernetes tem capacidade suficiente, expressa em cotas do Azure Stack Hub, para implantar toda a solução. Conforme recomendado na seção anterior, você deve automatizar a implantação do aplicativo usando a infraestrutura como código e pipelines de implantação como o Azure Pipelines.

Para obter mais informações sobre ofertas e cotas do Azure Stack Hub, consulte 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 AKS Engine, incluindo suas saídas. Esses arquivos contêm informações confidenciais que são usadas para acessar o cluster do Kubernetes, portanto, devem ser protegidos contra exposição a não-administradores.

Disponibilidade do aplicativo

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

Dados de aplicação

Os dados de aplicativos são o componente crítico do BCDR. As seções anteriores descrevem 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, há várias técnicas de disponibilidade e backup de banco de dados disponíveis.

Para alcançar a integridade, recomendamos que você use uma das seguintes soluções:

• Uma solução de backup nativa para o banco de dados específico.
• Uma solução de backup que oferece suporte a backup e recuperação do tipo de banco de dados usado pelo seu aplicativo.

Disponibilidade

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

A infraestrutura do Azure Stack Hub já é resiliente a falhas e fornece recursos como conjuntos de disponibilidade para distribuir componentes em vários domínios de falha e atualização. Mas a tecnologia subjacente (clustering de failover) ainda incorre em algum tempo de inatividade para VMs em um servidor físico afetado, se houver uma falha de hardware.

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

Os clientes que têm um único cluster Kubernetes normalmente se conectam ao IP do serviço ou ao nome DNS de um 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/entrada em cada cluster Kubernetes.

O cluster Kubernetes em si, implantado via AKS Engine, deve consistir em pelo menos três nós de plano de controle e dois nós de trabalho.

Segurança

A segurança oferece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. Para obter mais informações, consulte 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 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 por aplicativos.)
• O RBAC do Kubernetes controla as permissões para a API do Kubernetes. Por exemplo, criar pods e listar pods são ações que podem ser concedidas ou negadas a um usuário via RBAC. Para atribuir permissões do Kubernetes aos usuários, crie funções e associações de funções.

Identidade do Azure Stack Hub e RBAC

O Azure Stack Hub fornece duas opções de provedor de identidade. O provedor que você usa depende do ambiente e se você está executando em um ambiente conectado ou desconectado:

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

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

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

O usuário de exemplo agora tem permissões de Colaborador para ambos os grupos de recursos que contêm todo o conjunto de recursos de infraestrutura do Kubernetes. O usuário tem acesso a recursos em ambas as instâncias do Azure Stack Hub porque as instâncias compartilham o mesmo provedor de identidade.

Identidade Kubernetes e RBAC

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

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

Gerenciamento de segredos e credenciais de aplicativos

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

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

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

Corrigir e atualizar

O processo de patch e atualização no AKS é parcialmente automatizado. As atualizações de versão do Kubernetes são acionadas manualmente e 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 do kernel. O AKS não reinicia automaticamente os nós do Linux para concluir o processo de atualização.

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

O AKS Engine ajuda nas duas tarefas mais importantes:

• Atualize para uma versão mais recente do Kubernetes e da imagem base do sistema operacional
• Atualize apenas a imagem base do SO

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

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

Implantação (CI/CD)

O Azure e o Azure Stack Hub expõem as mesmas APIs REST do Resource Manager. Você aborda essas APIs como faria em qualquer outra plataforma de nuvem do Azure (Azure, Azure China 21Vianet, Azure Government). 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 para cada instância do Azure Stack Hub.

Além das diferenças sutis mencionadas, as APIs REST do Resource Manager fornecem uma maneira consistente de interagir com o Azure e o Azure Stack Hub. Você pode 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 Jenkins ou PowerShell para implantar e orquestrar serviços no Azure Stack Hub.

Considerações

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

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

O fluxograma a seguir pode ajudá-lo a decidir se precisa de um agente de compilação auto-hospedado ou hospedado pela Microsoft:

• Os pontos de extremidade de gerenciamento do Azure Stack Hub podem ser acessados pela Internet?
  • Sim: você pode usar o Azure Pipelines com agentes hospedados pela Microsoft para se conectar ao Azure Stack Hub.
  • Não: você precisa de agentes auto-hospedados que possam se conectar aos pontos de extremidade de gerenciamento do Azure Stack Hub.
• O cluster Kubernetes pode ser acessado via internet?
  • Sim: você pode usar o Azure Pipelines com agentes hospedados pela Microsoft para interagir diretamente com o ponto de extremidade da API do Kubernetes.
  • Não: você precisa de agentes auto-hospedados que possam se conectar ao ponto de extremidade da API do cluster 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, você poderá usar um agente de compilação auto-hospedado para executar as etapas do pipeline. Este design requer menos conectividade. Ele pode ser implantado apenas com conectividade de rede local para pontos de extremidade do Resource Manager e a API do Kubernetes:

A solução pode usar um cluster Kubernetes, implantado e orquestrado com o AKS Engine, em cada instância do Azure Stack Hub. Ele inclui um aplicativo que consiste em um front-end, uma camada intermediária, serviços back-end (por exemplo, MongoDB) e um controlador de entrada baseado em 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 MySQL, SQL Server ou qualquer tipo de banco de dados hospedado fora do Azure Stack Hub ou em IaaS. Essas configurações estão fora do escopo deste artigo.

Soluções de parceiros

Você pode usar soluções de parceiros da Microsoft para estender os recursos do Azure Stack Hub. Essas soluções podem ser úteis em implantações de aplicativos executados em clusters Kubernetes.

Soluções de armazenamento e dados

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

• O Scality fornece armazenamento em escala web. O armazenamento definido por 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 escalável ilimitado que consolida conjuntos de dados massivos em um único ambiente.

Próximos passos

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

Recursos relacionados

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