Mejores prácticas de cluster grande

Mejores prácticas: limite la escala de ráfaga a aproximadamente el 10 % de los pods y nodos de un cluster

Recomendamos que tanto los nodos como los pods se agreguen o eliminen de un cluster grande en lotes de aproximadamente el 10 % de su número total.

Las acciones de escala de cluster (como cambiar el número de nodos de un pool de nodos, configurar el número de réplicas en un despliegue y generar trabajos en el cluster) pueden generar una gran cantidad de tráfico de API para la coordinación distribuida y la programación de recursos. La recomendación del 10 % suele ser lo suficientemente conservadora como para evitar encontrar límites de frecuencia en el servidor de API de Kubernetes y otros puntos finales en la nube descendentes, por lo que se evitan costosos reintentos durante un momento de alto tráfico que pueden causar retrasos debido a retrasos.

La recomendación del 10 % es un punto de partida y depende del tamaño del cluster y de los tipos de carga de trabajo que contenga. Las cargas de trabajo con muchos operadores que se comunican con el elevador de kube pueden requerir más alisado de ráfagas, mientras que los nodos vacíos con una carga de trabajo mínima pueden explotar más rápidamente.

Consulte Consideraciones para clusters grandes en la documentación de Kubernetes.

Mejores prácticas: configure FlowSchemas para optimizar las decisiones de limitación de velocidad cuando están bajo carga

Recomendamos anular la priorización de solicitudes que no son críticas para el tiempo en clusters grandes.

La función API Priority and Fairness (APF) de kube-apiserver expone algunos controles a las solicitudes de límite de velocidad. Puede configurar la función APF mediante niveles de prioridad, que definen configuraciones flexibles para el tamaño de mano y el tamaño de cola asignados a una prioridad determinada. El uso de niveles de prioridad permite que las cargas de trabajo avanzadas optimicen el procesamiento de solicitudes y garantiza que se atiendan las solicitudes de alta prioridad.

Un valor FlowSchema define el nivel de prioridad al que pertenece una solicitud. Una configuración común, especialmente en clusters con cargas de trabajo de repartición que requieren la adición o eliminación de un gran número de pods o nodos, es utilizar un valor FlowSchema que reduzca la prioridad de las solicitudes LIST /events al nivel de prioridad catch-all. En Kubernetes, las llamadas LIST suelen ser las más caras para que sirva el kube-apiserver, y en tiempos de alta rotación, el número de eventos puede aumentar. Al instalar un FlowSchema que reduce el nivel de prioridad de estas llamadas, se pueden atender más solicitudes críticas para el tiempo. Las solicitudes de prioridad más baja reciben errores de HTTP 429 Demasiadas solicitudes y los clientes las reintentarán posteriormente para que sean consistentes.

Consulte Aislamiento de solicitudes no esenciales de la inanición de otros flujos en la documentación de Kubernetes.

Puede utilizar las métricas publicadas por kube-apiserver en /metrics para identificar cuándo se está produciendo la limitación y qué flujos pueden ser buenos candidatos para un esquema personalizado:

• Utilice la métrica apiserver_flowcontrol_rejected_requests_total para ver cuándo las solicitudes no se pueden servir y se deben volver a intentar. Si el valor se convierte en distinto de cero, se ha producido una limitación y puede que desee realizar una acción.
• Utilice la métrica apiserver_flowcontrol_request_wait_duration_seconds para ver qué niveles de prioridad son un cuello de botella.

Consulte Buenas prácticas para utilizar API Priority and Fairness en la documentación de Kubernetes.

Mejores prácticas: ajuste de los complementos de cluster para escalar con el tamaño del cluster

Recomendamos configurar los complementos CoreDNS y flannel en clusters grandes.

Los clusters mejorados de Kubernetes Engine permiten configurar los complementos instalados en un cluster (consulte Actualización de un complemento de cluster). Los valores por defecto razonables para clusters más pequeños no son necesariamente óptimos para clusters grandes.

La configuración por defecto para CoreDNS asigna 1 réplica por nodo. Sin embargo, en clusters grandes, es posible que sean más adecuadas menos réplicas. Por ejemplo, una configuración como {minReplica: 3, nodesPerReplica: 8} puede ser más adecuada en un cluster de gran tamaño. Una configuración con menos réplicas no solo consume menos recursos informáticos en el cluster, sino que también aumenta la probabilidad de aciertos de caché eficientes mediante la consolidación de solicitudes de DNS en menos réplicas.

Para evitar que un único nodo no disponible detenga la implementación de un cambio en el canal DaemonSet, puede configurar la estrategia de implementación para que tenga un valor maxUnavailable, como 25%. Esta estrategia permite implementar un cambio de canal DaemonSet en un cluster grande que tiene miles de nodos, incluso si algunos de esos nodos no están disponibles.

Para los complementos CoreDNS y flannel, en clusters grandes puede que sea necesario aumentar los límites/solicitudes de memoria y CPU asignados para adaptarse a la carga.

Consulte Configuring Cluster Add-ons.

Mejores prácticas: configuración de clientes de Kubernetes para utilizar el tipo de contenido protobuf en lugar de JSON

Recomendamos utilizar el tipo de contenido protobuf con clusters grandes, cuando esté disponible.

Por defecto, los clientes de Kubernetes utilizan JSON como tipo de contenido para todas las solicitudes. El uso de JSON como tipo de contenido es una opción fácil de usar y suficiente para la mayoría de los casos de uso. Sin embargo, con clusters grandes, el uso de protobuf en lugar de JSON como tipo de contenido puede mejorar el rendimiento.

Para especificar el uso del tipo de contenido protobuf:

• Para las solicitudes, utilice la cabecera Content-Type: application/vnd.kubernetes.protobuf.
• Para las respuestas, utilice la cabecera Accept: application/vnd.kubernetes.protobuf, application/json. Al especificar protobuf y json en la cabecera Accept, el servidor de API de Kubernetes puede volver a JSON si no existe una representación de protobuf para un objeto.

Consulte representaciones alternativas de recursos en la documentación de Kubernetes.

Mejores prácticas: activación del registro de servicio para obtener visibilidad de los logs del plano de control de Kubernetes

Recomendamos activar los logs de servicio para clusters grandes.

El servidor de API de Kubernetes informa de muchos problemas a los clientes mediante advertencias en las respuestas del servidor, así como a través de eventos. Sin embargo, los logs de los siguientes contenedores del plano de control de Kubernetes también capturan información adicional que puede ayudarle a comprender el comportamiento de los clusters de gran tamaño:

• Programador de kube
• Gestor de controlador de kube
• gestor de control de nube
• Aperitivo de kube

Para activar y ver estos logs del plano de control de Kubernetes como logs de servicio en Oracle Cloud Infrastructure Logging, siga las instrucciones de Visualización de logs de servicio de Kubernetes Engine (OKE).

Mejores prácticas: asignación de bloques CIDR de red con direcciones IP suficientes para el número esperado de pods

Recomendamos considerar de antemano el tamaño del bloque CIDR de red que se debe especificar para un cluster grande y qué plugin CNI seleccionar.

Los cambios de subred en un cluster en ejecución pueden ser perjudiciales. En el caso de los bloques CIDR de pod, no puede cambiar el bloque CIDR de pod que especifique inicialmente para un cluster después de crear el cluster. Por lo tanto, antes de crear un cluster grande, para evitar complicaciones de red a medida que se escala un cluster, tenga en cuenta cuál es el plugin CNI más adecuado para seleccionar y cuál es el tamaño de bloque CIDR más adecuado para especificar.

El plugin CNI de canal permite asignar subredes privadas grandes para su uso. Recomendamos un bloque CIDR /12 para el bloque CIDR de pod. Debido a la naturaleza de las VXLAN, el plugin CNI de canal puede asignar/desasignar pods rápidamente, con la compensación de que el tráfico de pod está ahora dentro de la encapsulación de VXLAN. Al seleccionar el tamaño de un bloque CIDR de pod, tenga en cuenta que Kubernetes Engine asigna un bloque CIDR /25 a cada nodo. El tamaño del bloque CIDR de pod que especifique puede limitar el número de nodos disponibles para un cluster (por ejemplo, si especifica un bloque CIDR /24 como bloque CIDR de pod, el cluster solo puede tener 8 nodos). Según el ratio pod-to-node que espere, se puede asignar un número significativo de direcciones IP a cada nodo que no se utilizará y que no estará disponible para otros nodos. Si este es el caso, especifique un bloque CIDR de pod más grande (consulte Bloques CIDRIPv4 CIDR IPv4 y motor de Kubernetes (OKE)).

El plugin CNI de red de pod nativo se integra directamente con redes de VCN mediante asociaciones de VNIC dedicadas. Este enfoque elimina las limitaciones en cuanto a las asignaciones de IP por nodo y elimina la necesidad de una capa de red de superposición de VXLAN adicional en el cluster. Sin embargo, las subredes de VCN están limitadas a un bloque CIDR /16, que es un espacio de direcciones más pequeño que el que se puede alojar con el canal (consulte Rangos de direcciones y tamaño de VCN permitidos). Tenga en cuenta que el número de VNIC que se pueden asociar a un nodo está limitado por el tamaño del nodo, por lo que debe tener en cuenta la selección de unidades para cada nodo al evaluar cuántas direcciones IP de pod se necesitan (consulte Unidades de computación).

Por lo general, la subred de punto final de API de Kubernetes solo necesita un bloque de CIDR pequeño, porque solo se necesita una dirección IP de punto final para cada cluster que comparte la subred. Por ejemplo, si se especifica un bloque CIDR /29 para la subred de punto final de API de Kubernetes, 6 clusters pueden compartir la subred, mientras que un bloque CIDR /28 permite que 14 clusters compartan la subred.

Mejores prácticas: aumentos de límite de servicio de solicitud preventiva

Recomendamos revisar los límites de servicio configurados para su arrendamiento y enviar solicitudes con antelación para aumentar los límites de servicio que espera que alcancen los clusters de gran tamaño. Límites de servicio

Los clusters grandes suelen alcanzar los siguientes límites:

• Número y tamaño de los repositorios de imágenes de contenedor.
• Número de nodos permitidos para un único cluster.
• Número de gigabytes de volúmenes en bloque que se pueden asignar.

Para evitar posibles interrupciones, recomendamos enviar solicitudes para aumentar los límites de servicio con antelación, especialmente para los límites de los volúmenes en bloque que se utilizan como volúmenes de inicio para los nodos.

Consulte Solicitud de aumento del límite de servicio

Mejores prácticas: aprovecha la escala automática para gestionar los recursos informáticos de forma proporcional con las cargas de trabajo

Recomendamos utilizar escalas automáticas (como la escala automática del cluster de Kubernetes (CA), la escala automática de pod horizontal (HPA) y la escala automática de pod vertical (VPA) con clusters grandes para optimizar el uso de recursos.

El uso de una escala automática permite configurar reglas que definan cuándo aprovisionar más nodos, crear más réplicas o reducir verticalmente un cluster durante un período de inactividad.

El escalado automático basado en reglas es una forma eficaz de gestionar clusters grandes con miles de nodos y pods.

Consulte Mejores prácticas de escala automática.

Mejores Prácticas: Uso de Reglas sin Estado para Listas de Seguridad y Grupos de Seguridad de Red para Minimizar la Sobrecarga de Seguimiento de Conexiones

Recomendamos utilizar reglas sin estado al configurar listas de seguridad y grupos de seguridad de red para clusters de gran tamaño.

Los tutoriales y la documentación a menudo especifican que debe crear listas de seguridad y grupos de seguridad de red con reglas "con estado". Las reglas con estado aprovechan el seguimiento de conexiones para garantizar que la ruta de retorno de una solicitud se permita automáticamente, independientemente de la presencia de una regla de salida (consulte Seguimiento de conexiones). Aunque permitir automáticamente rutas de retorno está destinado a simplificar la configuración de reglas, estas rutas de retorno permitidas automáticamente son una posible sobrecarga que puede convertirse en un problema para clusters grandes. El número de conexiones de las que se puede realizar un seguimiento es proporcional a la forma de la instancia utilizada, pero la simple selección de una unidad más grande no aborda necesariamente el problema.

Para eliminar la sobrecarga del seguimiento de conexiones y evitar posibles límites de escala, recomendamos que para cada ruta de red:

1. defina una regla de entrada y una regla de salida correspondiente como un par.
2. especifique las reglas de entrada y salida como "sin estado".

Consulte Reglas con estado frente a sin estado.