Versión 1.5. Esta versión es compatible como se describe en la política de asistencia de la versión de Anthos, que ofrece los últimos parches y actualizaciones de vulnerabilidades de seguridad, exposiciones y problemas que afectan a los clústeres de Anthos alojados en VMware (GKE On-Prem). Consulta las notas de la versión para obtener más detalles. Esta no es la versión más reciente.

Escalabilidad

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

Límites de escalabilidad

Ten en cuenta los siguientes límites cuando diseñes tus aplicaciones en GKE On-Prem:

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

  • Cada clúster de usuarios admite hasta:

  • Para cada nodo, puedes crear un máximo de 110 pods (cada pod puede tener 1 a 2 contenedores). Esto incluye los pods que ejecutan servicios de sistema de complemento.

Comprende los límites

Como GKE On-Prem es un sistema complejo con una gran superficie de integración, la escalabilidad del clúster implica muchas dimensiones interrelacionadas. Por ejemplo, GKE On-Prem puede escalar con el número de nodos, pods o Service. Estirar más de una dimensión a la vez puede causar problemas incluso en clústeres más pequeños. Por ejemplo, la programación de 110 pods por nodo en un clúster de 250 nodos puede sobrepasar la cantidad de pods, pods por nodo y nodos.

Consulta Límites de escalabilidad de Kubernetes para obtener más detalles.

Los límites 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, disco y E/S de red, 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 de complementos pueden admitir hasta 20 clústeres de usuarios, incluidos los clústeres de usuarios de alta disponibilidad y sin alta disponibilidad. Por lo tanto, no se requiere ajuste en el clúster de administrador.

  • La configuración de la VM de plano de control de clúster de usuarios predeterminado (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 almacenamiento, CPU y memoria RAM para cada VM individual.

Requisitos de E/S de disco y red

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 red. Por ejemplo, se necesitan 500 IOPS secuenciales (por ejemplo, un SSD local típico o un dispositivo de almacenamiento en bloques de alto rendimiento) 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 GKE On-Prem requiere un DHCP o una dirección IP asignada de forma estática.

Por ejemplo, se necesitan 308 direcciones IP en una configuración con un clúster de usuarios que no sea de alta disponibilidad, con 50 nodos y un clúster de usuario de alta disponibilidad con 250 nodos. En la siguiente tabla, se muestra un desglose de las direcciones IP:

Tipo de nodo Cantidad de direcciones IP
VM de plano de control de clúster administrador 1
VM del nodo de complemento de clúster de administrador 3
VM del plano de control 1 (sin alta disponibilidad) del usuario 1
VM del nodo del clúster del usuario 1 50
VM de plano de control (alta disponibilidad) del clúster de usuarios 2 3
VM del nodo del clúster del usuario 2 250
Total 308

Herramientas de redes de Kubernetes

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

Bloque CIDR del Pod

El bloque CIDR del pod 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 nodos N, debes asegurarte de que este bloque sea lo suficientemente grande como para admitir bloques N de /24.

En la tabla siguiente, se describe la cantidad máxima de nodos compatibles con diferentes tamaños de bloque CIDR de pod:

Tamaño de bloque CIDR de pod Cantidad máxima de nodos admitida
/19 32
/18 64
/17 128
/16 256

El bloque CIDR de pod predeterminado es 192.168.0.0/16, que es compatible con 256 nodos. El bloque CIDR de pod predeterminado te permite crear un clúster con 250 nodos, que es la cantidad máxima de nodos que GKE On-Prem admite en un clúster de usuario.

Servicios de Kubernetes

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

Bloque CIDR de Service

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

En la siguiente tabla, se describe la cantidad máxima de Service admitidos por diferentes tamaños de bloques de CIDR de Service:

Tamaño de bloque CIDR de Service Cantidad máxima de Service admitidos
/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 servicios. El bloque CIDR de Service predeterminado te permite crear un clúster con 500 Service, que es la cantidad máxima de Service que GKE On-Prem admite 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 Service que puedes configurar en tu balanceador de cargas.

Para el balanceo de cargas empaquetado (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 Service locales de tráfico. Un Service local de tráfico es un objeto Service en el que externalTrafficPolicy está configurada como Local.

En la siguiente tabla, se describe la cantidad máxima de Service, nodos y verificaciones de estado del balanceo de cargas empaquetado (Seesaw) y el balanceo de cargas integrado (F5):

Balanceo de cargas empaquetado (Seesaw) Balanceo de cargas integrado (F5)
Service máximos 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 servicios locales de tráfico 1 No disponible 2

1 Por ejemplo, supongamos que tienes 100 nodos y 99 Service de tráfico local. La cantidad de verificaciones de estado es 100 + (99 * 100) = 10,000, que está 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/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 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 usuarios

El uso de CPU y memoria de los agentes en el clúster implementados en un clúster de usuario escala en términos de 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 de la cantidad promedio de uso para cada componente:

Cantidad de nodos Nombre del contenedor Uso estimado de CPU Uso estimado de la memoria
0 pods/nodo 30 pods/nodo 0 pods/nodo 30 pods/nodo
3 a 50 stackdriver-log-aggregator 150 m 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 expulsan debido al consumo de recursos de los componentes de supervisión.

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

El uso de CPU y memoria de los componentes de registro y supervisión implementados en un clúster de administración se escala según la cantidad de clústeres de usuarios.

En la siguiente tabla, se describe la cantidad de CPU y memoria del nodo del clúster del administrador necesarias para ejecutar una gran cantidad de clústeres de usuarios:

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 administración 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 usuarios, primero debes cambiar el tamaño de la memoria del nodo del administrador de 16 GB a 32 GB.

Para cambiar la memoria del nodo del 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. Guarde la edición. Los nodos del clúster de administración se recrean con 32 GB de memoria.

Componentes del sistema de ajuste de escala automático

GKE On-Prem ajusta de forma automática los componentes del sistema en el 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.

  • GKE OnpremPrem hace un ajuste de escala vertical automáticamente mediante el escalamiento de las solicitudes y memorias de CPU y memoria de los siguientes componentes del sistema con add-resize:

    • kube-state-metrics es una Deployment 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 los límites o las solicitudes de recursos que establece el sistema, dada la cantidad de nodos en un clúster:

      Cantidad de nodos Solicitud/límite (milii) aproximado de CPU 1 Solicitud/límite (Mi) aproximado de memoria 1
      3 a 5 105 110
      6 a 250 100 + num_nodes 100 + (2 * num_nodes)

      1 Hay un margen de +5% para reducir la cantidad de reinicios de componentes durante el escalamiento.

      Por ejemplo, en un clúster con 50 nodos, la solicitud/límite de CPU está configurada en 150 m/150 m 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 350 m/350 m y la solicitud/límite de memoria se configura en 600 Mi.

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

  • GKE On-Prem realiza el escalamiento horizontal de forma automática mediante el escalamiento de la cantidad de réplicas de los siguientes componentes del sistema:

    • kube-dns es la solución de DNS que se usa para la detección de servicios en GKE On-Prem. Se ejecuta como un Deployment en los nodos trabajadores del clúster de usuarios. GKE On-Prem escala de manera automática 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ó desde GKE On-Prem 1.4 para admitir 1,500 solicitudes simultáneas por segundo.

    • calico-typha es un componente para admitir redes de pods en GKE On-Prem. Se ejecuta como un Deployment en los nodos trabajadores del clúster de usuarios. GKE On-Prem escala de manera automática la cantidad de réplicas según la cantidad de nodos en el 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 una 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, GKE On-Prem usa 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 en etapas

La creación de un nodo de Kubernetes implica clonar la plantilla de imagen de 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 almacén 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 de disco y 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 GKE On-Prem, 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 las que se aprovisionan los discos de arranque puedan proporcionar el rendimiento adecuado para el uso de tráfico efímero y de almacenamiento de la aplicación.

Supervisa la contención de recursos físicos

Ten en cuenta las proporciones de CPU virtual a pCPU y el exceso de compromiso de la 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.