Padrão de cluster Kubernetes de alta disponibilidade

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. 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 da nuvem que usam 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 há casos de uso de borda e cenários em que os aplicativos críticos para os negócios devem ser executados em um local específico. As consideraçõ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 descreve opções, decisões e considerações para uma implementação bem-sucedida do Kubernetes a correr no Azure Stack Hub.

Solução

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

A seguinte aplicação de exemplo foi concebida para utilizar soluções Kubernetes-native sempre que possível. Esse design evita a dependência do fornecedor, em vez de usar serviços nativos da plataforma. Como 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.

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 Kubernetes baseado no Motor AKS no Azure Stack Hub.
2. cert-manager, que fornece um conjunto de ferramentas para gerenciamento de certificados no Kubernetes, usado para solicitar automaticamente certificados do Let's Encrypt.
3. Um namespace 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 Ingress Controller que encaminha o tráfego HTTP/HTTPS para endpoints 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 (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 Azure Container Registry, 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 a 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 num ambiente local, fornecendo serviços do Azure no seu datacenter. Vá para visão geral do Azure Stack Hub para saber mais.

O Azure Kubernetes Service Engine (AKS Engine) é o motor por trás da oferta de serviços geridos Kubernetes, Azure Kubernetes Service (AKS), que está disponível atualmente no Azure. Para o Azure Stack Hub, o AKS Engine nos permite implantar, dimensionar e atualizar clusters Kubernetes autogerenciados com recursos completos usando os recursos IaaS do Azure Stack Hub. Vá para Visão Geral do AKS Engine para obter mais informações.

Vá para 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.

A Rede Virtual do Azure (VNet) é utilizada para fornecer a infraestrutura de rede em cada Azure Stack Hub para as Máquinas Virtuais (VMs) que hospedam a infraestrutura de cluster do Kubernetes.

O Balanceador de Carga do Azure é utilizado para o Endpoint da API do Kubernetes e o Controlador de Ingress do Nginx. O balanceador de carga redireciona o tráfego externo (por exemplo, da Internet) para nós e VMs que oferecem um serviço específico.

O Registro de Contêiner do Azure (ACR) é utilizado para armazenar imagens Docker privadas e charts Helm, que são implantados no cluster. O AKS Engine pode autenticar-se com o Registo de Contentores utilizando o Microsoft Entra ID. O Kubernetes não requer ACR. Você pode usar outros registros de contêiner, como o Docker Hub.

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. Vá para Visão Geral do Azure Repos para mais informações.

Pipelines do Azure faz parte dos Serviços de DevOps do Azure e executa compilações, testes e implementações automatizadas. Você também pode usar soluções de CI/CD de terceiros, como Jenkins. Vá para Visão Geral do Pipeline do Azure para obter mais informações.

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 com o Kubernetes para recolher métricas de controladores, nós e contentores, bem como registos de contentores e registos de nós primários. Vá para Visão Geral do Azure Monitor para obter mais informações.

do Azure Traffic Manager é um balanceador de carga de tráfego baseado em DNS que permite 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 da aplicação devem ser acessíveis de fora. Existem outras soluções locais também disponíveis.

Kubernetes Ingress Controller expõe rotas HTTP(S) para serviços num cluster Kubernetes. Nginx ou qualquer controlador de entrada adequado pode ser usado para este fim.

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ões e atualizar um objeto de gráfico. O Azure Container Registry pode ser usado como um repositório para armazenar Helm Charts empacotados.

Considerações de 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 a dependência 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 cargas de trabalho e cenários do mundo real.

Considerações sobre escalabilidade

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

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

* Utilização do Autoscaler Horizontal Pod (HPA) do Kubernetes; Dimensionamento automatizado baseado em métricas ou dimensionamento vertical dimensionando as instâncias de contêiner (CPU/memória).

Azure Stack Hub (nível de infraestrutura)

A infraestrutura do Azure Stack Hub é a base dessa implementação, porque 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:

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

cluster de Kubernetes (nível de cluster)

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

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

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

• Custo - Ao planear os nós de trabalho, tenha em conta o custo total incorrido por VM. Por exemplo, se as cargas de trabalho do aplicativo exigirem recursos limitados, você deve planejar a implantação de VMs de tamanho menor. 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 - A escalabilidade do cluster é alcançada aumentando ou diminuindo o número de nós principais e de trabalho, ou adicionando mais pools de nós (atualmente não disponíveis no Azure Stack Hub). O dimensionamento do cluster pode ser feito com base em dados de desempenho, coletados usando o Container Insights (Azure Monitor + Log Analytics).

  Se a sua aplicação precisar de mais (ou menos) recursos, pode escalar (ou reduzir) os nós atuais horizontalmente (entre 1 e 50 nós). Se precisares de mais de 50 nós, podes criar outro cluster numa subscrição separada. Não é possível dimensionar as VMs reais verticalmente para outro tamanho de VM sem reimplantar o cluster.

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

• Cotas - Considere as cotas que você configura ao planejar uma implantação do AKS em seu Azure Stack Hub. Certifique-se de que cada subscrição tem os planos adequados e as quotas configuradas. 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 aplicação - Consulte os conceitos de Clusters e cargas de trabalho no documento Conceitos principais do Kubernetes para 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.

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

Na camada de aplicação, usamos Kubernetes Horizontal Pod Autoscaler (HPA). A HPA pode aumentar ou diminuir o número de réplicas (instâncias de pod/contentor) na nossa implementação com base em métricas diferentes (como a utilização do CPU).

Outra opção é escalar as instâncias do contentor verticalmente, alterando a quantidade de CPU e Memória solicitada e disponível para uma implementação específica. Consulte Gerenciando recursos para contêineres no 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 elas contêm:

Aplicação

Para a camada de aplicativo, a consideração mais importante é se o aplicativo está exposto e acessível a partir da Internet. Do ponto de vista do Kubernetes, acessibilidade à Internet significa expor uma implantação ou pod usando um Serviço Kubernetes ou um Controlador de Ingresso.

Expor um aplicativo usando um IP público por meio de um Load Balancer ou um Ingress Controller não significa que o aplicativo agora está acessível pela Internet. É possível que o Azure Stack Hub tenha 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.

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

• Extraindo imagens de contêiner armazenadas no DockerHub ou no Registro de Contêiner do Azure
• Recuperando Helm Charts
• Emissão de dados do Application Insights (ou outros dados de monitoramento)

Alguns ambientes empresariais podem exigir o uso de servidores proxy transparentes ou não transparentes. Esses servidores exigem configuração específica em vários componentes do nosso cluster. A documentação do AKS Engine contém vários 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 implantação de exemplo consiste em clusters Kubernetes individuais em execução 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, é "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:

tráfego inter e intra cluster

Aglomeração

O cluster do Kubernetes não precisa necessariamente estar acessível pela 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 tema é abordado com mais detalhe a partir de uma perspetiva DevOps na secção de considerações de Implementação (CI/CD).

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

• Atualizações de nodes (para o Ubuntu)
• Dados de monitoramento (enviados para o Azure LogAnalytics)
• 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. Em vez de criar uma Rede Virtual dedicada, pode ser mais eficiente implementar um cluster numa rede já existente. Por exemplo, você pode usar uma conexão VPN Site a Site existente já 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 endpoints incluem os portais de administrador e locatário, bem como os endpoints de administrador e locatário do Azure Resource Manager. Esses pontos de extremidade são essenciais para operar o Azure Stack Hub e os seus serviços centrais.

Considerações sobre dados e armazenamento

Implementamos duas instâncias da nossa aplicação, 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 na 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 da resiliência de aplicativos em execução no Azure Stack Hub força você a considerar essa independência em seu design e 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 ou um obstáculo para implantar a solução no Azure Stack Hub, há soluções possíveis de Parceiros da Microsoft que fornecem anexos 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 de parceiros .

Em nossa arquitetura, estas 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 tanto quanto 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 facilmente sincronizadas em várias implantações. Portanto, recomendamos armazenar e aplicar a configuração do lado de fora e usar o pipeline de DevOps.

Aplicação

O aplicativo deve ser armazenado em um repositório baseado em Git. Sempre que há uma nova implantação, alterações no aplicativo ou recuperação de desastres, ela pode ser facilmente implantada 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. Os dados também precisam de uma estratégia de backup e recuperação de desastres se houver uma interrupção.

Alcançar este design depende fortemente de escolhas tecnológicas. 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 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 Azure Stack Hubs.
• 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 o Microsoft Entra ID ou o Microsoft Entra ID Federation. Como tal, há potencial para usar uma única identidade que pode interagir com várias instâncias independentes do Azure Stack Hub.

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

A continuidade de negócios e a recuperação de desastres (BCDR) são 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 BCDR. No Azure, partes do BCDR são gerenciadas automaticamente pela Microsoft.

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

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

E, como mencionado na seção anterior, essas áreas são de responsabilidade do operador do Azure Stack Hub e podem variar entre organizações. 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 de arrendamento.

O operador (ou administrador) do Azure Stack Hub é responsável pela manutenção das instâncias do Azure Stack Hub. Incluir componentes, como a rede, o armazenamento e a identidade, está fora do âmbito deste artigo. Para saber mais sobre as especificidades das operações do Azure Stack Hub, consulte 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 a partir do portal do administrador
• Recupere de perda de dados catastrófica
• Práticas recomendadas do Infrastructure Backup Service

O Azure Stack Hub é a plataforma e o tecido onde as aplicações Kubernetes são implementadas. O proprietário da aplicação Kubernetes é um utilizador do Azure Stack Hub, com acesso concedido para implementar a infraestrutura da aplicação necessária para a solução. A infraestrutura de aplicativos, neste caso, significa o cluster Kubernetes, implantado usando o AKS Engine, e os serviços ao redor. Esses componentes são implantados no Azure Stack Hub, limitados 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, especificamente 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 usadas para acessar o cluster do Kubernetes, portanto, ele deve ser protegido de ser exposto a não-administradores.

Disponibilidade de aplicativos

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

Dados do aplicativo

Os dados de aplicativos 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 da base de dados (MySQL, MongoDB, MSSQL ou outras) utilizada para armazenar os dados, existem diferentes técnicas de disponibilidade e backup de bases de dados disponíveis para escolher.

As maneiras recomendadas para alcançar a integridade são usar:

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

Considerações sobre disponibilidade

O Kubernetes no Azure Stack Hub implantado via AKS Engine não é um serviço gerenciado. É uma implantação e configuração automatizadas de um cluster Kubernetes usando a Infraestrutura como Serviço (IaaS) do Azure. Como tal, 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 entre vários domínios de falha e atualização. Mas a tecnologia subjacente (clustering de failover) ainda acarreta algum período de inatividade para VMs no servidor físico afetado, se houver uma avaria de hardware.

É uma boa prática implantar seu cluster Kubernetes de produção e 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 do Azure 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 multi-cluster, os clientes devem se conectar a um nome DNS do Traffic Manager 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 mestres e dois nós de trabalho.

Considerações sobre identidade e segurança

Identidade e segurança são 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 RBAC (controle de acesso baseado em função):

• O RBAC do Azure controla o acesso a 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. Um princípio de serviço é uma identidade de segurança usada por aplicações.
• 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 autorizadas (ou negadas) a um usuário por meio do 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 está sendo executado em um ambiente conectado ou desconectado:

• Microsoft Entra ID - só pode ser usado em um ambiente conectado.
• 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 a 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, deve considerar utilizar os mesmos grupos (diretos ou aninhados) para todos os Azure Stack Hubs. 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 para o Grupo de Recursos que contém nossa infraestrutura de cluster Kubernetes em uma instância específica do Azure Stack Hub (aqui "Colaborador de Cluster K8s de Seattle"). Esses grupos são então integrados a um grupo geral que contém os "subgrupos" para cada Azure Stack Hub.

O nosso utilizador de exemplo tem agora permissões "Contribuidor" para ambos os Grupos de Recursos que contêm todo o conjunto de recursos de infraestrutura 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 o Hub de Stack do Azure subjacente. As VMs que hospedam o cluster Kubernetes, os nós mestre e 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 padrão de "administrador de cluster". As credenciais dessa conta de serviço são inicialmente armazenadas no arquivo .kube/config nos nós mestres do Kubernetes.

Gestão de segredos e credenciais de aplicação

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 (executando em Kubernetes)

Não armazene segredos ou credenciais em texto sem formatação em seus arquivos de configuração, código de aplicativo ou em 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 à medida que for necessário.

Patch e atualização

O processo de Patch e Atualização de (PNU) no Serviço Kubernetes do Azure é parcialmente automatizado. As atualizações de versão do Kubernetes são acionadas 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 do kernel. O AKS não reinicia automaticamente esses nós Linux para concluir o processo de atualização.

O processo PNU para um cluster Kubernetes implantado usando o AKS Engine no Azure Stack Hub não é gerenciado e é de 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 mecanismo de Atualização Automática instala automaticamente as atualizações de segurança lançadas antes que uma nova versão de imagem de base do SO 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 reinicia os nós do cluster do Kubernetes. A reinicialização dos nós pode ser automatizada usando o de código aberto Kubernetes REboot Daemon (kured)). Kured monitoriza os nós Linux que requerem uma reinicialização e, posteriormente, lida automaticamente com o reagendamento dos pods em execução e o processo de reinicialização dos nós.

Considerações sobre implementação (CI/CD)

O Azure e o Azure Stack Hub expõem as mesmas APIs REST do Azure Resource Manager. Estas APIs são endereçadas como qualquer outra cloud da Azure (Azure, Azure operada pela 21Vianet, Azure Government). Podem existir diferenças nas versões da API entre clouds, 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 à 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. Aceda aos 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 compilação auto-hospedado ou hospedado pela Microsoft:

• Os pontos de extremidade de gerenciamento do Azure Stack Hub podem ser acessados pela Internet?
  • Sim: podemos usar o Azure Pipelines com agentes hospedados pela Microsoft para se conectar ao Azure Stack Hub.
  • Não: precisamos de agentes autoalojados que possam conectar-se aos endpoints de gestão do Azure Stack Hub.
• Nosso cluster Kubernetes pode ser acessado 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 podem ser acessados pela Internet, a implantação pode usar um agente hospedado pela Microsoft. Essa implantação resulta em uma arquitetura de aplicativo da seguinte maneira:

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 compilação auto-hospedado para executar as etapas do pipeline. Esse design precisa de menos conectividade e pode ser implantado apenas com conectividade de rede local para pontos de extremidade do Azure Resource Manager e a API do Kubernetes:

O padrão pode usar um cluster Kubernetes (implantado e orquestrado com o mecanismo AKS) em cada instância do Azure Stack Hub. Ele inclui um aplicativo que consiste em um frontend, um intermediário, serviços de back-end (por exemplo, MongoDB) e um controlador de ingresso baseado em nginx. Em vez de usar uma base de dados alojada no cluster K8s, pode usar repositórios 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. Configurações como esta estão fora do âmbito deste artigo.

Soluções de parceiros

Há soluções de parceiros da Microsoft que podem estender os recursos do Azure Stack Hub. Estas soluções são úteis na implementação de aplicações a correr em clusters Kubernetes.

Soluções de armazenamento e dados

Conforme descrito em Considerações sobre 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 por Parceiros da Microsoft que permitem a replicação de armazenamento nos Azure Stack Hubs e no Azure.

SCALITY

Scality oferece armazenamento em escala web que tem impulsionado as empresas digitais desde 2009. O Scality RING, nosso armazenamento definido por software, transforma servidores x86 de mercadoria em um pool de armazenamento ilimitado para qualquer tipo de dados – arquivo e objeto – em escala de petabytes.

CLOUDIAN

Cloudian simplifica o armazenamento corporativo com armazenamento escalável ilimitado que consolida conjuntos de dados massivos em um único ambiente de fácil gerenciamento.

Próximos passos

Para saber mais sobre os conceitos introduzidos neste artigo:

• Dimensionamento entre nuvens e padrões de aplicações distribuídas geograficamente no Azure Stack Hub.
• Arquitetura de microsserviços no Serviço Kubernetes do Azure (AKS).

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