Arquitectura del clúster

Un clúster es la base de Google Kubernetes Engine (GKE): los objetos de Kubernetes que representan tus aplicaciones en contenedores se ejecutan sobre un clúster.

En GKE, un clúster consta de al menos un plano de control y varias máquinas trabajadoras, llamadas nodos. Este plano de control y las máquinas de nodos ejecutan el sistema de organización de clústeres de Kubernetes.

En el siguiente diagrama, se proporciona una descripción general de la arquitectura de un clúster zonal en GKE:

GKE aprovisiona, mantiene y opera todo en el plano de control zonal y solo aprovisiona los nodos.

Plano de control

El plano de control ejecuta los procesos del plano de control, incluido el servidor, el programador y los controladores de recursos principales de la API de Kubernetes. GKE administra el ciclo de vida del plano de control cuando creas o borras un clúster. Esto incluye actualizaciones a la versión de Kubernetes que se ejecuta en el plano de control del clúster, las cuales GKE realiza de forma automática o manual según lo solicites si prefieres actualizar antes de la programación automática.

Plano de control y API de Kubernetes

El plano de control es el extremo unificado para tu clúster. Todas las interacciones con el clúster se realizan a través de las llamadas a la API de Kubernetes, y el plano de control ejecuta el proceso del servidor de la API de Kubernetes para controlar esas solicitudes. Puedes realizar llamadas a la API de Kubernetes directamente a través de HTTP/gRPC o de forma indirecta mediante la ejecución de los comandos desde el cliente de línea de comandos de Kubernetes (kubectl) o mediante la interacción con la IU en Cloud Console.

El proceso del servidor de la API es el centro de todas las comunicaciones para el clúster. Todos los procesos internos del clúster (como los nodos del clúster, el sistema y los componentes, los controladores de la aplicación) actúan como clientes del servidor de API. El servidor de API es la única "fuente de verdad" para todo el clúster.

Plano de control e interacción de los nodos

El plano de control es responsable de decidir qué se ejecuta en todos los nodos del clúster. Esto puede incluir la programación de cargas de trabajo, como aplicaciones en contenedores, y la administración del ciclo de vida de las cargas de trabajo, el escalamiento y las actualizaciones. El plano de control también administra los recursos de red y almacenamiento para esas cargas de trabajo.

El plano de control y los nodos también se comunican mediante las API de Kubernetes.

Interacciones del plano de control con el Container Registry gcr.io

Cuando creas o actualizas un clúster, las imágenes de contenedor para el software de Kubernetes que se ejecuta en el plano de control (y los nodos) se extraen de Container Registry gcr.io. Una interrupción que afecta al registro gcr.io puede provocar los siguientes tipos de fallas:

  • La creación de nuevos clústeres fallará durante la interrupción.
  • La actualización de los clústeres fallará durante la interrupción.
  • Las interrupciones en las cargas de trabajo pueden ocurrir incluso sin la intervención del usuario, según la naturaleza específica y la duración de la interrupción.

En caso de una interrupción zonal o regional del gcr.io de Container Registry, Google puede redireccionar las solicitudes a una zona o región no afectada por la interrupción.

Para verificar el estado actual de los servicios de Google Cloud, ve al panel de estado de Google Cloud.

Nodos

Un clúster suele tener uno o más nodos, que son las máquinas trabajadoras que ejecutan tus aplicaciones en contenedores y otras cargas de trabajo. Las máquinas individuales son instancias de VM de Compute Engine que GKE crea en tu nombre cuando creas un clúster.

Cada nodo se administra desde el plano de control, que recibe actualizaciones sobre el estado autoinformado de cada nodo. Puedes ejercer algún control manual sobre el ciclo de vida del nodo o puedes hacer que GKE realice reparaciones automáticas y actualizaciones automáticas en los nodos de tu clúster.

Un nodo ejecuta los servicios necesarios para admitir los contenedores de Docker que conforman las cargas de trabajo de tu clúster. Estos incluyen el entorno de ejecución de Docker y el agente de nodo de Kubernetes (kubelet) que se comunica con el plano de control y es responsable de iniciar y ejecutar los contenedores de Docker programados en ese nodo.

En GKE, también hay una serie de contenedores especiales que se ejecutan como agentes por nodo para proporcionar funcionalidades como la recopilación de registros y la conectividad de red dentro del clúster.

Tipo de máquina del nodo

Cada nodo es del tipo de máquina estándar de Compute Engine. El tipo predeterminado es e2-medium. Puedes seleccionar un tipo de máquina diferente cuando creas un clúster.

Imágenes de SO de nodos

Cada nodo ejecuta una imagen de SO especializada para ejecutar sus contenedores. Puedes especificar qué imagen de SO usan tus clústeres y grupos de nodos.

Plataforma de CPU mínima

Cuando creas un clúster o grupo de nodos, puedes especificar una plataforma de CPU mínima de referencia para tus nodos. Elegir una plataforma de CPU específica puede ser ventajoso para cargas de trabajo avanzadas o de alto procesamiento. Para obtener más información, consulta la Plataforma de CPU mínima.

Recursos asignables del nodo

Algunos de los recursos de un nodo son necesarios para ejecutar los componentes del nodo de GKE y Kubernetes a fin de que ese nodo funcione como parte de tu clúster. Como tal, puedes observar una diferencia entre los recursos totales del nodo (como se especifica en la documentación de tipo de máquina) y los recursos asignables del nodo en GKE.

A medida que los tipos de máquinas más grandes tienden a ejecutar más contenedores (y, por extensión, más pods), la cantidad de recursos que GKE reserva para los componentes de Kubernetes aumenta en las máquinas más grandes. Los nodos de Windows Server también requieren más recursos que un nodo de Linux típico. Los nodos necesitan recursos adicionales para ejecutar el SO Windows y los componentes de Windows Server que no se pueden ejecutar en contenedores.

Puedes realizar una solicitud de recursos para tus Pods o limitar su uso de recursos. Si deseas obtener información sobre cómo solicitar o limitar el uso de recursos para Pods, consulta Managing Resources for Containers (Administra recursos para contenedores).

Para inspeccionar los recursos asignables del nodo disponibles en un clúster, ejecuta el siguiente comando:

kubectl describe node node-name | grep Allocatable -B 7 -A 6

En el ejemplo anterior, node-name es el nombre del nodo que deseas inspeccionar.

El resultado que se muestra contiene campos Capacity y Allocatable con mediciones del almacenamiento efímero, la memoria y la CPU.

Límite de expulsiones

A fin de determinar la cantidad de memoria disponible para los pods, también debes considerar el límite de expulsiones. GKE reserva una memoria adicional de 100 MiB en cada nodo para la expulsión de kubelet.

Memoria asignable y recursos de CPU

Los recursos asignables se calculan de la siguiente manera:

Allocatable = Capacity - Reserved - Eviction Threshold

Para recursos de memoria, GKE reserva lo siguiente:

  • 255 MiB de memoria para máquinas con menos de 1 GB de memoria
  • Un 25% de los primeros 4 GB de memoria
  • Un 20% de los siguientes 4 GB de memoria (hasta 8 GB)
  • Un 10% de los siguientes 8 GB de memoria (hasta 16 GB)
  • Un 6% de los siguientes 112 GB de memoria (hasta 128 GB)
  • Un 2% de cualquier memoria por encima de 128 GB

Para recursos de CPU, GKE reserva lo siguiente:

  • Un 6% del primer núcleo
  • Un 1% del siguiente núcleo (hasta 2 núcleos)
  • Un 0.5% de los siguientes 2 núcleos (hasta 4 núcleos)
  • Un 0.25% de cualquier núcleo por encima de 4 núcleos

En la siguiente tabla, se muestra la cantidad de recursos de CPU y memoria asignables que están disponibles para programar las cargas de trabajo de Linux del clúster en cada tipo de máquina del nodo estándar.

Tipo de máquina Capacidad de memoria (GB) Memoria asignable (GB) Capacidad de CPU (núcleos) CPU asignable (núcleos)
c2-standard-4 16 13.3 4 3.92
c2-standard-8 32 28.6 8 7.91
c2-standard-16 64 58.7 16 15.89
c2-standard-30 120 111.2 30 29.89
c2-standard-60 240 228.4 60 59.85
e2-micro 1 0.62 2 0.941
e2-small 2 1.35 2 0.941
e2-medium (predeterminado) 4 2.76 2 0.941
e2-standard-2 8 6.1 2 1.93
e2-standard-4 16 13.3 4 3.92
e2-standard-8 32 28.6 8 7.91
e2-standard-16 64 58.7 16 15.89
e2-highmem-2 16 13.3 2 1.93
e2-highmem-4 32 28.6 4 3.92
e2-highmem-8 64 58.7 8 7.91
e2-highmem-16 128 118.6 16 15.89
e2-highcpu-2 2 1.5 2 1.93
e2-highcpu-4 4 2.9 4 3.92
e2-highcpu-8 8 6.1 8 7.91
e2-highcpu-16 16 13.3 16 15.89
g1-small 1.7 1.2 1 0.94
m1-megamem-96 1433.6 1414.7 96 95.69
m1-ultramem-40 961 942.1 40 39.85
m1-ultramem-80 1922 1903.1 80 79.77
m1-ultramem-160 3844 3825.1 160 159.69
m1-ultramem-208 5888 5869.1 208 207.69
m1-ultramem-416 11776 11757.1 416 415.69
n1-standard-1 3.75 2.7 1 0.94
n1-standard-2 7.5 5.7 2 1.93
n1-standard-4 15 12.3 4 3.92
n1-standard-8 30 26.6 8 7.91
n1-standard-16 60 54.7 16 15.89
n1-standard-32 120 111.2 32 31.85
n1-standard-64 240 228.4 64 63.77
n1-standard-96 360 346.4 96 95.69
n1-highmem-2 13 10.7 2 1.93
n1-highmem-4 26 22.8 4 3.92
n1-highmem-8 52 47.2 8 7.91
n1-highmem-16 104 96.0 16 15.89
n1-highmem-32 208 197.4 32 31.85
n1-highmem-64 416 400.8 64 63.77
n1-highmem-96 624 605.1 96 95.69
n1-highcpu-2 1.8 1.3 2 1.93
n1-highcpu-4 3.6 2.6 4 3.92
n1-highcpu-8 7.2 5.5 8 7.91
n1-highcpu-16 14.4 11.9 16 15.89
n1-highcpu-32 28.8 25.3 32 31.85
n1-highcpu-64 57.6 52.5 64 63.77
n1-highcpu-96 86.4 79.6 96 95.69
n2-standard-2 8 6.1 2 1.93
n2-standard-4 16 13.3 4 3.92
n2-standard-8 32 28.6 8 7.91
n2-standard-16 64 58.7 16 15.89
n2-standard-32 128 118.6 32 31.85
n2-standard-48 192 182.6 48 47.85
n2-standard-64 256 244.4 64 63.77
n2-standard-80 320 308.4 80 79.77
n2-highmem-2 16 13.3 2 1.93
n2-highmem-4 32 28.6 4 3.92
n2-highmem-8 64 58.7 8 7.91
n2-highmem-16 128 118.6 16 15.89
n2-highmem-32 256 244.4 32 31.85
n2-highmem-48 384 370.4 48 47.85
n2-highmem-64 512 496.8 64 63.77
n2-highmem-80 640 621.1 80 79.77
n2-highcpu-2 2 1.5 2 1.93
n2-highcpu-4 4 2.9 4 3.92
n2-highcpu-8 8 6.1 8 7.91
n2-highcpu-16 16 13.3 16 15.89
n2-highcpu-32 32 28.6 32 31.85
n2-highcpu-48 48 44.6 48 47.85
n2-highcpu-64 64 58.7 64 63.77
n2-highcpu-80 80 74.7 80 79.77
n2d-standard-2 8 6.1 2 1.93
n2d-standard-4 16 13.3 4 3.92
n2d-standard-8 32 28.6 8 7.91
n2d-standard-16 64 58.7 16 15.89
n2d-standard-32 128 118.6 32 31.85
n2d-standard-48 192 182.6 48 47.85
n2d-standard-64 256 244.4 64 63.77
n2d-standard-80 320 308.4 80 79.77
n2d-standard-96 384 370.4 96 95.69
n2d-standard-128 512 496.8 128 127.69
n2d-standard-224 896 877.1 224 223.69
n2d-highmem-2 16 13.3 2 1.93
n2d-highmem-4 32 28.6 4 3.92
n2d-highmem-8 64 58.7 8 7.91
n2d-highmem-16 128 118.6 16 15.89
n2d-highmem-32 256 244.4 32 31.85
n2d-highmem-48 384 370.4 48 47.85
n2d-highmem-64 512 496.8 64 63.77
n2d-highmem-80 640 621.1 80 79.77
n2d-highmem-96 780 761.1 96 95.69
n2d-highcpu-2 2 1.5 2 1.93
n2d-highcpu-4 4 2.9 4 3.92
n2d-highcpu-8 8 6.1 8 7.91
n2d-highcpu-16 16 13.3 16 15.89
n2d-highcpu-32 32 28.6 32 31.85
n2d-highcpu-48 48 44.6 48 47.85
n2d-highcpu-64 64 58.7 64 63.77
n2d-highcpu-80 80 74.7 80 79.77
n2d-highcpu-96 96 89.2 96 95.69
n2d-highcpu-128 128 118.6 128 127.69
n2d-highcpu-224 224 213.4 224 223.69

1 GKE decidió reducir los recursos de CPU asignables que están disponibles para programar las cargas de trabajo de los usuarios (conocidos como recursos asignables del nodo) en los tipos de máquinas e2-micro, e2-small y e2-medium. Para obtener más detalles, consulta las notas de la versión de GKE.

Recursos de almacenamiento efímero local asignables

A partir de la versión 1.10 de GKE, puedes administrar tus recursos de almacenamiento efímero local como lo haces con tus recursos de CPU y memoria. Para obtener información sobre cómo lograr que tus Pods especifiquen solicitudes y límites de almacenamiento efímero y ver los resultados, consulta Local ephemeral storage (Almacenamiento efímero local) en la documentación de Kubernetes.

Por lo general, GKE configura sus nodos con un solo sistema de archivos y análisis periódico. Una parte del disco de arranque que depende de su tamaño está reservada para que la use el sistema.

El almacenamiento efímero puede usar toda la capacidad del disco de arranque, excepto por una porción reservada para que la use el sistema y un umbral de expulsión. El tamaño total reservado depende del tamaño del disco de arranque según la siguiente fórmula:

10% * BOOT-DISK-CAPACITY + Min(50% * BOOT-DISK-CAPACITY, 6K + 35% * BOOT-DISK-CAPACITY, 100G)

Para obtener una representación aproximada de la cantidad de almacenamiento efímero asignable disponible a medida que aumenta la capacidad del disco de arranque, consulta el siguiente gráfico:

Un gráfico que muestra cómo aumenta el almacenamiento efímero con la capacidad del disco de arranque. La relación es lineal de forma aproximada.