Implantar um cluster do Kubernetes de alta disponibilidade no Azure Stack Hub
Este artigo vai mostrar como criar um ambiente de cluster do Kubernetes de alta disponibilidade, implantado em várias instâncias do Azure Stack Hub, em diferentes locais físicos.
Neste guia de implantação de solução, você aprenderá a:
- Baixar e preparar o mecanismo do AKS
- Conectar-se à VM auxiliar do mecanismo do AKS
- Implantar um cluster do Kubernetes
- Conectar-se ao cluster do Kubernetes
- Conectar o Azure Pipelines ao cluster do Kubernetes
- Configurar monitoramento
- Implantar um aplicativo
- Aplicativo de dimensionamento automático
- Configurar o Gerenciador de Tráfego
- Atualizar o Kubernetes
- Escalar Kubernetes
Dica
O Microsoft Azure Stack Hub é uma extensão do Azure. O Azure Stack Hub traz a agilidade e a inovação da computação em nuvem para seu ambiente local, fornecendo a única nuvem híbrida que permite criar e implantar aplicativos híbridos em qualquer lugar.
O artigo Considerações de design de aplicativos híbridos examina os pilares da qualidade de software (posicionamento, escalabilidade, disponibilidade, resiliência, capacidade de gerenciamento e segurança) relativos ao design, à implantação e à operação de aplicativos híbridos. As considerações de design ajudam na otimização do design de aplicativos híbridos, reduzindo os desafios nos ambientes de produção.
Pré-requisitos
Antes de começar a usar este guia de implantação, você deve:
- Examinar o artigo Padrão de cluster do Kubernetes de alta disponibilidade.
- Examinar o conteúdo do Repositório complementar do GitHub, que contém ativos adicionais referenciados neste artigo.
- Ter uma conta que possa acessar o Portal do usuário do Azure Stack Hub, com pelo menos permissões de "colaborador".
Baixar e preparar o mecanismo do AKS
O mecanismo do AKS é um binário que pode ser usado de qualquer host Windows ou Linux que possa alcançar os pontos de extremidade do Azure Resource Manager do Azure Stack Hub. Este guia descreve a implantação de uma nova VM do Linux (ou do Windows) no Azure Stack Hub. Ela será usada posteriormente, quando o mecanismo do AKS implantar os clusters do Kubernetes.
Observação
Você também pode usar uma VM existente do Windows ou do Linux para implantar um cluster do Kubernetes no Azure Stack Hub usando o mecanismo do AKS.
O processo passo a passo e os requisitos para o mecanismo do AKS estão documentados aqui:
O mecanismo do AKS é uma ferramenta auxiliar para implantar e operar clusters do Kubernetes (não gerenciados) no Azure e no Azure Stack Hub.
Os detalhes e as diferenças do mecanismo do AKS no Azure Stack Hub são descritos aqui:
O ambiente de exemplo usará o Terraform para automatizar a implantação da VM do mecanismo do AKS. Você pode encontrar os detalhes e o código no repositório complementar do GitHub.
O resultado dessa etapa é um novo grupo de recursos no Azure Stack Hub que contém a VM auxiliar do mecanismo do AKS e os recursos relacionados:
Observação
Se você precisar implantar o mecanismo do AKS em um ambiente air-gapped desconectado, examine as instâncias desconectadas do Azure Stack Hub para saber mais.
Na próxima etapa, usaremos a VM do mecanismo do AKS implantada recentemente a fim de implantar um cluster do Kubernetes.
Conectar-se à VM auxiliar do mecanismo do AKS
Primeiro, você deve se conectar à VM auxiliar do mecanismo AKS criada anteriormente.
A VM deve ter um Endereço IP Público e deve ser acessível via SSH (porta 22/TCP).
Dica
Você pode usar uma ferramenta de sua escolha, como o MobaXterm, o puTTY ou o PowerShell no Windows 10 para se conectar a uma VM do Linux usando SSH.
ssh <username>@<ipaddress>
Após a conexão, execute o comando aks-engine. Acesse Versões compatíveis do mecanismo do AKS para saber mais sobre as versões do mecanismo do AKS e do Kubernetes.
Implantar um cluster do Kubernetes
A própria VM auxiliar do mecanismo do AKS ainda não criou um cluster do Kubernetes no Azure Stack Hub. A criação do cluster é a primeira ação a ser tomada na VM auxiliar do mecanismo do AKS.
O processo passo a passo está documentado aqui:
O resultado final do comando aks-engine deploy e das preparações nas etapas anteriores é um cluster do Kubernetes com recursos completos, implantado no espaço do locatário da primeira instância do Azure Stack Hub. O próprio cluster consiste em componentes de IaaS do Azure, como VMs, balanceadores de carga, VNets, discos e assim por diante.
- Balanceador de carga do Azure (Ponto de extremidade da API K8s) 2) Nós de trabalho (pool de agentes) 3) Nós mestres
Agora o cluster está em execução e na próxima etapa faremos a conexão com ele.
Conectar-se ao cluster do Kubernetes
Agora você pode se conectar ao cluster do Kubernetes criado anteriormente, seja por meio de SSH (usando a chave SSH especificada como parte da implantação) ou por meio do kubectl (recomendado). A ferramenta de linha de comando do Kubernetes kubectl está disponível para Windows, Linux e macOS aqui. Ela já está pré-instalada e configurada nos nós mestres do nosso cluster:
ssh azureuser@<k8s-master-lb-ip>
Não é recomendável usar o nó mestre como um Jumpbox para tarefas administrativas. A configuração kubectl é armazenada em .kube/config nos nós mestres, bem como na VM do mecanismo do AKS. Você pode copiar a configuração para um computador de administração com conectividade para o cluster do Kubernetes e usar o comando kubectl lá. O arquivo .kube/config também é usado posteriormente para configurar uma conexão de serviço no Azure Pipelines.
Importante
Mantenha esses arquivos seguros porque eles contêm as credenciais para o cluster do Kubernetes. Um invasor com acesso ao arquivo tem informações suficientes para obter acesso de administrador a ele. Todas as ações feitas usando o arquivo .kube/config inicial são feitas por meio de uma conta do administrador do cluster.
Agora você pode tentar vários comandos usando kubectl para verificar o status do cluster. Aqui estão exemplos de comandos:
kubectl get nodes
NAME STATUS ROLE VERSION
k8s-linuxpool-35064155-0 Ready agent v1.14.8
k8s-linuxpool-35064155-1 Ready agent v1.14.8
k8s-linuxpool-35064155-2 Ready agent v1.14.8
k8s-master-35064155-0 Ready master v1.14.8
kubectl cluster-info
Kubernetes master is running at https://aks.***
CoreDNS is running at https://aks.***/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
kubernetes-dashboard is running at https://aks.***/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy
Metrics-server is running at https://aks.***/api/v1/namespaces/kube-system/services/https:metrics-server:/proxy
Importante
O Kubernetes tem seu próprio modelo RBAC (controle de acesso baseado em função) que permite criar definições e associações de função bem refinadas. Essa é a maneira preferível de controlar o acesso ao cluster em vez de distribuir as permissões de administrador de cluster.
Conectar o Azure Pipelines a clusters do Kubernetes
Para conectar os pipelines do Azure ao cluster do Kubernetes recém-implantado, precisamos de seu arquivo kubeconfig (.kube/config), conforme explicado na etapa anterior.
- Conecte-se a um dos nós mestres do cluster do Kubernetes.
- Copie o conteúdo do arquivo
.kube/config. - Vá para Azure DevOps> Configurações do projeto >Conexões de serviço para criar uma nova conexão de serviço "Kubernetes" (usar o KubeConfig como método de autenticação)
Importante
O Azure Pipelines (ou seus agentes de build) devem ter acesso à API do Kubernetes. Se houver uma conexão com a Internet do pipelines do Azure para o cluster do Kubernetes do Azure Stack Hub, você precisará implantar um agente de compilação de pipelines do Azure auto-hospedado.
Ao implantar agentes auto-hospedados para o Azure Pipelines, você pode implantá-los no Azure Stack Hub ou em um computador com conectividade de rede para todos os pontos de extremidade de gerenciamento necessários. Conferir os detalhes aqui:
- Agentes do Azure Pipelines no Windows ou no Linux
A seção do padrão Considerações sobre implantação (CI/CD) contém um fluxo de decisão que ajuda a entender se devem ser usados agentes hospedados pela Microsoft ou agentes auto-hospedados:
Baixe um arquivo do Visio de todos os diagramas neste artigo.
Nesta solução de exemplo, a topologia inclui um agente de build auto-hospedado em cada instância do Azure Stack Hub. O agente pode acessar os pontos de extremidade de gerenciamento do Azure Stack Hub e os pontos de extremidade da API do cluster do Kubernetes.
Baixe um arquivo do Visio de todos os diagramas neste artigo.
Esse design atende a um requisito normativo comum, que é ter apenas conexões de saída da solução do aplicativo.
Configurar monitoramento
Você pode usar o Azure Monitor para que os contêineres monitorem os contêineres da solução. Isso aponta o Azure Monitor para o cluster do Kubernetes implantado pelo mecanismo do AKS no Azure Stack Hub.
Há duas maneiras de habilitar o Azure Monitor no cluster. Ambas as maneiras exigem que você configure um workspace do Log Analytics no Azure.
- O Método um usa um gráfico do Helm
- O Método dois faz parte da especificação de cluster do mecanismo do AKS
A topologia de exemplo usa o "Método um", o que permite a automação do processo e as atualizações podem ser instaladas com mais facilidade.
Para a próxima etapa, você precisa de um workspace do Log Analytics no Azure (ID e chave), Helm (versão 3) e kubectl em seu computador.
O Helm é um gerenciador de pacotes do Kubernetes, disponível como um binário que é executado no macOS, no Windows e no Linux. Pode ser baixado aqui: helm.sh O Helm se baseia no arquivo de configuração do Kubernetes usado para o comando kubectl:
helm repo add incubator https://kubernetes-charts-incubator.storage.googleapis.com/
helm repo update
helm install incubator/azuremonitor-containers \
--set omsagent.secret.wsid=<your_workspace_id> \
--set omsagent.secret.key=<your_workspace_key> \
--set omsagent.env.clusterName=<my_prod_cluster> \
--generate-name
Este comando instalará o agente do Azure Monitor no cluster do Kubernetes:
kubectl get pods -n kube-system
NAME READY STATUS
omsagent-8qdm6 1/1 Running
omsagent-r6ppm 1/1 Running
omsagent-rs-76c45758f5-lmc4l 1/1 Running
O agente do OMS (Operations Management Suite) no cluster do Kubernetes enviará dados de monitoramento para o workspace do Log Analytics no Azure (usando HTTPS de saída). Agora você pode usar o Azure Monitor para obter insights mais aprofundados sobre seus clusters do Kubernetes no Azure Stack Hub. Esse design é uma forma eficiente de demonstrar o poder da análise que pode ser implantada automaticamente com os clusters do aplicativo.
Importante
Se o Azure Monitor não mostrar nenhum dado do Azure Stack Hub, certifique-se de ter seguido as instruções sobre como adicionar uma solução AzureMonitor-Contêineres a um workspace de análise de logs do Azure com cuidado.
Implantar o aplicativo
Antes de instalar o aplicativo de exemplo, há outra etapa para configurar o controlador de entrada baseado em NGINX no cluster do Kubernetes. O controlador de entrada é usado como um balanceador de carga de camada 7 para rotear o tráfego no cluster com base no host, no caminho ou no protocolo. O ingress do NGINX está disponível como um gráfico do Helm. Para obter instruções detalhadas, confira o Repositório do GitHub do gráfico do Helm.
O aplicativo de exemplo também é empacotado como um gráfico do Helm, como o Agente de Monitoramento do Azure na etapa anterior. Assim sendo, é simples implantar o aplicativo no cluster do Kubernetes. Você pode encontrar os Arquivos de gráfico do Helm no repositório complementar do GitHub
O aplicativo de exemplo é um aplicativo de três camadas, implantado em um cluster do Kubernetes em cada uma das duas instâncias do Azure Stack Hub. O aplicativo usa um banco de dados do MongoDB. Você pode aprender mais sobre como obter os dados replicados em várias instâncias no padrão Considerações sobre dados e armazenamento.
Depois de implantar o gráfico do Helm para o aplicativo, você verá todas as três camadas do aplicativo representadas como implantações e conjuntos com estado (para o banco de dados) com apenas um pod:
kubectl get pod,deployment,statefulset
NAME READY STATUS
pod/ratings-api-569d7f7b54-mrv5d 1/1 Running
pod/ratings-mongodb-0 1/1 Running
pod/ratings-web-85667bfb86-l6vxz 1/1 Running
NAME READY
deployment.extensions/ratings-api 1/1
deployment.extensions/ratings-web 1/1
NAME READY
statefulset.apps/ratings-mongodb 1/1
No lado dos serviços, você vai encontrar o controlador de entrada baseado em NGINX e o endereço IP público dele:
kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S)
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP
nginx-ingress-1588931383-controller LoadBalancer 10.0.114.180 *public-ip* 443:30667/TCP
nginx-ingress-1588931383-default-backend ClusterIP 10.0.76.54 <none> 80/TCP
ratings-api ClusterIP 10.0.46.69 <none> 80/TCP
ratings-web ClusterIP 10.0.161.124 <none> 80/TCP
O endereço "IP Externo" é o "ponto de extremidade do aplicativo". É assim que os usuários se conectarão para abrir o aplicativo e também serão usados como o ponto de extremidade para a próxima etapa, Configurar o Gerenciador de Tráfego.
Dimensionamento automático do aplicativo
Opcionalmente, você pode configurar o Dimensionador Automático de Pod Horizontal para escalar ou reduzir verticalmente com base em determinadas métricas, como a utilização da CPU. O comando a seguir criará um Dimensionador Automático de Pod Horizontal que mantém de 1 a 10 réplicas dos Pods controladas pela implantação de classificações Web. O HPA aumentará e diminuirá o número de réplicas (por meio da implantação) para manter uma utilização média da CPU em todos os pods de 80%.
kubectl autoscale deployment ratings-web --cpu-percent=80 --min=1 --max=10
Você pode verificar o status atual do dimensionador automático executando este comando:
kubectl get hpa
NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE
ratings-web Deployment/ratings-web/scale 0% / 80% 1 10 1 18s
Configurar o Gerenciador de Tráfego
Para distribuir o tráfego entre duas (ou mais) implantações do aplicativo, usaremos o Gerenciador de Tráfego do Azure. O Gerenciador de tráfego do Azure é um balanceador de carga de tráfego baseado em DNS no Azure.
Observação
O Gerenciador de Tráfego usa o DNS para direcionar as solicitações do cliente ao ponto de extremidade de serviço mais apropriado com base em um método de roteamento de tráfego e na integridade dos pontos de extremidade.
Em vez de usar o Gerenciador de Tráfego do Azure, você também pode usar outras soluções de balanceamento de carga global hospedadas no local. No cenário de exemplo, usaremos o Gerenciador de Tráfego do Azure para distribuir o tráfego entre duas instâncias do aplicativo. Eles podem ser executados em instâncias do Azure Stack Hub no mesmo local ou em locais diferentes:
Baixe um arquivo do Visio de todos os diagramas neste artigo.
No Azure, configuramos o Gerenciador de Tráfego para apontar para as duas instâncias diferentes de aplicativo:
Como você pode ver, os dois pontos de extremidade apontam para as duas instâncias do aplicativo implantado da seção anterior.
Neste ponto:
- A infraestrutura do Kubernetes já foi criada, incluindo um controlador de entrada.
- Os clusters já foram implantados em duas instâncias do Azure Stack Hub.
- O monitoramento já foi configurado.
- O Gerenciador de Tráfego do Azure balanceará a carga do tráfego entre as duas instâncias do Azure Stack Hub.
- Além dessa infraestrutura, o aplicativo de três camadas de exemplo já foi implantado de maneira automatizada usando os gráficos do Helm.
A solução agora deve estar ativa e acessível aos usuários.
Há também algumas considerações operacionais referentes ao pós-implantação que vale a pena discutir, as quais são abordadas nas próximas duas seções.
Atualizar o Kubernetes
Considere os seguintes tópicos ao atualizar o cluster do Kubernetes:
- A atualização de um cluster do Kubernetes é uma operação complexa do segundo dia que pode ser realizada usando o mecanismo do AKS. Para obter mais informações, confira Atualizar um cluster do Kubernetes no Azure Stack Hub.
- O mecanismo do AKS permite que você atualize os clusters para versões mais recentes do Kubernetes e da imagem do sistema operacional de base. Para obter mais informações, confira Etapas para atualizar para uma versão mais recente do Kubernetes.
- Você também pode atualizar apenas os nós subjacentes para versões mais recentes da imagem do sistema operacional de base. Para obter mais informações, confira Etapas para atualizar apenas a imagem do sistema operacional.
As imagens mais recentes do sistema operacional de base contêm atualizações de segurança e do kernel. É responsabilidade do operador do cluster monitorar a disponibilidade de versões mais recentes do Kubernetes e das imagens do sistema operacional. O operador deve planejar e executar essas atualizações usando o mecanismo do AKS. As imagens do sistema operacional base devem ser baixadas do Marketplace do Azure Stack Hub pelo operador do Azure Stack Hub.
Escalar Kubernetes
A escala é outra operação do segundo dia que pode ser orquestrada usando o mecanismo do AKS.
O comando de escala reutiliza o arquivo de configuração do cluster (apimodel.json) no diretório de saída, como entrada para uma nova implantação do Azure Resource Manager. O mecanismo do AKS executa a operação de escala em um pool de agentes específico. Quando a operação de escala for concluída, o mecanismo do AKS atualizará a definição do cluster no mesmo arquivo apimodel.json. A definição do cluster reflete a nova contagem de nós para refletir a configuração atualizada do cluster.
Próximas etapas
- Saiba mais sobre as considerações de design do aplicativo híbrido
- Revise e proponha melhorias para o código desse exemplo no GitHub.
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de