En Kubernetes, los pods recién creados y no programados se programa automáticamente en nodos que cumplen sus requisitos. Al utilizar la afinidad, marcas y tolerancias de nodo, puede tener más control sobre los nodos en los que se han programado pods.
La afinidad de nodos permite especificar reglas que limitación la ejecución de los pods a determinados nodos etiquetados. Las marcas se aplican a los nodos para rechazar pods, mientras que las tolerancias se aplican a los pods con el fin de tolerar 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. Consulte Administrar la ubicación de pods para obtener información sobre cómo aplicar la afinidad y las tolerancias de los nodos a los pods en ArcGIS Enterprise on Kubernetes.
La combinación de afinidad, marcas y tolerancias de nodos ayuda a lograr un control exhaustivo de la colocación de la carga de trabajo para mejorar el aislamiento, optimizar la asignación de recursos y cumplir satisfactoriamente los requisitos incluidos en el 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.
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:
- Configura nodos con grandes recursos de memoria y CPU con el par de clave-valor alto rendimiento: verdadero.
- Aplica reglas de afinidad de nodos para garantizar que los pods del servicio de mapas se programen en nodos con grandes recursos de memoria y CPU:
- Tipo: preferido
- Clave: alto rendimiento
- Operador: existe
- Valor: verdadero
- Aplica tolerancias para permitir que los pods se ejecuten en nodos marcados para cargas de trabajo de alto rendimiento, lo que asegura que el servicio de mapas pueda gestionar el aumento de tráfico:
- Efecto: ninguna programación
- Clave: carga de trabajo
- Operador: igual
- Valor: alto rendimiento
- Marca nodos de alto rendimiento con workload=high-performance:NoSchedule.
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:
- Configura nodos habilitados con GPU con el par de valor-clave gpu: verdadero.
- Aplica reglas de afinidad de nodos para programar los pods de análisis en nodos de GPU:
- Tipo: obligatorio
- Clave: gpu
- Operador: en
- Valor: verdadero
- Aplica tolerancias para permitir que los pods se ejecuten en nodos de GPU marcados:
- 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 ahí se programen menos pods que consuman muchos recursos.
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. Para permitir que el departamento mantenga la disponibilidad del servicio sin sobrecargar el sistema, el administrador de la organización:
- Configura nodos con la clave recursos limitados.
- Aplica reglas de afinidad de nodos 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 recursos limitados con resource-constrained: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 nodos en los que se ejecutan pods del data store gestionados por el sistema crea el riesgo de interrumpir dichos pods. Para evitar esta posible interrupción, el administrador de la organización:
- Crea un grupo de nodos independiente para los pods del data store, con cada nodo etiquetado con el par clave-valor data-store: true.
- 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 tolerancias para permitir que los pods del data store se ejecuten en los nodos del data store marcados:
- Efecto: ninguna programación
- Clave: carga de trabajo
- Operador: igual
- Valor: data-store
- Marca los nodos del data store con workload=data-store:NoSchedule.
- No reduce el grupo de nodos del data store al reducir los nodos del clúster durante la noche.