Ubicación de pods
En Kubernetes, los pods recién creados y no programados se programan automáticamente en nodos que cumplen sus requisitos. Cuando tiene diferentes tipos de nodos en su clúster, puede ser importante ejercer control sobre los nodos en los que se programan los pods. Hay cuatro herramientas que puede usar para la colocación de los pods de control:
Las etiquetas de nodo se aplican a un nodo para especificar información sobre el mismo. Una etiqueta puede ser una clave o un par clave/valor.
La afinidad de nodo se aplica a un pod para restringir ese pod a que funcione en nodos con una etiqueta especificada.
Se aplican marcas a un nodo para evitar que los pods se programen en ese nodo.
Se aplican tolerancias a un pod para permitir que esta ignore ciertas marcas.
Para obtener más información sobre la afinidad de nodos, las marcas y las tolerancias en general, consulte la documentación de Kubernetes. Para información sobre cómo aplicar afinidad y tolerancias de nodos a pods en ArcGIS Enterprise on Kubernetes, véase Administrar la ubicación de pods.
Ventajas
Las etiquetas de nodos y la afinidad de nodos aseguran que un pod esté programado en el nodo correspondiente. Las marcas y tolerancias aseguran que un nodo solo tenga programados los pods adecuados. Usarlos en combinación le ayuda a mejorar el aislamiento, optimizar la asignación de recursos y cumplir eficazmente los requisitos de cumplimiento normativo dentro de su clúster de Kubernetes:
Aislar cargas de trabajo con requisitos especializados: utilice reglas de afinidad de nodos y etiquetas para garantizar que ciertos pods se programen en nodos específicos. Utilice marcas para señalar nodos con características especiales, como grandes requisitos de memoria o CPU, como específicos de cargas de trabajo de ArcGIS. Aplique tolerancias a los pods de servicio para garantizar que se programen en nodos con los recursos necesarios.
Optimizar la asignación de recursos: aplique marcas a nodos con recursos limitados para evitar la sobrecarga de los recursos y defina tolerancia en pods de servicio para ajustarse a las restricciones de recursos de estos nodos. Combine la afinidad con marcas y tolerancias para garantizar que los pods de servicios solo se programen en nodos que puedan satisfacer los requisitos en cuanto a recursos.
Programación basada en geolocalización: para aplicaciones que requieren la localidad o adherencia de los datos a reglamentaciones específicas, utilice la afinidad de nodos para programar pods de servicio basados en la ubicación geográfica de los nodos. Marque los nodos basándose en normas de ubicación física o soberanía de datos y aplique tolerancias en los pods de servicio para garantizar que se programen en nodos y cumplan las restricciones de ubicación necesarias.
El ajuste automático a escala mejora el uso de la afinidad y las tolerancias de nodos al ajustar dinámicamente el número de pods en función de las demandas de carga de trabajo. Este ajuste a escala dinámico asegura que los pods se programen de forma eficaz en nodos que cumplan determinados requisitos o tengan disponibles los recursos necesarios, lo que optimiza la asignación de recursos. Al combinar el ajuste a escala automático con la afinidad y las tolerancias de nodos, los clústeres de Kubernetes pueden ofrecer una optimización de recursos, un rendimiento y una escalabilidad mejores, adaptando las fluctuaciones de la carga de trabajo al tiempo que se respetan las preferencias y las restricciones de nodos. Para obtener más información sobre el ajuste a escala automático, consulte Escala de servicio.
Administrar la ubicación de pods
Se recomienda aplicar etiquetas de nodo antes de la afinidad de nodos. De esta forma, se evita que los pods queden atascados en un estado pendiente porque los nodos aún no tienen la etiqueta correspondiente. De forma similar, se recomienda aplicar tolerancias antes de contaminar nodos. Esto garantiza que no se eliminen involuntariamente pods que todavía no tienen tolerancias coincidentes, lo que provocaría interrupciones en los servicios.
En la mayoría de los entornos, puede agrupar las cargas de trabajo con grupos de nodos. Se recomienda que aplique etiquetas y marcas a grupos de nodos en lugar de a nodos individuales.
En ArcGIS Enterprise on Kubernetes, puede usar ArcGIS Enterprise Manager para establecer afinidad y tolerancias de nodos para las siguientes implementaciones:
Configuración de afinidad de nodos
Para configurar una regla de afinidad de nodo, establezca los siguientes valores:
Tipo: tipo de afinidad de nodos. Los tipos disponibles son los siguientes:
Preferido (
PreferredDuringSchedulingIgnoredDuringExecution): el pod prefiere programarse en un nodo que cumple la regla.Obligatorio (
RequiredDuringSchedulingIgnoredDuringExecution): el pod debe programarse en un nodo que cumple la regla.
Clave: clave de la etiqueta o anotación de nodo que debe cumplir la regla.
Operador: operador de la regla. Los operadores disponibles son los siguientes:
En: la etiqueta de nodo o anotación debe estar en la lista de valores especificados.
No en: la etiqueta de nodo o anotación no debe estar en la lista de valores especificados.
Existe: el nodo debe tener la etiqueta o anotación especificada.
No existe: el nodo no debe tener la etiqueta o anotación especificada.
Valor: lista de valores para contrastar con la etiqueta o anotación del nodo. No está disponible cuando se selecciona el operador Existe o No Existe.
Configuración de tolerancias
Para configurar una tolerancia, establezca los siguientes valores:
Efecto: efecto de marca con la que debe coincidir la tolerancia. Los efectos disponibles son los siguientes:
Ninguna programación: los pods nuevos no se programan en el nodo marcado sin una tolerancia coincidente.
Preferir sin programación: los pods nuevos intentan evitar programarse en el nodo marcado sin una tolerancia coincidente, pero no se garantiza.
Sin ejecución: cualquier pod sin una tolerancia coincidente se expulsa inmediatamente después de que el nodo se contamina. Los pods nuevos no se programan en el nodo marcado sin una tolerancia coincidente.
Clave: clave de la marca con la que debería coincidir la tolerancia.
Operador: operador que se va a utilizar para la tolerancia. Los operadores disponibles son los siguientes:
Igual: el pod tolera una marca con la clave y el valor especificados.
Existe: el pod tolera cualquier marca con la clave especificada.
Valor: valor de la marca con la que debería coincidir la tolerancia si la operación se define como igual. No disponible cuando se selecciona el operador Existe.
Nota:
Las cargas de trabajo de análisis de rásteres y servicio de notebook que necesitan ejecutar nodos habilitados para GPU requieren una configuración específica de afinidad y tolerancia de nodos. Para obtener más información sobre esta configuración, consulte Configurar nodos habilitados para GPU para cargas de trabajo de análisis de rásteres y Ver y editar tiempos de ejecución para cargas de trabajo del servicio de notebook.
Escenarios
Para entender mejor cómo puede beneficiar la colocación de pods en servicios a su organización, revise los siguientes escenarios.
Escenario 1: aumento del tráfico estacional para servicios públicos de representación cartográfica
Un organismo público experimenta un aumento importante del tráfico durante un festival local. Los usuarios que acceden al mapa web en busca de información de los eventos están experimentando retrasos a causa de la gran demanda en el servicio de mapas subyacente. Para solucionarlo, el administrador de la organización realiza lo siguiente:
Agrega la etiqueta de clave/valor high-performance: true a los nodos con altos recursos de CPU y memoria.
Aplica reglas de afinidad de nodos para priorizar la programación de los pods del servicio de mapas en nodos con altos recursos de CPU y memoria. De esta forma, se garantiza que el servicio de mapas pueda gestionar el aumento de tráfico:
Tipo: preferido
Clave: alto rendimiento
Operador: existe
Valor: verdadero
Aplica una tolerancia a los pods para el servicio de mapas crítico, lo que permite programarlos en nodos marcados para cargas de trabajo de alto rendimiento.
Efecto: ninguna programación
Clave: carga de trabajo
Operador: igual
Valor: alto rendimiento
Contamina nodos de alto rendimiento con workload=high-performance:NoSchedule para evitar que pods menos críticos sin la tolerancia correspondiente se programen en el nodo. Esto garantiza que haya espacio en los nodos de alto rendimiento para programar los pods para servicios relacionados con el evento.
Escenario 2: procesamiento de datos para la monitorización ambiental
Una agencia medioambiental está ejecutando una serie de análisis geoespaciales para monitorizar cambios en el uso del suelo. El análisis requiere importantes recursos informáticos y la agencia tiene nodos específicos con GPU para este fin. Para garantizar que el análisis geoespacial se ejecute de manera eficaz sin competir con otros servicios por los recursos, el administrador de la organización:
Agrega la etiqueta clave/valor gpu: true a los nodos habilitados para GPU.
Aplica reglas de afinidad de nodos para programar los pods de análisis solo en nodos de GPU:
Tipo: obligatorio
Clave: gpu
Operador: en
Valor: verdadero
Aplica una tolerancia a los pods de análisis, permitiendo que se programen en los nodos marcados de la GPU:
Efecto: ninguna programación
Clave: carga de trabajo
Operador: igual
Valor: muchos recursos
Marca los nodos de GPU con workload=high-resource:NoSchedule para evitar que se programen en el nodo pods que consuman menos recursos sin la tolerancia correspondiente. Esto garantiza que las costosas máquinas habilitadas con GPU solo se usen para los pods de análisis que las necesitan.
Escenario 3: optimización de recursos de servicios de entidades compartidos
El departamento de SIG de una ciudad tiene varios servicios de entidades que no se utilizan mucho, pero que, en conjunto, suponen una carga para una única implementación de servicio. El clúster contiene nodos premium para garantizar la calidad de servicio garantizada para servicios de alta prioridad y nodos con menor disponibilidad de recursos para servicios de baja prioridad. Para asegurar que estos servicios de entidades de baja prioridad se programen preferentemente en los nodos menos costosos, el administrador de la organización:
Configura los nodos con menor disponibilidad de recursos con la clave recursos limitados.
Aplica reglas de afinidad de nodos para pods de servicio de entidades para priorizar la programación en nodos con menos disponibilidad de recursos:
Tipo: preferido
Clave: recursos limitados
Operador: no existe
Aplica tolerancia a pods de servicio de entidades para garantizar que puedan programarse en nodos marcados a pesar de las restricciones:
Efecto: sin programación preferido
Clave: recursos limitados
Operador: existe
Marca los nodos con menor disponibilidad de recursos con resource-restrained:PreferNoSchedule.
Escenario 4: evitar la interrupción del data store durante el escalado del clúster
Un gobierno nacional tiene un patrón de uso de servicios en el que estos se utilizan intensamente durante las horas diurnas. Este patrón requiere un gran número de nodos de clúster para admitir todas las réplicas de pod necesarias para estos servicios. Dado que los servicios no se utilizan por la noche, la organización desea reducir el número de nodos para ahorrar en sus costes de computación en la nube. Sin embargo, la terminación de los nodos en los que se ejecutan los pods de data store administrados por el sistema con estado crea el riesgo de interrumpir ArcGIS Enterprise. Para evitar esta posible interrupción, el administrador de la organización:
Crea un grupo de nodos separado.
Añade la etiqueta clave/valor data-store: true a cada nodo del grupo.
Aplica reglas de afinidad de nodos para garantizar que los pods del data store se programen en los nodos de este grupo
Tipo: obligatorio
Clave: data-store
Operador: en
Valor: verdadero
Aplica una tolerancia a los pods de data store con estado, lo que les permite ejecutarse en los nodos de data store marcados:
Efecto: ninguna programación
Clave: carga de trabajo
Operador: igual
Valor: data-store
Marca los nodos de data store con workload=data-store:NoSchedule para evitar que pods sin estado sin la tolerancia coincidente se programen en el nodo. Esto garantiza que haya espacio en los nodos de data store para programar todos los pods de data store con estado.
No reduce el grupo de nodos del data store al reducir los nodos del clúster durante la noche. Como todos los pods de data store con estado están en este grupo de nodos, no se ven afectados por la reducción de los otros grupos de nodos.