Versión 1.6. Esta versión ya no es compatible como se describe en la política de compatibilidad de versiones de Anthos. Para obtener los últimos parches y actualizaciones de vulnerabilidades de seguridad, exposiciones y problemas que afectan a clústeres de Anthos alojados en VMware (GKE On-Prem), actualiza a una versión compatible. Puedes encontrar la versión más reciente aquí.

Escalabilidad

En esta página, se describen las prácticas recomendadas para crear, configurar y operar clústeres de Anthos alojados en VMware (GKE On-Prem) a fin de adaptarse a las cargas de trabajo que abordan los límites de estabilidad de Kubernetes.

Límites de escalabilidad

Ten en cuenta los siguientes límites cuando diseñes tus aplicaciones en clústeres de Anthos alojados en VMware:

  • Cada clúster de administrador admite hasta 20 clústeres de usuario, incluidos los clústeres con alta disponibilidad (HA) y sin HA.

  • Cada clúster de usuario admite hasta:

  • 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

Debido a que los clústeres de Anthos alojados en VMware son un sistema complejo con una gran superficie de integración, la escalabilidad del clúster implica muchas dimensiones interrelacionadas. Por ejemplo, los clústeres de Anthos alojados en VMware pueden 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 250 nodos puede extender demasiado 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, considera los requisitos y las limitaciones de la infraestructura de vSphere, las herramientas de redes de Kubernetes, GKE Hub, Cloud Logging y Cloud Monitoring.

Infraestructura de vSphere

En esta sección, se analizan las consideraciones de escalabilidad para los requisitos de CPU, memoria, almacenamiento, E/S de red y de disco, y las direcciones IP de nodo.

Requisitos de CPU, memoria y almacenamiento

Los siguientes requisitos se aplican a las VM de plano de control:

  • El plano de control del clúster de administrador y los nodos complementarios pueden admitir hasta 20 clústeres de usuarios, incluidos los clústeres de usuarios de alta disponibilidad y que no sean HA. Por lo tanto, no se requiere ajuste en el clúster de administrador.

  • La configuración predeterminada de la VM de plano de control de clúster de usuario (4 CPU, 8 GB de memoria y 40 GB de almacenamiento) es la configuración mínima necesaria para ejecutar hasta 250 nodos en un clúster de usuario.

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 de clúster de Anthos alojado en VMware requiere una dirección IP asignada de forma estática o DHCP.

Por ejemplo, se necesitan 308 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
VM del plano de control del clúster de administrador 1
VM del nodo de complemento del clúster de administrador 3
VM del plano de control del clúster de usuario 1 (sin HA) 1
VM del nodo del clúster de usuario 1 50
VM del plano de control del clúster de usuario 2 (HA) 3
VM del nodo del clúster de usuario 2 250
Total 308

Herramientas de redes de Kubernetes

En esta sección, se analizan las consideraciones de escalabilidad para el bloque CIDR de pods y los servicios de Kubernetes.

Bloque CIDR del Pod

El bloque CIDR de pods es el bloque CIDR de todos los pods de un clúster de usuario. A partir de este rango, se asignan bloques de /24 más pequeños 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
/19 32
/18 64
/17 128
/16 256

El bloque CIDR de pods predeterminado es 192.168.0.0/16, que es compatible con 256 nodos. El bloque CIDR de pods predeterminado te permite crear un clúster con 250 nodos, que es la cantidad máxima de nodos que los clústeres de Anthos alojados en VMware admiten en un clúster de usuario.

Servicios de Kubernetes

En esta sección, se analizan las consideraciones de escalabilidad para el bloque CIDR de Service y el balanceador de cargas.

Bloque CIDR de Service

El bloque CIDR de Service es el bloque CIDR de todos los Services de un clúster de usuario. Los Services que se analizan en esta sección hacen referencia a los Services de Kubernetes con el tipo LoadBalancer.

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
/20 4,096
/19 8,192
/18 16,384

El valor predeterminado es 10.96.0.0/12, que es compatible con 1,048,576 Services. El bloque CIDR de Service predeterminado te permite crear un clúster con 500 Services, que es la cantidad máxima de Services que los clústeres de Anthos alojados en VMware admiten en un clúster de usuario.

Balanceador de cargas

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 250 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.

GKE Hub

De forma predeterminada, puedes registrar un máximo de 15 clústeres de usuario. Si deseas registrar más clústeres en GKE Hub, puedes enviar una solicitud para aumentar tu cuota en Google Cloud Console.

Cloud Logging y Cloud Monitoring

Cloud Logging y Cloud Monitoring te permiten hacer un seguimiento de tus recursos.

Ejecuta muchos nodos en un clúster de usuario

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 registro y supervisión de Cloud, como prometheus-server, stackdriver-prometheus-sidecar y stackdriver-log-aggregator, 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 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 stackdriver-log-aggregator 150m 170m 1.6G 1.7G
prometheus-server 100m 390m 650M 1.3G
stackdriver-prometheus-sidecar 100m 340m 1.5G 1.6G
51 a 100 stackdriver-log-aggregator 220m 1100m 1.6G 1.8G
prometheus-server 160m 500m 1.8G 5.5G
stackdriver-prometheus-sidecar 200m 500m 1.9G 5.7G
101 a 250 stackdriver-log-aggregator 450m 1800m 1.7G 1.9G
prometheus-server 400m 2500m 6.5G 16G
stackdriver-prometheus-sidecar 400m 1300m 7.5G 12G

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/observability

Esto 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.

Ejecuta muchos clústeres de usuario en un clúster de administrador

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.

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:

Cantidad de clústeres de usuario 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

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. Para crear más de 10 clústeres de usuario, primero debes cambiar el tamaño de la memoria del nodo del clúster de administrador de 16 GB a 32 GB.

Para cambiar la memoria del nodo del clúster de administrador, edita la configuración de MachineDeployment:

  1. Ejecuta el siguiente comando:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG edit machinedeployment gke-admin-node

    En el ejemplo anterior, ADMIN_CLUSTER_KUBECONFIG es la ruta de acceso del archivo kubeconfig del clúster de administrador.

  2. Cambia el campo spec.template.spec.providerSpec.value.machineVariables.memory a 32768.

  3. Guarda la edición. Los nodos del clúster de administrador se recrean con 32 GB de memoria.

Dataplane V2

Para 500 clústeres de nodos que usan Dataplane V2, recomendamos 120 GB de memoria y 32 núcleos de CPU para el plano de control.

Componentes del sistema de ajuste de escala automático

Los clústeres de Anthos alojados en VMware escalan de forma automática los componentes del sistema del clúster según la cantidad de nodos sin necesidad de cambiar las configuraciones. Puedes usar la información de esta sección para la planificación de recursos.

  • Los clústeres de Anthos alojados en VMware realizan el escalamiento vertical automáticamente mediante el escalamiento de las solicitudes/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 250 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 clústeres de Anthos alojados en VMware realizan el escalamiento horizontal automáticamente mediante el escalamiento de la cantidad de réplicas de los siguientes componentes del sistema:

    • kube-dns es la solución DNS que se usa para descubrir servicios en clústeres de Anthos alojados en VMware. Se ejecuta como una implementación en los nodos trabajadores del clúster de usuario. Los clústeres de Anthos alojados en VMware realizan un ajuste de escala automático de la cantidad de réplicas 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 N nodos y núcleos de C, puedes esperar réplicas máximas (N/16, C/256). Ten en cuenta que kube-dns se actualizó porque los clústeres de Anthos alojados en VMware 1.4 admiten 1,500 solicitudes simultáneas por segundo.

    • calico-typha es un componente para admitir redes de Pods en clústeres de Anthos alojados en VMware. Se ejecuta como una implementación en los nodos trabajadores del clúster de usuario. Los clústeres de Anthos alojados en VMware escalan automáticamente la cantidad de réplicas según la cantidad de nodos del clúster. Hay 1 réplica de calico-typha en un clúster con menos de 200 nodos y 2 réplicas en un clúster con 200 nodos o más.

    • ingress-gateway/istio-pilot son los componentes para admitir la entrada del clúster y se ejecutan 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, los clústeres de Anthos alojados en VMware usan un escalador automático de pod horizontal 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.

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 250 nodos, considera escalarlo en etapas de 80 a 160 a 250, 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:

  • 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_seconds
    • etcd_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 de clústeres de Anthos alojados en VMware que cuenta con el respaldo del 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.