Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Ejecución de cargas de trabajo heterogéneas

Kubernetes admite clústeres heterogéneos en los que puede tener una combinación de nodos de Linux y Windows en el mismo clúster. Dentro de ese clúster, puedes tener una combinación de pods que se ejecuten en Linux y pods que se ejecuten en Windows. Incluso puedes ejecutar varias versiones de Windows en el mismo clúster. Sin embargo, hay varios factores (como se menciona a continuación) que deberán tenerse en cuenta al tomar esta decisión.

Mejores prácticas para asignar POD a nodos

Para mantener las cargas de trabajo de Linux y Windows en sus respectivos OS-specific nodos, necesitas usar una combinación de selectores de nodos y. taints/tolerations El objetivo principal de programar las cargas de trabajo en un entorno heterogéneo es evitar que se rompa la compatibilidad con las cargas de trabajo de Linux existentes.

Garantizar que OS-specific las cargas de trabajo lleguen al host de contenedor adecuado

Los usuarios pueden asegurarse de que los contenedores de Windows se puedan programar en el host adecuado mediante NodeSelectors. Todos los nodos de Kubernetes actuales tienen las siguientes etiquetas predeterminadas:

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

Si la especificación de un pod no incluye un NodeSelector como el de NodeSelector"kubernetes.io/os": windows, el pod se puede programar en cualquier host, ya sea Windows o Linux. Esto puede resultar problemático, ya que un contenedor de Windows solo puede ejecutarse en Windows y un contenedor de Linux solo puede ejecutarse en Linux.

En los entornos empresariales, no es raro tener una gran cantidad de implementaciones preexistentes de contenedores de Linux, así como un ecosistema de configuraciones listas para usar, como los gráficos de Helm. En estas situaciones, es posible que dude en realizar cambios en los NodeSelectors de una implementación. La alternativa es usar Taints.

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

Si utilizas EKS, eksctl ofrece formas de aplicar contaminaciones a través de ClusterConfig:

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

Al añadir una mancha a todos los nodos de Windows, el programador no programará los pods en esos nodos a menos que toleren la contaminación. Ejemplo de manifiesto de pod:

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

Cómo gestionar varias compilaciones de Windows en el mismo clúster

La imagen base del contenedor de Windows que usa cada pod debe coincidir con la misma versión de compilación del kernel que la del nodo. Si quieres usar varias compilaciones de Windows Server en el mismo clúster, debes establecer etiquetas de nodo adicionales, NodeSelectors, o utilizar una etiqueta llamada windows-build.

Kubernetes 1.17 agrega automáticamente una nueva etiqueta node.kubernetes. io/windows-build para simplificar la administración de varias compilaciones de Windows en el mismo clúster. Si está ejecutando una versión anterior, se recomienda agregar esta etiqueta manualmente a los nodos de Windows.

Esta etiqueta refleja el número principal, secundario y de compilación de Windows que deben coincidir para garantizar la compatibilidad. A continuación se muestran los valores que se utilizan actualmente para cada versión de Windows Server.

Es importante tener en cuenta que Windows Server se está trasladando al canal Long-Term de servicio (LTSC) como canal de lanzamiento principal. El Semi-Annual canal Windows Server (SAC) se retiró el 9 de agosto de 2022. No habrá ninguna versión futura de Windows Server en el SAC.

Es posible comprobar la versión de compilación del sistema operativo mediante el siguiente comando:

kubectl get nodes -o wide

El KERNEL-VERSION resultado coincide con la versión de compilación del sistema operativo 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

En el siguiente ejemplo, se aplica un NodeSelector adicional al manifiesto del pod para que coincida con la Windows-build versión correcta al ejecutar diferentes versiones del sistema operativo de grupos de nodos de Windows.

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

Simplificación NodeSelector y tolerancia en los manifiestos del pod utilizando RuntimeClass

También puedes utilizarlos RuntimeClass para simplificar el proceso de uso de las tolerancias y las tolerancias. Esto se puede lograr creando un RuntimeClass objeto que se utilice para encapsular estos matices y tolerancias.

Crea un RuntimeClass ejecutando el siguiente manifiesto:

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"

Una vez creada la clase Runtime, asígnala usándola como especificación en el manifiesto del 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

Soporte gestionado para grupos de nodos

Para ayudar a los clientes a ejecutar sus aplicaciones de Windows de manera más eficiente, AWS lanzó la compatibilidad con Amazon EKS Managed Node Group (MNG) para contenedores de Windows el 15 de diciembre de 2022. Para ayudar a alinear los equipos de operaciones, los MNG de Windows se habilitan con los mismos flujos de trabajo y herramientas que los MNG de Linux. Se admiten las versiones completas y principales de la familia AMI (Amazon Machine Image) de Windows Server 2019 y 2022.

Las siguientes familias de AMI son compatibles con los grupos de nodos administrados (MNG).

Documentaciones adicionales

Documentación oficial de AWS: https://docs.aws.amazon.com/eks/latest/userguide/windows-support.html

Para entender mejor cómo funciona Pod Networking (CNI), consulte el siguiente enlace: https://docs.aws.amazon.com/eks/latest/userguide/pod-networking.html

Blog de AWS sobre la implementación de Managed Node Group para Windows en EKS: https://aws.amazon.com/blogs/containers/deploying-amazon-eks-windows-managed-node-groups/