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 que rodam no Linux e pods que rodam 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.
## Atribuição de PODs a nós: melhores práticas
Para manter as cargas de trabalho do Linux e do Windows em seus respectivos OS-specific nós, você precisa usar alguma 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 das 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 programados 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 do Pod não incluir um NodeSelector`"kubernetes.io/os": windows`, o Pod poderá ser programado 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 do Linux só pode ser executado no Linux.
Em ambientes corporativos, não é incomum ter um grande número de implantações pré-existentes para contêineres Linux, bem como um ecossistema de configurações prontas para uso, como gráficos 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 manchas por meio do ClusterConfig:
```
NodeGroups:
- name: windows-ng
amiFamily: WindowsServer2022FullContainer
...
labels:
nodeclass: windows2022
taints:
os: "windows:NoSchedule"
```
Adicionando uma contaminação 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 de pod:
```
nodeSelector:
kubernetes.io/os: windows
tolerations:
- key: "os"
operator: "Equal"
value: "windows"
effect: "NoSchedule"
```
## Manipulando 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 você quiser usar várias compilações do Windows Server no mesmo cluster, defina rótulos de nós adicionais, nodeSelectors ou utilize 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 retirado em 9 de agosto de 2022. Não haverá versões futuras do SAC do Windows Server.
| Nome do produto | Número (s) de compilação |
| --- | --- |
| Servidor LTSC 2022 completo | 10.0.20348 |
| Núcleo do servidor 2019 LTSC | 10.0.17763 |
É 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 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 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 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 Pod usando RuntimeClass
Você também pode usá-lo RuntimeClass para simplificar o processo de uso de manchas e tolerâncias. Isso pode ser feito criando um RuntimeClass objeto que é usado para encapsular essas manchas 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
```
## Managed Node Group Support
Para ajudar os clientes a executar seus aplicativos Windows de forma mais simplificada, a AWS lançou o suporte para o suporte do Amazon [EKS Managed Node Group (MNG) para contêineres Windows](https://aws.amazon.com/about-aws/whats-new/2022/12/amazon-eks-automated-provisioning-lifecycle-management-windows-containers/) em 15 de dezembro de 2022. [Para ajudar a alinhar as equipes de operações, os [Windows MNGs](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html) são habilitados usando os mesmos fluxos de trabalho e ferramentas dos MNGs Linux.](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html) Há suporte para as 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).
| Família AMI |
| --- |
| Windows\_Core\_2019\_x86\_64 |
| Windows\_Full\_2019\_x86\_64 |
| Windows\_Core\_2022\_x86\_64 |
| Windows\_Full\_2022\_x86\_64 |
## Documentações adicionais
Documentação oficial da AWS: https://docs.aws.amazon.com/eks/latest/userguide/windows-support.html
Para entender melhor como funciona o Pod Networking (CNI), 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/