Padrão de cluster do Kubernetes de elevada disponibilidade

Este artigo descreve como arquitetar e operar uma infraestrutura baseada em Kubernetes de elevada disponibilidade com o Motor Azure Kubernetes Service (AKS) no Azure Stack Hub. Este cenário é comum para organizações com cargas de trabalho críticas em ambientes altamente restritos e regulados. Organizações em domínios como finanças, defesa e governo.

Contexto e problema

Muitas organizações estão a desenvolver soluções nativas da cloud que tiram partido de serviços e tecnologias de última geração, como o Kubernetes. Embora o Azure forneça datacenters na maioria das regiões do mundo, por vezes existem casos de utilização de limites e cenários em que as aplicações críticas para a empresa têm de ser executadas numa localização específica. As considerações incluem:

• Sensibilidade à localização
• Latência entre a aplicação e os sistemas no local
• Conservação da largura de banda
• Conectividade
• Requisitos regulamentares ou estatutários

O Azure, em combinação com o Azure Stack Hub, resolve a maioria destas preocupações. Um vasto 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

Este padrão pressupõe que temos de lidar com um conjunto estrito de restrições. A aplicação tem de ser executada no local e todos os dados pessoais não podem chegar aos serviços cloud públicos. A monitorização e outros dados não PII podem ser enviados para o Azure e processados nesse local. Os serviços externos, como um Container Registry público ou outros, podem ser acedidos, mas podem ser filtrados através de uma firewall ou servidor proxy.

A aplicação de exemplo aqui apresentada foi concebida para utilizar soluções nativas do Kubernetes sempre que possível. Esta estrutura evita o bloqueio do fornecedor, em vez de utilizar serviços nativos da plataforma. Por exemplo, a aplicação utiliza um back-end de base de dados do MongoDB autoalojado em vez de um serviço PaaS ou um serviço de base de dados externo. Para obter mais informações, veja o percurso de aprendizagem Introdução ao Kubernetes no Azure.

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

1. Um cluster do Kubernetes baseado no Motor AKS no Azure Stack Hub.
2. O cert-manager, que fornece um conjunto de ferramentas para a gestão de certificados no Kubernetes, utilizado para pedir certificados automaticamente a partir de Let's Encrypt.
3. Um espaço de nomes do Kubernetes que contém os componentes da aplicação para o front-end (ratings-web), api (ratings-api) e base de dados (ratings-mongodb).
4. O Controlador de Entrada que encaminha o tráfego HTTP/HTTPS para pontos finais no cluster do Kubernetes.

A aplicação de exemplo é utilizada para ilustrar a arquitetura da aplicação. Todos os componentes são exemplos. A arquitetura contém apenas uma única implementação de aplicação. Para obter elevada disponibilidade (HA), iremos executar a implementação pelo menos duas vezes em duas instâncias diferentes do Azure Stack Hub: podem ser executadas na mesma localização ou em dois (ou mais) sites diferentes:

Serviços como Azure Container Registry, Azure Monitor e outros, estão alojados fora do Azure Stack Hub no Azure ou no local. Esta estrutura híbrida protege a solução contra a indisponibilidade de uma única instância do Azure Stack Hub.

Componentes

A arquitetura geral consiste nos seguintes componentes:

O Azure Stack Hub é uma extensão do Azure que pode executar cargas de trabalho num ambiente no local ao fornecer serviços do Azure no seu datacenter. Aceda a Descrição geral do Azure Stack Hub para saber mais.

Azure Kubernetes Service Engine (Motor AKS) é o motor por trás da oferta de serviço do Kubernetes gerida, Azure Kubernetes Service (AKS), que está disponível no Azure atualmente. Para o Azure Stack Hub, o Motor do AKS permite-nos implementar, dimensionar e atualizar clusters do Kubernetes totalmente em destaque e autogeridos com as capacidades IaaS do Azure Stack Hub. Aceda a Descrição Geral do Motor do AKS para saber mais.

Aceda a Problemas Conhecidos e Limitações para saber mais sobre as diferenças entre o Motor do AKS no Azure e o Motor AKS no Azure Stack Hub.

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

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

Azure Container Registry (ACR) é utilizado para armazenar imagens privadas do Docker e gráficos Helm, que são implementados no cluster. O Motor AKS pode autenticar-se com o Container Registry com uma identidade Azure AD. O Kubernetes não necessita do ACR. Pode utilizar outros registos de contentores, como Docker Hub.

O Azure Repos é um conjunto de ferramentas de controlo de versões que pode utilizar para gerir o seu código. Também pode utilizar o GitHub ou outros repositórios baseados em git. Aceda a Descrição Geral dos Repositórios do Azure para saber mais.

O Azure Pipelines faz parte dos Serviços do Azure DevOps e executa compilações, testes e implementações automatizadas. Também pode utilizar soluções CI/CD de terceiros, como o Jenkins. Aceda a Descrição Geral do Pipeline do Azure para saber mais.

O Azure Monitor recolhe e armazena métricas e registos, incluindo métricas de plataforma para os serviços do Azure na solução e telemetria da aplicação. Utilize estes dados para monitorizar a aplicação, configurar alertas e dashboards e realizar a análise da causa raiz das 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 principais. Aceda a Descrição Geral do Azure Monitor para saber mais.

O Gestor de Tráfego do Azure é um balanceador de carga de tráfego baseado em DNS que lhe permite distribuir o tráfego de forma ideal para serviços em diferentes regiões do Azure ou implementações do Azure Stack Hub. O Gestor de Tráfego também fornece elevada disponibilidade e capacidade de resposta. Os pontos finais da aplicação têm de estar acessíveis a partir do exterior. Existem também outras soluções no local disponíveis.

O Controlador de Entrada do Kubernetes expõe rotas HTTP(S) para serviços num cluster do Kubernetes. O Nginx ou qualquer controlador de entrada adequado pode ser utilizado para esta finalidade.

O Helm é um gestor de pacotes para a implementação do Kubernetes, fornecendo uma forma de agrupar diferentes objetos do Kubernetes, como Implementações, Serviços, Segredos, num único "gráfico". Pode publicar, implementar, controlar a gestão de versões e atualizar um objeto de gráfico. Azure Container Registry pode ser utilizado como um repositório para armazenar Gráficos Helm empacotados.

Considerações de design

Este padrão segue algumas considerações de alto nível explicadas mais detalhadamente nas secções seguintes deste artigo:

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

Estas práticas recomendadas também se aplicarão a cargas de trabalho e cenários do mundo real.

Considerações de escalabilidade

A escalabilidade é importante para fornecer aos utilizadores acesso consistente, fiável e de bom desempenho à aplicação.

O cenário de exemplo abrange a escalabilidade em várias camadas da pilha de aplicações. Eis uma descrição geral de alto nível das diferentes camadas:

Nível de arquitetura	Afeta	Como posso fazê-lo?
Aplicação	Aplicação	Dimensionamento horizontal com base no número de Pods/Réplicas/Container Instances*
Cluster	Cluster do Kubernetes	Número de Nós (entre 1 e 50), tamanhos de SKU de VM e Conjuntos de Nós (o Motor AKS no Azure Stack Hub suporta atualmente apenas um único conjunto de nós); utilizar o comando de dimensionamento do Motor AKS (manual)
Infraestrutura	Azure Stack Hub	Número de nós, capacidade e unidades de dimensionamento numa implementação do Azure Stack Hub

* Utilizar o Dimensionador Automático de Pods Horizontal (HPA) do Kubernetes; dimensionamento automático baseado em métricas ou dimensionamento vertical ao dimensionar as instâncias de contentor (cpu/memória).

Azure Stack Hub (nível de infraestrutura)

A infraestrutura do Azure Stack Hub é a base desta implementação, uma vez que o Azure Stack Hub é executado em hardware físico num datacenter. Ao selecionar o hardware do Hub, tem de 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, consulte os seguintes recursos:

• Descrição geral do planeamento de capacidade do Azure Stack Hub
• Adicionar nós de unidades de escala adicionais no Azure Stack Hub

Cluster do Kubernetes (nível de cluster)

O cluster do Kubernetes é constituído por si e baseia-se nos componentes IaaS do Azure (Stack), incluindo recursos de computação, armazenamento e rede. As soluções do Kubernetes envolvem nós principais e de trabalho, que são implementados como VMs no Azure (e no Azure Stack Hub).

• Os nós do plano de controlo (master) fornecem os principais serviços do Kubernetes e a orquestração das cargas de trabalho da aplicação.
• Os nós de trabalho (trabalho) executam as cargas de trabalho da aplicação.

Ao selecionar tamanhos de VM para a implementação inicial, existem várias considerações:

• Custo – ao planear os nós de trabalho, tenha em atenção o custo global por VM em que irá incorrer. Por exemplo, se as cargas de trabalho da aplicação precisarem de recursos limitados, deve planear implementar VMs de tamanho mais pequeno. O Azure Stack Hub, tal como o Azure, é normalmente faturado numa base de consumo, pelo que o dimensionamento adequado das VMs para funções do Kubernetes é crucial para otimizar os custos de consumo.

• Escalabilidade – a escalabilidade do cluster é conseguida ao aumentar e reduzir verticalmente o número de nós principais e de trabalho ou ao adicionar conjuntos de nós adicionais (não disponíveis no Azure Stack Hub atualmente). O dimensionamento do cluster pode ser feito com base nos dados de desempenho, recolhidos com o Container Insights (Azure Monitor + Log Analytics).

  Se a sua aplicação precisar de mais (ou menos) recursos, pode aumentar horizontalmente (ou em) os nós atuais horizontalmente (entre 1 e 50 nós). Se precisar de mais de 50 nós, pode criar um cluster adicional numa subscrição separada. Não pode aumentar verticalmente as VMs reais para outro tamanho de VM sem reimplementar o cluster.

  O dimensionamento é feito manualmente com a VM auxiliar do Motor AKS que foi utilizada para implementar o cluster do Kubernetes inicialmente. Para obter mais informações, veja Dimensionar clusters do Kubernetes

• Quotas – considere as quotas que configurou ao planear uma implementação do AKS no Azure Stack Hub. Certifique-se de que cada subscrição tem os planos adequados e as quotas configuradas. A subscrição terá de acomodar a quantidade de computação, armazenamento e outros serviços necessários para os clusters à medida que estes se reduzem horizontalmente.

• Cargas de trabalho de aplicação – veja os conceitos de Clusters e cargas de trabalho nos conceitos principais do Kubernetes para Azure Kubernetes Service documento. Este artigo irá ajudá-lo a definir o âmbito do tamanho adequado da VM com base nas necessidades de computação e memória da sua aplicação.

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

Na camada da aplicação, utilizamos o Dimensionador Automático do Pod Horizontal (HPA) do Kubernetes. O HPA pode aumentar ou diminuir o número de Réplicas (Pod/Container Instances) na nossa implementação com base em métricas diferentes (como a utilização da CPU).

Outra opção é dimensionar as instâncias de contentor verticalmente. Isto pode ser feito alterando a quantidade de CPU e Memória pedida e disponível para uma implementação específica. Veja Gerir Recursos para Contentores no kubernetes.io para saber mais.

Considerações de 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 seguinte mostra as camadas e os serviços que contêm:

Camada	Afeta	What?
Aplicação	Aplicação	Como é que a aplicação está acessível? Será exposto à Internet?
Cluster	Cluster do Kubernetes	API do Kubernetes, VM do Motor do AKS, Solicitar imagens de contentor (saída), Enviar dados de monitorização e telemetria (saída)
Infraestrutura	Azure Stack Hub	Acessibilidade dos pontos finais de gestão do Azure Stack Hub, como o portal e o Azure Resource Manager pontos finais.

Aplicação

Para a camada da aplicação, a consideração mais importante é se a aplicação está exposta e acessível a partir da Internet. Do ponto de vista do Kubernetes, a acessibilidade à Internet significa expor uma implementação ou pod com um Serviço Kubernetes ou um Controlador de Entrada.

Expor uma aplicação através de um IP público através de um Balanceador de Carga ou de um Controlador de Entrada não significa que a aplicação esteja agora acessível através 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 estão verdadeiramente virados para a Internet.

O bloco anterior considera o tráfego de entrada para a aplicação. Outro tópico que tem de ser considerado para uma implementação do Kubernetes bem-sucedida é o tráfego de saída/saída. Eis alguns casos de utilização que requerem tráfego de saída:

• Solicitar Imagens de Contentor armazenadas no DockerHub ou Azure Container Registry
• Obter Gráficos Helm
• Emitir dados do Application Insights (ou outros dados de monitorização)

Alguns ambientes empresariais podem exigir a utilização de servidores proxy transparentes ou não transparentes . Estes servidores requerem uma configuração específica em vários componentes do nosso cluster. A documentação do Motor AKS contém vários detalhes sobre como acomodar proxies de rede. Para obter mais detalhes, veja Motor do AKS e servidores proxy

Por último, o tráfego entre clusters tem de fluir entre instâncias do Azure Stack Hub. A implementação de exemplo consiste em clusters do Kubernetes individuais em execução em instâncias individuais do Azure Stack Hub. O tráfego entre as mesmas, como o tráfego de replicação entre duas bases de dados, é "tráfego externo". O tráfego externo tem de ser encaminhado através de uma VPN Site a Site ou de endereços IP Públicos do Azure Stack Hub para ligar o Kubernetes em duas instâncias do Azure Stack Hub:

Cluster

O cluster do Kubernetes não precisa necessariamente de estar acessível através da Internet. A parte relevante é a API do Kubernetes utilizada para operar um cluster, por exemplo, com kubectl. O ponto final da API do Kubernetes tem de estar acessível a todas as pessoas que operam o cluster ou implementa aplicações e serviços sobre o mesmo. Este tópico é abordado mais detalhadamente a partir de uma perspetiva de DevOps na secção Considerações de Implementação (CI/CD) abaixo.

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

• Atualizações de nós (para Ubuntu)
• Dados de monitorização (enviados para o Azure LogAnalytics)
• Outros agentes que necessitam de tráfego de saída (específico para o ambiente de cada implementador)

Antes de implementar o cluster do Kubernetes com o Motor AKS, planeie a conceção final da rede. Em vez de criar um Rede Virtual dedicado, pode ser mais eficiente implementar um cluster numa rede existente. Por exemplo, pode tirar partido de uma ligação VPN Site a Site já configurada no ambiente do Azure Stack Hub.

Infraestrutura

A infraestrutura refere-se ao acesso aos pontos finais de gestão do Azure Stack Hub. Os pontos finais incluem os portais de inquilino e administrador e os pontos finais de administrador e inquilino do Azure Resource Manager. Estes pontos finais são necessários para operar o Azure Stack Hub e os seus serviços principais.

Considerações sobre dados e armazenamento

Duas instâncias da nossa aplicação serão implementadas em dois clusters individuais do Kubernetes, em duas instâncias do Azure Stack Hub. Esta estrutura irá exigir que ponderemos como replicar e sincronizar dados entre os mesmos.

Com o Azure, temos a capacidade incorporada de replicar o armazenamento em várias regiões e zonas dentro da cloud. Atualmente, com o Azure Stack Hub, não existem formas nativas de replicar o armazenamento em duas instâncias diferentes do Azure Stack Hub. Formam duas clouds independentes sem forma abrangente de as gerir como um conjunto. Planear a resiliência das aplicações em execução no Azure Stack Hub obriga-o a considerar esta independência na conceção e implementações da sua aplicação.

Na maioria dos casos, a replicação de armazenamento não será necessária para uma aplicação resiliente e de elevada disponibilidade implementada no AKS. Contudo, deve considerar o armazenamento independente por instância do Azure Stack Hub na estrutura da sua aplicação. Se esta estrutura for uma preocupação ou um bloqueio de estrada para implementar a solução no Azure Stack Hub, existem possíveis soluções do Microsoft Partners que fornecem anexos de armazenamento. Os anexos de armazenamento fornecem uma solução de replicação de armazenamento em vários Hubs do Azure Stack e no Azure. Para obter mais informações, veja Soluções de parceiros.

Na nossa arquitetura, estas camadas foram consideradas:

Configuração

A configuração inclui a configuração do Azure Stack Hub, do Motor AKS e do próprio cluster do Kubernetes. A configuração deve ser automatizada tanto quanto possível e armazenada como Infraestrutura como Código num sistema de controlo de versões baseado em Git, como o Azure DevOps ou o GitHub. Estas definições não podem ser facilmente sincronizadas em várias implementações. Por conseguinte, recomendamos que armazene e aplique a configuração de fora e utilize o pipeline de DevOps.

Aplicação

A aplicação deve ser armazenada num repositório baseado em Git. Sempre que existir uma nova implementação, alterações na aplicação ou recuperação após desastre, pode ser facilmente implementada com os Pipelines do Azure.

Dados

Os dados são a consideração mais importante na maioria dos designs de aplicações. Os dados da aplicação têm de permanecer sincronizados entre as diferentes instâncias da aplicação. Os dados também precisam de uma estratégia de cópia de segurança e recuperação após desastre se ocorrer uma falha.

Alcançar este design depende muito das escolhas tecnológicas. Eis alguns exemplos de solução para implementar uma base de dados de forma altamente disponível no Azure Stack Hub:

• Implementar um grupo de disponibilidade SQL Server 2016 no Azure e no Azure Stack Hub
• Implementar uma solução do MongoDB de elevada disponibilidade no Azure e no Azure Stack Hub

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

• Latência e conectividade de rede entre o Azure Stack Hubs.
• Disponibilidade de identidades para serviços e permissões. Cada instância do Azure Stack Hub integra-se num diretório externo. Durante a implementação, opta por utilizar o Azure Active Directory (Azure AD) ou o Serviços de Federação do Active Directory (AD FS) (ADFS). Como tal, existe potencial para utilizar 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ócio e a recuperação após desastre (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 tem de gerir todo o processo BCDR. No Azure, partes do BCDR são geridas automaticamente por Microsoft.

O BCDR afeta as mesmas áreas mencionadas na secção anterior Considerações de dados e armazenamento:

• Infraestrutura/Configuração
• Disponibilidade da Aplicação
• Dados da Aplicação

Tal como mencionado na secção anterior, estas áreas são da responsabilidade do operador do Azure Stack Hub e podem variar entre organizações. Planeie o BCDR de acordo com as ferramentas e processos disponíveis.

Infraestrutura e configuração

Esta secção abrange a infraestrutura física e lógica e a configuração do Azure Stack Hub. Abrange ações no administrador e nos espaços de inquilino.

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

• Recuperar dados no Azure Stack Hub com o Serviço de Cópia de Segurança da Infraestrutura
• Ativar a cópia de segurança do Azure Stack Hub a partir do portal de 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 os recursos de infraestrutura em que as aplicações do Kubernetes serão implementadas. O proprietário da aplicação para a aplicação Kubernetes será um utilizador do Azure Stack Hub, com acesso concedido para implementar a infraestrutura da aplicação necessária para a solução. Neste caso, a infraestrutura de aplicações significa o cluster do Kubernetes, implementado com o Motor AKS e os serviços adjacentes. Estes componentes serão implementados no Azure Stack Hub, restringidos por uma oferta do Azure Stack Hub. Certifique-se de que a oferta aceite pelo proprietário da aplicação Kubernetes tem capacidade suficiente (expressa nas quotas do Azure Stack Hub) para implementar toda a solução. Conforme recomendado na secção anterior, a implementação da aplicação deve ser automatizada com pipelines de Infraestrutura como Código e implementação, como o Azure DevOps Azure Pipelines.

Para obter mais informações sobre as ofertas e quotas do Azure Stack Hub, veja Descrição geral dos serviços, planos, ofertas e subscrições do Azure Stack Hub

É importante guardar e armazenar de forma segura a configuração do Motor AKS, incluindo as respetivas saídas. Estes ficheiros contêm informações confidenciais utilizadas para aceder ao cluster do Kubernetes, pelo que têm de ser protegidos contra serem expostos a não administradores.

Disponibilidade da aplicação

A aplicação não deve depender de cópias de segurança de uma instância implementada. Como prática padrão, reimplemente a aplicação seguindo completamente os padrões Infraestrutura como Código. Por exemplo, reimplementar com o Azure DevOps Azure Pipelines. O procedimento BCDR deve envolver a reimplementação da aplicação no mesmo ou noutro cluster do Kubernetes.

Dados da aplicação

Os dados da aplicação são a parte fundamental para minimizar a perda de dados. Na secção anterior, foram descritas técnicas para replicar e sincronizar dados entre duas (ou mais) instâncias da aplicação. Dependendo da infraestrutura de base de dados (MySQL, MongoDB, MSSQL ou outros) utilizadas para armazenar os dados, existirão diferentes técnicas de disponibilidade e cópia de segurança da base de dados disponíveis para escolher.

As formas recomendadas de alcançar a integridade são utilizar:

• Uma solução de cópia de segurança nativa para a base de dados específica.
• Uma solução de cópia de segurança que suporta oficialmente a cópia de segurança e a recuperação do tipo de base de dados utilizado pela sua aplicação.

Considerações de disponibilidade

O Kubernetes no Azure Stack Hub implementado através do Motor AKS não é um serviço gerido. Trata-se de uma implementação automatizada e configuração de um cluster do Kubernetes com a Infraestrutura como Serviço do Azure (IaaS). Como tal, fornece a mesma disponibilidade que a infraestrutura subjacente.

A infraestrutura do Azure Stack Hub já é resiliente a falhas e fornece capacidades como Conjuntos de Disponibilidade para distribuir componentes por vários domínios de falha e atualização. No entanto, a tecnologia subjacente (clustering de ativação pós-falha) ainda implica algum tempo de inatividade para as VMs num servidor físico afetado, caso exista uma falha de hardware.

É uma boa prática implementar o cluster do Kubernetes de produção, bem como a carga de trabalho em dois (ou mais) clusters. Estes clusters devem ser alojados em localizações ou datacenters diferentes e utilizar tecnologias como o Gestor de Tráfego do Azure para encaminhar utilizadores com base no tempo de resposta do cluster ou com base na geografia.

Normalmente, os clientes que têm um único cluster do Kubernetes ligam-se ao IP do serviço ou ao nome DNS de uma determinada aplicação. Numa implementação de vários clusters, os clientes devem ligar-se a um nome DNS do Gestor de Tráfego que aponte para os serviços/entradas em cada cluster do Kubernetes.

O próprio cluster do Kubernetes, implementado através do Motor AKS, deve consistir em, pelo menos, três nós principais e dois nós de trabalho.

Considerações de 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 controlo de acesso baseado em funções (RBAC):

• 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 utilizadores, grupos ou principais de serviço. (Um principal de serviço é uma identidade de segurança utilizada pelas 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 utilizador através do RBAC. Para atribuir permissões do Kubernetes aos utilizadores, crie funções e enlaces de função.

Identidade e RBAC do Azure Stack Hub

O Azure Stack Hub fornece duas opções de fornecedor de identidade. O fornecedor que utilizar depende do ambiente e da execução num ambiente ligado ou desligado:

• Azure AD - só pode ser utilizado num ambiente ligado.
• ADFS para uma floresta tradicional do Active Directory – pode ser utilizado num ambiente ligado ou desligado.

O fornecedor de identidade gere utilizadores e grupos, incluindo autenticação e autorização para aceder a recursos. O acesso pode ser concedido a recursos do Azure Stack Hub, como subscrições, grupos de recursos e recursos individuais, como VMs ou balanceadores de carga. Para ter um modelo de acesso consistente, deve considerar a utilização dos mesmos grupos (diretos ou aninhados) para todos os Azure Stack Hubs. Eis um exemplo de configuração:

O exemplo contém um grupo dedicado (com o AAD ou o ADFS) para um objetivo específico. Por exemplo, para fornecer permissões de Contribuidor para o Grupo de Recursos que contém a nossa infraestrutura de cluster do Kubernetes numa instância específica do Azure Stack Hub (aqui "Contribuidor de Cluster do Seattle K8s"). Em seguida, estes grupos são aninhados num grupo global que contém os "subgrupos" para cada Azure Stack Hub.

O nosso utilizador de exemplo terá agora permissões de "Contribuidor" para ambos os Grupos de Recursos que contêm todo o conjunto de recursos de infraestrutura do Kubernetes. O utilizador terá acesso aos recursos em ambas as instâncias do Azure Stack Hub, porque as instâncias partilham o mesmo fornecedor de identidade.

Identidade e RBAC do Kubernetes

Por predefinição, um cluster do Kubernetes não utiliza o mesmo Fornecedor de Identidade que o Azure Stack Hub subjacente. As VMs que alojam o cluster do Kubernetes, os nós principais e de trabalho utilizam a Chave SSH especificada durante a implementação do cluster. Esta chave SSH é necessária para ligar a estes nós através de SSH.

A API do Kubernetes (por exemplo, acedida com kubectl) também está protegida por contas de serviço, incluindo uma conta de serviço "administrador de cluster" predefinida. As credenciais para esta conta de serviço são inicialmente armazenadas no .kube/config ficheiro nos nós principais do Kubernetes.

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

Para armazenar segredos, como cadeias de ligação ou credenciais de base de dados, existem várias opções, incluindo:

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

Não armazene segredos ou credenciais em texto simples nos ficheiros de configuração, no código da aplicação ou nos scripts. E não os armazene num sistema de controlo de versões. Em vez disso, a automatização da implementação deve obter os segredos conforme necessário.

Aplicar patches e atualizar

O processo patch e atualização (PNU) no Azure Kubernetes Service é parcialmente automatizado. As atualizações de versões do Kubernetes são acionadas manualmente, enquanto as atualizações de segurança são aplicadas automaticamente. Estas atualizações podem incluir correções de segurança do SO ou atualizações de kernel. O AKS não reinicia automaticamente estes nós do Linux para concluir o processo de atualização.

O processo de PNU para um cluster do Kubernetes implementado com o Motor AKS no Azure Stack Hub não é gerido e é da responsabilidade do operador de cluster.

O Motor AKS ajuda com as duas tarefas mais importantes:

• Atualizar para uma versão mais recente do Kubernetes e da imagem de SO base
• Atualizar apenas a imagem do SO base

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

O mecanismo de Atualização Automática instala automaticamente as atualizações de segurança lançadas antes de uma nova versão de imagem de SO base estar disponível no Marketplace do Azure Stack Hub. A atualização automática está ativada por predefinição e instala atualizações de segurança automaticamente, mas não reinicia os nós de cluster do Kubernetes. O reinício dos nós pode ser automatizado com o AemonDde arranque K Ubernetes REde código aberto (kured)). O Kured observa os nós do Linux que requerem um reinício e, em seguida, processa automaticamente o reagendamento de pods em execução e o processo de reinício do nó.

Considerações de 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 abordadas como qualquer outra cloud do Azure (Azure, Azure China 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 final de gestão também é diferente para cada cloud e para cada instância do Azure Stack Hub.

Além das diferenças subtis mencionadas, as APIs REST do Azure Resource Manager fornecem uma forma consistente de interagir com o Azure e o Azure Stack Hub. O mesmo conjunto de ferramentas pode ser utilizado aqui como seria utilizado com qualquer outra cloud do Azure. Pode utilizar o Azure DevOps, ferramentas como o Jenkins ou o PowerShell, para implementar e orquestrar serviços no Azure Stack Hub.

Considerações

Uma das principais diferenças no que diz respeito às implementações do Azure Stack Hub é a questão da acessibilidade à Internet. A acessibilidade à Internet determina se deve selecionar um agente de compilação alojado Microsoft ou autoalojado para as tarefas ci/CD.

Um agente autoalojado pode ser executado sobre o Azure Stack Hub (como uma VM IaaS) ou numa sub-rede de rede que pode aceder ao Azure Stack Hub. Aceda aos agentes do Azure Pipelines para saber mais sobre as diferenças.

A imagem seguinte ajuda-o a decidir se precisa de um agente de compilação autoalojado ou alojado Microsoft:

• Os pontos finais de gestão do Azure Stack Hub estão acessíveis através da Internet?
  • Sim: podemos utilizar os Pipelines do Azure com agentes alojados Microsoft para ligar ao Azure Stack Hub.
  • Não: precisamos de agentes autoalojados que se possam ligar aos pontos finais de gestão do Azure Stack Hub.
• O nosso cluster do Kubernetes está acessível através da Internet?
  • Sim: podemos utilizar os Pipelines do Azure com agentes alojados Microsoft para interagir diretamente com o ponto final da API do Kubernetes.
  • Não: precisamos de Agentes autoalojados que se possam ligar ao ponto final da API de cluster do Kubernetes.

Em cenários em que os pontos finais de gestão do Azure Stack Hub e a API do Kubernetes estão acessíveis através da Internet, a implementação pode utilizar um agente alojado Microsoft. Esta implementação resultará numa arquitetura de aplicação da seguinte forma:

Se o Azure Resource Manager pontos finais, a API do Kubernetes ou ambos não estiverem diretamente acessíveis através da Internet, podemos tirar partido de um agente de compilação autoalojado para executar os passos do pipeline. Esta estrutura precisa de menos conectividade e só pode ser implementada com conectividade de rede no local aos pontos finais do Azure Resource Manager e à API do Kubernetes:

O padrão pode utilizar um cluster do Kubernetes (implementado e orquestrado com o motor AKS) em cada instância do Azure Stack Hub. Inclui uma aplicação composta por um front-end, um serviço de back-end de camada média (por exemplo, MongoDB) e um Controlador de Entradas baseado em nginx. Em vez de utilizar uma base de dados alojada no cluster K8s, pode tirar partido de "arquivos de dados externos". As opções da base de dados incluem MySQL, SQL Server ou qualquer tipo de base de dados alojada fora do Azure Stack Hub ou em IaaS. Configurações como esta não estão no âmbito aqui.

Soluções de parceiros

Existem Microsoft soluções de Parceiros que podem expandir as capacidades do Azure Stack Hub. Estas soluções foram consideradas úteis em implementações de aplicações em execução em clusters do Kubernetes.

Soluções de armazenamento e dados

Conforme descrito em Considerações sobre dados e armazenamento, atualmente, o Azure Stack Hub 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 armazenamento em várias regiões não existe. No Azure Stack Hub, cada instância é a sua própria cloud distinta. No entanto, as soluções estão disponíveis nos Parceiros Microsoft que permitem a replicação de armazenamento nos Azure Stack Hubs e no Azure.

ESCALABILIDADE

A scality fornece armazenamento à escala Web que tem alimentado empresas digitais desde 2009. O RING de Scality, o nosso armazenamento definido pelo software, transforma os servidores x86 de base num agrupamento de armazenamento ilimitado para qualquer tipo de dados –ficheiro e objeto– à escala de petabytes.

CLOUDIAN

O Cloudian simplifica o armazenamento empresarial com armazenamento dimensionável ilimitado que consolida conjuntos de dados maciços num único ambiente facilmente gerido.

Passos seguintes

Para saber mais sobre os conceitos introduzidos neste artigo:

• Dimensionamento entre clouds e Padrões de aplicações distribuídas geograficamente no Azure Stack Hub.
• Arquitetura de microsserviços no Azure Kubernetes Service (AKS).

Quando estiver pronto para testar o exemplo de solução, continue com o Guia de implementação do cluster do Kubernetes de elevada disponibilidade. O guia de implementação fornece instruções passo a passo para implementar e testar os respetivos componentes.