Esta página se ha traducido con Cloud Translation API.

Arquitectura de clúster de GKE

Autopilot Standard

En esta página se describe la arquitectura de los clústeres de Google Kubernetes Engine (GKE) que ejecutan tus cargas de trabajo en contenedores. En esta página se explica qué son el plano de control y los nodos, y cómo interactúan entre sí los distintos componentes de un clúster de GKE.

Esta página está dirigida a administradores, arquitectos y operadores que definen soluciones de TI y arquitecturas de sistemas. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido de Google Cloud , consulta Roles y tareas de usuario habituales de GKE.

Antes de leer esta página, asegúrate de que conoces la arquitectura de clúster de Kubernetes.

Un clúster de GKE consta de un plano de control y máquinas de trabajador llamadas nodos. El plano de control y los nodos forman el sistema de orquestación del clúster de Kubernetes. Autopilot de GKE gestiona toda la infraestructura subyacente de los clústeres, incluido el plano de control, los nodos y todos los componentes del sistema.

Si usas el modo estándar de GKE, GKE gestiona el plano de control y los componentes del sistema, y tú gestionas los nodos.

En el siguiente diagrama se muestra la arquitectura de un clúster de GKE:

En este diagrama se muestran los siguientes componentes:

Plano de control: gestionado por GKE. Ejecuta el servidor de la API de Kubernetes, los controladores de cargas de trabajo, el programador de Kubernetes y el almacenamiento del estado del clúster.
Nodos: GKE los gestiona en el modo Autopilot y los clientes en el modo Standard. Todos tus pods se ejecutan en nodos.
Otros servicios de Google Cloud : se pueden integrar con GKE.

Acerca del plano de control

El plano de control ejecuta procesos como el servidor de la API de Kubernetes, el programador y los controladores de recursos principales. GKE gestiona el ciclo de vida del plano de control desde la creación hasta la eliminación del clúster. Esto incluye las actualizaciones de la versión de Kubernetes que se ejecuta en el plano de control, que GKE realiza automáticamente, o bien manualmente si lo solicitas, en caso de que prefieras actualizar antes de la fecha programada.

Plano de control y API de Kubernetes

El plano de control es el endpoint unificado de tu clúster. Interactúas con el plano de control mediante llamadas a la API de Kubernetes. El plano de control ejecuta el proceso del servidor de la API de Kubernetes (kube-apiserver) para gestionar las solicitudes de la API. Puedes hacer llamadas a la API de Kubernetes de las siguientes formas:

Llamadas directas: HTTP/gRPC
Llamadas indirectas: clientes de línea de comandos de Kubernetes, como kubectl o la consolaGoogle Cloud .

El proceso del servidor de la API es el centro de todas las comunicaciones del clúster. Todos los componentes internos del clúster, como los nodos, los procesos del sistema y los controladores de aplicaciones, actúan como clientes del servidor de la API.

Las solicitudes a la API indican a Kubernetes el estado deseado de los objetos de tu clúster. Kubernetes intenta mantener ese estado constantemente. Kubernetes te permite configurar objetos en la API de forma imperativa o declarativa.

Para obtener más información sobre la gestión de objetos en Kubernetes, consulta las siguientes páginas:

Plano de control y base de datos de estado del clúster

El proyecto de código abierto Kubernetes usa etcd como base de datos de almacenamiento de todos los datos del clúster de forma predeterminada. El estado del clúster se mantiene en un almacén de clave-valor que contiene información sobre el estado de cada objeto de la API de Kubernetes de tu clúster. Por ejemplo, la base de datos de estado del clúster almacena todos los secretos, los ConfigMap y los Deployments.

Los clústeres de GKE almacenan el estado del clúster en uno de los siguientes almacenes de clave-valor:

etcd: GKE almacena el estado del clúster en instancias de etcd que se ejecutan en cada máquina virtual (VM) del plano de control.
Spanner: GKE almacena el estado del clúster en Spanner. La base de datos de Spanner no se ejecuta en el plano de control del clúster.

Independientemente del tipo de base de datos, todos los clústeres de GKE sirven la API etcd en el plano de control. El servidor de la API de Kubernetes usa la API de etcd para comunicarse con la base de datos de estado del clúster backend.

Interacción entre el plano de control y los nodos

El plano de control gestiona lo que se ejecuta en todos los nodos del clúster. El plano de control programa las cargas de trabajo y gestiona su ciclo de vida, su escalado y sus actualizaciones. El plano de control también gestiona los recursos de red y almacenamiento de esas cargas de trabajo. El plano de control y los nodos se comunican entre sí mediante las APIs de Kubernetes.

Interacciones del plano de control con Artifact Registry

Cuando creas o actualizas un clúster, GKE extrae imágenes de contenedor del software del sistema Kubernetes que se ejecuta en el plano de control y los nodos de los repositorios de Artifact Registry en el dominio pkg.dev o gcr.io. Si se produce una interrupción que afecte a estos registros, es posible que no se puedan llevar a cabo las siguientes acciones:

Creación de clústeres
Actualizaciones de la versión del clúster

Es posible que se produzcan interrupciones en las cargas de trabajo incluso sin tu intervención, en función de la naturaleza y la duración específicas de la interrupción.

Si la interrupción del repositorio de Artifact Registry es regional, es posible que redirijamos las solicitudes a una zona o región que no se vea afectada por la interrupción.

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

Práctica recomendada:

Despliega en varias regiones para permitir la disponibilidad de las aplicaciones durante las interrupciones de servicio de las regiones.

Acerca de los nodos

Los nodos son las máquinas de trabajador que ejecutan tus aplicaciones en contenedores y otras cargas de trabajo. Las máquinas individuales son máquinas virtuales (VMs) de Compute Engine que crea GKE. El plano de control gestiona y recibe actualizaciones sobre el estado autoinformado de cada nodo.

Un nodo ejecuta los servicios necesarios para poder usar los contenedores que conforman las cargas de trabajo de tu clúster. Entre ellos, se incluyen el entorno de ejecución y el agente de nodo de Kubernetes (kubelet), que se comunica con el plano de control y se encarga de iniciar y ejecutar los contenedores programados en el nodo.

GKE también ejecuta varios contenedores del sistema que se ejecutan como agentes por nodo, llamados DaemonSets, que proporcionan funciones como la recogida de registros y la conectividad de red dentro del clúster.