Partilhar via

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

  • Artigo

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

Azure Kubernetes Service (AKS) no Azure Stack HCI e Windows Server é uma plataforma de contentores kubernetes de nível empresarial com tecnologia do Azure Stack HCI. Inclui o Kubernetes principal suportado pela Microsoft, um anfitrião de contentor do Windows criado de propósito e um anfitrião de contentores do Linux suportado pela Microsoft, com o objetivo de ter uma experiência de gestão de ciclo de vida e implementação simples.

Este artigo apresenta os componentes principais da infraestrutura do Kubernetes, como o plano de controlo, os nós e os conjuntos de nós. Também são introduzidos recursos de carga de trabalho, como pods, implementações e conjuntos, bem como agrupar recursos em espaços de nomes.

Arquitetura do cluster do Kubernetes

O Kubernetes é o componente principal do AKS ativado pelo Azure Arc. O AKS utiliza um conjunto de configurações predefinidas para implementar os clusters do Kubernetes de forma eficaz e tendo em conta a escalabilidade.

A operação de implementação cria várias máquinas virtuais linux ou Windows e associa-as para criar clusters do Kubernetes.

Nota

Para ajudar a melhorar a fiabilidade do sistema, se estiver a executar vários Volumes Partilhados de Cluster (CSVs) no cluster, por predefinição, os dados da máquina virtual são distribuídos automaticamente por todos os CSVs disponíveis no cluster. Isto garante que as aplicações sobrevivem em caso de indisponibilidade do CSV. Isto aplica-se apenas a novas instalações (não a atualizações).

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

Um cluster de Azure Kubernetes Service tem os seguintes componentes:

  • O cluster de gestão (também conhecido como anfitrião do AKS) fornece o mecanismo de orquestração principal e a interface para implementar e gerir um ou mais clusters de cargas de trabalho.
  • Os clusters de cargas de trabalho (também conhecidos como clusters de destino) são onde as aplicações em contentores são implementadas.

Ilustração a mostrar a arquitetura técnica do Azure Kubernetes Service no Azure Stack HCI e no Windows Server.

Gerir o AKS ativado pelo Arc

Pode gerir o AKS com as seguintes opções de gestão:

  • Windows Admin Center oferece uma IU intuitiva para o operador do Kubernetes gerir o ciclo de vida dos clusters.
  • Um módulo do PowerShell facilita a transferência, configuração e implementação do AKS. O módulo do PowerShell também suporta a implementação e configuração de outros clusters de cargas de trabalho e a reconfiguração de clusters existentes.

O cluster de gestão

Quando cria um cluster do Kubernetes, é criado e configurado automaticamente um cluster de gestão. Este cluster de gestão é responsável pelo aprovisionamento e gestão de clusters de cargas de trabalho onde as cargas de trabalho são executadas. Um cluster de gestão inclui os seguintes componentes principais do Kubernetes:

  • Servidor de API: o servidor de API é como as APIs do Kubernetes subjacentes são expostas. Este componente fornece a interação para ferramentas de gestão, 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 gestão.

O cluster de cargas de trabalho

O cluster de cargas de trabalho é uma implementação de elevada disponibilidade do Kubernetes com VMs do Linux para executar componentes do plano de controlo do Kubernetes e nós de trabalho do Linux. As VMs baseadas no Windows Server Core são utilizadas para estabelecer nós de trabalho do Windows. Pode haver um ou mais clusters de carga de trabalho geridos por um cluster de gestão.

Componentes do cluster de cargas de trabalho

O cluster de cargas de trabalho tem muitos componentes, que são descritos nas secções seguintes.

Plano de controlo

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

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 implementados pelo cluster de gestão. Para cada cluster de cargas de trabalho, o AKS adiciona pelo menos uma máquina virtual de balanceador de carga. Qualquer serviço do Kubernetes do tipo LoadBalancer criado no cluster de cargas de trabalho eventualmente cria uma regra de balanceamento de carga na VM.

Nós de trabalho

Para executar as suas aplicações e serviços de suporte, 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 máquinas virtuais (VMs) que executam os componentes do nó do Kubernetes e alojam os pods e serviços que compõem a carga de trabalho da aplicação.

Existem componentes principais da carga de trabalho do Kubernetes que podem ser implementados em clusters de cargas de trabalho do AKS, como pods e implementações.

Pods

O Kubernetes utiliza pods para executar uma instância da sua aplicação. Um pod representa uma única instância da sua aplicação. Normalmente, os pods têm um mapeamento 1:1 com um contentor, embora existam cenários avançados em que um pod pode conter vários contentores. Estes pods com vários contentores são agendados em conjunto no mesmo nó e permitem que os contentores partilhem recursos relacionados. Para obter mais informações, veja Ciclo de vida dos pods do Kubernetes e do Kubernetes.

Implementações

Uma implementação representa um ou mais pods idênticos, geridos pelo Controlador de Implementação do Kubernetes. Uma implementação define o número de réplicas (pods) a criar e o agendador do Kubernetes garante que, se os pods ou nós encontrarem problemas, os pods adicionais são agendados em nós em bom estado de funcionamento. Para obter mais informações, veja Implementações do Kubernetes.

StatefulSets e DaemonSets

O Controlador de Implementação utiliza o agendador do Kubernetes para executar um determinado número de réplicas em qualquer nó disponível com recursos disponíveis. Esta abordagem de utilização de implementações pode ser suficiente para aplicações sem estado, mas não para aplicações que requerem uma convenção de nomenclatura persistente ou armazenamento. Para aplicações que requerem a existência de uma réplica em cada nó (ou nós selecionados) dentro de um cluster, o Controlador de Implementação não analisa a forma como as réplicas são distribuídas pelos nós.

  • StatefulSets: um StatefulSet é semelhante a uma implementação na qual um ou mais pods idênticos são criados e geridos. As réplicas num StatefulSet seguem uma abordagem graciosa e sequencial para implementação, dimensionamento, atualizações e terminações. Com um StatefulSet (à medida que as réplicas são reagendadas), a convenção de nomenclatura, os nomes de rede e o armazenamento persistem. As réplicas num StatefulSet são agendadas e executadas em qualquer nó disponível num cluster do Kubernetes. Se precisar de garantir que, pelo menos, um pod no seu conjunto é executado num nó, em vez disso, pode utilizar um DaemonSet. Para obter mais informações, veja Kubernetes StatefulSets.
  • DaemonSets: para necessidades específicas de recolha ou monitorização de registos, poderá ter de executar um determinado pod em todos os nós ou selecionados. Um DaemonSet é novamente utilizado para implementar um ou mais pods idênticos, mas o controlador DaemonSet garante que cada nó especificado executa uma instância do pod. Para obter mais informações, veja Kubernetes DaemonSets.

Espaços de nomes

Os recursos do Kubernetes, como pods e implementações, são agrupados logicamente num espaço de nomes. Estes agrupamentos fornecem uma forma de dividir logicamente os clusters de cargas de trabalho e restringir o acesso para criar, ver ou gerir recursos. Por exemplo, pode criar espaços de nomes para separar grupos de negócios. Os utilizadores só podem interagir com recursos dentro dos espaços de nomes atribuídos. Para obter mais informações, veja Kubernetes namespaces (Espaços de nomes do Kubernetes).

Quando cria um cluster Azure Kubernetes Service no AKS ativado pelo Arc, estão disponíveis os seguintes espaços de nomes:

  • predefinição: um espaço de nomes onde os pods e as implementações são criados por predefinição quando nenhum é fornecido. Em ambientes mais pequenos, pode implementar aplicações diretamente no espaço de nomes predefinido sem criar separações lógicas adicionais. Quando interage com a API do Kubernetes, como com kubectl get pods, o espaço de nomes predefinido é utilizado quando nenhum é especificado.
  • kube-system: um espaço de nomes onde existem recursos principais, como funcionalidades de rede, como DNS e proxy, ou o dashboard do Kubernetes. Normalmente, não implementa as suas próprias aplicações neste espaço de nomes.
  • kube-public: um espaço de nomes normalmente não é utilizado, mas pode ser utilizado para que os recursos fiquem visíveis em todo o cluster e possam ser visualizados por qualquer utilizador.

Segredos

Os segredos do Kubernetes permitem-lhe armazenar e gerir informações confidenciais, como palavras-passe, tokens OAuth e chaves Secure Shell (SSH). Por predefinição, o Kubernetes armazena segredos como cadeias codificadas com base64 não encriptadas e podem ser obtidos como texto simples por qualquer pessoa com acesso à API. Para obter mais informações, veja Segredos do Kubernetes.

Volumes persistentes

Um volume persistente é um recurso de armazenamento num cluster do Kubernetes que foi aprovisionado pelo administrador ou aprovisionado dinamicamente com classes de armazenamento. Para utilizar volumes persistentes, os pods pedem acesso com um PersistentVolumeClaim. Para obter mais informações, veja Volumes Persistentes.

Implementações de SO misto

Se um determinado cluster de cargas de trabalho for composto por nós de trabalho do Linux e do Windows, tem de ser agendado para um SO que suporte o aprovisionamento da carga de trabalho. O Kubernetes oferece dois mecanismos para garantir que as cargas de trabalho são colocadas em nós com um sistema operativo de destino:

  • O Seletor de Nós é um campo simples na especificação do pod que restringe os pods a serem agendados apenas para nós em bom estado de funcionamento que correspondam ao sistema operativo.
  • Taints e tolerâncias funcionam em conjunto para garantir que os pods não são agendados para nós involuntariamente. Um nó pode ser "contaminado" de modo a não aceitar pods que não toleram explicitamente a sua taint através de uma "tolerância" na especificação do pod.

Para obter mais informações, veja seletores de nós , taints e tolerâncias.

Passos seguintes

Neste artigo, ficou a conhecer a arquitetura do cluster do AKS ativada pelo Azure Arc e os componentes do cluster de cargas de trabalho. Para obter mais informações sobre estes conceitos, veja os seguintes artigos: