Descripción general de la implementación de cargas de trabajo

Para implementar y administrar las aplicaciones alojadas en contenedores y otras cargas de trabajo en tu clúster de Google Kubernetes Engine (GKE), usa el sistema de Kubernetes para crear objetos de controlador de Kubernetes. Estos objetos de controlador representan las aplicaciones, daemons y trabajos por lotes que se ejecutan en tus clústeres.

Puedes crear estos objetos de controlador con la API de Kubernetes o con kubectl, una interfaz de línea de comandos para Kubernetes que instala gcloud. Por lo general, se compila una representación del objeto de control de Kubernetes que quieres, como un archivo de configuración YAML y, luego, usas ese archivo con la API de Kubernetes o la interfaz de línea de comandos kubectl.

Tipos de cargas de trabajo

Kubernetes proporciona diferentes tipos de objetos de controlador que corresponden a distintos tipos de cargas de trabajo que puedes ejecutar. Ciertos objetos de controlador son más adecuados para representar tipos específicos de cargas de trabajo. En las siguientes secciones, se describen algunos tipos comunes de cargas de trabajo y los objetos del controlador Kubernetes que puedes crear para ejecutarlos en tu clúster, incluidos los siguientes:

  • Aplicaciones sin estado
  • Aplicaciones con estado
  • Trabajos por lotes
  • Daemons

Aplicaciones sin estado

Una aplicación sin estado no conserva su estado ni guarda datos en el almacenamiento continuo: todos los datos de usuario y de sesión permanecen con el cliente.

Algunos ejemplos de aplicaciones sin estado incluyen frontends web, como Nginx, servidores web como Apache Tomcat y otras aplicaciones web.

Puedes crear un Deployment de Kubernetes para implementar una aplicación sin estado en tu clúster. Los Pods que crean las Implementaciones no son únicos y no conservan su estado, lo que facilita el escalamiento y la actualización de aplicaciones sin estado.

Aplicaciones con estado

Una aplicación con estado requiere que su estado se guarde o sea persistente. Las aplicaciones con estado usan almacenamiento continuo, como los volúmenes persistentes, para guardar datos a fin de que los usen el servidor o los otros usuarios.

Los ejemplos de aplicaciones con estado incluyen bases de datos, como MongoDB y colas de mensajes como Apache ZooKeeper.

Puedes crear un StatefulSet de Kubernetes para implementar una aplicación con estado. Los Pods que crean los StatefulSets tienen identificadores únicos y pueden actualizarse de forma ordenada y segura.

Trabajos por lotes

Los trabajos por lotes representan tareas finitas, independientes y, a menudo, paralelas que se ejecutan hasta su finalización. Algunos ejemplos de trabajos por lotes incluyen tareas automáticas o programadas como enviar correos electrónicos, procesar videos y realizar cálculos costosos.

Puedes crear un Trabajo de Kubernetes para ejecutar y administrar una tarea por lotes en tu clúster. Puedes especificar la cantidad de Pods que deben finalizar sus tareas antes de que se complete el Trabajo, así como la cantidad máxima de Pods que deben ejecutarse en paralelo.

Daemons

Los daemons realizan tareas continuas en segundo plano en sus nodos asignados sin necesidad de que intervenga el usuario. Algunos ejemplos de daemons incluyen los recopiladores de registros, como Fluentd y los servicios de supervisión.

Puedes crear un DaemonSet de Kubernetes para implementar un daemon en tu clúster. Los DaemonSets crean un Pod por nodo y puedes elegir en qué nodo específico se debe implementar un DaemonSet.

DaemonSets en GKE Autopilot

GKE administra los nodos en los clústeres que creas mediante el modo de operación Autopilot. No puedes agregar, quitar o modificar de forma manual los nodos o las máquinas virtuales (VM) subyacentes de Compute Engine. Sin embargo, el objeto del nodo de Kubernetes aún es visible y Autopilot admite DaemonSets como tus cargas de trabajo.

Autopilot de GKE limita algunas funciones administrativas que afectan a todos los pods de carga de trabajo, incluidos los pods administrados por DaemonSets. Los DaemonSets que realizan funciones administrativas en nodos que usan privilegios elevados, como el contexto de seguridad privileged, no se ejecutarán en clústeres de Autopilot, a menos que GKE lo permita de forma explícita.

Para obtener más información sobre los límites que aplica Autopilot, consulta Limitaciones y restricciones de cargas de trabajo. Puedes usar DaemonSets con cargas de trabajo que cumplan con las restricciones que establece Autopilot y DaemonSets de algunos socios de Google Cloud.

Prácticas recomendadas para los DaemonSets en Autopilot

GKE usa el tamaño total de las cargas de trabajo implementadas a fin de determinar el tamaño de los nodos que Autopilot aprovisiona para el clúster. Si agregas o cambias el tamaño de un DaemonSet después de que Autopilot aprovisiona un nodo, GKE no cambiará el tamaño de los nodos existentes para ajustar el tamaño nuevo de la carga de trabajo total. Los DaemonSets con solicitudes de recursos mayores que la capacidad asignable de los nodos existentes, después de tener en cuenta los pods del sistema, tampoco se programarán en esos nodos.

A partir de la versión 1.27.6-gke.1248000 de GKE, los clústeres en modo Autopilot detectan nodos que no admiten todos los DaemonSets y, con el tiempo, migran cargas de trabajo a nodos más grandes que puedan admitir todos los DaemonSets. Este proceso lleva tiempo, en especial si los nodos ejecutan Pods del sistema, que necesitan tiempo adicional para finalizar de forma correcta a fin de que no haya interrupciones en las capacidades principales del clúster.

En GKE versión 1.27.5-gke.200 o anterior, recomendamos acordonar y vaciar nodos que no pueden admitir Pods del DaemonSet.

Para todas las versiones de GKE, sugerimos las siguientes prácticas recomendadas cuando se implementan DaemonSets en Autopilot:

  • Implementa DaemonSets antes de cualquier otra carga de trabajo.
  • Configura una PriorityClass más alta en DaemonSets que los pods normales. La PriorityClass más alta permite que GKE expulsa los pods de menor prioridad para alojar los pods de DaemonSet si el nodo puede acomodar esos pods. Esto ayuda a garantizar que el DaemonSet esté presente en cada nodo sin activar la recreación de nodos.

Administra objetos de carga de trabajo

Puedes crear, administrar y borrar objetos con métodos imperativos y declarativos. En las siguientes secciones, se describen estos métodos y las siguientes herramientas que puedes usar para emplearlos:

Comandos imperativos

Los comandos imperativos te permiten crear, ver, actualizar y borrar objetos con rapidez a través de kubectl. Estos comandos son útiles para tareas únicas o a fin de realizar cambios en objetos activos en un clúster. Los comandos imperativos se usan, por lo general, para operar en objetos activos implementados en tu clúster.

kubectl cuenta con varios comandos basados en verbos para crear y editar objetos de Kubernetes. Por ejemplo:

  • run: genera un objeto nuevo en el clúster. A menos que se especifique lo contrario, run crea un objeto de implementación. run también admite varios generadores adicionales.
  • expose: crea un objeto de Servicio nuevo para balancear las cargas del tráfico en un conjunto de pods etiquetados.
  • autoscale: Crea un nuevo objeto de escalador automático para escalar de forma automática y horizontal un objeto de controlador, como una implementación.

Los comandos imperativos no requieren archivos de configuración ni una comprensión sólida del esquema de objetos.

Configuración de objetos imperativa

La configuración de objetos imperativa crea, actualiza y borra objetos mediante archivos de configuración que contienen definiciones de objetos completas. Puedes almacenar los archivos de configuración de objetos en los sistemas de control de origen y auditar los cambios con más facilidad que si usas los comandos imperativos.

Puedes ejecutar operaciones kubectl apply, delete y replace con archivos de configuración o directorios que contengan archivos de configuración.

Configuración de objetos declarativa

La configuración de objetos declarativa opera en archivos de configuración almacenados de forma local, pero no requiere una definición explícita de las operaciones que se ejecutarán. En su lugar, las operaciones se detectan por objeto de forma automática mediante kubectl. Esto es útil si trabajas con un directorio de archivos de configuración con muchas operaciones diferentes. La administración de objetos declarativa requiere una comprensión sólida de los esquemas de objetos y los archivos de configuración.

Puedes ejecutar kubectl apply para crear y actualizar objetos de forma declarativa. apply actualiza objetos con una lectura de todo el objeto activo, un cálculo de las diferencias y una fusión de estas diferencias mediante solicitudes de parches al servidor de API.

Imágenes públicas de Docker Hub

Cuando implementas una imagen de contenedor pública desde Docker Hub, GKE verifica de forma automática el proxy de almacenamiento en caché mirror.gcr.io para obtener una copia almacenada en caché de la imagen de contenedor. Si una copia almacenada en caché no está disponible, GKE extrae la imagen solicitada de Docker Hub, y el proxy de almacenamiento en caché puede almacenar la imagen en caché para usarla más adelante. Para obtener más información, consulta la sección Extrae imágenes almacenadas en caché.

Consola

Después de que implementaste una carga de trabajo con kubectl o la API, puedes usar el menú Cargas de trabajo de GKE en la consola de Google Cloud para inspeccionar, administrar y editar las cargas de trabajo que se ejecutan en tus clústeres.

El menú ofrece las siguientes características:

  • Puedes usar el editor de texto basado en YAML para editar objetos en vivo desde tu navegador web.
  • Puedes ver información detallada sobre los objetos, lo que incluye el historial de revisiones, eventos y actividades recientes, y sus Pods administrados.
  • Puedes escalar Implementaciones, Trabajos y StatefulSets con facilidad.
  • Puedes ajustar la escala de forma automática, activar actualizaciones progresivas y escalar Implementaciones de forma manual desde el menú de Acciones.
  • Puedes usar Cloud Shell para inspeccionar, editar y borrar cualquier objeto.

API

Puedes usar la API de REST de GKE y la API de Kubernetes junto con las Bibliotecas cliente de Google Cloud para crear y administrar cargas de trabajo de manera programática.

Archivos de configuración

Cuando implementas una carga de trabajo con cualquiera de los métodos anteriores, GKE agrega un archivo de configuración a tu clúster que representa el objeto.

La configuración activa de un objeto puede diferir de su archivo local. YAML se usa con más frecuencia para crear y representar objetos de Kubernetes. También puedes usar JSON.

Para obtener más información sobre las especificaciones de objetos, los estados y la API de Kubernetes, consulta Fundamentos de los objetos de Kubernetes y la referencia de la API de Kubernetes.

Inspecciona opciones de configuración activas

Consola

Para inspeccionar la configuración activa de un objeto implementado, realiza los siguientes pasos:

  1. Ve a la página Cargas de trabajo en la consola de Google Cloud.

    Ir a Cargas de trabajo

  2. Selecciona la carga de trabajo deseada.

  3. Haz clic en YAML.

gcloud

Para inspeccionar la configuración activa de un objeto implementado, ejecuta el comando siguiente:

kubectl get [OBJECT_TYPE] [OBJECT_NAME] -o yaml

[OBJECT_TYPE] puede ser deployment, statefulset, job, o bien otro tipo de objeto. Por ejemplo:

kubectl get deployment my-stateless-app -o yaml

Administra el uso de recursos con cuotas

Cuando muchos usuarios o equipos comparten los recursos en el clúster, existe la preocupación de que algunos puedan usar más que el uso legítimo. Puedes usar el objeto ResourceQuota de Kubernetes para limitar el consumo de recursos dentro de espacios de nombres específicos.

GKE también aplica un objeto gke-resource-quotas inmutable predeterminado a espacios de nombres en clústeres con 100 nodos o menos para evitar inestabilidad.

Usa GitLab para implementar en GKE

Si usas GitLab para la integración continua, puedes usar el componente de GKE de GitLab a fin de implementar tu carga de trabajo en un clúster de GKE.

También puedes probar el instructivo de extremo a extremo para usar GitLab con Google Cloud.

Para obtener más información, consulta la descripción general de GitLab en Google Cloud.

¿Qué sigue?