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. Interactúas con el clúster a través de 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 decide qué se ejecuta en todos los nodos del clúster. El plano de control programa cargas de trabajo, como aplicaciones alojadas en contenedores, y administra el 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 se comunican mediante las API de Kubernetes.
Interacciones del plano de control con Artifact Registry y Container Registry
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 Artifact Registry pkg.dev o Container Registry gcr.io. Una interrupción que afecta a estos registros puede provocar los siguientes tipos de fallas:
- La creación de nuevos clústeres falla durante la interrupción.
- La actualización de los clústeres falla 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 el caso de una interrupción regional de Artifact Registry pkg.dev o Container Registry gcr.io, Google podría redireccionar las solicitudes a una zona o región que no se vea 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 que conforman las cargas de trabajo de tu clúster. Estos incluyen el entorno de ejecución 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 programados en el 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. Por este motivo, es posible que notes 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.
Debido a 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 solicitar recursos para los Pods o limitar su uso. 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 no asignables que están disponibles en un clúster, ejecuta el siguiente comando y reemplaza NODE_NAME por el nombre del nodo que deseas inspeccionar:
kubectl describe node NODE_NAME | grep Allocatable -B 7 -A 6
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 GiB de memoria
- Un 20% de los siguientes 4 GiB de memoria (hasta 8 GiB)
- Un 10% de los siguientes 8 GiB de memoria (hasta 16 GiB)
- Un 6% de los siguientes 112 GiB de memoria (hasta 128 GiB)
- Un 2% de cualquier memoria por encima de 128 GiB
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
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. El almacenamiento efímero también puede estar respaldado por SSD locales. En cualquier caso, una parte del sistema de archivos está reservada para el uso de kubelet. La parte restante, llamada almacenamiento efímero local asignable, está disponible para su uso como recursos de almacenamiento efímero.
La cantidad de sistema de archivos reservada para kubelet y otros componentes del sistema se proporciona de la siguiente manera:
EVICTION-THRESHOLD + SYSTEM-RESERVATION
Almacenamiento efímero respaldado por un disco de arranque
De forma predeterminada, el almacenamiento efímero está respaldado por el disco de arranque del nodo. En este caso, el umbral de expulsión y el tamaño de la reserva del sistema se proporcionan mediante las siguientes fórmulas:
EVICTION-THRESHOLD = 10% * BOOT-DISK-CAPACITY
SYSTEM-RESERVATION = Min(50% *
BOOT-DISK-CAPACITY, 6GB + 35% * BOOT-DISK-CAPACITY, 100 GB)
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:
Almacenamiento efímero respaldado por SSD locales
El espacio reservado del sistema depende de la cantidad de SSD locales:
| Cantidad de SSD locales | SYSTEM-RESERVATION
(GB) |
|---|---|
| 1 | 50 |
| 2 | 75 |
| 3 o más | 100 |
El límite de expulsión es similar al almacenamiento efímero respaldado por el disco de arranque:
EVICTION-THRESHOLD = 10% * NUM-LOCAL-SSDS * 375 GB
La capacidad de cada SSD local es de 375 GB. Para obtener más información, consulta la documentación de Compute Engine sobre cómo agregar SSD locales.