Ajustes y mejores prácticas para SUSE Rancher Prime a gran escala

Las recomendaciones descritas en la recomendaciones generales de Rancher son particularmente importantes en un contexto de alta escala.

Etcd es la base de datos de respaldo para Kubernetes y para Rancher. La base de datos puede eventualmente encontrar limitaciones en el número de un solo tipo de recurso de Kubernetes que puede almacenar. Los límites exactos varían y dependen de varios factores. Sin embargo, la experiencia indica que los problemas de rendimiento surgen frecuentemente una vez que el conteo de objetos de un solo tipo de recurso supera los 60,000. A menudo, ese tipo es RoleBinding.

Esto es típico en Rancher, ya que muchas operaciones crean nuevos objetos de RoleBinding en el clúster ascendente como efecto secundario.

Puedes reducir el número de RoleBindings en el clúster ascendente de las siguientes maneras:

Si tienes cincuenta o más usuarios, deberías configurar un proveedor de autenticación externa. Esto es necesario para un mejor rendimiento.

Después de configurar la autenticación externa, asegúrate de asignar permisos a grupos en lugar de a usuarios individuales. Esto ayuda a reducir el conteo de objetos RoleBinding.

Predecir cuántos RoleBinding objetos creará una configuración dada es complicado. Sin embargo, las siguientes consideraciones pueden ofrecer una estimación aproximada:

Rancher utiliza dos recursos de aplicaciones de Kubernetes: apps.projects.cattle.io y apps.cattle.cattle.io. Las aplicaciones heredadas, representadas por apps.projects.cattle.io, se introdujeron con la antigua interfaz de usuario del Administrador de Clústeres y ahora están obsoletas. Las aplicaciones actuales, representadas por apps.catalog.cattle.io, se encuentran en la interfaz de usuario del Explorador de Clústeres para su respectivo clúster. Las aplicaciones Apps.cattle.cattle.io son preferibles porque sus datos residen en clústeres descendentes, lo que libera recursos en el clúster ascendente.

Debes eliminar cualquier aplicación heredada que aparezca en la interfaz de usuario del Administrador de Clústeres y reemplazarla por aplicaciones en la interfaz de usuario del Explorador de Clústeres. Crea cualquier nueva app únicamente en la interfaz de usuario de Cluster Explorer.

Un Endpoint Autorizado del Clúster (ACE) proporciona acceso a la API de Kubernetes de clústeres RKE2 y K3s provisionados por Rancher. Cuando está habilitado, el ACE añade un contexto a los archivos kubeconfig generados para el clúster. El contexto utiliza un punto de acceso directo al clúster, eludiendo así a Rancher. Esto reduce la carga en Rancher en casos donde el acceso a la API sin mediación es aceptable o preferible. Consulta Endpoint Autorizado del Clúster para más información e instrucciones de configuración.

La mayor parte de la lógica de Rancher ocurre en los controladores de eventos. Estos controladores de eventos se ejecutan en un objeto cada vez que el objeto se actualiza y cuando se inicia Rancher. Además, se ejecutan cada 10 horas cuando Rancher sincroniza cachés. En configuraciones escaladas, estas ejecuciones programadas conllevan enormes costos de rendimiento porque cada controlador se ejecuta en cada objeto aplicable. Sin embargo, la ejecución programada del controlador se puede desactivar con la variable de entorno CATTLE_SYNC_ONLY_CHANGED_OBJECTS. Si se observan picos en la asignación de recursos cada 10 horas, esta configuración puede ayudar.

El valor para CATTLE_SYNC_ONLY_CHANGED_OBJECTS puede ser una lista separada por comas de las siguientes opciones. Los valores se refieren a los tipos de manejadores y controladores (las estructuras que contienen y ejecutan los manejadores). Agregar los tipos de controladores a la variable desactiva ese conjunto de controladores para que no ejecuten sus manejadores como parte de la re-sincronización de caché.

En resumen, si notas picos de uso de CPU cada 10 horas, añade la variable de entorno CATTLE_SYNC_ONLY_CHANGED_OBJECTS a tu ampliación de Rancher (en la lista spec.containers.env) con el valor mgmt,user.

Dado que Rancher puede ser muy exigente con el clúster ascendente, especialmente a gran escala, debes tener control administrativo total sobre la configuración y los nodos del clúster. Para identificar la causa raíz del consumo excesivo de recursos, utiliza técnicas y herramientas de resolución de problemas estándar de Linux. Esto puede ayudar a distinguir si son Rancher, Kubernetes o los componentes del sistema operativo los que están causando problemas.

Aunque los servicios de Kubernetes gestionados facilitan el despliegue y la ejecución de clústeres de Kubernetes, se desaconsejan para el clúster en sentido ascendente en escenarios de alta escala. Los servicios de Kubernetes gestionados suelen limitar el acceso a la configuración y a la información sobre nodos y servicios individuales.

Utiliza RKE2 para casos de uso a gran escala.

Para proporcionar alta disponibilidad, Kubernetes está diseñado para ejecutar nodos y componentes de control en diferentes zonas. Sin embargo, si los nodos y los componentes del plano de control están ubicados en diferentes zonas, el tráfico de red puede ser más lento.

El tráfico entre los componentes de Rancher y la API de Kubernetes es especialmente sensible a la latencia más baja, al igual que el tráfico de etcd entre nodos.

Para mejorar el rendimiento, ejecuta todos los clústeres de nodos en sentido ascendente en la misma ubicación. En particular, asegúrate de que la latencia entre los nodos de etcd y Rancher sea lo más baja posible.

Debes mantener el clúster local de Kubernetes actualizado. Esto asegurará que tu clúster tenga todas las mejoras de rendimiento y correcciones de fallos disponibles.

Etcd es la base de datos backend para Kubernetes y para Rancher. Desempeña un papel muy importante en el rendimiento de Rancher.

Los dos principales cuellos de botella para el rendimiento de etcd son la velocidad del disco y de la red. Etcd debe ejecutarse en nodos dedicados con una configuración de red rápida y con SSDs que tengan altas operaciones de entrada/salida por segundo (IOPS). Para más información sobre el rendimiento de etcd, consulta Rendimiento lento de etcd (pruebas de rendimiento y optimización) y Ajustando etcd para grandes instalaciones. La información sobre discos también se puede encontrar en Requisitos de instalación.

Es mejor ejecutar etcd en exactamente tres nodos, ya que añadir más nodos reducirá la velocidad de operación. Esto puede ser contraintuitivo para los enfoques comunes de escalado, pero se debe a los mecanismos de replicación de etcd.

El rendimiento de etcd también se verá afectado negativamente por la latencia de la red entre nodos, ya que eso ralentizará la comunicación de red. Los nodos de etcd deben estar ubicados junto a los nodos de Rancher.

A gran escala, Rancher transfiere más datos del clúster ascendente a los componentes de la interfaz de usuario que se ejecutan en el navegador, y esos componentes también necesitan realizar más procesamiento.

Para obtener el mejor rendimiento, asegúrate de que el host que ejecuta el hardware cumpla con estos requisitos: