Arquitectura del clúster de GKE


En esta página, se presenta la arquitectura de un clúster de Google Kubernetes Engine (GKE). Todas las cargas de trabajo alojados en contenedores de Kubernetes se ejecutan en un clúster de GKE.

Esta página está destinada a administradores, arquitectos y operadores que definen soluciones de TI y arquitectura de sistema. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en el contenido de Google Cloud, consulta Tareas y roles comunes de los usuarios de GKE Enterprise.

Un clúster de GKE consiste en un plano de control y máquinas de trabajador llamadas nodos. El plano de control y los nodos conforman el sistema de organización de clúster de Kubernetes. GKE Autopilot administra 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 administra el plano de control y los componentes del sistema, y tú administras los nodos. En el siguiente diagrama, se muestra la arquitectura de un clúster de GKE:

Arquitectura del clúster de GKE. El plano de control es administrado por GKE y ejecuta el servidor de la API, los controladores de recursos, el programador y el almacenamiento del clúster. Los nodos son administrados por GKE en modo Autopilot y administrados por el usuario en modo Standard.
     Los Pods de usuario ejecutan contenedores en nodos. Hay otros servicios de Google Cloud disponibles que se integran en GKE.

Información sobre el 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 administra el ciclo de vida del plano de control desde la creación hasta la eliminación del 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 plano de control a través de llamadas a la API de Kubernetes. El plano de control ejecuta el proceso del servidor de la API de Kubernetes (kube-apiserver) para controlar las solicitudes a la API. Puedes realizar llamadas a la API de Kubernetes de las siguientes maneras:

  • Llamadas directas: HTTP/gRPC
  • Llamadas indirectas: Clientes de la línea de comandos de Kubernetes como kubectl o la consola de Google Cloud.

El proceso del servidor de la API es el centro de todas las comunicaciones para el 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 le indican a Kubernetes cuál es el estado deseado para los objetos en tu clúster. Kubernetes intenta mantener ese estado de forma constante. Kubernetes te permite configurar objetos en la API de forma imperativa o declarativa.

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

Plano de control e interacción de los nodos

El plano de control administra qué se ejecuta en todos los nodos del clúster. El plano de control programa las cargas de trabajo 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 entre sí mediante las API de Kubernetes.

Interacciones del plano de control con Artifact Registry

Cuando creas o actualizas un clúster, GKE extrae imágenes de contenedor para el software del sistema de Kubernetes que se ejecuta en el plano de control y los nodos del Artifact Registry pkg.dev o del Container Registry gcr.io. Una interrupción que afecte a estos registros puede provocar que fallen las siguientes acciones:

  • Creación de clústeres nuevos
  • Actualizaciones de versiones de clústeres

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.

Si la interrupción del Artifact Registry pkg.dev o del Container Registry gcr.io es regional, es posible que redireccionemos 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.

Práctica recomendada:

Implementa en varias regiones para permitir la disponibilidad de las aplicaciones durante las interrupciones regionales.

Acerca de los nodos

Los nodos son 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 administra y recibe actualizaciones sobre el estado autoinformado de cada nodo.

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.

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

Práctica recomendada:

Usa stdout para aplicaciones en contenedores, ya que stdout permite que tu plataforma controle los registros de la aplicación.

La administración de nodos varía según el modo de operación del clúster, de la siguiente manera:
Componente de nodo Modo Autopilot Modo estándar
Lifecycle

Completamente administrado por GKE, incluido lo siguiente:

GKE administra lo siguiente:

Puedes administrar lo siguiente:

Visibilidad Visualiza los nodos mediante kubectl. Las máquinas virtuales subyacentes de Compute Engine no son visibles ni accesibles en la CLI de gcloud ni en la consola de Google Cloud. Visualiza los nodos mediante kubectl, la CLI de gcloud y la consola de Google Cloud. Visualiza y accede a las VMs de Compute Engine subyacentes.
Conectividad Sin conexión directa a las VMs subyacentes. Conéctate a las VMs subyacentes mediante SSH.
Sistema operativo (SO) del nodo Administrado por GKE Todos los nodos usan Container-Optimized OS con containerd (cos_containerd). Elige un sistema operativo para los nodos.
Selección de hardware de máquina

Solicita clases de procesamiento en Pods según el caso de uso.

GKE administra la configuración, la programación, la cantidad y el ciclo de vida de las máquinas.

Elige y configura los tipos de máquinas de Compute Engine cuando crees grupos de nodos. Establece la configuración del tamaño, escalamiento, cantidad, programación y ubicación según la necesidad.