El aislamiento de cargas de trabajo en Google Distributed Cloud (GDC) aislado te permite separar las aplicaciones de contenedores y máquinas virtuales (VMs) entre proyectos y clústeres de Kubernetes. Planificar los límites de los entornos te ayuda a controlar las políticas de acceso, contener el impacto del mantenimiento y optimizar la capacidad de los nodos. Puedes adaptar estos patrones de arquitectura para que se ajusten a los requisitos específicos de cada universo de GDC.
Este documento está dirigido al personal de TI del grupo de administradores de la plataforma que gestiona los recursos de la organización y a los desarrolladores del grupo de operadores de aplicaciones que mantienen los servicios. Para obtener más información, consulta Audiencias de la documentación de GDC aislado.
Dónde desplegar las cargas de trabajo
En la plataforma de GDC, las operaciones para desplegar cargas de trabajo de máquinas virtuales (VMs) y de contenedores son diferentes. En el siguiente diagrama se muestra la separación de las cargas de trabajo en la capa del plano de datos de tu organización.
Las cargas de trabajo basadas en VMs se ejecutan en una VM. Por el contrario, las cargas de trabajo de contenedores se ejecutan en un clúster de Kubernetes. La separación fundamental entre las máquinas virtuales y los clústeres de Kubernetes proporciona límites de aislamiento entre las cargas de trabajo de las máquinas virtuales y las de los contenedores. Para obtener más información, consulta Jerarquía de recursos.
En las siguientes secciones se presentan las diferencias entre cada tipo de carga de trabajo y su ciclo de vida de despliegue.
Cargas de trabajo basadas en máquinas virtuales
Puedes crear máquinas virtuales para alojar tus cargas de trabajo basadas en máquinas virtuales. Tienes muchas opciones de configuración para la forma y el tamaño de tu VM, lo que te ayudará a cumplir los requisitos de tu carga de trabajo basada en VMs. Debes crear una VM en un proyecto, que puede tener muchas cargas de trabajo de VM. Las VMs son un recurso secundario de un proyecto. Para obtener más información, consulta la descripción general de las VMs.
Los proyectos que solo contienen cargas de trabajo basadas en VMs no requieren un clúster de Kubernetes. Por lo tanto, no es necesario aprovisionar clústeres de Kubernetes para las cargas de trabajo basadas en máquinas virtuales.
Cargas de trabajo basadas en contenedores
Puedes desplegar cargas de trabajo basadas en contenedores en un pod de un clúster de Kubernetes. Un clúster de Kubernetes consta de los siguientes tipos de nodos:
Nodo del plano de control: ejecuta los servicios gestionados, como la programación, etcd y un servidor de la API.
Nodo de trabajador: ejecuta tus pods y aplicaciones en contenedores.
Hay dos tipos de configuración para los clústeres de Kubernetes:
- Clústeres compartidos: un clúster de Kubernetes de ámbito de organización que puede abarcar varios proyectos y que no se gestiona desde un solo proyecto, sino que está asociado a ellos.
- Clústeres estándar: un clúster de Kubernetes de ámbito de proyecto que gestiona los recursos de clúster de un proyecto y no puede abarcar varios proyectos.
Para obtener más información, consulta Configuraciones de clústeres de Kubernetes.
Los clústeres de Kubernetes ofrecen varias opciones jerárquicas de recursos, ya que los clústeres compartidos se aplican a nivel de organización y los clústeres estándar se aplican a nivel de proyecto. Esta es una diferencia fundamental entre los clústeres de Kubernetes y las máquinas virtuales. Una VM es un recurso secundario de un proyecto y no se puede configurar para que funcione fuera de un proyecto. Para obtener más información sobre cómo diseñar la infraestructura de tu clúster de Kubernetes, consulta Prácticas recomendadas para diseñar clústeres de Kubernetes.
Para la programación de pods en un clúster de Kubernetes, GDC adopta los conceptos generales de Kubernetes de programación, preferencia y desalojo. Las prácticas recomendadas para programar pods en un clúster varían en función de los requisitos de tu carga de trabajo.
Para obtener más información sobre los clústeres de Kubernetes, consulta la información general sobre los clústeres de Kubernetes. Para obtener más información sobre cómo gestionar tus contenedores en un clúster de Kubernetes, consulta Cargas de trabajo de contenedores en GDC.
Prácticas recomendadas para diseñar clústeres de Kubernetes
En esta sección se presentan las prácticas recomendadas para diseñar clústeres de Kubernetes:
- Crear clústeres independientes para cada entorno de desarrollo de software
- Crear menos clústeres, pero más grandes
- Crear menos grupos de nodos, pero más grandes, en un clúster
Ten en cuenta cada práctica recomendada para diseñar un clúster resiliente para el ciclo de vida de tu carga de trabajo de contenedores.
Crear clústeres independientes para cada entorno de desarrollo de software
Además de proyectos independientes para cada entorno de desarrollo de software, te recomendamos que diseñes clústeres de Kubernetes independientes para cada entorno de desarrollo de software. Un entorno de desarrollo de software es un área de tu universo de GDC destinada a todas las operaciones que corresponden a una fase designada del ciclo de vida. Por ejemplo, si tienes tres entornos de desarrollo de software llamados development, staging y production en tu organización, puedes crear un conjunto independiente de clústeres de Kubernetes para cada entorno y adjuntar proyectos a cada clúster según tus necesidades.
Te recomendamos que uses clústeres estándar en los ciclos de vida de preproducción que se limiten a un solo proyecto, lo que permite aislar cualquier proceso destructivo relacionado con las pruebas de los proyectos de producción. Por su parte, los clústeres compartidos son ideales para entornos de producción que pueden abarcar varios proyectos. Un clúster compartido que aloja cargas de trabajo de producción que abarcan varios proyectos proporciona un área de despliegue compartida en la que los clústeres estándar que se limitan a un solo proyecto pueden promocionar sus cargas de trabajo directamente al entorno de producción.
Los clústeres estándar definidos para cada entorno de desarrollo de software asumen que las cargas de trabajo de preproducción de un entorno de desarrollo de software se limitan a ese clúster. Un clúster de Kubernetes se puede subdividir en varios grupos de nodos o usar intolerancias para aislar las cargas de trabajo.
Al separar los clústeres de Kubernetes por entorno de desarrollo de software, aíslas el consumo de recursos, las políticas de acceso, los eventos de mantenimiento y los cambios de configuración a nivel de clúster entre tus cargas de trabajo de producción y las que no lo son.
En el siguiente diagrama se muestra un ejemplo de diseño de clúster de Kubernetes para varias cargas de trabajo que abarcan proyectos, clústeres, entornos de desarrollo de software y clases de máquinas proporcionadas por diferentes grupos de nodos.
En esta arquitectura de ejemplo se asume que las cargas de trabajo de los entornos de desarrollo, staging y producción de software pueden compartir clústeres. Cada entorno tiene un clúster estándar independiente, que se subdivide en varios grupos de nodos para cumplir los requisitos de las distintas clases de máquinas. El clúster compartido abarca todos los entornos de desarrollo de software, lo que proporciona un área de despliegue común para todos los entornos.
También puedes diseñar varios clústeres estándar por entorno de desarrollo de software, lo que resulta útil para operaciones de contenedores como las siguientes:
- Tienes algunas cargas de trabajo vinculadas a una versión específica de Kubernetes, por lo que mantienes diferentes clústeres en diferentes versiones.
- Tienes algunas cargas de trabajo que requieren configuraciones de clúster diferentes, como la política de copias de seguridad, por lo que creas varios clústeres con configuraciones distintas.
- Ejecutas copias de un clúster en paralelo para facilitar las actualizaciones de versiones disruptivas o una estrategia de despliegue azul-verde.
- Creas una carga de trabajo experimental que corre el riesgo de limitar el servidor de la API u otro punto único de fallo de un clúster, por lo que la aíslas de las cargas de trabajo que ya tienes.
Debes adaptar tus entornos de desarrollo de software a los requisitos que establezcan tus operaciones de contenedores.
Crear menos clústeres
Para usar los recursos de forma eficiente, te recomendamos que diseñes el menor número posible de clústeres de Kubernetes que cumplan tus requisitos para separar los entornos de desarrollo de software y las operaciones de contenedores. Cada clúster adicional conlleva un consumo de recursos de sobrecarga adicional, como los nodos de plano de control adicionales que se necesitan. Por lo tanto, un clúster más grande con muchas cargas de trabajo utiliza los recursos de computación subyacentes de forma más eficiente que muchos clústeres pequeños.
Cuando hay varios clústeres con configuraciones similares, se genera una sobrecarga de mantenimiento adicional para monitorizar la capacidad de los clústeres y planificar las dependencias entre ellos.
Si un clúster se está acercando a su capacidad máxima, te recomendamos que añadas más nodos al clúster en lugar de crear uno nuevo.
Crear menos grupos de nodos en un clúster
Para usar los recursos de forma eficiente, te recomendamos que diseñes menos grupos de nodos y que estos sean más grandes dentro de un clúster de Kubernetes.
Configurar varios grupos de nodos es útil cuando necesitas programar pods que requieren una clase de máquina diferente a la de otros. Crea un grupo de nodos para cada clase de máquina que requieran tus cargas de trabajo y configura la capacidad de los nodos para que se autoescale y se haga un uso eficiente de los recursos de computación.