Cargas de trabajo de contenedores en GDC

En esta página de descripción general se explica el modelo operativo de las cargas de trabajo de contenedores en un clúster de Kubernetes aislado de Google Distributed Cloud (GDC). GDC proporciona un servicio de Kubernetes gestionado que admite aplicaciones de contenedores nativas de Kubernetes que se usan 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 gestionar las cargas de trabajo de las aplicaciones de su organización. Para obtener más información, consulta Audiencias de la documentación aislada de GDC.

Aplicaciones de Kubernetes para un entorno desconectado

GKE en GDC es un servicio de Kubernetes gestionado que incorpora muchas funciones de GKE a 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 usar y mantener la distribución de Kubernetes proporcionada con una API de KRM estándar, como cualquier otra oferta de Kubernetes 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 información general sobre los clústeres de Kubernetes. Para obtener más información sobre los conceptos clave de Kubernetes, consulta la documentación de GKE sobre cómo empezar a aprender sobre Kubernetes.

Estado de la carga de trabajo del contenedor

Los contenedores de GDC se despliegan en clústeres de Kubernetes de la siguiente forma:

Puedes escalar verticalmente los nodos de tu clúster de Kubernetes de GDC en función de los requisitos de tus cargas de trabajo de contenedores, incluso después del aprovisionamiento del clúster, a medida que evolucionen tus requisitos de computación.

Kubernetes proporciona varios recursos de carga de trabajo integrados para conseguir 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 reconocimiento del estado

Las cargas de trabajo sin reconocimiento del estado son aplicaciones que no almacenan datos ni estado de la aplicación en el clúster de Kubernetes ni en el almacenamiento persistente. En su lugar, los datos y el estado de la aplicación permanecen en el cliente, lo que hace que las aplicaciones sin estado sean más escalables. Por ejemplo, una aplicación frontend puede no tener estado: puedes desplegar varias réplicas para aumentar su disponibilidad y reducir la escala cuando la demanda sea baja. Además, las réplicas no necesitan identidades únicas.

Kubernetes usa el recurso Deployment para desplegar aplicaciones sin estado como pods uniformes y no únicos. Los despliegues gestionan el estado deseado de tu aplicación, como los siguientes:

  • La cantidad de pods para ejecutar tu aplicación.
  • Versión de la imagen de contenedor que se va a ejecutar.
  • Las etiquetas de los pods.

Puedes cambiar el estado deseado de forma dinámica actualizando la especificación Deployment del recursoPod.

Las aplicaciones sin reconocimiento del estado se diferencian de las cargas de trabajo con reconocimiento del estado, que usan almacenamiento persistente para guardar datos y el estado de las aplicaciones.

Cargas de trabajo con reconocimiento del 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 pares 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 desplegar aplicaciones con estado. Los pods de los recursos StatefulSet no son intercambiables: cada pod tiene un identificador único que se mantiene independientemente de dónde se programe.

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

Almacenamiento persistente para contenedores

GDC proporciona almacenamiento en bloques persistente 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 varios contenedores con almacenamiento compartido y recursos de red. Un PVC tiene un ciclo de vida independiente del Pod, lo que le permite persistir más allá de un solo Pod.

Puedes aprovisionar dinámicamente almacenamiento persistente para tus cargas de trabajo con reconocimiento del estado de forma que los volúmenes subyacentes se creen bajo demanda. En GDC, la asignación dinámica se configura creando uno de los siguientes objetos StorageClass preinstalados:

  • standard-rwo: la clase de almacenamiento en bloques ReadWriteOnce (RWO). Solo puede acceder a un volumen un nodo 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: clase de almacenamiento en bloques de rendimiento ReadWriteOnce. Esta clase de almacenamiento es una versión más eficiente del almacenamiento RWO que ofrece una garantía de IOPS y un límite de 30 IOPS por GiB.

También puedes crear un objeto VolumeSnapshot para copiar el volumen de almacenamiento de la aplicación de tu contenedor en un momento específico sin crear un volumen completamente nuevo. Por ejemplo, un administrador de bases de datos puede 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.

Siguientes pasos