Adaptar aplicações para utilização em clusters do Kubernetes de SO misto

  • Artigo

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

O AKS ativado pelo Azure Arc permite-lhe executar clusters do Kubernetes com nós linux e Windows, mas tem de fazer pequenas edições às suas aplicações para utilização nestes clusters de SO misto. Neste guia de procedimentos, vai aprender a garantir que a sua aplicação é agendada no SO anfitrião certo através de seletores de nós ou taints e tolerâncias.

Este artigo pressupõe uma compreensão básica dos conceitos do Kubernetes. Para obter mais informações, veja Kubernetes core concepts for AKS enabled by Arc (Conceitos fundamentais do Kubernetes para o AKS ativado pelo Arc).

Seletores de nós

Um seletor de nós é um campo simples na especificação do pod YAML que restringe os pods a serem agendados apenas para nós em bom estado de funcionamento que correspondam ao sistema operativo. Na especificação do pod YAML, especifique um nodeSelector valor do Windows ou Linux, conforme mostrado nos seguintes exemplos:

kubernetes.io/os = Windows

ou,

kubernetes.io/os = Linux

Para obter mais informações sobre nodeSelectors, veja seletores de nós.

Taints e tolerâncias

Taints e tolerâncias funcionam em conjunto para garantir que os pods não são agendados em nós involuntariamente. Um nó pode ser "contaminado" para rejeitar pods que não toleram explicitamente a sua taint através de uma "tolerância" na especificação do pod YAML.

Os nós do SO Windows no AKS Arc podem ser contaminados quando criados com os comandos New-AksHciNodePool ou New-AksHciCluster . Também pode utilizar estes comandos para manchar os nós do SO Linux. O exemplo seguinte mancha os nós do Windows.

Aplicar taint ao novo cluster

Se também criar um novo cluster, execute o seguinte comando para criar um conjunto de nós do Windows com um taint. Se tiver um cluster existente ao qual pretende adicionar um conjunto de nós com um taint, veja o exemplo seguinte, que utiliza o New-AksHciNodePool comando .

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

Adicionar conjunto de nós contaminados ao cluster existente

Para adicionar um conjunto de nós contaminados 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 conjunto 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

Pode especificar uma tolerância para um pod na especificação do pod YAML. A seguinte tolerância "corresponde" ao taint criado pela kubectl linha taint mostrada no exemplo anterior. O resultado é que um pod com tolerância pode agendar para os nós contaminados.

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

Os passos nesta secção funcionam bem se estiver a controlar a especificação do pod que está a implementar. No entanto, em alguns casos, os utilizadores têm um grande número de implementações pré-existentes para contentores linux, bem como um ecossistema de configurações comuns, como gráficos Helm da comunidade. Não terá acesso à especificação do pod, a menos que pretenda transferir e editar o gráfico.

Se implementar estes gráficos Helm num ambiente de cluster misto com nós de trabalho do Linux e do Windows, os pods de aplicação 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

Neste caso, pode utilizar taints para o ajudar. 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 taints e tolerâncias, veja Taints and Tolerations (Taints and Tolerations).

Passos seguintes

Neste guia de procedimentos, aprendeu a adicionar seletores de nós ou taints e tolerâncias aos clusters do Kubernetes com kubectl. Em seguida, pode: