Administración de pods en clústeres de Kubernetes de varios grupos
Los desarrolladores de Contoso trabajan en la transformación de aplicaciones de Windows y Linux desarrolladas internamente en imágenes basadas en Docker que se pueden implementar mediante gráficos de Helm. En el planeamiento de la implementación de clústeres de Kubernetes en Azure Stack HCI, debe garantizar la compatibilidad con ambas plataformas de sistema operativo.
¿Qué son los grupos de nodos en los clústeres de Kubernetes en Azure Stack HCI?
AKS en Azure Stack HCI admite varios grupos de nodos en el mismo clúster de Kubernetes. Cada grupo consta de máquinas virtuales configuradas de forma idéntica, según la configuración que especifique al aprovisionar ese grupo.
Al agrupar nodos en grupos distintos, puede dirigir las implementaciones de pods al conjunto adecuado de máquinas virtuales. Por ejemplo, es posible que tenga cargas de trabajo contenedorizadas que solo admitan el sistema operativo Windows o que requieran hardware especializado, como unidades de procesador de gráficos.
Control de la implementación de pods en grupos de nodos en clústeres de Kubernetes en Azure Stack HCI
De forma predeterminada, Kubernetes programa el aprovisionamiento de cargas de trabajo contenedorizadas en los nodos de trabajo disponibles de forma que se optimice el uso de recursos. Para modificar este comportamiento, puede aplicar restricciones en la elección de nodos en función de criterios personalizados que especifique. Estas restricciones incluyen selectores de nodo, manchas y tolerancias.
Selectores de nodos
El selector de nodos es una configuración dentro de la definición basada en YAML de un pod o una implementación que identifica los nodos de destino en los que se puede programar el pod correspondiente. Si su intención es designar nodos de destino en función de su sistema operativo, puede confiar en las etiquetas integradas que Kubernetes asigna automáticamente a los nodos. Según el sistema operativo previsto, el selector de nodos tendrá el formato kubernetes.io/os = Windows o kubernetes.io/os = Linux. Por ejemplo, el siguiente manifiesto de pod basado en YAML designa los nodos de Linux como destinos de implementación:
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
env: test
spec:
containers:
- name: nginx
image: nginx
nodeSelector:
kubernetes.io/os = Linux
Intolerancias y tolerancias
Las manchas y tolerancias proporcionan un enfoque alternativo para controlar la colocación del pod. Con este enfoque, las manchas forman parte de la configuración del nodo y las tolerancias forman parte de las especificaciones del pod. Al manchar un nodo, se impide eficazmente que hospede un pod sin la tolerancia específica de la mancha correspondiente.
Por ejemplo, en AKS en Azure Stack HCI, si quisiera permitir la programación de un pod en un nodo de Windows, agregaría la siguiente tolerancia a su definición:
tolerations:
- key: node.kubernetes.io/os
operator: Equal
value: Windows
effect: NoSchedule
Además, tendría que agregar la mancha node.kubernetes.io/os=Windows:NoSchedule a cada uno de los nodos de Windows que quiera que estén disponibles exclusivamente para la implementación de pods con la tolerancia correspondiente. Para ello, podría emplear la utilidad de línea de comandos kubectl y, luego, después de conectarse al clúster de destino, ejecutar el siguiente comando para cada uno de los nodos del ámbito (donde el marcador de posición <node_name> designa el nombre del nodo de destino):
kubectl taint node <node_name> node.kubernetes.io/os=Windows:NoSchedule
Nota:
Los selectores de nodos exigen la colocación de pods en un conjunto específico de nodos. Las tolerancias permiten que los pods se ejecuten en un conjunto designado de nodos manchados, pero no impide su colocación en nodos sin manchas.