En esta página, se describen las prácticas recomendadas que puedes seguir cuando planificas y diseñas clústeres de gran tamaño.
Motivos para planificar clústeres de GKE grandes
Todos los sistemas informáticos, incluidos Kubernetes, tienen algunos límites de arquitectura. Superar los límites puede afectar el rendimiento de tu clúster o, en los mismos casos, incluso causar tiempos de inactividad. Sigue las prácticas recomendadas y ejecuta acciones recomendadas para asegurarte de que tus clústeres ejecuten tus cargas de trabajo de manera confiable y a gran escala.
Prácticas recomendadas para dividir las cargas de trabajo entre varios clústeres
Puedes ejecutar tus cargas de trabajo en un solo clúster grande. Este enfoque es más fácil de administrar, más rentable y proporciona un mejor uso de los recursos que varios clústeres. Sin embargo, en algunos casos, debes considerar dividir la carga de trabajo en varios clústeres:
- Revisa los casos prácticos de varios clústeres a fin de obtener más información sobre los requisitos generales y las situaciones para usar múltiples clústeres.
- Además, desde el punto de vista de la escalabilidad, divide tu clúster cuando pueda superar uno de los límites descritos en la siguiente sección o una de las cuotas de GKE. Reducir el riesgo para alcanzar los límites de GKE minimiza el riesgo de tiempo de inactividad o de otros problemas de confiabilidad.
Si decides dividir tu clúster, usa la Administración de flotas para simplificar la administración de una flota de varios clústeres.
Límites y prácticas recomendadas
Para asegurarte de que tu arquitectura admita clústeres de GKE a gran escala, revisa los siguientes límites y las prácticas recomendadas relacionadas. Superar estos límites puede causar una degradación del rendimiento del clúster o problemas de confiabilidad.
Estas prácticas recomendadas se aplican a cualquier clúster predeterminado de Kubernetes sin extensiones instaladas. Es común ampliar los clústeres de Kubernetes con webhooks o definiciones de recursos personalizados (CRD), pero puede limitar tu capacidad para escalar el clúster.
En la siguiente tabla, se extienden los límites y cuotas de GKE principales. También deberías familiarizarte con los límites de Kubernetes de código abierto para clústeres a gran escala.
Los requisitos de la versión de GKE que se mencionan en la tabla se aplican a los nodos y al plano de control.
| Límite de GKE | Descripción | Prácticas recomendadas |
|---|---|---|
| El tamaño de la base de datos de etcd | El tamaño máximo de la base de datos etcd es de 6 GB. Si ejecutas un clúster muy grande con decenas de miles de recursos, tus instancias de etcd podrían exceder este límite. Puedes verificar el nivel de uso de tus clústeres en la consola de Google Cloud. | Si superas este límite, GKE podría marcar tus instancias de etcd como en mal estado. Esto hace que el plano de control de los clústeres no responda.
Si superas este límite, comunícate con el equipo de Asistencia de Google Cloud. |
| Tamaño total de objetos etcd por tipo | El tamaño total de todos los objetos del tipo de recurso dado no debe exceder los 800 MB. Por ejemplo, puedes crear 750 MB de instancias de Pod y 750 MB de objetos Secret, pero no puedes crear 850 MB de objetos Secret. Si creas más de 800 MB de objetos, esto podría provocar que Kubernetes o los controladores personalizados no se inicialicen y causen interrupciones. |
Mantén el tamaño total de todos los objetos de cada tipo almacenados en etcd por debajo de los 800 MB. Esto se aplica en particular a los clústeres que usan muchos objetos Secret o ConfigMaps de gran tamaño, o un gran volumen de CRD. |
| Cantidad de servicios para clústeres en los que GKE Dataplane V2 no está habilitado | El rendimiento de iptables que utiliza kube-proxy se degrada si se produce alguna de las siguientes situaciones:
Este límite se elimina cuando se habilita GKE Dataplane V2. |
Mantén la cantidad de objetos Service en el clúster por debajo de 10,000. Para obtener más información, consulta Expón aplicaciones con servicios. |
| Cantidad de servicios por espacio de nombres | El número de variables de entorno generadas para los objetos Service puede superar los límites de shell. Esto podría provocar que los Pods fallen en el inicio. |
Mantén la cantidad de objetos Service por espacio de nombres por debajo de 5,000. Puedes inhabilitar la propagación de esas variables de entorno. Consulta la documentación sobre cómo establecer Para obtener más información, consulta Expón aplicaciones mediante objetos Service. |
| Cantidad de pods detrás de un solo servicio para clústeres en los que no está habilitado GKE Dataplane V2 |
Cada nodo ejecuta un kube-proxy que usa agentes de observación para supervisar cualquier cambio en el servicio. Cuanto más grande sea un clúster, más datos relacionados con el cambio procesará el agente. Esto es especialmente visible en clústeres con más de 500 nodos. La información sobre los extremos se divide entre Los objetos de extremo aún están disponibles para los componentes, pero cualquier extremo superior a 1,000 Pods se trunca de forma automática. |
Mantén la cantidad de Pods detrás de un solo Service por debajo de 10,000. Para obtener más información, consulta Expón aplicaciones con los objetos Service. |
| Cantidad de pods detrás de un solo servicio para clústeres en los que GKE Dataplane V2 está habilitado |
GKE Dataplane V2 contiene límites para la cantidad de pods expuestos por un solo servicio. El mismo límite se aplica a los clústeres de Autopilot que usan GKE Dataplane V2. |
En GKE 1.23 y versiones anteriores, mantén la cantidad de Pods detrás de un solo Service por debajo de 1,000. En GKE 1.24 y versiones posteriores, mantén la cantidad de Pods detrás de un solo Service por debajo de 10,000. Para obtener más información, consulta Expón aplicaciones con servicios. |
| Registros DNS por Service sin interfaz gráfica |
La cantidad de registros DNS por Service sin interfaz gráfica es limitada para kube-dns y Cloud DNS. |
Mantén la cantidad de registros DNS por Service sin interfaz gráfica por debajo de 1,000 para kube-dns y 3,500/2,000 (IPv4/IPv6) para Cloud DNS. |
| Cantidad de todos los extremos de servicio | La cantidad de extremos en todos los servicios puede alcanzar límites. Esto puede aumentar la latencia de la programación o puede no permitir programar extremos nuevos. |
Mantén la cantidad de todos los extremos en todos los servicios por debajo de 64,000. GKE Dataplane V2, que es el plano de datos predeterminado para GKE, se basa en mapas de eBPF que están limitados a 64,000 extremos en todos los servicios. |
| Cantidad de objetos Horizontal Pod Autoscaler por clúster |
Cada Horizontal Pod Autoscaler (HPA) se procesa cada 15 segundos. Más de 300 objetos HPA pueden causar una degradación lineal del rendimiento. |
Mantén la cantidad de objetos HPA dentro de este límite; de lo contrario, podrías experimentar una degradación lineal de la frecuencia del procesamiento de HPA. Por ejemplo, en GKE 1.22 con 2,000 HPA, se volverá a procesar un solo HPA cada 1 minuto y 40 segundos. Para obtener más información, consulta el ajuste de escala automático según el uso de recursos y el ajuste de escala automático horizontal de Pods. |
| Cantidad de pods por nodo | GKE tiene un límite estricto de 256 Pods por nodo. Esto supone un promedio de dos o menos contenedores por pod. Si aumentas la cantidad de contenedores por Pod, este límite podría ser menor porque GKE asigna más recursos por contenedor. |
Te recomendamos que uses nodos trabajadores con al menos una CPU virtual por cada 10 Pods. Para obtener más información, consulta Actualiza un clúster o grupo de nodos de forma manual. |
| Frecuencia de cambios en los Pods |
Kubernetes tiene límites internos que afectan la tasa de creación o eliminación de Pods (deserción de Pods) en respuesta a las solicitudes de escalamiento. Factores adicionales, como borrar un Pod que forma parte de un Service, también pueden afectar esta tasa de deserción del Pod. Para los clústeres con hasta 500 nodos, puedes esperar una tasa promedio de 20 Pods creados por segundo y 20 Pods borrados por segundo. Para los clústeres con más de 500 nodos, puedes esperar una tasa promedio de 100 Pods creados por segundo y 100 Pods borrados por segundo. |
Ten en cuenta el límite de frecuencia de creación y eliminación de Pods cuando planifiques cómo escalar tus cargas de trabajo. Los Pods comparten la misma capacidad de procesamiento de eliminación con otros tipos de recursos (por ejemplo, EndpointSlices). Puedes reducir la capacidad de procesamiento de eliminación cuando defines Pods como parte de un Service. Para permitir que el escalador automático del clúster quite los Pods de los nodos con poco uso, evita usar PodDisruptionBudgets y períodos de gracia de finalización largos. Tampoco se recomiendan las tolerancias comodín, ya que pueden programar cargas de trabajo en nodos que están en proceso de quitarse. |
| Cantidad de observaciones abiertas | Los nodos crean una observación para cada Secret y ConfigMaps que configuras para los Pods. La cantidad combinada de observaciones que crean todos los nodos puede generar una carga sustancial en el plano de control del clúster. Tener más de 200,000 observaciones por clúster puede afectar el tiempo de inicialización del clúster. Este problema puede hacer que el plano de control se reinicie con frecuencia. |
Define nodos más grandes para disminuir la probabilidad y la gravedad de los problemas causados por una gran cantidad de observaciones. Una densidad de Pods más alta (menos nodos de gran tamaño) podría reducir la cantidad de observaciones y mitigar la gravedad del problema. Para obtener más información, consulta la comparación de series de máquinas. |
| Cantidad de objetos Secret por clúster si la encriptación de objetos Secret de la capa de la aplicación está habilitada | Un clúster debe desencriptar todos los Secret durante el inicio del clúster cuando la encriptación de los objetos Secret de la capa de la aplicación está habilitada. Si almacenas más de 30,000 objetos Secret, es posible que el clúster se vuelva inestable durante el inicio o las actualizaciones, lo que provoca interrupciones en la carga de trabajo. | Almacena menos de 30,000 objetos Secret cuando se usa la encriptación de objetos Secret de la capa de la aplicación. Para obtener más información, consulta Encripta Secrets en la capa de la aplicación. |
| Ancho de banda de registro por nodo |
Existe un límite para la cantidad máxima de registros que envía cada nodo a la API de Cloud Logging. El límite predeterminado varía entre 100 Kbps y 500 Kbps según la carga. Puedes elevar el límite a 10 Mbps si implementas una configuración de agente de Logging de alta capacidad de procesamiento. Si se supera este límite, es posible que se descarten las entradas de registro. |
Configura Logging para que se mantenga dentro de los límites predeterminados o configura un agente de Logging con alta capacidad de procesamiento. Para obtener más información, consulta Aumenta la capacidad de procesamiento del agente de Logging. |
| Límites de copias de seguridad de GKE |
Puedes usar la Copia de seguridad para GKE a fin de crear una copia de seguridad de tus cargas de trabajo de GKE y restablecerlas. La copia de seguridad para GKE está sujeta a los límites que debes tener en cuenta cuando defines tus planes de copia de seguridad. |
Revisa los límites de la copia de seguridad para GKE. Si tu carga de trabajo supera estos límites, te recomendamos crear varios planes de copia de seguridad para particionar la copia de seguridad y mantenerte dentro de los límites. |
| Límites de Config Connector |
Puedes usar Config Connector para administrar los recursos de Google Cloud a través de Kubernetes. Config Connector tiene dos modos de operación:
|
Cada instancia de Config Connector tiene un límite de memoria de 512 MB y solicitud de CPU de 0.1. Por lo tanto, no se escala bien a una gran cantidad de recursos administrados. Recomendamos no tener más de 25,000 recursos de Google Cloud por cada instancia de Config Connector. Esta limitación es solo para fines de referencia, ya que la cantidad de memoria usada depende del tipo de recurso y casos prácticos específicos. Cuando administras una mayor cantidad de recursos administrados, recomendamos usar el modo de espacio de nombres para limitar la cantidad de recursos que administra cada instancia de Config Connector. Recomendamos usar hasta 500 espacios de nombres con Config Connector en el modo de espacio de nombres.
Cada instancia de Config Connector abre muchas conexiones de watch en kube-apiserver. Una gran cantidad de estas instancias puede sobrecargar el plano de control del clúster de GKE, en especial durante las actualizaciones del plano de control, cuando se deben reiniciar las conexiones del reloj. Recomendamos usar varios clústeres de GKE para administrar la cantidad de recursos que no se podrían dividir a fin de ajustarse a los límites especificados antes. Consulta los lineamientos de escalabilidad del controlador de configuración para obtener más información. |