As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Executando cargas de trabalho heterogêneas

O Kubernetes tem suporte para clusters heterogêneos, nos quais você pode ter uma mistura de nós Linux e Windows no mesmo cluster. Dentro desse cluster, você pode ter uma mistura de pods executados no Linux e pods executados no Windows. Você pode até mesmo executar várias versões do Windows no mesmo cluster. No entanto, há vários fatores (conforme mencionado abaixo) que precisarão ser considerados ao tomar essa decisão.

Melhores práticas de atribuição de PODs a nós

Para manter as cargas de trabalho do Linux e do Windows em seus respectivos OS-specific nós, você precisa usar uma combinação de seletores de nós e. taints/tolerations O principal objetivo de programar cargas de trabalho em um ambiente heterogêneo é evitar a quebra da compatibilidade com cargas de trabalho Linux existentes.

Garantir que OS-specific as cargas de trabalho cheguem ao host de contêiner apropriado

Os usuários podem garantir que os contêineres do Windows possam ser agendados no host apropriado usando nodeSelectors. Atualmente, todos os nós do Kubernetes têm os seguintes rótulos padrão:

kubernetes.io/os = [windows|linux]
kubernetes.io/arch = [amd64|arm64|...]

Se uma especificação de pod não incluir um NodeSelector como o NodeSelector"kubernetes.io/os": windows, o pod poderá ser agendado em qualquer host, Windows ou Linux. Isso pode ser problemático, pois um contêiner do Windows só pode ser executado no Windows e um contêiner Linux só pode ser executado no Linux.

Em ambientes corporativos, não é incomum ter um grande número de implantações preexistentes para contêineres Linux, bem como um ecossistema de configurações prontas para uso, como gráficos do Helm. Nessas situações, você pode hesitar em fazer alterações nos NodeSelectors de uma implantação. A alternativa é usar Taints.

Por exemplo: --register-with-taints='os=windows:NoSchedule'

Se você estiver usando o EKS, o eksctl oferece maneiras de aplicar contaminações por meio do ClusterConfig:

NodeGroups:
  - name: windows-ng
    amiFamily: WindowsServer2022FullContainer
    ...
    labels:
      nodeclass: windows2022
    taints:
      os: "windows:NoSchedule"

Ao adicionar uma mancha a todos os nós do Windows, o agendador não agendará pods nesses nós, a menos que eles tolerem a contaminação. Exemplo de manifesto do pod:

nodeSelector:
    kubernetes.io/os: windows
tolerations:
    - key: "os"
      operator: "Equal"
      value: "windows"
      effect: "NoSchedule"

Manipulação de várias compilações do Windows no mesmo cluster

A imagem base do contêiner do Windows usada por cada pod deve corresponder à mesma versão de compilação do kernel do nó. Se quiser usar várias compilações do Windows Server no mesmo cluster, defina rótulos de nós adicionais, nodeSelectors ou use um rótulo chamado windows-build.

O Kubernetes 1.17 adiciona automaticamente um novo rótulo node.kubernetes. io/windows-build para simplificar o gerenciamento de várias compilações do Windows no mesmo cluster. Se você estiver executando uma versão mais antiga, é recomendável adicionar esse rótulo manualmente aos nós do Windows.

Esse rótulo reflete o número principal, secundário e de compilação do Windows que precisam corresponder para fins de compatibilidade. Abaixo estão os valores usados atualmente para cada versão do Windows Server.

É importante observar que o Windows Server está migrando para o Long-Term Servicing Channel (LTSC) como o principal canal de lançamento. O Windows Server Semi-Annual Channel (SAC) foi descontinuado em 9 de agosto de 2022. Não haverá futuras versões SAC do Windows Server.

É possível verificar a versão de compilação do sistema operacional por meio do seguinte comando:

kubectl get nodes -o wide

A KERNEL-VERSION saída corresponde à versão de compilação do sistema operacional Windows.

NAME                          STATUS   ROLES    AGE   VERSION                INTERNAL-IP   EXTERNAL-IP     OS-IMAGE                         KERNEL-VERSION                  CONTAINER-RUNTIME
ip-10-10-2-235.ec2.internal   Ready    <none>   23m   v1.24.7-eks-fb459a0    10.10.2.235   3.236.30.157    Windows Server 2022 Datacenter   10.0.20348.1607                 containerd://1.6.6
ip-10-10-31-27.ec2.internal   Ready    <none>   23m   v1.24.7-eks-fb459a0    10.10.31.27   44.204.218.24   Windows Server 2019 Datacenter   10.0.17763.4131                 containerd://1.6.6
ip-10-10-7-54.ec2.internal    Ready    <none>   31m   v1.24.11-eks-a59e1f0   10.10.7.54    3.227.8.172     Amazon Linux 2                   5.10.173-154.642.amzn2.x86_64   containerd://1.6.19

O exemplo abaixo aplica um nodeSelector adicional ao manifesto do pod para corresponder à Windows-build versão correta ao executar diferentes versões do sistema operacional de grupos de nós do Windows.

nodeSelector:
    kubernetes.io/os: windows
    node.kubernetes.io/windows-build: '10.0.20348'
tolerations:
    - key: "os"
    operator: "Equal"
    value: "windows"
    effect: "NoSchedule"

Simplificação NodeSelector e tolerância em manifestos de pods usando RuntimeClass

Você também pode usar RuntimeClass para simplificar o processo de uso de impurezas e tolerâncias. Isso pode ser feito criando um RuntimeClass objeto que é usado para encapsular essas impurezas e tolerâncias.

Crie um RuntimeClass executando o seguinte manifesto:

apiVersion: node.k8s.io/v1beta1
kind: RuntimeClass
metadata:
  name: windows-2022
handler: 'docker'
scheduling:
  nodeSelector:
    kubernetes.io/os: 'windows'
    kubernetes.io/arch: 'amd64'
    node.kubernetes.io/windows-build: '10.0.20348'
  tolerations:
  - effect: NoSchedule
    key: os
    operator: Equal
    value: "windows"

Depois que a classe Runtime for criada, atribua-a usando como especificação no manifesto do pod:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: iis-2022
  labels:
    app: iis-2022
spec:
  replicas: 1
  template:
    metadata:
      name: iis-2022
      labels:
        app: iis-2022
    spec:
      runtimeClassName: windows-2022
      containers:
      - name: iis

Suporte para grupos de nós gerenciados

Para ajudar os clientes a executar seus aplicativos Windows de forma mais simplificada, a AWS lançou o suporte ao Amazon EKS Managed Node Group (MNG) para contêineres do Windows em 15 de dezembro de 2022. Para ajudar a alinhar as equipes de operações, os MNGs do Windows são habilitados usando os mesmos fluxos de trabalho e ferramentas dos MNGs do Linux. https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html Há suporte para versões completas e principais da família AMI (Amazon Machine Image) do Windows Server 2019 e 2022.

As seguintes famílias de AMI são compatíveis com grupos de nós gerenciados (MNG).

Documentações adicionais

Documentação oficial da AWS: https://docs.aws.amazon.com/eks/latest/userguide/windows-support.html

Para entender melhor como o Pod Networking (CNI) funciona, confira o link a seguir: https://docs.aws.amazon.com/eks/latest/userguide/pod-networking.html

Blog da AWS sobre a implantação do Managed Node Group para Windows no EKS: https://aws.amazon.com/blogs/containers/deploying-amazon-eks-windows-managed-node-groups/