Compartilhar via


Adaptar aplicativos para uso em clusters Kubernetes de sistemas operacionais mistos

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

O AKS habilitado pelo Arc permite que você execute clusters do Kubernetes com nós do Linux e do Windows, mas você deve fazer pequenas edições em seus aplicativos para uso nesses clusters de sistema operacional misto. Este guia de instruções descreve como garantir que seu aplicativo seja agendado no sistema operacional host correto usando seletores de nó ou taints e tolerâncias.

Este artigo pressupõe uma compreensão básica dos conceitos do Kubernetes. Para obter mais informações, consulte Conceitos básicos do Kubernetes para AKS habilitado pelo Arc.

Seletores de nó

Um seletor de nó é um campo simples no YAML de especificação de pod que restringe os pods a serem agendados apenas em nós íntegros que correspondem ao sistema operacional. No YAML de especificação de pod, especifique um nodeSelector valor de Windows ou Linux, conforme mostrado nos exemplos a seguir:

kubernetes.io/os = Windows

ou

kubernetes.io/os = Linux

Para obter mais informações sobre seletores de nó, consulte seletores de nó.

Taints e tolerâncias

Taints e tolerations trabalham juntos para garantir que os pods não sejam agendados involuntariamente nos nós. Um nó pode ser "contaminado" para rejeitar pods que não toleram explicitamente sua contaminação por meio de uma "tolerância" no YAML de especificação de pod.

Os nós do sistema operacional Windows no AKS Arc podem ser contaminados quando criados com os comandos New-AksHciNodePool ou New-AksHciCluster. Você também pode usar esses comandos para contaminar os nós do sistema operacional Linux. O exemplo a seguir contamina os nós do Windows.

Aplicar taint ao novo cluster

Se você também criar um novo cluster, execute o comando a seguir para criar um pool de nós do Windows com um taint. Se você tiver um cluster existente ao qual deseja adicionar um pool de nós com um taint, consulte o próximo exemplo, que usa o New-AksHciNodePool comando.

New-AksHciCluster -name mycluster -nodePoolName taintnp -nodeCount 1 -osType Windows -osSku Windows2022 -taints sku=Windows:NoSchedule

Adicionar pool de nós contaminado ao cluster existente

Para adicionar um pool de nós contaminado a um cluster existente, execute o seguinte comando:

New-AksHciNodePool -clusterName <cluster-name> -nodePoolNAme taintnp -count 1 -osType Windows -osSku Windows2022 -taints sku=Windows:NoSchedule

Para verificar se o pool de nós foi implementado com êxito com o taint, execute o seguinte comando:

Get-AksHciNodePool -clusterName <cluster-name> -name taintnp

Exemplo de saída:

Status       : {Phase, Details}
ClusterName  : mycluster
NodePoolName : taintnp
Version      : v1.20.7-kvapkg.1
OsType       : Windows
NodeCount    : 0
VmSize       : Standard_K8S3_v1
Phase        : Deployed
Taints       : {sku=Windows:NoSchedule}

Especificar tolerância para pod

Você pode especificar uma tolerância para um pod no YAML de especificação de pod. A tolerância a seguir "corresponde" ao taint criado pela linha de kubectl taint mostrada no exemplo anterior. O resultado é que um pod com a tolerância pode ser agendado nos nós contaminados.

tolerations:
- key: node.kubernetes.io/os
  operator: Equal
  value: Windows
  effect: NoSchedule

As etapas nesta seção funcionam bem se você estiver no controle da especificação do pod que está implantando. No entanto, em alguns casos, os usuários têm um grande número pré-existente de implantações para contêineres Linux, bem como um ecossistema de configurações comuns, como gráficos do Helm da comunidade. Você não terá acesso à especificação do pod, a menos que queira baixar e editar o gráfico.

Se você implantar esses gráficos do Helm em um ambiente de cluster misto com nós de trabalho do Linux e do Windows, os pods do aplicativo falharão com o erro "ImagePullBackOff". Por exemplo:

kubectl get pods
NAMESPACE              NAME                                                    READY   STATUS              RESTARTS   AGE
default                nginx-deployment-558fc78868-795dp                       0/1     ImagePullBackOff    0          6m24s
default                nginx-deployment-6b474476c4-gpb77                       0/1     ImagePullBackOff    0          11m

Nesse caso, você pode usar taints para ajudar com isso. Os nós do Windows Server podem ser contaminados com o par node.kubernetes.io/os=windows:NoSchedulechave-valor.

Para obter mais informações sobre impurezas e tolerâncias, consulte Impurezas e tolerâncias.

Próximas etapas

Neste guia de instruções, você aprendeu como adicionar seletores de nó ou taints e tolerâncias aos clusters do Kubernetes usando o kubectl. Em seguida, você pode: