Padrão de cluster do Kubernetes de alta disponibilidade

Este artigo descreve como arquitetar e operar uma infraestrutura altamente disponível baseada em Kubernetes usando o Mecanismo do AKS (Serviço de Kubernetes do Azure) no Azure Stack Hub. Esse cenário é comum para organizações com cargas de trabalho críticas em ambientes altamente restritos e regulamentados. Organizações em domínios como finanças, defesa e governo.

Contexto e problema

Muitas organizações estão desenvolvendo soluções nativas de nuvem que usam serviços de última geração e tecnologias como o Kubernetes. Embora o Azure forneça datacenters na maioria das regiões do mundo, às vezes há casos de uso de borda e cenários em que aplicativos comercialmente críticos devem ser executados em um local específico. As considerações incluem:

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

O Azure, em combinação com o Azure Stack Hub, aborda a maioria dessas preocupações. Um amplo conjunto de opções, decisões e considerações para uma implementação bem-sucedida do Kubernetes em execução no Azure Stack Hub é descrito abaixo.

Solução

Esse padrão pressupõe que temos que lidar com um conjunto estrito de restrições. O aplicativo deve ser executado localmente e todos os dados pessoais não devem acessar os 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 ou outros podem ser acessados, mas podem ser filtrados por meio de um firewall ou servidor proxy.

O aplicativo de exemplo mostrado aqui é projetado para usar soluções nativas do Kubernetes sempre que possível. Esse design evita o bloqueio do fornecedor ao não usar serviços nativos de plataforma. Por exemplo, o aplicativo usa um back-end de banco de dados do 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 a introdução ao Kubernetes no roteiro de aprendizagem do Azure.

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

1. Um cluster do Kubernetes baseado no AKS Engine no Azure Stack Hub.
2. cert-manager, que fornece um conjunto de ferramentas para gerenciamento de certificados no Kubernetes, era usado para solicitar automaticamente certificados do Let's Encrypt.
3. Um namespace do Kubernetes que contém os componentes do aplicativo para o front-end (ratings-web), API (ratings-api) e 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 única implantação de aplicativo. Para obter alta disponibilidade (HA), executamos a implantação pelo menos duas vezes em duas instâncias diferentes do Azure Stack Hub: elas podem ser executadas no mesmo local ou em dois (ou mais) sites diferentes:

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

Componentes

A arquitetura geral consiste nos seguintes componentes:

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. Acesse a visão geral do Azure Stack Hub para saber mais.

Azure Kubernetes Service Engine (AKS Engine) é o mecanismo por trás do serviço de Kubernetes gerenciado, Azure Kubernetes Service (AKS), que está disponível no Azure hoje. Para o Azure Stack Hub, o AKS Engine nos permite implantar, dimensionar e atualizar clusters Kubernetes com todos os recursos e autogerenciados, usando os recursos de IaaS do Azure Stack Hub. Acesse Visão geral do Mecanismo do AKS para saber mais.

Acesse Problemas Conhecidos e Limitações para saber mais sobre as diferenças entre o AKS Engine no Azure e o AKS Engine no Azure Stack Hub.

VNet (Rede Virtual) do Azure é usado para fornecer a infraestrutura de rede em cada Azure Stack Hub para 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, Internet) para os nós e as VMs que oferecem um serviço específico.

O ACR (Registro de Contêiner do Azure) é usado para armazenar imagens privadas 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 usando a ID do Microsoft Entra. O Kubernetes não requer a ACR. Você pode usar outros registros de contêiner, como o Hub do Docker.

do 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. Acesse Visão geral do Azure Repos para saber mais.

Azure Pipelines faz parte do Azure DevOps Services e executa builds, testes e implantações automatizados. Você também pode usar soluções de CI/CD de terceiros, como o Jenkins. Acesse Visão geral do Azure Pipeline para saber mais.

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 a telemetria do aplicativo. Use esses dados para monitorar o aplicativo, configurar alertas e dashboards 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 e contêineres, bem como logs do contêiner e logs do nó mestre. Para saber mais, acesse Azure Monitor: visão geral.

Azure Traffic Manager é um balanceador de carga de tráfego baseado em DNS que permite 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 precisam ser acessíveis externamente. Há outras soluções locais disponíveis também.

O Controlador de Entrada do Kubernetes expõe as rotas HTTP(S) aos serviços em um cluster do Kubernetes. O Nginx ou qualquer controlador de entrada adequado pode ser usado para essa finalidade.

Helm é um gerenciador de pacotes para implantação do Kubernetes, fornecendo uma maneira de agrupar diferentes objetos do Kubernetes, como Implantações, Serviços, Segredos, em um único "gráfico". Você pode publicar, implantar, controlar o gerenciamento de versão e atualizar um objeto de gráfico. O Registro de Contêiner do Azure pode ser usado como um repositório para armazenar gráficos empacotados do Helm.

Considerações sobre design

Esse padrão segue algumas considerações de alto nível explicadas com mais detalhes nas próximas seções deste artigo:

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

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

Considerações sobre escalabilidade

A escalabilidade é importante para fornecer aos usuários acesso consistente, confiável e com bom desempenho ao aplicativo.

O cenário de exemplo aborda a escalabilidade em várias camadas da pilha de aplicativos. Aqui está uma visão geral de alto nível das diferentes camadas:

Nível de arquitetura	Afeta	Como?
Aplicação	Aplicação	Escala horizontal com base no número de pods/réplicas/Instâncias de Contêiner*
Agrupamento	Cluster do Kubernetes	Número de nós (entre 1 e 50), tamanhos de SKU da VM e pools de nós (atualmente, o Mecanismo do AKS no Azure Stack Hub só dá suporte a um pool de nós); uso do comando scale do Mecanismo do AKS (manual)
Infra-estrutura	Azure Stack Hub	Número de nós, capacidade e unidades de escala em uma implantação do Azure Stack Hub

* Usando o HPA (Dimensionador Automático de Pod Horizontal) do Kubernetes; dimensionamento horizontal automatizado baseado em métricas ou dimensionamento vertical através do dimensionamento das instâncias de contêiner (cpu/memória).

hub do Azure Stack (nível de infraestrutura)

A infraestrutura do Azure Stack Hub é a base dessa implementação, pois o Azure Stack Hub é executado em hardware físico em um datacenter. Ao selecionar o hardware do Hub, você precisa fazer escolhas para CPU, densidade de memória, configuração de armazenamento e número de servidores. Para saber mais sobre a escalabilidade do Azure Stack Hub, confira os seguintes recursos:

• Planejamento de capacidade para o Azure Stack Hub: visão geral
• Adicionar nós de unidade de escala adicionais no Azure Stack Hub

Cluster do Kubernetes (nível de cluster)

O cluster Kubernetes em si consiste de e é construído sobre componentes IaaS do Azure (Stack), incluindo recursos de computação, armazenamento e rede. As soluções do Kubernetes envolvem nós mestre e de trabalho, que são implantados como VMs no Azure (e no Azure Stack Hub).

• Os nós do painel de controle (mestre) fornecem os serviços principais de Kubernetes e a orquestração de cargas de trabalho do aplicativo.
• Os nós de trabalho (trabalho) executam as cargas de trabalhos do aplicativo.

Quando você seleciona tamanhos de VM para a implantação inicial, há várias considerações:

• Custo – Ao planejar seus nós de trabalho, tenha em mente o custo geral por VM que você terá. Por exemplo, se as cargas de trabalho do aplicativo exigirem recursos limitados, você deverá planejar a implantação de VMs de tamanho menor. O Azure Stack Hub, como o Azure, normalmente é cobrado em uma base de consumo, portanto, dimensionar adequadamente as VMs para funções do Kubernetes é crucial para otimizar os custos de consumo.

• Escalabilidade: a escalabilidade do cluster é obtida pela escala e pela redução do número de nós mestres e de trabalho ou pela adição de pools de nós extras (não disponíveis atualmente no Azure Stack Hub). O dimensionamento do cluster pode ser feito com base nos dados de desempenho, coletados usando o Container Insights (Azure Monitor + Log Analytics).

  Se o seu aplicativo precisar de mais (ou menos) recursos, você poderá escalar seus nós atuais horizontalmente para fora (ou para dentro) entre 1 e 50 nós. Se você precisar de mais de 50 nós, poderá criar um cluster adicional em uma assinatura separada. Você não pode escalar verticalmente as VMs reais para outro tamanho de VM sem reimplantar o cluster.

  O dimensionamento é feito manualmente usando a VM auxiliar do AKS Engine que foi utilizada inicialmente para implantar o cluster do Kubernetes. Para obter mais informações, consulte Dimensionamento de clusters do Kubernetes

• Cotas: considere as cotas que você configura 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 precisa 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 nos conceitos principais do Kubernetes no documento sobre o Azure Kubernetes Service. Este artigo ajuda você a definir o escopo do tamanho adequado da VM com base nas necessidades de computação e memória do seu aplicativo.

Aplicativo (nível de aplicativo)

Na camada de aplicativo, usamos o Kubernetes Horizontal Pod Autoscaler (HPA). O HPA pode aumentar ou diminuir o número de réplicas (pod/Instâncias de Contêiner) em nossa implantação com base em diferentes métricas (como utilização da CPU).

Outra opção é dimensionar as instâncias de contêiner verticalmente. Isso pode ser feito alterando a quantidade de CPU e memória solicitadas e disponíveis para uma implantação específica. Consulte Gerenciamento de Recursos para Contêineres sobre kubernetes.io para saber mais.

Considerações sobre rede e conectividade

A rede e a conectividade também afetam as três camadas mencionadas anteriormente para o Kubernetes no Azure Stack Hub. A tabela a seguir mostra as camadas e quais serviços eles contêm:

Camada	Afeta	Que?
Aplicação	Aplicação	Como o aplicativo está acessível? Será exposto à Internet?
Agrupamento	Cluster do Kubernetes	API do Kubernetes, VM do Mecanismo do AKS, pull de imagens de contêiner (saída), envio de dados de monitoramento e telemetria (saída)
Infra-estrutura	Azure Stack Hub	A acessibilidade dos endpoints de gerenciamento do Azure Stack Hub, incluindo o portal e os endpoints do Azure Resource Manager.

Aplicativo

Para a camada de aplicativo, a consideração mais importante é se o aplicativo é exposto e acessível da Internet. Da perspectiva dos Kubernetes, a acessibilidade da Internet significa expor uma implantação ou um pod usando um Serviço de Kubernetes ou um controlador de entrada.

Expor um aplicativo usando um IP público por meio de um Load Balancer ou um Controlador de Entrada não significa que o aplicativo agora esteja acessível por meio da Internet. É possível que o Azure Stack Hub tenha um endereço IP público que só esteja visível na intranet local - nem todos os IPs públicos são verdadeiramente voltados para a Internet.

O bloco anterior considera o tráfego de entrada para o aplicativo. Outra consideração para uma implementação bem-sucedida do Kubernetes é o tráfego de saída/egresso. Aqui estão alguns casos de uso que exigem tráfego de saída:

• Puxando imagens de contêiner armazenadas no DockerHub ou no Registro de Contêiner do Azure
• Recuperação de gráficos do Helm
• Emitindo dados do Application Insights (ou outros dados de monitoramento)

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 nosso cluster. A documentação do AKS Engine contém diversos detalhes sobre como acomodar proxies de rede. Para obter mais informações, consulte o Mecanismo do AKS e servidores proxy

Por fim, o tráfego entre clusters deve fluir entre instâncias do Azure Stack Hub. A implantação de exemplo consiste em clusters Kubernetes individuais em execução em instâncias independentes do Azure Stack Hub. O tráfego entre eles, como o tráfego de replicação entre dois bancos de dados, é "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 para conectar o Kubernetes em duas instâncias do Azure Stack Hub:

Cluster

O cluster do Kubernetes não precisa necessariamente ser acessível por meio da Internet. A parte relevante é a API do Kubernetes usada para operar um cluster, por exemplo, usando kubectl. O ponto de extremidade da API do Kubernetes deve estar acessível a todos que operam o cluster ou implantam aplicativos e serviços sobre ele. Este tópico é abordado mais detalhadamente da perspectiva de DevOps na seção Considerações sobre implantação (CI/CD) abaixo.

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 Azure LogAnalytics)
• Outros agentes que exigem tráfego de saída (específico para o ambiente de cada implantador)

Antes de implantar o cluster do Kubernetes usando o Mecanismo do AKS, planeje o design de rede final. Em vez de criar uma Rede Virtual dedicada, pode ser mais eficiente implantar um cluster em uma rede existente. Por exemplo, você pode usar uma conexão VPN site a site existente já configurada em 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 Azure Resource Manager. Esses pontos de extremidade são necessários para operar o Azure Stack Hub e os serviços principais dele.

Considerações sobre dados e armazenamento

Duas instâncias do nosso aplicativo serão implantadas, em dois clusters kubernetes individuais, em duas instâncias do Azure Stack Hub. Esse design exige que consideremos como replicar e sincronizar dados entre eles.

Com o Azure, temos a capacidade interna de replicar o armazenamento em várias regiões e zonas dentro da nuvem. Atualmente, com o Azure Stack Hub, não há maneiras nativas de replicar o armazenamento em duas instâncias diferentes do Azure Stack Hub: elas formam duas nuvens independentes sem nenhuma maneira abrangente de gerenciá-las como um conjunto. O planejamento de resiliência de aplicativos em execução no Azure Stack Hub força você a considerar essa independência no design e nas implantações do aplicativo.

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 no design do aplicativo. Se esse design for uma preocupação ou um obstáculo para implantar a solução no Azure Stack Hub, há soluções possíveis de parceiros da Microsoft que fornecem soluções de armazenamento. Os anexos de armazenamento fornecem uma solução de replicação de armazenamento em vários Azure Stack Hubs e no Azure. Para obter mais informações, consulte as soluções do Partner.

Em nossa arquitetura, essas camadas foram consideradas:

Configuração

A configuração inclui a configuração do Azure Stack Hub, do AKS Engine e do próprio cluster Kubernetes. A configuração deve ser automatizada o máximo possível e armazenada como Infraestrutura como Código em um sistema de controle de versão baseado em Git, como o Azure DevOps ou o GitHub. Essas configurações não podem ser sincronizadas facilmente em várias implantações. Portanto, recomendamos armazenar e aplicar a configuração de fora e usar o pipeline de DevOps.

Aplicativo

O aplicativo deve ser armazenado em um repositório baseado em Git. Sempre que houver uma nova implantação, alterações no aplicativo ou recuperação de desastre, ela poderá ser facilmente implantada usando o Azure Pipelines.

Dados

Os dados são a consideração mais importante na maioria dos designs de aplicativos. Os dados do aplicativo devem permanecer em sincronia entre as diferentes instâncias do aplicativo. Os dados também precisarão de uma estratégia de backup e recuperação de desastre se houver uma interrupção.

A obtenção desse design depende muito das opções de tecnologia. Aqui estão alguns exemplos de solução para implementar um banco de dados de forma altamente disponível no Azure Stack Hub:

• implantar um grupo de disponibilidade do SQL Server 2016 no Azure e no Azure Stack Hub
• Implantar uma solução do MongoDB altamente disponível no Azure e no Azure Stack Hub

Considerações ao trabalhar com dados em vários locais é uma consideração ainda mais complexa para uma solução altamente disponível e resiliente. Considere:

• Latência e conectividade de rede entre os Hubs do Azure Stack.
• 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 a Federação de IDs do Microsoft Entra. Dessa forma, há potencial para usar uma única identidade que pode interagir com várias instâncias independentes do Azure Stack Hub.

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

A BCDR (continuidade dos negócios e recuperação de desastre) é um tópico importante no Azure Stack Hub e no Azure. A principal diferença é que, no Azure Stack Hub, o operador deve gerenciar todo o processo de BCDR. No Azure, partes do BCDR são gerenciadas automaticamente pela Microsoft.

O BCDR afeta as mesmas áreas mencionadas na seção anterior considerações sobre dados e armazenamento:

• Infraestrutura/Configuração
• Disponibilidade do aplicativo
• Dados do aplicativo

E, conforme mencionado na seção anterior, essas áreas são de responsabilidade do operador do Azure Stack Hub e podem variar entre as organizações. Planeje 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. Ele abrange ações na área administrativa e nos espaços de inquilinos.

O operador do Azure Stack Hub (ou administrador) é responsável pela manutenção das instâncias do Azure Stack Hub. Incluindo componentes como rede, armazenamento, identidade e outros tópicos que estão fora do escopo deste artigo. Para saber mais sobre as especificidades das operações do Azure Stack Hub, confira os seguintes recursos:

• Recuperar 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
• 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 na qual os aplicativos Kubernetes serão implantados. O proprietário do aplicativo para o aplicativo Kubernetes será um usuário do Azure Stack Hub, com acesso concedido para implantar a infraestrutura de aplicativo necessária para a solução. A infraestrutura do aplicativo, nesse caso, significa o cluster Kubernetes, implantado usando AKS Engine, e os serviços ao redor. Esses componentes são implantados no Azure Stack Hub, restringidos por uma 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, a implantação do aplicativo deve ser automatizada usando Infraestrutura-como-Código e pipelines de implantação, como o Azure DevOps e Azure Pipelines.

Para obter mais informações sobre ofertas e cotas do Azure Stack Hub, consulte visão geral de 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 kubernetes, portanto, eles devem ser protegidos contra serem expostos a não administradores.

Disponibilidade do aplicativo

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

Dados do aplicativo

Os dados do aplicativo são a parte crítica para minimizar a perda de dados. Na seção anterior, foram descritas técnicas para replicar e sincronizar dados entre duas (ou mais) instâncias do aplicativo. Dependendo da infraestrutura de banco de dados (MySQL, MongoDB, MSSQL ou outros) usada para armazenar os dados, haverá diferentes técnicas de disponibilidade e backup de banco de dados disponíveis para escolha.

As maneiras recomendadas de obter integridade são usar:

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

Importante

Não armazene seus dados de backup na mesma instância do Azure Stack Hub em que os dados do aplicativo residem. Uma interrupção completa da instância do Azure Stack Hub também comprometeria seus backups.

Considerações sobre disponibilidade

O Kubernetes no Azure Stack Hub implantado por meio do Mecanismo do AKS não é um serviço gerenciado. É uma implantação automatizada e uma configuração de um cluster kubernetes usando IaaS (Infraestrutura como Serviço) do Azure. Dessa forma, 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 . 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 e a carga de trabalho, em dois ou mais clusters. Esses clusters devem ser hospedados em locais ou datacenters diferentes e usar tecnologias como o Gerenciador de Tráfego do Azure para rotear usuários com base no tempo de resposta do cluster ou com base 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/o ingress em cada cluster do Kubernetes.

Nota

Esse padrão também é uma prática recomendada para clusters AKS (gerenciados) no Azure.

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

Considerações sobre identidade e segurança

Identidade e segurança são tópicos importantes. Especialmente 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 aos recursos no Azure (e no 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 as permissões para a API do Kubernetes. Por exemplo, a criação e a listagem de pods são ações que podem ser autorizadas (ou negadas) a um usuário por meio de RBAC. Para atribuir permissões do 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 da execução em um ambiente conectado ou desconectado:

• ID do Microsoft Entra – só pode ser usada em um ambiente conectado.
• A Federação de ID do Microsoft Entra para uma floresta tradicional do Active Directory pode ser usada 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 aos recursos do Azure Stack Hub, como assinaturas, grupos de recursos e recursos individuais, como VMs ou balanceadores de carga. Para ter um modelo de acesso consistente, você deve considerar o uso dos mesmos grupos (diretos ou aninhados) para todos os Hubs do Azure Stack. Aqui está um exemplo de configuração:

O exemplo contém um grupo dedicado para uma finalidade específica. Por exemplo, para fornecer permissões de Colaborador ao grupo de recursos que contém nossa infraestrutura de cluster do Kubernetes em uma instância específica do Azure Stack Hub (aqui, "Colaborador do Cluster do K8s Seattle"). Esses grupos são aninhados em um grupo geral que contém os "subgrupos" para cada Azure Stack Hub.

Nosso usuário de exemplo agora terá 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, pois as instâncias compartilham o mesmo provedor de identidade.

Importante

Essas permissões afetam apenas o Azure Stack Hub e alguns dos recursos implantados em cima dele. Um usuário que tem esse nível de acesso pode causar muitos danos, mas não pode acessar as VMs de IaaS do Kubernetes nem a API do Kubernetes sem acesso adicional à implantação do Kubernetes.

Identidade e RBAC do Kubernetes

Um cluster do Kubernetes, por padrão, não usa o mesmo Provedor de Identidade que o Azure Stack Hub subjacente. As VMs que hospedam o cluster kubernetes, o mestre e os nós de trabalho, usam a chave SSH especificada durante a implantação do cluster. Essa chave SSH é necessária para se conectar a esses nós usando SSH.

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

Gerenciamento de segredos e credenciais de aplicativo

Para armazenar segredos como cadeias de conexão ou credenciais de banco de dados, há várias opções, incluindo:

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

Não armazene segredos ou credenciais em texto sem formatação nos arquivos de configuração, no código do aplicativo ou nos scripts. E não armazene-os 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 (PNU) no Serviço de Kubernetes do Azure é 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 PNU para um cluster Kubernetes implantado usando o AKS Engine no Azure Stack Hub não é gerenciado e é responsabilidade do operador de cluster.

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

• Atualizar para uma versão mais recente do Kubernetes e da imagem base do sistema operacional
• Apenas atualizar a imagem do sistema operacional base

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

O mecanismo de atualização não assistida instala automaticamente as atualizações de segurança lançadas antes que uma nova versão da 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 de cluster do Kubernetes. A reinicialização dos nós pode ser automatizada usando o código aberto Kubernetes REboot Daemon (kured)). O 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.

Considerações de implantação (CI/CD)

O Azure e o Azure Stack Hub expõem as mesmas APIs REST do Azure Resource Manager. Essas APIs são tratadas como qualquer outra nuvem do Azure (Azure, Azure China 21Vianet, Azure Government). Pode haver diferenças nas versões de API entre nuvens 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 nuvem e cada instância do Azure Stack Hub.

Além das diferenças sutis mencionadas, as APIs REST do Azure Resource Manager fornecem uma maneira consistente de interagir com o Azure e o Azure Stack Hub. O mesmo conjunto de ferramentas pode ser usado aqui como seria usado com qualquer outra 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 quando se trata de implantações do Azure Stack Hub é a questão da acessibilidade à Internet. A acessibilidade da Internet determina se um agente de construção hospedado pela Microsoft ou auto-hospedado deve ser escolhido para seus trabalhos de CI/CD.

Um agente auto-hospedado pode ser executado na parte superior do Azure Stack Hub (como uma VM IaaS) ou em uma sub-rede de rede que pode acessar o Azure Stack Hub. Acesse Agentes do Azure Pipelines para saber mais sobre as diferenças.

A imagem a seguir ajuda você a decidir se precisa de um agente de build auto-hospedado ou hospedado pela Microsoft:

• Os pontos de extremidade de gerenciamento do Azure Stack Hub estão acessíveis via Internet?
  • Sim: podemos usar o Azure Pipelines com agentes hospedados pela Microsoft para se conectar ao Azure Stack Hub.
  • Não: precisamos de agentes auto-hospedados que possam se conectar aos endereços de gerenciamento do Azure Stack Hub.
• Nosso cluster do Kubernetes está acessível pela Internet?
  • Sim: podemos usar o Azure Pipelines com agentes hospedados pela Microsoft para interagir diretamente com o ponto de extremidade da API do Kubernetes.
  • Não: precisamos de agentes auto-hospedados que possam se conectar ao ponto de extremidade da API de cluster do Kubernetes.

Em cenários em que os pontos de extremidade de gerenciamento do Azure Stack Hub e a API do Kubernetes estão acessíveis pela Internet, a implantação pode usar um agente hospedado pela Microsoft. Essa implantação resulta em uma arquitetura de aplicativo da seguinte maneira:

visão geral da arquitetura pública

Se os pontos de extremidade do Azure Resource Manager, a API do Kubernetes ou ambos não estiverem diretamente acessíveis pela Internet, poderemos usar um agente de build auto-hospedado para executar as etapas do pipeline. Esse design precisa de menos conectividade e pode ser implantado apenas com conectividade de rede local com pontos de extremidade do Azure Resource Manager e a API do Kubernetes:

Nota

E os cenários desconectados? Em cenários em que o Azure Stack Hub ou o Kubernetes ou ambos não têm pontos de extremidade de gerenciamento voltados para a Internet, ainda é possível usar o Azure DevOps para suas implantações. Você pode usar um Pool de Agentes auto-hospedado (que é um DevOps Agent em execução local ou no próprio Azure Stack Hub) ou um servidor do Azure DevOps totalmente auto-hospedado local. O agente auto-hospedado precisa apenas de conectividade de internet HTTPS (TCP/443) de saída.

O padrão pode usar um cluster Kubernetes (implantado e orquestrado com 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 de back-end (por exemplo, MongoDB) e um controlador de entrada baseado em nginx. Em vez de usar um banco de dados hospedado no cluster K8s, 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 no IaaS. Configurações como essa não estão no escopo aqui.

Soluções de parceiros

Há soluções do Microsoft Partner que podem estender os recursos do Azure Stack Hub. Essas soluções foram consideradas úteis em implantações de aplicativos em execução em clusters do Kubernetes.

Soluções de armazenamento e dados

Conforme descrito em considerações de dados e armazenamento, o Azure Stack Hub atualmente não tem uma solução nativa para replicar o armazenamento em várias instâncias. Ao contrário do Azure, a capacidade de replicar o armazenamento em várias regiões não existe. No Azure Stack Hub, cada instância é sua própria nuvem distinta. No entanto, as soluções estão disponíveis nos Parceiros da Microsoft que habilitam a replicação de armazenamento nos Hubs do Azure Stack e no Azure.

ESCALABILIDADE

Scality fornece armazenamento em escala da Web que alimenta empresas digitais desde 2009. O Scality RING, nosso armazenamento definido por software, transforma servidores x86 convencionais em um pool de armazenamento ilimitado para qualquer tipo de dados – arquivos e objetos – na escala de petabytes.

CLOUDIAN

Cloudian simplifica o armazenamento empresarial com uma solução de armazenamento escalável e ilimitada que consolida conjuntos de dados maciços em um único ambiente de fácil gerenciamento.

Próximas etapas

Para saber mais sobre os conceitos introduzidos neste artigo:

• Escala entre nuvens e padrões de aplicativo distribuídos geograficamente no Azure Stack Hub.
• arquitetura de microsserviços no AKS (Serviço de Kubernetes do Azure).

Quando estiver pronto para testar o exemplo da solução, continue com o guia de implantação do cluster de Kubernetes de Alta Disponibilidade . O guia de implantação fornece instruções passo a passo para implantar e testar seus componentes.