Los clústeres de Anthos en VMware ahora son Google Distributed Cloud (solo software) para VMware. Para obtener más información, consulta la descripción general del producto.

Esta página se ha traducido con Cloud Translation API.

Escalabilidad

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 con el fin de dar cabida a cargas de trabajo que se acerquen a los límites de escalabilidad de Kubernetes.

Reglas de nombres de clústeres

Por cada Google Cloud proyecto:

Cada clúster de usuarios debe tener un nombre único en todos los clústeres de administradores que se encuentren en un mismo Google Cloud proyecto.

Límites de escalabilidad

Ten en cuenta los siguientes límites al diseñar tus aplicaciones:

Si el clúster avanzado no está habilitado:
- Cada clúster de administrador admite hasta 100 clústeres de usuario, incluidos los clústeres de usuario de alta disponibilidad (HA) y los que no son de HA, mediante el modo de balanceo de carga agrupado (MetalLB) o el balanceador de carga manual.
- Cada clúster de usuarios admite hasta:
  - 500 nodos con el modo de balanceo de carga agrupado (MetalLB)
  - 15.000 pódcasts
  - 500 servicios LoadBalancer que usen el modo de balanceo de carga agrupado (MetalLB).
- Por cada nodo, puedes crear un máximo de 110 pods (cada pod puede constar de 1 o 2 contenedores). Esto incluye los pods que ejecutan servicios del sistema complementarios.
Si la opción Clúster avanzado está habilitada
- Cada clúster de administrador admite hasta 100 clústeres de usuario. Los clústeres de usuario deben ser de alta disponibilidad (HA) y usar el modo de balanceo de carga incluido (MetalLB) o un balanceador de carga manual.
- Cada clúster de usuarios admite hasta:
  - 500 nodos que usan el modo de balanceo de carga agrupado (MetalLB).
  - 15.000 pódcasts
  - 500 servicios LoadBalancer que usen el modo de balanceo de carga agrupado (MetalLB).
- Por cada nodo, puedes crear un máximo de 110 pods (cada pod puede constar de 1 o 2 contenedores). Esto incluye los pods que ejecutan servicios del sistema complementarios.
- El número total de nodos, incluidos los nodos del plano de control del clúster de administrador, todos los nodos del plano de control del clúster de usuario y los nodos de trabajo, no debe superar los 500 nodos.

Información sobre los límites

Como Google Distributed Cloud es un sistema complejo con una gran superficie de integración, la escalabilidad de los clústeres implica muchas dimensiones interrelacionadas. Por ejemplo, Google Distributed Cloud puede escalar en función del número de nodos, pods o servicios. Si estiras más de una dimensión a la vez, pueden surgir problemas incluso en clústeres más pequeños. Por ejemplo, programar 110 pods por nodo en un clúster de 500 nodos puede superar el número de pods, pods por nodo y nodos.

Consulta los umbrales de escalabilidad de Kubernetes para obtener más información.

Los límites de escalabilidad también dependen de la configuración de vSphere y del hardware en el que se ejecute el clúster. Estos límites se verifican en un entorno que probablemente sea diferente al tuyo. Por lo tanto, es posible que no obtengas los mismos números si el entorno subyacente es el factor limitante.

Preparación para escalar

Cuando te prepares para escalar tus clústeres de administrador o de usuario, ten en cuenta los siguientes requisitos y limitaciones.

Requisitos de CPU, memoria y almacenamiento

Consulta los requisitos de CPU, RAM y almacenamiento de cada máquina virtual.

Requisitos de E/S de disco y de red

Las cargas de trabajo con gran cantidad de datos y determinados componentes del plano de control son sensibles a la latencia de E/S de disco y de red. Por ejemplo, se suelen necesitar 500 IOPS secuenciales (por ejemplo, una SSD local típica o un dispositivo de bloque virtualizado de alto rendimiento) para que etcd funcione de forma estable en un clúster con decenas de nodos y miles de pods.

Dirección IP del nodo

Cada nodo requiere una dirección IP asignada de forma estática o por DHCP.

Por ejemplo, se necesitan 307 direcciones IP en una configuración con un clúster de usuario no de alta disponibilidad con 50 nodos y un clúster de usuario de alta disponibilidad con 250 nodos.

En la siguiente tabla se muestra el desglose de las direcciones IP:

Tipo de nodo	Número de direcciones IP
Máquinas virtuales de plano de control del clúster de administrador	3
Máquina virtual de plano de control del clúster de usuarios 1 (sin alta disponibilidad)	1
Máquinas virtuales de nodo de trabajo del clúster de usuarios 1	50
Máquinas virtuales de plano de control del clúster de usuario 2 (alta disponibilidad)	3
Máquinas virtuales de nodo de trabajo del clúster de usuarios 2	250
Total	307

Ejecutar muchos clústeres de usuarios en un clúster de administrador

Cuando te prepares para ejecutar muchos clústeres de usuarios en un clúster de administrador, sigue estos pasos al crear el clúster de administrador.

Bloque CIDR de pods en el clúster de administradores

El bloque CIDR de los pods es el bloque CIDR de todos los pods de un clúster de administrador. Se configura mediante el campo network.podCIDR de admin-cluster.yaml.

A partir de este intervalo, se asignan bloques /24 más pequeños a cada nodo. Si todos tus clústeres de usuarios tienen habilitado Controlplane V2, tu clúster de administrador solo tendrá tres nodos y habrá muchas direcciones IP de pods disponibles. Sin embargo, cada vez que creas un clúster de usuario que usa kubeception en lugar de Controlplane V2, se añaden uno o tres nodos al clúster de administrador:

Cada clúster de usuarios de kubeception de alta disponibilidad añade tres nodos al clúster de administradores.
Cada clúster de usuarios de kubeception que no sea de alta disponibilidad añade un nodo al clúster de administrador.

Si necesitas un clúster de administración de N nodos, debes asegurarte de que el bloque CIDR de pods sea lo suficientemente grande como para admitir bloques de N /24.

En la siguiente tabla se describe el número máximo de nodos admitidos por los diferentes tamaños de bloque CIDR de pods:

Tamaño del bloque CIDR de pods	Número máximo de nodos admitidos
/18	64
/17	128
/16	256
/15	512

El bloque CIDR de pods predeterminado de un clúster de administrador es 192.168.0.0/16, que admite 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. El número total de nodos es 303 (más de 256). Por lo tanto, debes actualizar el bloque CIDR de Pod a /15 para admitir hasta 100 clústeres de usuario de kubeception de alta disponibilidad.

Para configurar el bloque CIDR de Pod, define el campo network.podCIDR en el archivo de configuración del clúster de administrador.

Bloque CIDR de servicio en el clúster de administración

El bloque CIDR de servicio es el bloque CIDR de todos los servicios de un clúster de administrador. Se configura mediante el campo network.serviceCIDR de admin-cluster.yaml.

En la siguiente tabla se describe el número máximo de servicios admitidos por los diferentes tamaños de bloque CIDR de servicio:

Tamaño del bloque CIDR de servicio	Número máximo de servicios admitidos
/24	256
/23	512
/22	1024

El valor predeterminado es 10.96.232.0/24, que admite 256 servicios.

Cada clúster de usuarios de kubeception usa 6 servicios y el plano de control del clúster de administrador usa 14 servicios. Por lo tanto, para ejecutar 100 clústeres de usuario de kubeception, debes cambiar el bloque CIDR de servicio del clúster de administrador para usar un intervalo /22.

Cloud Logging y Cloud Monitoring para clústeres de usuario de kubeception

Cloud Logging y Cloud Monitoring te ayudan a monitorizar tus recursos.

El uso de CPU y memoria de los componentes de registro y monitorización desplegados en un clúster de administrador se escala en función del número de clústeres de usuario de kubeception.

En la siguiente tabla se describe la cantidad de CPU y memoria de los nodos del clúster de administrador que se necesita para ejecutar un gran número de clústeres de usuario de kubeception:

Número de clústeres de usuarios de kubeception	CPU del nodo del clúster de administrador	Memoria de los nodos del clúster de administrador
De 0 a 10	4 CPUs	16 GB
Entre 11 y 20	4 CPUs	32 GB
De 20 a 100	4 CPUs	90 GB

Por ejemplo, si hay 2 nodos de clúster de administrador y cada uno tiene 4 CPUs y 16 GB de memoria, puedes ejecutar entre 0 y 10 clústeres de usuario de kubeception. Para crear más de 20 clústeres de usuarios de kubeception, primero debes cambiar el tamaño de la memoria de los nodos del clúster de administrador de 16 GB a 90 GB.

Nodos de clúster de administrador cuando los clústeres avanzados están habilitados

El uso de CPU y memoria de los componentes del ciclo de vida implementados en un clúster de administrador se escala en función del número total de nodos (el número total de nodos incluye los nodos del plano de control del clúster de administrador, todos los nodos del plano de control del clúster de usuario y los nodos de trabajador).

En la siguiente tabla se describe la cantidad de CPU y memoria de los nodos del clúster de administrador que se necesita para ejecutar un gran número de todos los nodos que gestiona:

Número total de nodos	CPU del nodo del clúster de administrador	Memoria de los nodos del clúster de administrador
De 0 a 20	4 CPUs	16 GB
De 21 a 100	8 CPUs	16 GB
De 101 a 500	16 CPUs	32 GB

Por ejemplo, si hay 3 nodos de clúster de administrador y cada uno tiene 4 CPUs y 16 GB de memoria, puedes ejecutar un clúster de usuario de alta disponibilidad con 14 nodos de trabajador. Para crear más de 20 clústeres de usuarios avanzados, cada uno de los cuales tiene más de 10 nodos, primero debes cambiar el tamaño de la memoria de los nodos del clúster de administrador de 16 GB a 32 GB.

Hub de GKE

De forma predeterminada, puedes registrar un máximo de 250 clústeres con membresías globales por flota. Si quieres registrar más clústeres en GKE Hub, puedes enviar una solicitud para aumentar tu cuota a través de la Google Cloud consola:

Ir a Cuotas

Para obtener más información sobre las cuotas de clústeres en función de la configuración de la pertenencia, consulta Cuotas de asignación.

Ejecutar muchos nodos y pods en un clúster de usuarios

Cuando te prepares para ejecutar muchos nodos y pods en un clúster de usuarios, sigue estos pasos al crear el clúster.

Bloque CIDR de pods en el clúster de usuarios

El bloque CIDR de los pods es el bloque CIDR de todos los pods de un clúster de usuarios. Se configura mediante el campo network.podCIDR de user-cluster.yaml.

A partir de este intervalo, se asigna un bloque /24 más pequeño a cada nodo. Si necesitas un clúster de N nodos, debes asegurarte de que este bloque sea lo suficientemente grande como para admitir N /24 bloques.

En la siguiente tabla se describe el número máximo de nodos admitidos por los diferentes tamaños de bloque CIDR de pods:

Tamaño del bloque CIDR de pods	Número máximo de nodos admitidos
/18	64
/17	128
/16	256
/15	512

El bloque CIDR de pods predeterminado es 192.168.0.0/16, que admite 256 nodos. Por ejemplo, para crear un clúster con 500 nodos, debes cambiar el bloque CIDR de Pod en el clúster de usuario para que use un intervalo /15.

Bloque CIDR de servicio en el clúster de usuario

El bloque CIDR de servicio es el bloque CIDR de todos los servicios de un clúster de usuario. Se configura mediante el campo network.serviceCIDR de user-cluster.yaml.

En la siguiente tabla se describe el número máximo de servicios admitidos por los diferentes tamaños de bloque CIDR de servicio:

Tamaño del bloque CIDR de servicio	Número máximo de servicios admitidos
/21	2048
/20	4096
/19	8192
/18	16.384

Nodos del plano de control de clústeres de usuarios

El uso de memoria de los componentes del plano de control del clúster de usuarios se ajusta en función del número de nodos del clúster de usuarios.

En la siguiente tabla se indica la CPU y la memoria que necesita un nodo de plano de control de un clúster de usuarios en función del tamaño del clúster de usuarios:

Número de nodos de clúster de usuarios	CPU del nodo del plano de control	Memoria del nodo del plano de control
De 0 a 20	3 CPUs	5 GB
De 21 a 75	3 CPUs	6 GB
De 76 a 250	4 CPUs	8 GB
De 251 a 500	4 CPUs	16 GB

Por ejemplo, para crear más de 250 nodos en un clúster de usuario, debes usar nodos del plano de control del clúster de usuario con al menos 16 GB de memoria.

La especificación del nodo de plano de control del clúster de usuarios se puede cambiar mediante el campo masterNode del user-cluster.yaml.

Dataplane v2

En el caso de los clústeres de usuario de 500 nodos que usan Dataplane V2, recomendamos 120 GB de memoria y 32 núcleos de CPU para los nodos del plano de control del clúster de usuario.

Cloud Logging y Cloud Monitoring

Cloud Logging y Cloud Monitoring te ayudan a monitorizar tus recursos.

El uso de CPU y memoria de los agentes del clúster desplegados en un clúster de usuarios se escala en función del número de nodos y pods del clúster de usuarios.

Los componentes de registro y monitorización de Cloud, como prometheus-server y stackdriver-prometheus-sidecar, tienen un uso de recursos de CPU y memoria diferente en función del número de nodos y de pods. Antes de aumentar la escala de tu clúster, define la solicitud y el límite de recursos según el uso medio estimado de estos componentes. En la siguiente tabla se muestran las estimaciones del uso medio de cada componente:

Número de nodos	Nombre del contenedor	Uso de CPU estimado		Uso de memoria estimado
Número de nodos	Nombre del contenedor	0 pods por nodo	30 pods por nodo	0 pods por nodo	30 pods por nodo
De 3 a 50	prometheus-server	100 m	390 m	650M	1.3G
De 3 a 50	stackdriver-prometheus-sidecar	100 m	340 m	1,5 G	1,6 G
De 51 a 100	prometheus-server	160 m	500 m	1,8 G	5.5G
De 51 a 100	stackdriver-prometheus-sidecar	200 m	500 m	1,9 G	5.7G
De 101 a 250	prometheus-server	400 m	2500 m	6,5 G	16G
De 101 a 250	stackdriver-prometheus-sidecar	400 m	1300 m	7,5 G	12G
De 250 a 500	prometheus-server	1200m	2600 m	22G	25G
De 250 a 500	stackdriver-prometheus-sidecar	400 m	2250 m	65G	78G

Asegúrate de que los nodos sean lo suficientemente grandes para programar los componentes de Cloud Logging y Cloud Monitoring. Una forma de hacerlo es crear primero un clúster pequeño, editar los recursos de los componentes de Cloud Logging y Cloud Monitoring según la tabla anterior, crear un pool de nodos para alojar los componentes y, a continuación, aumentar gradualmente el tamaño del clúster.

Puedes mantener un grupo de nodos lo suficientemente grande para que los componentes de monitorización y registro impidan que se programen otros pods en el grupo de nodos. Para ello, debes añadir los siguientes taints al grupo de nodos:

taints:
  - effect: NoSchedule
    key: node-role.gke.io/observability

De esta forma, se evita que se programen otros componentes en el grupo de nodos y que se expulsen las cargas de trabajo de los usuarios debido al consumo de recursos de los componentes de monitorización.

Balanceador de carga

Los servicios que se describen en esta sección son los servicios de Kubernetes de tipo LoadBalancer.

Hay un límite en el número de nodos de tu clúster y en el número de servicios que puedes configurar en tu balanceador de carga.

En el balanceo de carga agrupado (Seesaw), también hay un límite en el número de comprobaciones de estado. El número de comprobaciones de estado depende del número de nodos y del número de servicios locales de tráfico. Un servicio de tráfico local es un servicio que tiene el valor Local en externalTrafficPolicy.

En la siguiente tabla se describe el número máximo de servicios, nodos y comprobaciones de estado para el balanceo de carga agrupado (Seesaw) y el balanceo de carga integrado (F5):

	Balanceo de carga agrupado (Seesaw)	Balanceo de carga integrado (F5)
Max Services	500	250 ²
Número máximo de nodos	500	250 ²
Número máximo de comprobaciones del estado	N + (L * N) <= 10.000, donde N es el número de nodos y L es el número de servicios locales de tráfico ¹	N/A ²

¹ Por ejemplo, supongamos que tienes 100 nodos y 99 servicios locales de tráfico. El número de comprobaciones de estado es 100 + (99 * 100) = 10.000, que está dentro del límite de 10.000.

² Consulta F5 para obtener más información. Este número se ve afectado por factores como el número de modelo de hardware de F5, la CPU o la memoria de la instancia virtual y las licencias.

Componentes del sistema de autoescalado

Google Distributed Cloud escala automáticamente los componentes del sistema en los clústeres de usuarios en función del número de nodos sin que tengas que cambiar ninguna configuración. Puedes usar la información de esta sección para planificar los recursos.

Google Distributed Cloud realiza automáticamente el escalado vertical al escalar las solicitudes o los límites de CPU y memoria de los siguientes componentes del sistema mediante addon-resizer:
- kube-state-metrics es un Deployment que se ejecuta en los nodos de trabajo del clúster, escucha el servidor de la API de Kubernetes y genera métricas sobre el estado de los objetos. Las solicitudes y los límites de CPU y memoria se escalan en función del número de nodos.
  
  En la siguiente tabla se describen las solicitudes y los límites de recursos definidos por el sistema en función del número de nodos de un clúster:
  
  Número de nodos Solicitud/límite de CPU aproximado¹ (milis) Solicitud o límite de memoria aproximado ¹ (Mi)
  
  De 3 a 5 105 110
  
  De 6 a 500 100 + num_nodes 100 + (2 * num_nodes)
  
  ¹ Hay un margen de ±5% para reducir el número de reinicios de componentes durante el escalado.
  
  Por ejemplo, en un clúster con 50 nodos, la solicitud y el límite de CPU se definen en 150 m/150 m, y la solicitud y el límite de memoria se definen en 200 Mi/200 Mi. En un clúster con 250 nodos, la solicitud y el límite de CPU se definen en 350 m/350 m, y la solicitud y el límite de memoria se definen en 600 Mi.
- metrics-server es un despliegue que se ejecuta en los nodos de trabajo del clúster y que utilizan los flujos de procesamiento de autoescalado integrados de Kubernetes. Las solicitudes y los límites de CPU y memoria se escalan en función del número de nodos.

Número de nodos	Solicitud/límite de CPU aproximado¹ (milis)	Solicitud o límite de memoria aproximado ¹ (Mi)
De 3 a 5	105	110
De 6 a 500	100 + num_nodes	100 + (2 * num_nodes)

Google Distributed Cloud realiza automáticamente el escalado horizontal en los clústeres de administrador y de usuario. Para ello, escala el número 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 un Deployment en los nodos de trabajo del clúster de usuarios. Google Distributed Cloud escala automáticamente el número de réplicas en función del número de nodos y núcleos de CPU del 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 N nodos y C núcleos, puedes esperar max(N/16, C/256) réplicas.
calico-typha es un componente que admite la creación de redes de pods. Se ejecuta como un Deployment en los nodos de trabajo del clúster de usuarios. Google Distributed Cloud escala automáticamente el número de réplicas de calico-typha en función del número de nodos del clúster:

Número de nodos (N) Número de réplicas de calico-typha

N = 1 1
1 < N < 200 2
N >= 200 3 o más
Ingress-gateway de Istio es el componente que admite el ingreso de clústeres y se ejecuta como un Deployment en los nodos de trabajo del clúster de usuario. En función de la cantidad de tráfico que gestione ingress-gateway, Google Distributed Cloud usa Horizontal Pod Autoscaler para escalar el número de réplicas en función del uso de CPU, con un mínimo de 2 réplicas y un máximo de 5.

Número de nodos (N)	Número de réplicas de calico-typha
N = 1	1
1 < N < 200	2
N >= 200	3 o más

El proxy de red konnectivity (KNP) proporciona un proxy a nivel de TCP para el tráfico de salida de los nodos del plano de control del clúster de usuarios. Crea un túnel para el tráfico de salida de kube-apiserver del usuario que va dirigido a los nodos del clúster del usuario. El agente de conectividad se ejecuta como un Deployment en los nodos de trabajo del clúster de usuario. Google Distributed Cloud escala automáticamente el número de réplicas del agente de conectividad en función del número de nodos del clúster.

Número de nodos (N)	Número de réplicas del agente de conectividad
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.

Escalar un clúster por fases

La creación de un nodo de Kubernetes implica clonar la plantilla de imagen del SO del nodo en un nuevo archivo de disco, que es una operación de vSphere que requiere muchas operaciones de E/S. No hay aislamiento de E/S entre la operación de clonación y las operaciones de E/S de la carga de trabajo. Si se crean demasiados nodos al mismo tiempo, las operaciones de clonación tardarán mucho en completarse y pueden afectar al rendimiento y la estabilidad del clúster y de las cargas de trabajo.

Asegúrate de que el clúster se escale por fases en función de tus recursos de vSphere. Por ejemplo, para cambiar el tamaño de un clúster de 3 a 500 nodos, plantéate escalarlo por fases, de 3 a 150, de 150 a 350 y de 350 a 500, lo que ayuda a reducir la carga en la infraestructura de vSphere.

Optimizar el rendimiento de E/S de disco de etcd

etcd es un almacén de clave-valor que se usa como almacén de respaldo de Kubernetes para todos los datos de clúster. Su rendimiento y estabilidad son fundamentales para el estado de un clúster y dependen de la latencia de E/S de disco y de red.

Para optimizar el rendimiento de E/S del almacén de datos de vSphere que se usa en las VMs del plano de control, siga estas recomendaciones:
- Cumple los requisitos de hardware de etcd.
- Usa almacenamiento flash o SSD.
Una latencia de unos cientos de milisegundos indica un cuello de botella en la E/de disco o de red, y puede provocar que el clúster no esté en buen estado. Monitoriza y define umbrales de alerta para las siguientes métricas de latencia de E/S de etcd:
- etcd_disk_backend_commit_duration_seconds
- etcd_disk_wal_fsync_duration_seconds

Optimizar el rendimiento de E/S del disco de arranque de los nodos

Los pods usan almacenamiento efímero para sus operaciones internas, como guardar archivos temporales. El almacenamiento efímero lo consumen la capa de escritura del contenedor, el directorio de registros y los volúmenes de emptyDir. El almacenamiento efímero procede del sistema de archivos del nodo, que se basa en el disco de arranque del nodo.

Como no hay aislamiento de E/S de almacenamiento en los nodos de Kubernetes, las aplicaciones que consumen una cantidad extremadamente alta de E/S en su almacenamiento efímero pueden provocar inestabilidad en los nodos al privar de recursos a componentes del sistema como Kubelet y el daemon de Docker.

Asegúrese 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 que hace la aplicación del almacenamiento efímero y el tráfico de registro.

Monitorizar la contención de recursos físicos

Ten en cuenta las relaciones entre vCPUs y pCPUs y la sobreasignación de memoria. Una relación subóptima o una contención de memoria en los hosts físicos pueden provocar una degradación del rendimiento de las máquinas virtuales. Debes monitorizar el uso de los recursos físicos a nivel de host y asignar suficientes recursos para ejecutar tus clústeres grandes.