Arquitectura del clúster

En Google Kubernetes Engine, un clúster consta de al menos un clúster principal y varias máquinas de trabajo denominadas nodos. Este nodo principal y máquinas de nodo de Kubernetes ejecutan el sistema de organización de clúster.

Un clúster es la base de GKE: Los objetos de Kubernetes que representan tus aplicaciones en contenedores se ejecutan todos sobre un clúster.

Clúster principal

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

API de Kubernetes y clúster principal

El clúster principal 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 clúster principal 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 indirectamente ejecutando comandos desde el cliente de línea de comandos de Kubernetes (kubectl) o interactuando con la IU en GCP Console.

El proceso del servidor de API del clúster principal 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.

Interacción principal y nodo

El clúster principal 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 principal también administra los recursos de red y almacenamiento para esas cargas de trabajo.

El clúster principal y los nodos también se comunican con las API de Kubernetes.

Nodos

Un clúster generalmente tiene uno o más nodos, que son las máquinas de trabajo 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 crea un clúster.

Cada nodo se administra desde el clúster principal, 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 clúster principal 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 n1-standard-1 con 1 CPU virtual y 3.75 GB de memoria. 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 disparidad entre los recursos totales del nodo (como se especifica en la documentación tipo de máquina) y los recursos asignables del nodo en GKE.

Puedes realizar una solicitud de recursos para tus pods o limitar tu uso de recursos. Para obtener más información sobre cómo solicitar o limitar el uso de recursos a pods, consulta Administración de recursos de procesamiento de los 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 4 -A 3

La salida que se muestra contiene los campos Capacity y Allocatable con mediciones para almacenamiento efímero, memoria y CPU.

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:

  • 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

GKE reserva una memoria adicional de 100 MiB en cada nodo para la expulsión de kubelet.

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

La siguiente tabla muestra la cantidad de memoria asignable y los recursos de CPU disponibles a fin de programar las cargas de trabajo de tu clúster para cada tipo de máquina de nodo estándar:

Tipo de máquina Capacidad de memoria (GB) Memoria asignable (GB) Capacidad de CPU (núcleos) CPU asignable (núcleos)
f1-micro (exento de memoria) 0.6 0.6 1 0.94
g1-small 1.7 1.2 1 0.94
n1-standard-1 (predeterminado) 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

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. Las reservas del sistema del almacenamiento local se realizan principalmente para el espacio en disco que usan las imágenes de contenedor.

Si tu nodo no consume todo el almacenamiento reservado, los pods todavía pueden usar el espacio. Esto no impide que el espacio en el disco se use en cualquier situación.

Los recursos de almacenamiento efímero local asignables se calculan mediante la siguiente fórmula con un umbral de desalojo del 10% de la capacidad de almacenamiento:

Allocatable = Capacity - Reserved - Eviction Threshold
Capacidad de disco (GB) Reservado (GB) Asignable (GB)
8 4 3.2
16 8 6.4
32 16 12.8
64 28.4 29.2
128 50.8 64.4
256 95.6 134.8
512 100 360.8
1,024 100 821.6
2,048 100 1,743.2
4,096 100 3,586.4
¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...