Arquitetura de cluster do Kubernetes e cargas de trabalho para AKS habilitadas pelo Azure Arc

  • Artigo

Aplica-se a: AKS no Azure Stack HCI 22H2, AKS no Windows Server

Serviço de Kubernetes do Azure (AKS) no Azure Stack HCI e no Windows Server é uma plataforma de contêiner kubernetes de nível empresarial da plataforma do Azure Stack HCI. Ele inclui o Kubernetes principal com suporte da Microsoft, um host de contêiner do Windows criado com finalidade e um host de contêiner linux com suporte da Microsoft, com a meta de ter uma experiência simples de gerenciamento de ciclo de vida e implantação.

Este artigo apresenta os principais componentes de infraestrutura do Kubernetes, como o painel de controle, os nós e os pools de nós. Recursos de carga de trabalho, como pods, implantações e conjuntos, também são apresentados, além de como agrupar recursos em namespaces.

Arquitetura de cluster do Kubernetes

O Kubernetes é o componente principal do AKS habilitado pelo Azure Arc. O AKS usa um conjunto de configurações predefinidas para implantar clusters do Kubernetes de forma eficaz e com a escalabilidade em mente.

A operação de implantação cria várias máquinas virtuais Linux ou Windows e as une para criar clusters do Kubernetes.

Observação

Para ajudar a melhorar a confiabilidade do sistema, se você estiver executando vários CSVs (Volumes Compartilhados clusterizados) em seu cluster, por padrão os dados da máquina virtual serão distribuídos automaticamente em todos os CSVs disponíveis no cluster. Isso garante que os aplicativos sobrevivam em caso de interrupções de CSV. Isso se aplica apenas a novas instalações (não a atualizações).

O sistema implantado está pronto para receber cargas de trabalho padrão do Kubernetes, dimensionar essas cargas de trabalho ou até mesmo dimensionar o número de máquinas virtuais e o número de clusters para cima e para baixo conforme necessário.

Um cluster Serviço de Kubernetes do Azure tem os seguintes componentes:

  • O cluster de gerenciamento (também conhecido como host do AKS) fornece o mecanismo de orquestração principal e a interface para implantar e gerenciar um ou mais clusters de carga de trabalho.
  • Os clusters de carga de trabalho (também conhecidos como clusters de destino) são onde os aplicativos conteinerizados são implantados.

Ilustração mostrando a arquitetura técnica do Serviço de Kubernetes do Azure no Azure Stack HCI e no Windows Server.

Gerenciar o AKS habilitado pelo Arc

Você pode gerenciar o AKS usando as seguintes opções de gerenciamento:

  • Windows Admin Center oferece uma interface do usuário intuitiva para o operador Kubernetes gerenciar o ciclo de vida dos clusters.
  • Um módulo do PowerShell facilita o download, a configuração e a implantação do AKS. O módulo do PowerShell também dá suporte à implantação e configuração de outros clusters de carga de trabalho e à reconfiguração dos existentes.

O cluster de gerenciamento

Quando você cria um cluster do Kubernetes, um cluster de gerenciamento é criado e configurado automaticamente. Esse cluster de gerenciamento é responsável por provisionar e gerenciar clusters de carga de trabalho em que as cargas de trabalho são executadas. Um cluster de gerenciamento inclui os seguintes componentes principais do Kubernetes:

  • Servidor de API: o servidor de API é como as APIs subjacentes do Kubernetes são expostas. Esse componente fornece a interação para ferramentas de gerenciamento, como Windows Admin Center, módulos do PowerShell ou kubectl.
  • Balanceador de carga: o balanceador de carga é uma única VM do Linux dedicada com uma regra de balanceamento de carga para o servidor de API do cluster de gerenciamento.

O cluster de carga de trabalho

O cluster de carga de trabalho é uma implantação altamente disponível do Kubernetes usando VMs linux para executar componentes do painel de controle do Kubernetes e nós de trabalho do Linux. As VMs baseadas no Windows Server Core são usadas para estabelecer nós de trabalho do Windows. Pode haver um ou mais clusters de carga de trabalho gerenciados por um cluster de gerenciamento.

Componentes de cluster de carga de trabalho

O cluster de carga de trabalho tem muitos componentes, que são descritos nas seções a seguir.

Painel de controle

  • Servidor de API: o servidor de API permite a interação com a API do Kubernetes. Esse componente fornece a interação para ferramentas de gerenciamento, como Windows Admin Center, módulos do PowerShell ou kubectl.
  • Etcd: Etcd é um repositório de chave-valor distribuído que armazena os dados necessários para o gerenciamento do ciclo de vida do cluster. Ele armazena o estado do plano de controle.

Balanceador de carga

O balanceador de carga é uma máquina virtual que executa Linux e HAProxy + KeepAlive para fornecer serviços com balanceamento de carga para os clusters de carga de trabalho implantados pelo cluster de gerenciamento. Para cada cluster de carga de trabalho, o AKS adiciona pelo menos uma máquina virtual do balanceador de carga. Qualquer serviço kubernetes do tipo LoadBalancer criado no cluster de carga de trabalho eventualmente cria uma regra de balanceamento de carga na VM.

Nós de trabalho

Para executar seus aplicativos e serviços de suporte, você precisa de um nó do Kubernetes. Um cluster de carga de trabalho do AKS tem um ou mais nós de trabalho. Os nós de trabalho atuam como VMs (máquinas virtuais) que executam os componentes do nó do Kubernetes e hospedam os pods e serviços que compõem a carga de trabalho do aplicativo.

Há componentes de carga de trabalho principais do Kubernetes que podem ser implantados em clusters de carga de trabalho do AKS, como pods e implantações.

Pods

O Kubernetes usa pods para executar uma instância do seu aplicativo. Um pod representa uma única instância do seu aplicativo. Normalmente, os pods têm um mapeamento 1:1 com um contêiner, embora haja cenários avançados em que um pod pode conter vários contêineres. Esses pods de vários contêineres são agendados juntos no mesmo nó e permitem que os contêineres compartilhem recursos relacionados. Para obter mais informações, consulte pods Kubernetes e ciclo de vida de pod Kubernetes.

Implantações

Uma implementação representa um ou mais pods idênticos, gerenciados pelo Kubernetes Deployment Controller. Uma implantação define o número de réplicas (pods) a serem criadas e o agendador do Kubernetes garante que, se pods ou nós encontrarem problemas, pods adicionais serão agendados em nós íntegros. Para obter mais informações, consulte implantações de Kubernetes.

StatefulSets e DaemonSets

O Controlador de Implantação usa o agendador do Kubernetes para executar um determinado número de réplicas em qualquer nó disponível com recursos disponíveis. Essa abordagem de uso de implantações pode ser suficiente para aplicativos sem estado, mas não para aplicativos que exigem uma convenção de nomenclatura persistente ou armazenamento. Para aplicativos que exigem que um réplica exista em cada nó (ou nós selecionados) em um cluster, o Controlador de Implantação não analisa como as réplicas são distribuídas entre os nós.

  • StatefulSets: um StatefulSet é semelhante a uma implantação em que um ou mais pods idênticos são criados e gerenciados. As réplicas em um StatefulSet seguem uma abordagem normal e sequencial para implantação, escala, atualizações e terminações. Com um StatefulSet (como réplicas são reagendadas), a convenção de nomenclatura, os nomes de rede e o armazenamento persistem. As réplicas em um StatefulSet são agendadas e executadas em qualquer nó disponível em um cluster do Kubernetes. Se você precisar garantir que pelo menos um pod em seu conjunto seja executado em um nó, use um DaemonSet. Para obter mais informações, consulte Kubernetes StatefulSets.
  • DaemonSets: para necessidades específicas de coleta de logs ou monitoramento, talvez seja necessário executar um determinado pod em todos os nós ou selecionados. Um DaemonSet é usado novamente para implantar um ou mais pods idênticos, mas o controlador DaemonSet garante que cada nó especificado execute uma instância do pod. Para obter mais informações, consulte Kubernetes DaemonSets.

Namespaces

Os recursos do Kubernetes, como pods e implantações, são logicamente agrupados em um namespace. Esses agrupamentos fornecem uma maneira de dividir logicamente os clusters de carga de trabalho e restringir o acesso para criar, exibir ou gerenciar recursos. Por exemplo, você pode criar namespaces para separar grupos de negócios. Os usuários podem interagir apenas com recursos dentro de seus namespaces atribuídos. Para obter mais informações, consulte Kubernetes namespaces.

Quando você cria um cluster Serviço de Kubernetes do Azure no AKS habilitado pelo Arc, os seguintes namespaces estão disponíveis:

  • padrão: um namespace em que pods e implantações são criados por padrão quando nenhum é fornecido. Em ambientes menores, você pode implantar aplicativos diretamente no namespace padrão sem criar separações lógicas adicionais. Quando você interage com a API do Kubernetes, como com kubectl get pods, o namespace padrão é usado quando nenhum é especificado.
  • kube-system: um namespace em que existem recursos principais, como recursos de rede como DNS e proxy, ou o dashboard do Kubernetes. Normalmente, você não implantar seus próprios aplicativos para esse namespace.
  • kube-public: um namespace normalmente não usado, mas pode ser usado para que os recursos fiquem visíveis em todo o cluster e possam ser exibidos por qualquer usuário.

Segredos

Os segredos do Kubernetes permitem armazenar e gerenciar informações confidenciais, como senhas, tokens OAuth e chaves SSH (Secure Shell). Por padrão, o Kubernetes armazena segredos como cadeias de caracteres codificadas em base64 não criptografadas e eles podem ser recuperados como texto sem formatação por qualquer pessoa com acesso à API. Para obter mais informações, consulte Segredos do Kubernetes.

Volumes persistentes

Um volume persistente é um recurso de armazenamento em um cluster do Kubernetes que foi provisionado pelo administrador ou provisionado dinamicamente usando classes de armazenamento. Para usar volumes persistentes, os pods solicitam acesso usando um PersistentVolumeClaim. Para obter mais informações, confira Volumes Persistentes.

Implantações de so misto

Se um determinado cluster de carga de trabalho consistir em nós de trabalho do Linux e do Windows, ele precisará ser agendado em um sistema operacional que possa dar suporte ao provisionamento da carga de trabalho. O Kubernetes oferece dois mecanismos para garantir que as cargas de trabalho cheguem em nós com um sistema operacional de destino:

  • O Seletor de Nós é um campo simples na especificação de pod que restringe os pods a serem agendados apenas em nós íntegros correspondentes ao sistema operacional.
  • Taints e tolerations funcionam juntos para garantir que os pods não sejam agendados em nós sem querer. Um nó pode ser "contaminado" de modo que não aceite pods que não toleram explicitamente seu taint por meio de uma "tolerância" na especificação de pod.

Para obter mais informações, consulte seletores de nó e taints e tolerations.

Próximas etapas

Neste artigo, você aprendeu sobre a arquitetura de cluster do AKS habilitada pelo Azure Arc e os componentes do cluster de carga de trabalho. Para obter mais informações sobre esses conceitos, consulte os seguintes artigos: