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 AKS (Serviço de Kubernetes do Azure) no Azure Local e no Windows Server é uma plataforma de contêiner do Kubernetes de nível empresarial da plataforma Azure Local. Ele inclui o Kubernetes principal com suporte da Microsoft, um host de contêiner do Windows criado especificamente e um host de contêiner Linux com suporte da Microsoft, com o objetivo de ter uma experiência simples de implantação e gerenciamento do ciclo de vida.
Este artigo apresenta os principais componentes da infraestrutura do Kubernetes, como o plano 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 Volumes Compartilhados de Cluster (CSVs) 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 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 do 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 em contêineres são implantados.
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 do 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 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 do 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.
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: o Etcd é um armazenamento 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 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 do balanceador de carga. Qualquer serviço do Kubernetes do tipo LoadBalancer criado no cluster de carga de trabalho eventualmente cria uma regra de balanceamento de carga na VM.
Nó de trabalho
Para executar seus aplicativos e serviços de suporte, é necessário um Kubernetes nó. 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 principais de carga de trabalho 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 programador do Kubernetes garante que, se os pods ou nós encontrarem problemas, os 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 ou armazenamento persistente. Para aplicativos que exigem que uma réplica exista em cada nó (ou nós selecionados) em 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 seqüencial para implantaçã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 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ó, você poderá 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 é 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 agrupados logicamente 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 do 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 onde existem recursos principais, como recursos de rede, como DNS e proxy, ou o painel do Kubernetes. Normalmente, você não implanta seus próprios aplicativos para esse namespace.
- kube-public: um namespace normalmente não usado, mas pode ser usado para que os recursos sejam visíveis em todo o cluster e podem ser visualizados por qualquer usuário.
Segredos
Os segredos do Kubernetes permitem que você armazene e gerencie informações confidenciais, como senhas, tokens OAuth e chaves Secure Shell (SSH). Por padrão, o Kubernetes armazena segredos como strings codificadas em base64 não criptografadas e podem ser recuperados como texto simples 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 sistemas operacionais mistos
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 a nós com um sistema operacional de destino:
- O Seletor de Nós é um campo simples na especificação do pod que restringe os pods a serem agendados apenas em nós íntegros que correspondem ao sistema operacional.
- Taints e tolerations trabalham juntos para garantir que os pods não sejam agendados em nós involuntariamente. Um nó pode ser "contaminado" de forma que não aceite pods que não tolerem explicitamente sua contaminação por meio de uma "tolerância" na especificação do pod.
Para obter mais informações, consulte seletores de nó e taints e tolerâncias.
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: