Arquitetura de cluster do Kubernetes e cargas de trabalho para AKS habilitadas pelo Azure Arc
Aplica-se a: AKS no Azure Stack HCI 22H2, AKS no Windows Server
O Serviço Kubernetes do Azure (AKS) no Azure Local e no Windows Server é uma plataforma de contêiner Kubernetes de nível empresarial com tecnologia do Azure Local. Ele inclui Kubernetes principais suportados pela Microsoft, um host de contêiner Windows criado especificamente para isso e um host de contêiner Linux suportado pela Microsoft, com o objetivo de ter uma implantação simples e experiência de gerenciamento do ciclo de vida.
Este artigo apresenta os principais componentes da infraestrutura do Kubernetes, como o plano de controle, nós e pools de nós. Recursos de carga de trabalho, como pods, implantações e conjuntos, também são introduzidos, juntamente com como agrupar recursos em namespaces.
Arquitetura de clusters do Kubernetes
O Kubernetes é o componente principal do AKS habilitado pelo Azure Arc. O AKS usa um conjunto de configurações predefinidas para implantar cluster(s) Kubernetes de forma eficaz e com escalabilidade em mente.
A operação de implantação cria várias máquinas virtuais Linux ou Windows e as une para criar cluster(s) Kubernetes.
Nota
Para ajudar a melhorar a confiabilidade do sistema, se você estiver executando vários CSVs (Volumes Compartilhados de Cluster) em seu cluster, por padrão, os dados da máquina virtual serão distribuídos automaticamente por todos os CSVs disponíveis no cluster. Isso garante que os aplicativos sobrevivam no caso de interrupções de CSV. Isto aplica-se 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 do Serviço Kubernetes do Azure tem os seguintes componentes:
- O cluster de gerenciamento (também conhecido como host AKS) fornece o mecanismo de orquestração central 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 em contêineres são implantados.
Gerenciar AKS habilitado pelo Arc
Você pode gerenciar o AKS usando as seguintes opções de gerenciamento:
- O 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 PowerShell também oferece suporte à implantação e configuração de outros clusters de carga de trabalho e à reconfiguração dos existentes.
O cluster de gestão
Quando você cria um cluster Kubernetes, um cluster de gerenciamento é criado e configurado automaticamente. Esse cluster de gerenciamento é responsável pelo provisionamento e gerenciamento de clusters de carga de trabalho onde 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 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 plano 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 do cluster de carga de trabalho
O cluster de carga de trabalho tem muitos componentes, que são descritos nas seções a seguir.
Plano de controlo
- 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: O Etcd é um armazenamento distribuído de chave-valor 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 de 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 de 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ó Kubernetes. Um cluster de carga de trabalho 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ó Kubernetes e hospedam os pods e serviços que compõem a carga de trabalho do aplicativo.
Há componentes principais da carga de trabalho do Kubernetes que podem ser implantados em clusters de carga de trabalho 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 existam cenários avançados nos quais 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 Kubernetes pods e Kubernetes pod lifecycle.
Implementações
Uma implantaçã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 do 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 usar implantações pode ser suficiente para aplicativos sem monitoração de estado, mas não para aplicativos que exigem uma convenção de nomenclatura ou armazenamento persistente. Para aplicativos que exigem a existência de uma réplica em cada nó (ou nós selecionados) dentro de um cluster, o Controlador de Implantação não examina 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, dimensionamento, atualizações e encerramentos. 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 em um StatefulSet são agendadas e executadas em qualquer nó disponível em um cluster Kubernetes. Se você precisar garantir que pelo menos um pod em seu conjunto seja executado em um nó, você pode usar um DaemonSet. Para obter mais informações, consulte Kubernetes StatefulSets.
- DaemonSets: para necessidades específicas de coleta ou monitoramento de logs, talvez seja necessário executar um determinado pod em todos os nós ou em nós selecionados. Um DaemonSet é novamente usado 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.
Espaços de nomes
Os recursos do Kubernetes, como pods e implantações, são agrupados logicamente em um namespace. Esses agrupamentos fornecem uma maneira de dividir logicamente clusters de carga de trabalho e restringir o acesso para criar, exibir ou gerenciar 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, consulte Namespaces do Kubernetes.
Quando você cria um cluster do Serviço Kubernetes do Azure no AKS habilitado pelo Arc, os seguintes namespaces estão disponíveis:
- Padrão: um namespace onde 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 onde existem recursos principais, como recursos de rede, como DNS e proxy, ou o painel do Kubernetes. Normalmente, não implementa as suas próprias aplicações neste espaço de nomes.
- kube-public: um namespace normalmente não usado, mas pode ser usado para que os recursos fiquem visíveis em todo o cluster e podem ser visualizados por qualquer usuário.
Segredos
Os segredos do Kubernetes permitem armazenar e gerenciar informações confidenciais, como senhas, tokens OAuth e chaves Secure Shell (SSH). Por padrão, o Kubernetes armazena segredos como cadeias de caracteres codificadas em base64 não criptografadas e elas podem ser recuperadas 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 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, consulte Volumes persistentes.
Implantações de SO misto
Se um determinado cluster de carga de trabalho consistir em nós de trabalho Linux e Windows, ele precisará ser agendado em um sistema operacional que possa suportar o provisionamento da carga de trabalho. O Kubernetes oferece dois mecanismos para garantir que as cargas de trabalho aterrissem em nós com um sistema operacional de destino:
- O Seletor de Nó é um campo simples na especificação do pod que restringe os pods a serem programados apenas em nós íntegros correspondentes ao sistema operacional.
- Manchas e tolerâncias trabalham juntas para garantir que os pods não sejam programados em nós involuntariamente. Um nó pode ser "contaminado" de tal forma que não aceita pods que não toleram explicitamente sua mancha através de uma "tolerância" na especificação do pod.
Para obter mais informações, consulte seletores de nó e manchas e tolerâncias.
Próximos passos
Neste artigo, você aprendeu sobre a arquitetura de cluster do AKS habilitada pelo Azure Arc e os componentes de cluster de carga de trabalho. Para obter mais informações sobre esses conceitos, consulte os seguintes artigos: