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:

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

Nota: Antes de la versión 1.12.0, las máquinas con menos de 1 GB de memoria están exentas de reservas de memoria.

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.

Nota: GKE reserva alrededor de 1.5 veces más recursos en los nodos de Windows Server, por lo que los valores asignables son más bajos que los valores de Linux enumerados en la tabla.

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.94^1
e2-small	2	1.35	2	0.94^1
e2-medium (predeterminado)	4	2.76	2	0.94^1
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

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

Nota: Los valores enumerados para los recursos asignables no tienen en cuenta los recursos usados por los pods kube-system, cuya cantidad varía con cada actualización de Kubernetes. Por lo general, estos módulos del sistema ocupan una memoria adicional de 0.4 CPU virtual y 400 MiB en cada nodo (los valores son aproximados). Se recomienda inspeccionar directamente tu clúster si necesitas un recuento exacto de los recursos utilizables en cada nodo.

Nota: Las máquinas f1-micro no son compatibles porque no tienen memoria suficiente para ejecutar GKE.

Recursos de almacenamiento efímero local asignables

Beta

Esta función está sujeta a las Condiciones de las ofertas anteriores a la disponibilidad general de las Condiciones del Servicio de Google Cloud Platform. Las características anteriores a la disponibilidad general pueden tener asistencia limitada, y los cambios en las características anteriores a la disponibilidad general puede que no sean compatibles con otras versiones anteriores a la disponibilidad general. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

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: