Gerenciar pods em clusters do Kubernetes de vários pools
Os desenvolvedores da Contoso estão trabalhando na transformação de aplicativos Windows e Linux desenvolvidos internamente em imagens baseadas no Docker implantáveis usando gráficos Helm. Em seu planejamento para a implementação de clusters do Kubernetes no Azure Stack HCI, você precisa garantir o suporte para ambas as plataformas de sistema operacional.
O que são pools de nós em clusters do Kubernetes no Azure Stack HCI
O AKS no Azure Stack HCI dá suporte a vários pools de nó no mesmo cluster do Kubernetes. Cada pool consiste em VMs configuradas de forma idêntica, de acordo com as configurações que você especifica ao provisionar esse pool.
Ao agrupar nós em pools separados, você pode direcionar as implantações de pod para o conjunto adequado de VMs. Por exemplo, você pode ter cargas de trabalho conteinerizadas com suporte apenas pelo sistema operacional Windows ou exigir hardware especializado, como unidades de processador gráfico.
Controlar a implantação de pods em pools de nós em clusters do Kubernetes no Azure Stack HCI
Por padrão, o Kubernetes agenda o provisionamento de cargas de trabalho conteinerizadas em quaisquer nós de trabalho disponíveis de uma maneira que otimiza a utilização de recursos. Para alterar esse comportamento, você pode aplicar restrições à escolha de nós com base nos critérios personalizados que você especificar. Essas restrições incluem seletores de nós, taints e tolerâncias.
Seletores de nó
O seletor de nó é uma configuração dentro da definição baseada em YAML de um pod ou uma implantação que identifica os nós de destino nos quais o pod correspondente pode ser agendado. Se a sua intenção for designar nós de destino com base no sistema operacional, você poderá contar com os rótulos internos atribuídos automaticamente aos nós pelo Kubernetes. Dependendo do sistema operacional pretendido, o seletor de nó usará o formulário kubernetes.io/os = Windows ou kubernetes.io/os = Linux. Por exemplo, o seguinte manifesto de pod baseado em YAML designa nós do Linux como destinos de implantação:
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
env: test
spec:
containers:
- name: nginx
image: nginx
nodeSelector:
kubernetes.io/os = Linux
Taints e tolerâncias
Taints e tolerâncias fornecem uma abordagem alternativa para controlar o posicionamento do pod. Com essa abordagem, os taints fazem parte da configuração do nó e as tolerâncias fazem parte das especificações do pod. Ao corromper um nó, você evita efetivamente que ele hospede qualquer pod sem a tolerância específica de taint correspondente.
Por exemplo, no AKS no Azure Stack HCI, se você quiser permitir que um pod seja agendado em um nó do Windows, deverá adicionar a seguinte tolerância à sua definição:
tolerations:
- key: node.kubernetes.io/os
operator: Equal
value: Windows
effect: NoSchedule
Além disso, você precisaria adicionar o taint node.kubernetes.io/os=Windows:NoSchedule a cada um dos nós do Windows que deseja disponibilizar exclusivamente para implantação de pods com a tolerância correspondente. Para fazer isso, você pode usar o utilitário de linha de comando kubectl e, depois de se conectar ao cluster de destino, executar o seguinte comando para cada um dos nós no escopo (em que o espaço reservado <node_name> designa o nome do nó de destino):
kubectl taint node <node_name> node.kubernetes.io/os=Windows:NoSchedule
Observação
Os seletores de nó impõem posicionamentos de pods em um conjunto específico de nós. As tolerâncias permitem que os pods sejam executados em um conjunto designado de nós afetados, mas não evita o posicionamento em nós sem taints.