Recommendations for using large-scale ACK Pro clusters - Container Service for Kubernetes

El rendimiento y la disponibilidad de un clúster de Container Service for Kubernetes (ACK) dependen de la cantidad de recursos del clúster, la frecuencia de acceso a dichos recursos y los patrones de acceso. Las distintas combinaciones de estas variables ejercen diferentes niveles de presión sobre el API Server y generan variaciones en el rendimiento. En un clúster ACK Pro a gran escala (generalmente con más de 500 nodos o 10,000 pods), los administradores deben planificar y utilizar el clúster adecuadamente según las condiciones reales del negocio, además de monitorear de cerca las métricas para garantizar la estabilidad y disponibilidad del sistema.

Guía de lectura

Este tema está dirigido a desarrolladores y administradores de clústeres ACK Pro. Proporciona recomendaciones generales para planificar y utilizar clústeres a gran escala. Ajústelas según el entorno real de su clúster y los requisitos de su negocio.

Bajo el shared responsibility model , ACK gestiona la seguridad de los componentes del plano de control del clúster —incluidos los componentes del plano de control de Kubernetes y etcd— y la infraestructura subyacente de Alibaba Cloud. Usted es responsable de asegurar sus aplicaciones empresariales y configurar sus recursos en la nube. Para obtener más detalles, consulte Shared responsibility model .

Etapa de planificación

Clúster único frente a múltiples clústeres

Un solo clúster a gran escala reduce la sobrecarga de gestión y mejora la utilización de recursos. Sin embargo, en algunos escenarios empresariales, dividir los servicios en varios clústeres resulta más conveniente.

Considere el uso de múltiples clústeres cuando:

Consideración	Cuándo dividir
Aislamiento	Para evitar que problemas en un entorno (por ejemplo, pruebas) afecten a producción. Dividir los clústeres reduce el radio de impacto de los fallos.
Distribución geográfica	Para desplegar clústeres en regiones específicas y cumplir con los requisitos de disponibilidad y latencia de los usuarios finales.
Límites de tamaño de un clúster único	El plano de control gestionado de ACK se adapta a clústeres de diferentes escalas mediante Auto Scaling y optimizaciones de rendimiento de componentes. No obstante, la arquitectura de Kubernetes tiene límites de rendimiento inherentes, y un clúster sobredimensionado puede afectar la disponibilidad y el desempeño. Antes de planificar un clúster a gran escala, revise los límites de capacidad y los SLOs de la comunidad; después, verifique su cuota en el Quota Center. Si sus necesidades superan los límites comunitarios o de ACK, divida la carga en varios clústeres.

Para gestionar múltiples clústeres en tareas como despliegue de aplicaciones, gestión de tráfico, distribución de trabajos y monitoreo, habilite fleet management.

Mantenga los clústeres en la versión más reciente

Las versiones más recientes de Kubernetes incluyen mejoras de estabilidad, rendimiento y escalabilidad que benefician directamente a los clústeres a gran escala. Algunos ejemplos destacados:

v1.31: kube-apiserver atiende lecturas consistentes para solicitudes List desde su caché, lo que reduce el acceso directo a etcd y disminuye su carga. Consulte Lecturas consistentes desde caché.
v1.33: kube-apiserver utiliza codificación por streaming (StreamingCollectionEncodingToJSON y StreamingCollectionEncodingToProtobuf) para operaciones List, lo que reduce el uso de memoria de kube-apiserver a gran escala. Consulte Respuestas List por streaming.
v1.34: kube-apiserver admite almacenamiento en caché de instantáneas de versiones históricas de recursos, lo que mejora el rendimiento de lectura y escritura. Consulte Caché de servidor API con instantáneas.

ACK publica versiones compatibles de Kubernetes en sincronía con la comunidad y deja de admitir versiones caducadas. Esto incluye el cese de nuevas funciones, correcciones de bugs y parches de seguridad, y se proporciona únicamente soporte técnico limitado para versiones expiradas. Monitoree los anuncios de lanzamiento de versiones a través de canales como la documentación, avisos en la consola y mensajes internos, y actualice oportunamente para evitar posibles problemas de seguridad y estabilidad en el clúster.

Versiones compatibles: Version guide
Consideraciones y procedimientos de actualización: Upgrade clusters
Actualización manual: Manually upgrade an ACK cluster
Actualización automática: Automatically upgrade a cluster

Utilice el plano de control preconfigurado de ACK Pro

El plano de control de un clúster ACK Pro emplea una arquitectura de escalado automático. En clústeres ultra grandes o ante picos repentinos de alta concurrencia, la latencia de respuesta del escalado elástico puede afectar la continuidad del negocio. El plano de control preconfigurado de ACK Pro preasigna y fija los recursos del plano de control, manteniendo la concurrencia de API y la capacidad de programación de pods en un nivel alto garantizado. Es adecuado para entrenamiento e inference de IA, clústeres ultra grandes y cargas de trabajo críticas.

Al fijar los recursos del plano de control y las configuraciones base del API Server, el plano de control preconfigurado de ACK Pro elimina la incertidumbre del escalado elástico desde el origen, en lugar de depender de mecanismos elásticos para compensar posteriormente. Esto mantiene el rendimiento del plano de control predecible en todo momento.

Para obtener más información, consulte ACK Pro preset control plane.

Monitoree los límites de recursos del clúster

Respete los siguientes límites para mantener la disponibilidad y el rendimiento en clústeres a gran escala.

Recurso	Límite	Acción
Tamaño de la base de datos etcd (DB Size)	Manténgalo por debajo de 8 GB. Una base de datos etcd sobredimensionada degrada el rendimiento, incluida la latencia de lectura y escritura de datos, el consumo de recursos del sistema y la latencia de elección. También dificulta y prolonga la recuperación de servicios y datos.	Mantenga el tamaño total de la DB de etcd por debajo de 8 GB: Controle la cantidad total de recursos del clúster y limpie oportunamente los recursos no utilizados. Para recursos modificados frecuentemente, mantenga el tamaño de cada objeto por debajo de 100 KB. Cada actualización de un par clave-valor en etcd genera una nueva versión histórica. En escenarios donde se actualizan objetos grandes con frecuencia, etcd consume más recursos para almacenar las versiones históricas.
Datos totales por tipo de recurso en etcd	Manténgalo por debajo de 800 MB por tipo. Si el volumen total de un tipo de recurso es demasiado grande, los clientes que listan todos los recursos de ese tipo consumen recursos significativos del sistema. En casos graves, el servidor API o los controladores personalizados podrían fallar al inicializarse.	Al definir un nuevo CustomResourceDefinition (CRD), estime con antelación el número final de recursos personalizados (CRs). Al desplegar charts con Helm, tenga en cuenta que Helm crea releases para rastrear el estado del despliegue. De forma predeterminada, Helm almacena la información de release en Secrets. En clústeres a gran escala, almacenar grandes cantidades de información de releases en Secrets puede exceder el límite de Kubernetes sobre el tamaño total de Secrets. Utilice el backend de almacenamiento SQL de Helm en su lugar.
Conexiones y ancho de banda del CLB del API Server	Ancho de banda máximo: 5,120 Mbps; consulte CLB instances para los límites de conexión. Exceder el límite de conexiones o ancho de banda del CLB puede provocar que los nodos entren en estado Not Ready.	Para clústeres con 1,000 nodos o más, utilice instancias de Classic Load Balancer (CLB) de pago por uso. Utilice el modo de conexión directa ENI (Elastic Network Interface) cuando los clústeres a gran escala accedan al servicio Kubernetes en el namespace Default. Los clústeres creados después de febrero de 2023 con Kubernetes 1.20 o posterior usan conexión directa ENI de forma predeterminada. Consulte Access the API server using an internal endpoint.
Servicios por namespace	Manténgalo por debajo de 5,000	El kubelet inyecta información de servicios como variables de entorno en los pods. Un exceso de servicios por namespace provoca inicios lentos o fallos en el arranque de los pods. Establezca `enableServiceLinks: false` en el `podSpec` para desactivar esta función. Consulte Acceso al servicio.
Total de servicios en el clúster	Mantenga un máximo de 10,000 en total; 500 para servicios de tipo LoadBalancer	El exceso de servicios incrementa las reglas de red que procesa kube-proxy, lo que degrada su rendimiento. Para servicios de tipo LoadBalancer, la demora de sincronización con el CLB puede alcanzar varios minutos cuando la cantidad es elevada.
Pods de backend por endpoint de servicio	Manténgalo por debajo de 3,000	El kubelet en cada nodo observa actualizaciones de Service para refrescar las reglas de red locales. Cuando un servicio tiene muchos endpoints, su objeto Endpoints es grande, y cada actualización transfiere tráfico significativo entre el servidor API y kube-proxy. Cuanto mayor sea el clúster, más pronunciado será este efecto dominó. Para solucionarlo, kube-proxy usa EndpointSlices de forma predeterminada en clústeres v1.19 y posteriores. Utilice EndpointSlices en lugar de Endpoints en clústeres a gran escala, ya que dividen los endpoints en fragmentos más pequeños y reducen los datos transmitidos por cambio. Si usa un controlador personalizado que lee Endpoints directamente, mantenga el recuento por debajo de 1,000 por objeto Endpoints; por encima de esta cifra, el objeto se trunca automáticamente. Consulte Endpoints sobre capacidad.
Total de endpoints en todos los servicios	Manténgalo por debajo de 64,000	El exceso de endpoints sobrecarga el API Server y degrada el rendimiento de la red.
Pods en estado Pending	Manténgalo por debajo de 10,000	Un alto número de pods pendientes hace que el programador genere eventos repetidos, lo que puede desencadenar tormentas de eventos.
Secrets en clústeres con cifrado KMS V1	Manténgalo por debajo de 2,000	Con KMS V1, cada operación de cifrado genera una nueva clave de cifrado de datos (DEK). Al iniciar o actualizar el clúster, todos los secrets se descifran secuencialmente. Demasiados secrets ralentizan significativamente el arranque. Consulte Encryption at rest for secrets using KMS.

Etapa de configuración

Configure los parámetros de los componentes del plano de control

kube-apiserver

kube-apiserver limita el manejo concurrente de solicitudes para proteger el plano de control. Cuando se supera el límite, devuelve HTTP 429 (Too Many Requests) e indica a los clientes que reintenten. Sin limitación en el lado del servidor, el exceso de solicitudes puede colapsar el plano de control.

Mecanismos de limitación

Existen dos mecanismos de limitación según la versión de Kubernetes:

Anterior a v1.18: Solo limitación por concurrencia máxima. Los parámetros de inicio --max-requests-inflight y --max-mutating-requests-inflight restringen la concurrencia de solicitudes de lectura y escritura respectivamente. No hay diferenciación de prioridad: las solicitudes lentas o de baja prioridad pueden bloquear las urgentes. Los clústeres ACK Pro permiten personalizar estos parámetros. Consulte Customize the parameters of control plane components.

v1.18 y posterior: API Priority and Fairness (APF) ofrece una gestión de tráfico detallada. APF clasifica y aísla las solicitudes por prioridad, garantizando que las de alta prioridad se procesen primero sin perder equidad. APF entró en fase Beta en v1.20 y está habilitado de forma predeterminada. En clústeres con v1.20 o posterior, la capacidad total de solicitudes concurrentes equivale a la suma de --max-requests-inflight y --max-mutating-requests-inflight. APF utiliza dos tipos de CRD para asignar dicha capacidad.

PriorityLevelConfiguration: Define los niveles de prioridad y la proporción de concurrencia total que recibe cada nivel.
FlowSchema: Asigna las solicitudes entrantes a un PriorityLevelConfiguration.

kube-apiserver mantiene estos objetos automáticamente. Para consultar la configuración actual, revise PriorityLevelConfiguration:

ACK agrega ack-system-leader-election y ack-default al FlowSchema para los componentes principales de ACK. Las entradas restantes coinciden con los valores predeterminados de la comunidad de Kubernetes.

kubectl get PriorityLevelConfiguration
# Expected output
NAME              TYPE      ASSUREDCONCURRENCYSHARES   QUEUES   HANDSIZE   QUEUELENGTHLIMIT   AGE
catch-all         Limited   5                          <none>   <none>     <none>             4m20s
exempt            Exempt    <none>                     <none>   <none>     <none>             4m20s
global-default    Limited   20                         128      6          50                 4m20s
leader-election   Limited   10                         16       4          50                 4m20s
node-high         Limited   40                         64       6          50                 4m20s
system            Limited   30                         64       6          50                 4m20s
workload-high     Limited   40                         128      6          50                 4m20s
workload-low      Limited   100                        128      6          50                 4m20s

Consulte FlowSchema:

kubectl get flowschemas
# Expected output
NAME                           PRIORITYLEVEL     MATCHINGPRECEDENCE   DISTINGUISHERMETHOD   AGE     MISSINGPL
exempt                         exempt            1                    <none>                4d18h   False
probes                         exempt            2                    <none>                4d18h   False
system-leader-election         leader-election   100                  ByUser                4d18h   False
endpoint-controller            workload-high     150                  ByUser                4d18h   False
workload-leader-election       leader-election   200                  ByUser                4d18h   False
system-node-high               node-high         400                  ByUser                4d18h   False
system-nodes                   system            500                  ByUser                4d18h   False
ack-system-leader-election     leader-election   700                  ByNamespace           4d18h   False
ack-default                    workload-high     800                  ByNamespace           4d18h   False
kube-controller-manager        workload-high     800                  ByNamespace           4d18h   False
kube-scheduler                 workload-high     800                  ByNamespace           4d18h   False
kube-system-service-accounts   workload-high     900                  ByNamespace           4d18h   False
service-accounts               workload-low      9000                 ByUser                4d18h   False
global-default                 global-default    9900                 ByUser                4d18h   False
catch-all                      catch-all         10000                ByUser                4d18h   False

Respuesta ante la limitación

Detecte la limitación revisando las respuestas HTTP 429 o monitoreando la métrica apiserver_flowcontrol_rejected_requests_total. Cuando ocurra limitación:

Utilice el plano de control preconfigurado de ACK Pro: Este plano fija los recursos base del API Server y proporciona directamente una capacidad garantizada de procesamiento de alta concurrencia. Para obtener más información, consulte ACK Pro preset control plane.
Ajuste PriorityLevelConfiguration:
- Para solicitudes que no deben limitarse, cree un nuevo FlowSchema y asígnelo a un nivel de alta prioridad como workload-high o exempt. Utilice exempt con precaución, ya que las solicitudes exentas no están sujetas a limitación por APF. También puede crear un nuevo PriorityLevelConfiguration con mayor concurrencia para solicitudes prioritarias.
- Para clientes lentos que causan alta carga en el API Server, cree un FlowSchema que asigne esas solicitudes a un PriorityLevelConfiguration de baja concurrencia.

kube-controller-manager y kube-scheduler

Tras actualizar al plano de control preconfigurado de ACK Pro, los parámetros relacionados con QPS que utilizan kube-controller-manager y kube-scheduler para comunicarse con el API Server se ajustan automáticamente según el nivel seleccionado.

kubelet

El valor predeterminado de kube-api-qps es 5 y el de kube-api-burst es 10, valores suficientes para la mayoría de los clústeres. Si observa actualizaciones lentas en el estado de los pods, retrasos en la programación o montajes lentos de volúmenes persistentes, aumente estos valores. Consulte Customize kubelet configurations for a node pool.

Importante

Aumentar el QPS de kubelet eleva la tasa de comunicación de cada nodo con el API Server. Incremente el valor gradualmente y monitoree el rendimiento del API Server para evitar sobrecargar el plano de control.
ACK limita las actualizaciones paralelas de kubelet a un máximo de 10 nodos por lote por node pool para proteger la estabilidad del plano de control durante los despliegues.

Planifique cargas de trabajo a gran escala

Deshabilite el montaje automático de tokens de ServiceAccount en pods que no requieren acceso a la API

El kubelet establece una conexión Watch persistente por cada secret montado en un pod. Un gran número de conexiones Watch degrada el rendimiento del plano de control.

Antes de Kubernetes v1.22: Si no se especifica ningún ServiceAccount, Kubernetes monta automáticamente un secret para el ServiceAccount predeterminado. Para trabajos por lotes y pods de aplicaciones que no acceden al API Server, establezca automountServiceAccountToken: false para omitir este montaje. Esto evita la creación innecesaria de secrets y conexiones Watch. Consulte Desactivar el montaje automático de credenciales de API.
Kubernetes v1.22 y posterior: Utilice la API TokenRequest para obtener tokens de corta duración con rotación automática, montados como un volumen proyectado. Esto mejora la seguridad y reduce la cantidad de conexiones Watch que mantiene el kubelet. Consulte Use ServiceAccount token volume projection.

Controle la cantidad y el tamaño de los objetos de Kubernetes

Limpie oportunamente los recursos no utilizados (ConfigMaps, Secrets, PVCs) para reducir la sobrecarga del sistema y mantener etcd optimizado.

Limite el historial de despliegues: Establezca revisionHistoryLimit en un valor bajo para controlar cuántos ReplicaSets antiguos conserva Kubernetes. El valor predeterminado es 10. En clústeres con muchos despliegues actualizados frecuentemente, una retención alta del historial aumenta la sobrecarga de gestión de kube-controller-manager. Consulte revisionHistoryLimit.
Limpie automáticamente los trabajos completados: Utilice ttlSecondsAfterFinished para eliminar trabajos completados y sus pods tras un periodo especificado. Esto previene la acumulación de objetos de trabajo en clústeres que ejecutan muchos CronJobs. Consulte Controlador TTL para recursos finalizados.

Configure límites de recursos adecuados para componentes basados en informers

Los componentes basados en informers (como controladores y kube-scheduler) mantienen una caché local de los recursos que observan. Su uso de memoria escala con la cantidad y el tamaño de dichos recursos.

En clústeres a gran escala, debe prestar especial atención al consumo de memoria de estos componentes para prevenir errores de falta de memoria (OOM). Cuando un componente agota su memoria, se finaliza y reinicia. Cada reinicio desencadena un nuevo ciclo List-Watch, lo que ejerce presión adicional sobre el API Server. Los reinicios frecuentes crean un bucle que degrada el plano de control.

Aumente los límites de memoria de los componentes basados en informers para que coincidan con la escala real de recursos que gestionan.

Configure webhooks y servicios de API adecuadamente

Si hay webhooks o servicios de API configurados en el clúster, las solicitudes de recursos específicos pasan por los servidores de webhook y de servicios de API. Las respuestas lentas de estos servidores personalizados provocan la acumulación de solicitudes en el API Server, ralentizando las respuestas. Monitoree la utilización de recursos de los servidores de webhook y servicios de API, y escálelos oportunamente.

Etapa de ejecución

Planifique las tasas de escalado

El plano de control suele estar bajo poca presión durante operaciones estables, incluso en clústeres grandes. El riesgo proviene de cambios rápidos y masivos, como crear o eliminar muchos recursos a la vez, o escalar numerosos nodos simultáneamente.

Por ejemplo, un clúster de 5,000 nodos con cargas de trabajo estables puede mostrar poca presión en el plano de control. Pero un clúster de 1,000 nodos que crea 10,000 trabajos efímeros en un minuto, o escala horizontalmente 2,000 nodos concurrentemente, puede llevar el plano de control al límite.

Importante

Las siguientes cifras son pautas de referencia, no límites estrictos. Muchos factores afectan la capacidad del plano de control. Escale siempre gradualmente: aumente la tasa solo tras confirmar que el plano de control responde con normalidad.

Escalado de nodos:

Para clústeres con más de 2,000 nodos, al escalar manualmente mediante node pools:

Node pool único, operación única: no más de 100 nodos
En múltiples node pools simultáneamente: no más de 300 nodos en total

Escalado de pods:

Cuando un pod está asociado a un servicio, cada evento de escalado actualiza Endpoints o EndpointSlice y propaga esa actualización a todos los nodos, creando un evento de propagación de datos en todo el clúster. En clústeres grandes, este efecto se amplifica.

Para clústeres con más de 5,000 nodos:

Pods no asociados a un endpoint de servicio: QPS de actualización ≤ 300/s
Pods asociados a un endpoint de servicio: QPS de actualización ≤ 10/s

Para despliegues que usan estrategia Rolling Update, establezca valores menores para maxUnavailable y maxSurge con el fin de reducir la tasa de reemplazo de pods.

Optimice los patrones de acceso del cliente

A medida que crece la cantidad de recursos del clúster, las solicitudes frecuentes al API Server amplifican la carga del plano de control y pueden causar fallos en cascada. Siga estas pautas al construir controladores o herramientas que accedan al API Server.

Use informers para acceso a datos en caché:

Utilice informers de client-go para leer recursos desde una caché local en lugar de emitir solicitudes List directas al API Server.
Los informers mantienen una sola conexión Watch y atienden solicitudes de lectura localmente, lo que reduce significativamente la carga del API Server.

Optimice las solicitudes directas al API Server:

**Establezca resourceVersion=0 en solicitudes List** para leer desde la caché del API Server en lugar de consultar directamente a etcd. Esto reduce los viajes de ida y vuelta entre API Server y etcd, acelerando las respuestas:
```
k8sClient.CoreV1().Pods("").List(context.Background(), metav1.ListOptions{ResourceVersion: "0"})
```
Utilice selectores de etiquetas y selectores de campos para acotar el alcance de las solicitudes List y reducir el tamaño de la respuesta. Nota: etcd es un almacén de clave-valor y no puede filtrar por etiqueta o campo; el API Server maneja ese filtrado desde su caché. Combine siempre los selectores con resourceVersion=0 para evitar consultar etcd directamente.
Utilice protobuf para recursos que no sean CRD. protobuf consume menos memoria y ancho de banda que JSON. Especifique múltiples tipos de contenido en el encabezado Accept para volver a JSON cuando protobuf no esté disponible:
```
Accept: application/vnd.kubernetes.protobuf, application/json
```
Consulte Representaciones alternativas de recursos.

Utilice un diseño de controlador centralizado:

Evite desplegar controladores independientes en cada nodo que observen individualmente el estado completo del clúster. Al iniciarse, todos esos controladores emiten solicitudes List simultáneas para sincronizar el estado, lo que puede colapsar el plano de control.

En su lugar, ejecute una o pocas instancias de controladores gestionados centralmente para todo el clúster. Un controlador centralizado emite una única solicitud List al arrancar y mantiene el mínimo de conexiones Watch, reduciendo drásticamente la presión sobre el API Server.

Etapa de observability: monitoree métricas del plano de control

Utilice el panel de monitoreo de componentes del plano de control para rastrear métricas clave y detectar problemas tempranamente. Consulte Control plane component monitoring.

Uso de recursos del plano de control

Puede consultar el uso de recursos de todos los componentes del plano de control. Las métricas relacionadas se describen en la siguiente tabla.

Métrica	PromQL	Descripción
Uso de memoria	`memory_utilization_byte{container="kube-apiserver"}`	Uso de memoria del API Server, en bytes
Uso de CPU	`cpu_utilization_core{container="kube-apiserver"}*1000`	Uso de CPU del API Server, en milinúcleos
Concurrencia de solicitudes API	`sum(apiserver_flowcontrol_current_executing_seats)`	Concurrencia del API Server, en seats
Tasa de programación de pods	`rate(scheduler_schedule_attempts_total{result="scheduled"}[2m])`	Tasa de programación de pods, en pods/s
Tamaño de la base de datos etcd	`max(etcd_mvcc_db_total_size_in_use_in_bytes)`	Tamaño de la base de datos etcd, en bytes

kube-apiserver

Para la lista completa de métricas e instrucciones de visualización, consulte kube-apiserver component monitoring metrics.

Recuento de objetos de recursos:

Métrica	PromQL	Notas
Recuento de objetos de recursos	`max by(resource)(apiserver_storage_objects)`	Kubernetes 1.22 y posterior
	`max by(resource)(etcd_object_counts)`	Kubernetes 1.22 y anterior; ambas métricas coexisten en v1.22 por compatibilidad

Latencia de solicitudes:

Métrica	PromQL	Descripción
Latencia de solicitudes GET	`histogram_quantile($quantile, sum(irate(apiserver_request_duration_seconds_bucket{verb="GET",resource!="",subresource!~"log	proxy"}[$interval])) by (pod, verb, resource, subresource, scope, le))`	Tiempo de respuesta GET por pod del API Server, recurso y alcance
Latencia de solicitudes LIST	`histogram_quantile($quantile, sum(irate(apiserver_request_duration_seconds_bucket{verb="LIST"}[$interval])) by (pod_name, verb, resource, scope, le))`	Tiempo de respuesta LIST por pod del API Server, recurso y alcance
Latencia de solicitudes de escritura	`histogram_quantile($quantile, sum(irate(apiserver_request_duration_seconds_bucket{verb!~"GET	WATCH	LIST	CONNECT"}[$interval])) by (cluster, pod_name, verb, resource, scope, le))`	Tiempo de respuesta de solicitudes mutativas por verbo, recurso y alcance

Limitación de solicitudes:

Métrica	PromQL	Descripción
Tasa de limitación de solicitudes	`sum(irate(apiserver_dropped_requests_total{request_kind="readOnly"}[$interval])) by (name)`	Tasa de limitación para solicitudes de lectura; `No data` o `0` indica que no hay limitación
	`sum(irate(apiserver_dropped_requests_total{request_kind="mutating"}[$interval])) by (name)`	Tasa de limitación para solicitudes mutativas

kube-scheduler

Para la lista completa de métricas e instrucciones de visualización, consulte kube-scheduler component monitoring metrics.

Pods pendientes:

Métrica	PromQL	Descripción
Pods pendientes del programador	`scheduler_pending_pods{job="ack-scheduler"}`	Desglose por tipo: `unschedulable` (no programable), `backoff` (fallido y en espera de reintento), `active` (listo para programar)

Latencia de solicitudes:

Métrica	PromQL	Descripción
Latencia de solicitudes a kube-apiserver	`histogram_quantile($quantile, sum(rate(rest_client_request_duration_seconds_bucket{job="ack-scheduler"}[$interval])) by (verb,url,le))`	Tiempo entre el envío de una solicitud por kube-scheduler y la respuesta de kube-apiserver, por verbo y URL

kube-controller-manager

Para la lista completa de métricas e instrucciones de visualización, consulte kube-controller-manager component monitoring metrics.

Cola de trabajo:

Métrica	PromQL	Descripción
Profundidad de la cola de trabajo	`sum(rate(workqueue_depth{job="ack-kube-controller-manager"}[$interval])) by (name)`	Tasa de cambio en la longitud de la cola de trabajo durante el intervalo especificado
Retraso de procesamiento de la cola	`histogram_quantile($quantile, sum(rate(workqueue_queue_duration_seconds_bucket{job="ack-kube-controller-manager"}[5m])) by (name, le))`	Tiempo que los eventos pasan esperando en la cola de trabajo

etcd

Para la lista completa de métricas e instrucciones de visualización, consulte etcd component monitoring metrics.

Recuento de claves-valores:

Métrica	PromQL	Descripción
Recuento total de KV	`etcd_debugging_mvcc_keys_total`	Número total de pares clave-valor en el clúster etcd

Tamaño de la base de datos:

Métrica	PromQL	Descripción
Tamaño en disco	`etcd_mvcc_db_total_size_in_bytes`	Tamaño total de la base de datos backend de etcd
Uso de la base de datos	`etcd_mvcc_db_total_size_in_use_in_bytes`	Tamaño real en uso de la base de datos backend de etcd

Documentación relacionada

Cuotas y límites del clúster: Quotas and limits
Planificación de red: Plan CIDR blocks for an ACK managed cluster
Configuraciones de cargas de trabajo de alta fiabilidad: Recommended workload configurations
Capacidad del plano de control para clústeres a ultra gran escala: ACK Pro preset control plane preasigna y fija recursos del plano de control para garantizar concurrencia de API y capacidad de programación de pods deterministas.
Solución de problemas del clúster: Solución de problemas y FAQ about cluster management