En esta página, se describen las prácticas recomendadas para crear, configurar y operar clústeres creados con Google Distributed Cloud (solo software) para VMware y adaptarse a las cargas de trabajo que se acercan a los límites de escalabilidad de Kubernetes.
Reglas de nombre del clúster
Para cada proyecto de Google Cloud, debe cumplirse lo siguiente:
- Cada clúster de usuario debe tener un nombre único en todos los clústeres de administrador que se encuentren dentro de un proyecto de Google Cloud individual.
Límites de escalabilidad
Ten en cuenta los siguientes límites cuando diseñes tus aplicaciones:
Cada clúster de administrador admite hasta 100 clústeres de usuarios, incluidos los clústeres con alta disponibilidad (HA) y los que no son de HA, mediante el modo de balanceo de cargas en paquetes (Seesaw o MetalLB) o el modo de balanceo de cargas integrado (F5)
Cada clúster de usuario admite hasta:
500 nodos mediante el modo de balanceo de cargas en paquetes (Seesaw o MetalLB) o 250 nodos mediante el modo de balanceo de cargas integrado (F5)
15,000 Pods
500 servicios LoadBalancer mediante el modo de balanceo de cargas en paquetes (Seesaw o MetalLB), or 250 servicios LoadBalancer mediante el modo de balanceo de cargas integrado (F5).
Para cada nodo, puedes crear un máximo de 110 pods (cada pod puede tener 1 o 2 contenedores). Esto incluye los pods que ejecutan servicios de sistema de complementos.
Comprende los límites
Dado que Google Distributed Cloud es un sistema complejo con una gran superficie de integración, la escalabilidad del clúster implica muchas dimensiones interrelacionadas. Por ejemplo, Google Distributed Cloud puede escalar a través de la cantidad de nodos, Pods o servicios. Estirar más de una dimensión a la vez puede causar problemas, incluso en clústeres más pequeños. Por ejemplo, programar 110 Pods por nodo en un clúster de 500 nodos puede extender la cantidad de Pods, Pods por nodo y nodos.
Consulta Umbrales de escalabilidad de Kubernetes para obtener más detalles.
Los umbrales de escalabilidad también son sensibles a la configuración de vSphere y el hardware en el que se ejecuta tu clúster. Estos límites se verifican en un entorno que es muy diferente al tuyo. Por lo tanto, no puedes reproducir las cifras exactas cuando el entorno subyacente es el factor limitante.
Prepara para escalar
Mientras te preparas para escalar los clústeres de administración o los clústeres de usuario, ten en cuenta los requisitos y las limitaciones siguientes.
Requisitos de CPU, memoria y almacenamiento
Consulta los requisitos de CPU, memoria RAM y almacenamiento para cada VM individual.
Requisitos de E/S de red y de disco
Las cargas de trabajo con uso intensivo de datos y ciertos componentes del plano de control son sensibles a la latencia de E/S de disco y de red. Por ejemplo, 500 IOPS secuenciales (por ejemplo, un SSD local típico o un dispositivo de bloque virtualizado de alto rendimiento) se necesitan para el rendimiento y la estabilidad de etcd en un clúster con decenas de nodos y miles de pods.
Dirección IP del nodo
Cada nodo requiere un DHCP o una dirección IP asignada de forma estática.
Por ejemplo, se necesitan 307 direcciones IP en una configuración con un clúster de usuarios que no sea HA, con 50 nodos y un clúster de usuario de HA con 250 nodos.
En la siguiente tabla, se muestra el desglose de las direcciones IP:
| Tipo de nodo | Cantidad de direcciones IP |
|---|---|
| VMs del plano de control del clúster de administrador | 3 |
| VM del plano de control del clúster de usuario 1 (sin HA) | 1 |
| VMs del nodo trabajador del clúster de usuario 1 | 50 |
| VM del plano de control del clúster de usuario 2 (HA) | 3 |
| VMs del nodo trabajador del clúster de usuario 2 | 250 |
| Total | 307 |
Ejecuta muchos clústeres de usuario en un clúster de administrador
Mientras te preparas para ejecutar muchos clústeres de usuarios en un clúster de administrador, realiza los siguientes pasos cuando creas el clúster de administrador.
Bloque CIDR de Pod en el clúster de administración
El bloque CIDR del Pod es el bloque CIDR de todos los Pods de un clúster de administración. Se configura a través del campo network.podCIDR en el admin-cluster.yaml.
A partir de este rango, se asignan bloques de /24 más pequeños a cada nodo. Si todos tus clústeres de usuario tienen Controlplane V2 habilitado, el clúster de administrador solo tiene tres nodos y hay muchas direcciones IP de Pod disponibles. Sin embargo, cada vez que creas un clúster de usuario que usa kubeception en lugar de Controlplane V2, se agregan uno o tres nodos al clúster de administrador:
Cada clúster de usuario de kubeception con alta disponibilidad (HA) agrega tres nodos al clúster de administrador.
Cada clúster de usuario de Kubeception sin alta disponibilidad agrega un nodo al clúster de administrador.
Si necesitas un clúster administrador de N nodos, asegúrate de que el bloque de CIDR del Pod sea lo suficientemente grande como para admitir N bloques de /24.
En la tabla siguiente, se describe la cantidad máxima de nodos compatibles según los diferentes tamaños de bloque CIDR de pods:
| Tamaño de bloque CIDR de pods | Cantidad máxima de nodos admitida |
|---|---|
| /18 | 64 |
| /17 | 128 |
| /16 | 256 |
| /15 | 512 |
El bloque CIDR de Pod predeterminado de un clúster de administración es 192.168.0.0/16, que es compatible con 256 nodos.
En un clúster de administrador con 100 clústeres de usuario de Kubeception de alta disponibilidad, hay 3 nodos del plano de control del clúster de administrador y 300 nodos del plano de control del clúster de usuario. La cantidad total de nodos es 303 (más de 256). Por lo tanto, debes actualizar el bloque CIDR del Pod a /15 para admitir hasta 100 clústeres de usuario de kubeception con alta disponibilidad.
Para configurar el bloque CIDR del Pod, establece el campo network.podCIDR en el archivo de configuración del clúster de administrador.
Bloque CIDR de servicio en el clúster de administrador
El bloque CIDR de servicio es el bloque CIDR para todos los servicios en un clúster de administrador.
Se configura a través del campo network.serviceCIDR en el admin-cluster.yaml.
En la siguiente tabla, se describe la cantidad máxima de Services admitida según los diferentes tamaños de bloque CIDR de Service:
| Tamaño de bloque CIDR de Service | Cantidad máxima de Services admitida |
|---|---|
| /24 | 256 |
| /23 | 512 |
| /22 | 1,024 |
El valor predeterminado es 10.96.232.0/24, que es compatible con 256 services.
Cada clúster de usuario de kubeception usa 6 servicios y el plano de control de clúster del administrador usa 14 servicios. Por lo tanto, para ejecutar 100 clústeres de usuario de kubeception, debes cambiar el bloque CIDR de servicio en el clúster de administrador a fin de usar un rango /22.
Cloud Logging y Cloud Monitoring
Cloud Logging y Cloud Monitoring te permiten hacer un seguimiento de tus recursos.
El uso de memoria y CPU de los componentes de Logging y Monitoring implementados en un clúster de administrador se escala según la cantidad de clústeres de usuario de kubeception.
En la siguiente tabla, se describe la cantidad de CPU y memoria del nodo del clúster del administrador necesaria para ejecutar una gran cantidad de clústeres de usuario de kubeception:
| Cantidad de clústeres de usuarios de kubeception | CPU del nodo del clúster de administrador | Memoria del nodo del clúster de administrador |
|---|---|---|
| 0 a 10 | 4 CPU | 16 GB |
| 11 a 20 | 4 CPU | 32 GB |
| De 20 a 100 | 4 CPU | 90 GB |
Por ejemplo, si hay 2 nodos del clúster de administrador y cada uno tiene 4 CPU y 16 GB de memoria, puedes ejecutar de 0 a 10 clústeres de usuario de kubeception. Para crear más de 20 clústeres de usuario de kubeception, primero debes cambiar el tamaño de la memoria del nodo del clúster de administrador de 16 GB a 90 GB.
GKE Hub
De forma predeterminada, puedes registrar un máximo de 250 clústeres con membresías globales por flota. Si deseas registrar más clústeres en GKE Hub, puedes enviar una solicitud para aumentar tu cuota en la consola de Google Cloud.
Para obtener más información sobre las cuotas de clústeres según la configuración de membresía, consulta Cuotas de asignación.
Ejecuta muchos nodos y Pods en un clúster de usuarios
Mientras te preparas para ejecutar muchos nodos y Pods en un clúster de usuarios, realiza los siguientes pasos cuando creas el clúster de usuarios.
Bloque CIDR de Pod en el clúster de usuarios
El bloque CIDR de pods es el bloque CIDR de todos los pods de un clúster de usuario. Se configura a través del campo network.podCIDR en el user-cluster.yaml.
A partir de este rango, se asigna un bloque de /24 más pequeño a cada nodo. Si necesitas un clúster de N nodos, asegúrate de que este bloque sea lo suficientemente grande como para admitir N bloques de /24.
En la tabla siguiente, se describe la cantidad máxima de nodos compatibles según los diferentes tamaños de bloque CIDR de pods:
| Tamaño de bloque CIDR de pods | Cantidad máxima de nodos admitida |
|---|---|
| /18 | 64 |
| /17 | 128 |
| /16 | 256 |
| /15 | 512 |
El bloque CIDR de pods predeterminado es 192.168.0.0/16, que es compatible con 256 nodos. Por ejemplo, para crear un clúster con 500 nodos, debes cambiar el bloque CIDR de Pod en el clúster de usuarios a fin de usar un rango 15.
Bloque CIDR de servicio en el clúster de usuarios
El bloque CIDR de Service es el bloque CIDR de todos los Services de un clúster de usuario. Se configura a través del campo network.serviceCIDR en el user-cluster.yaml.
En la siguiente tabla, se describe la cantidad máxima de Services admitida según los diferentes tamaños de bloque CIDR de Service:
| Tamaño de bloque CIDR de Service | Cantidad máxima de Services admitida |
|---|---|
| /21 | 2,048 |
| /20 | 4,096 |
| /19 | 8,192 |
| /18 | 16,384 |
Nodos de plano de control de clúster del usuario
El uso de memoria de los componentes del plano de control del clúster de usuarios se escala según la cantidad de nodos en el clúster de usuarios.
En la siguiente tabla, se proporciona la CPU y la memoria que requiere un nodo del plano de control del clúster de usuario según el tamaño del clúster de usuario:
| Cantidad de nodos del clúster de usuario | CPU del nodo del plano de control | Memoria de nodo del plano de control |
|---|---|---|
| De 0 a 20 | 3 CPU | 5 GB |
| De 21 a 75 | 3 CPU | 6 GB |
| De 76 a 250 | 4 CPU | 8 GB |
| De 251 a 500 | 4 CPU | 16 GB |
Por ejemplo, para crear más de 250 nodos en un clúster de usuarios, debes usar nodos del plano de control de clúster de usuario con al menos 16 GB de memoria.
La especificación del nodo del plano de control del clúster de usuarios se puede cambiar a través del campo masterNode en user-cluster.yaml.
Dataplane v2
En el caso de los clústeres de usuarios de 500 nodos con Dataplant V2, recomendamos 120 GB de memoria y 32 núcleos de CPU para los nodos del plano de control del clúster de usuarios.
Cloud Logging y Cloud Monitoring
Cloud Logging y Cloud Monitoring te permiten hacer un seguimiento de tus recursos.
El uso de memoria y CPU de los agentes en el clúster implementados en un clúster de usuario se escala en términos de la cantidad de nodos y de pods en un clúster de usuario.
Los componentes de Cloud Logging y Monitoring, como prometheus-server y stackdriver-prometheus-sidecar, tienen un uso de recursos de CPU y memoria diferente en función de la cantidad de nodos y la cantidad de Pods. Antes de escalar verticalmente tu clúster, configura la solicitud y el límite de recursos según el uso promedio estimado de estos componentes. En la siguiente tabla, se muestran las estimaciones por la cantidad promedio de uso para cada componente:
| Cantidad de nodos | Nombre del contenedor | Uso estimado de CPU | Uso la memoria estimado | ||
|---|---|---|---|---|---|
| 0 pods/nodo | 30 pods/nodo | 0 pods/nodo | 30 pods/nodo | ||
| 3 a 50 | prometheus-server | 100m | 390m | 650M | 1.3G |
| stackdriver-prometheus-sidecar | 100m | 340m | 1.5G | 1.6G | |
| 51 a 100 | prometheus-server | 160m | 500m | 1.8G | 5.5G |
| stackdriver-prometheus-sidecar | 200 m | 500m | 1.9G | 5.7G | |
| 101 a 250 | prometheus-server | 400m | 2500m | 6.5G | 16G |
| stackdriver-prometheus-sidecar | 400m | 1300m | 7.5G | 12G | |
| 250 a 500 | prometheus-server | 1200 m | 2600 m | 22 G | 25 G |
| stackdriver-prometheus-sidecar | 400m | 2250 m | 65 G | 78 G | |
Asegúrate de tener nodos lo suficientemente grandes para programar los componentes de Cloud Logging y Cloud Monitoring. Una forma de hacerlo es crear primero un pequeño clúster, editar los recursos del componente de Cloud Logging y Cloud Monitoring según la tabla anterior, crea un grupo de nodos para adaptarse a los componentes, y luego, escalar verticalmente el clúster a un tamaño mayor.
Puedes elegir mantener un grupo de nodos que sea lo suficientemente grande para los componentes de supervisión y registro, y así evitar que se programen otros pods en el grupo de nodos. Para hacerlo, debes agregar los siguientes taints al grupo de nodos:
taints:
- effect: NoSchedule
key: node-role.gke.io/observabilityEsto evita que se programen otros componentes en el grupo de nodos y evita que las cargas de trabajo de los usuarios se expulsen debido al consumo de recursos de los componentes de Monitoring.
Balanceador de cargas
Los Services que se analizan en esta sección hacen referencia a los Services de Kubernetes con el tipo LoadBalancer.
Existe un límite para la cantidad de nodos en tu clúster y la cantidad de Services que puedes configurar en tu balanceador de cargas.
Para el balanceo de cargas agrupado (Seesaw), también hay un límite en la cantidad de verificaciones de estado. La cantidad de verificaciones de estado depende de la cantidad de nodos y de la cantidad de Services locales de tráfico. Un Service local de tráfico es un Service en el que externalTrafficPolicy está configurado como Local.
En la siguiente tabla, se describe la cantidad máxima de Services, nodos y verificaciones de estado del balanceo de cargas agrupado (Seesaw) y el balanceo de cargas integrado (F5):
| Balanceo de cargas agrupado (Seesaw) | Balanceo de cargas integrado (F5) | |
|---|---|---|
| Cantidad máxima de Services | 500 | 250 2 |
| Nodos máximos | 500 | 250 2 |
| Cantidad máxima de verificaciones de estado | N + (L * N) <= 10K, donde N es la cantidad de nodos y L es la cantidad de Services locales de tráfico1 | N/A 2 |
1 Por ejemplo, supongamos que tienes 100 nodos y 99 servicios de tráfico local. La cantidad de verificaciones de estado será de 100 + (99 x 100) = 10,000, que se encuentra dentro del límite de 10,000.
2 Consulta F5 para obtener más información. Este número se ve afectado por factores como tu número de modelo de hardware F5, CPU y memoria virtual de instancia y licencias.
Componentes del sistema de ajuste de escala automático
Google Distributed Cloud escala automáticamente los componentes del sistema en los clústeres de usuarios según la cantidad de nodos sin que tengas que cambiar la configuración. Puedes usar la información de esta sección para la planificación de recursos.
Google Distributed Cloud realiza un escalamiento vertical de forma automática mediante el escalamiento de las solicitudes y límites de CPU y memoria de los siguientes componentes del sistema con addon-resizer:
kube-state-metrics es una implementación que se ejecuta en los nodos trabajadores del clúster que escucha el servidor de API de Kubernetes y genera métricas sobre el estado de los objetos. Los requisitos de CPU y memoria y los límites se escalan según la cantidad de nodos.
En la siguiente tabla, se describen las solicitudes/límites de recursos que establece el sistema, dada la cantidad de nodos en un clúster:
Cantidad de nodos Solicitud/límite de CPU aproximado1 (mili) Solicitud/límite de memoria aproximado1 (Mi) 3 a 5 105 110 6 a 500 100 + num_nodes 100 + (2 * num_nodes) 1Existe un margen de +-5% a fin de reducir la cantidad de reinicios de los componentes durante el escalamiento.
Por ejemplo, en un clúster con 50 nodos, la solicitud/límite de CPU está configurada en 150m/150m y la solicitud/límite de memoria se configura en 200Mi/200Mi. En un clúster con 250 nodos, la solicitud/límite de CPU se configura en 350m/350m y la solicitud/límite de memoria se configura en 600Mi.
metrics-server es una implementación que se ejecuta en los nodos trabajadores del clúster que usan las canalizaciones integradas de ajuste de escala automático de Kubernetes. Los requisitos de CPU y memoria y los límites se escalan según la cantidad de nodos.
Google Distributed Cloud realiza automáticamente el escalamiento horizontal en los clústeres de administrador y en los de usuario mediante el escalamiento de la cantidad de réplicas de los siguientes componentes del sistema:
core-dns es la solución de DNS que se usa para el descubrimiento de servicios. Se ejecuta como una implementación en los nodos trabajadores del clúster de usuario. Google Distributed Cloud escala la cantidad de réplicas de forma automática según la cantidad de nodos y núcleos de CPU en el clúster. Con cada adición o eliminación de 16 nodos o 256 núcleos, se aumenta o disminuye 1 réplica. Si tienes un clúster de nodos
NyCnúcleos, puedes esperar réplicasmax(N/16, C/256).calico-typha es un componente compatible con las redes de pods. Se ejecuta como una implementación en los nodos trabajadores del clúster de usuario. Google Distributed Cloud escala automáticamente la cantidad de réplicas de calico-typha en función de la cantidad de nodos en el clúster:
Cantidad de nodos (N) Cantidad de réplicas de caico-typha N = 1 1 1 < N < 200 2 N >= 200 3 o más Istio ingress-gateway es el componente para admitir la entrada del clúster y se ejecuta como un Deployment en los nodos trabajadores del clúster de usuario. Según la cantidad de tráfico que maneje la puerta de enlace de entrada, Google Distributed Cloud usa un Horizontal Pod Autoscalator para escalar la cantidad de réplicas según su uso de CPU, con un mínimo de 2 réplicas y un máximo de 5 réplicas.
El proxy de red konnectivity (KNP) proporciona un proxy de nivel TCP para la salida de los nodos del plano de control del clúster de usuario. Crea un túnel del tráfico de salida de kube-apiserver del usuario que está destinado a los nodos del clúster de usuario. El agente de Konnectivity se ejecuta como un Deployment en los nodos trabajadores del clúster de usuario. Google Distributed Cloud escala automáticamente la cantidad de réplicas del agente de conectividad según la cantidad de nodos del clúster.
Cantidad de nodos (N) Cantidad de réplicas de agentes de konnectivity 1 <= N <= 6 N 6 < N < 10 6 10 <= N < 100 8 N >= 100 12 o más
Prácticas recomendadas
En esta sección, se describen las prácticas recomendadas para escalar los recursos.
Escala tu clúster por etapas
La creación de un nodo de Kubernetes implica clonar la plantilla de imagen del SO del nodo en un archivo de disco nuevo, que es una operación de vSphere de E/S intensiva. No hay aislamiento de E/S entre la operación de clonación y las operaciones de E/S de carga de trabajo. Si hay demasiados nodos que se crean al mismo tiempo, las operaciones de clonación tardan mucho tiempo en completarse y pueden afectar el rendimiento y la estabilidad del clúster y las cargas de trabajo existentes.
Asegúrate de que el clúster se escale en etapas según tus recursos de vSphere. Por ejemplo, para cambiar el tamaño de un clúster de 3 a 500 nodos, considera escalarlo en etapas de 150 a 350 a 500, lo que ayuda a reducir la carga en la infraestructura de vSphere.
Optimiza el rendimiento de E/S del disco de etcd
etcd es un almacén de valor clave que se usa como almacenamiento de respaldo de Kubernetes para todos los datos del clúster. Su rendimiento y estabilidad son fundamentales para el estado de un clúster y son sensibles a la latencia de E/S del disco y de la red.
Optimiza el rendimiento de E/S del almacén de datos de vSphere que se usa para las VM del plano de control mediante las siguientes recomendaciones:
- Sigue los requisitos de hardware para etcd.
- Usa SSD o todo el almacenamiento flash.
La latencia de unos cientos de milisegundos indica un cuello de botella en el disco o la E/S de la red, y puede dar como resultado un clúster en mal estado. Supervisa y establece los límites de alerta para las siguientes métricas de latencia de E/S de etcd:
etcd_disk_backend_commit_duration_secondsetcd_disk_wal_fsync_duration_seconds
Optimiza el rendimiento de E/S del disco de arranque del nodo
Los Pods usan almacenamiento efímero para sus operaciones internas, como guardar archivos temporales. El almacenamiento efímero se consume mediante la capa que admite escritura del contenedor, el directorio de registros y los volúmenes emptyDir. El almacenamiento efímero proviene del sistema de archivos del nodo, que está respaldado por el disco de arranque del nodo.
Como no hay aislamiento de E/S de almacenamiento en los nodos de Kubernetes, las aplicaciones que consumen E/S extremadamente altas en su almacenamiento efímero pueden causar inestabilidad en el nodo, mediante la privación de los componentes del sistema, como Kubelet y el daemon de Docker de los recursos.
Asegúrate de que las características de rendimiento de E/S del almacén de datos en el que se aprovisionan los discos de arranque puedan proporcionar el rendimiento adecuado para el uso de tráfico de registro y almacenamiento efímero de la aplicación.
Supervisa la contención de recursos físicos
Ten en cuenta las proporciones de CPU virtual a pCPU y sobre el exceso de memoria. Una proporción subóptima o contención en la memoria en los hosts físicos puede causar una degradación del rendimiento de las VM. Debes supervisar el uso de recursos físicos a nivel de host y asignar recursos suficientes para ejecutar tus clústeres grandes.