Cargas de trabajo de contenedores en GDC

En esta página de descripción general, se explica el modelo operativo para las cargas de trabajo de contenedores en un clúster de Kubernetes aislado de Google Distributed Cloud (GDC). GDC proporciona un servicio administrado de Kubernetes que admite aplicaciones en contenedores nativas de Kubernetes que se consumen y admiten ampliamente en Google Kubernetes Engine (GKE).

Esta página está dirigida a los desarrolladores del grupo de operadores de aplicaciones, que son responsables de administrar las cargas de trabajo de las aplicaciones de su organización. Para obtener más información, consulta Audiences for GDC air-gapped documentation.

Aplicaciones de Kubernetes para un entorno desconectado

GKE on GDC es un servicio administrado de Kubernetes que incorpora muchas funciones de GKE en tu universo de GDC de forma predeterminada. Este servicio elimina la necesidad de instalar, actualizar, integrar y ejecutar Kubernetes de código abierto por tu cuenta. Puedes operar y mantener la distribución de Kubernetes proporcionada con una API de KRM estándar, como cualquier otra oferta de Kubernetes que sea declarativa e idempotente. Del mismo modo, GKE en GDC se ofrece desde la consola de GDC, la CLI de gdcloud y Terraform. Para obtener más información sobre los clústeres de Kubernetes de GDC, consulta la descripción general del clúster de Kubernetes. Para obtener más información sobre los conceptos clave de Kubernetes, consulta la documentación de GKE en Comienza a aprender sobre Kubernetes.

Estado de la carga de trabajo del contenedor

Los contenedores en GDC se implementan en clústeres de Kubernetes de la siguiente manera:

Puedes escalar horizontalmente los nodos de tu clúster de Kubernetes de GDC según los requisitos de tus cargas de trabajo de contenedores, incluso después del aprovisionamiento del clúster, a medida que evolucionan tus requisitos de procesamiento.

Kubernetes proporciona varios recursos de carga de trabajo integrados para lograr el estado de aplicación de contenedor que prefieras. Para obtener más información, consulta la documentación sobre las cargas de trabajo de Kubernetes.

Cargas de trabajo sin estado

Las cargas de trabajo sin estado son aplicaciones que no almacenan datos ni estados de la aplicación en el clúster de Kubernetes ni en el almacenamiento persistente. En cambio, los datos y el estado de la aplicación se quedan con el cliente. Esto hace que las aplicaciones sin estado sean más escalables. Por ejemplo, una aplicación de frontend puede no tener estado: implementas varias réplicas para aumentar su disponibilidad y disminuyes la escala cuando la demanda es baja, y las réplicas no necesitan tener identidades únicas.

Kubernetes usa el recurso Deployment para implementar aplicaciones sin estado como Pods uniformes que no son únicos. Los objetos Deployment administran el estado deseado de tu aplicación, como los siguientes:

  • Es la cantidad de Pods para ejecutar tu aplicación.
  • Es la versión de la imagen del contenedor que se ejecutará.
  • Son las etiquetas de los Pods.

Puedes cambiar el estado deseado de forma dinámica a través de actualizaciones en la especificación Pod del recurso Deployment.

Las aplicaciones sin estado se diferencian de las cargas de trabajo con estado, que usan almacenamiento persistente para guardar datos y el estado de la aplicación.

Cargas de trabajo con estado

Las cargas de trabajo con estado son aplicaciones que guardan datos en el almacenamiento de disco persistente para que los usen el servidor, los clientes y otras aplicaciones. Un ejemplo de aplicación con estado es una base de datos o un almacén de clave-valor en el que otras aplicaciones guardan y recuperan datos. Debes aprovisionar almacenamiento persistente para que lo use tu aplicación con estado.

Kubernetes usa el recurso StatefulSet para implementar aplicaciones con estado. Los Pods en los recursos StatefulSet no son intercambiables: cada Pod tiene un identificador único que se mantiene sin importar dónde se programe.

Las aplicaciones con estado son diferentes de las cargas de trabajo sin estado, en las que los datos del cliente no se guardan en el servidor entre sesiones.

Almacenamiento persistente para contenedores

GDC proporciona almacenamiento persistente en bloque y de archivos a través de objetos PersistentVolumeClaim (PVC). Un PVC es una solicitud de almacenamiento a la que hace referencia un objeto Pod. Un Pod es un grupo de uno o más contenedores con recursos de red y almacenamiento compartidos. Un PVC tiene un ciclo de vida independiente del Pod, lo que le permite persistir más allá de un solo Pod.

Puedes aprovisionar de forma dinámica almacenamiento persistente para tus cargas de trabajo con estado de modo que los volúmenes subyacentes se creen a pedido. En GDC, configuras el aprovisionamiento dinámico creando uno de los siguientes objetos StorageClass preinstalados:

  • standard-rwo: Es la clase de almacenamiento en bloque ReadWriteOnce (RWO). Solo un nodo puede acceder al volumen a la vez. Esta clase de almacenamiento ofrece una garantía y un límite de operaciones de entrada y salida por segundo (IOPS) de 3 IOPS por GiB.

  • system-performance-rwo: Es la clase de almacenamiento en bloque de rendimiento ReadWriteOnce. Esta clase de almacenamiento es una versión más eficiente del almacenamiento RWO que incluye una garantía y un límite de IOPS de 30 IOPS por GiB.

También puedes crear un objeto VolumeSnapshot para copiar el volumen de almacenamiento de la aplicación del contenedor en un momento específico sin crear un volumen completamente nuevo. Por ejemplo, un administrador de bases de datos podría crear una instantánea de volumen para hacer una copia de seguridad de las bases de datos antes de realizar modificaciones de edición o eliminación.

¿Qué sigue?