Casos de uso de varios clústeres

Si bien, por lo general, se recomienda usar la menor cantidad de clústeres posible, las organizaciones eligen implementar varios clústeres para lograr sus objetivos técnicos y comerciales por una variedad de motivos. Como mínimo, la mayoría de las organizaciones separan su no producción de sus servicios de producción a través de trabajos en clústeres diferentes. En situaciones más complejas, las organizaciones pueden elegir varios clústeres para separar servicios en niveles, configuraciones regionales, equipos o proveedores de infraestructura.

La mayoría de los motivos para adoptar varios clústeres se dividen en tres categorías:

  • Aislamiento: Separa el plano de control y el plano de datos de los servicios, principalmente, con el fin de mejorar la confiabilidad o abordar las necesidades de seguridad.
  • Ubicación: Ubicación de servicios en ubicaciones específicas para satisfacer las necesidades de disponibilidad, latencia y localidad
  • Escala: especialmente en el contexto de los clústeres de Kubernetes, escalamiento de los servicios más allá de los límites prácticos impuestas por un solo clúster

Las veremos en más detalle en las siguientes secciones.

En muchos casos, las organizaciones deben equilibrar varios de estos requisitos de manera simultánea. Cuando pienses en tu propia organización, recuerda que nuestra recomendación general es usar la menor cantidad de clústeres posible. Determina cuál de las necesidades de varios clústeres es la prioridad más alta para tu organización y no puede verse comprometida. Luego, realiza las compensaciones adecuadas para crear una arquitectura de varios clústeres.

Si crees que tu organización considera un modo de clúster por servicio o de clúster por equipo, te recomendamos considerar la carga de administración aplicada en los operadores de dicho sistema. Environs y los componentes y características de Google Cloud que los admiten son un ejemplo para hacer que la administración de varios clústeres sea lo más fácil posible, pero existen algunos complejidad adicional de la administración con más clústeres.

Aislamiento

En este contexto, aislamiento hace referencia a la separación del plano de control o el plano de datos, que se pueden lograr mediante la ejecución de varios clústeres. Sin embargo, según la implementación, es probable que esta separación también se extienda al aislamiento del plano de datos. Por lo general, el aislamiento ocurre cuando se considera lo siguiente:

  • Entorno
    Con frecuencia, las organizaciones ejecutan sus servicios de desarrollo, etapa de pruebas/prueba y producción en diferentes clústeres, a menudo se ejecutan en diferentes redes y proyectos en la nube. Esta separación se realiza para evitar interrupciones accidentales en los servicios de producción y evitar el acceso a datos sensibles durante el desarrollo o las pruebas.

  • Niveles de carga de trabajo
    A menudo, las organizaciones que tienen muchas aplicaciones complejas nivelan sus servicios y eligen ejecutar sus servicios más críticos en clústeres separados de los menos importantes. En esos entornos, estos servicios más críticos y sus clústeres se tratan con consideración especial en relación con el acceso, la seguridad, las actualizaciones, la política y más. Un ejemplo de este nivel es la separación de los servicios sin estado y con estado mediante la ubicación en clústeres separados.

  • Reducción del impacto de la falla
    Cuando las organizaciones quieren limitar los impactos de un error de operador, una falla del clúster o una falla en la infraestructura relacionada, pueden dividir sus servicios en varios clústeres.

  • Actualizaciones
    : A las organizaciones se preocupa por posibles problemas con la actualización in situ (es decir, actualizar la falla de automatización, la inestabilidad de la aplicación o la capacidad de revertir la implementación), pueden implementar una copia de sus servicios en un clúster nuevo. Actualizar de esta manera requiere la planificación o la automatización para que sea posible, asegúrate de abordar la administración del tráfico y la replicación de estado durante el proceso de actualización.

  • Separación regulatoria/seguridad
    Las organizaciones pueden elegir aislar los servicios por muchas razones, incluida la posibilidad de mantener las cargas de trabajo sujetas a requisitos regulatorios independientes de las menos sensibles, o ejecutar Servicios de terceros (menos de confianza) en infraestructuras separadas de servicios de origen (de confianza)

  • Separación de instancias
    Por lo general, la separación de instancias en varios clústeres se realiza por varias razones, incluido el aislamiento de seguridad, el aislamiento de rendimiento, la contabilidad de costos y la propiedad.

Ubicación

  • Latencia
    Algunos servicios tienen requisitos de latencia que se deben cumplir mediante la ubicación física de esa carga de trabajo en una ubicación específica (o ubicación geográfica). Esto puede ocurrir si los servicios o usuarios finales son sensibles a la latencia, pero también pueden ocurrir fácilmente si la carga de trabajo es sensible a la latencia del servicio descendente.

  • Disponibilidad
    La ejecución del mismo servicio en varias zonas de disponibilidad en un proveedor de nube único (o en varios proveedores) puede proporcionar una disponibilidad general más alta.

  • Jurisdicción
    La residencia de los datos y otros requisitos de procesamiento legislativos pueden requerir que el procesamiento y el almacenamiento se encuentren en una región específica, lo que requiere que la infraestructura se implemente en varios centros de datos. proveedores de servicios en la nube.

  • Gravedad de datos
    Un gran corpus de datos, o incluso ciertas instancias de bases de datos, puede ser difícil, imposible o incluso no recomendable para consolidar en un solo proveedor de servicios en la nube o región. Según los requisitos de procesamiento y entrega, es posible que una aplicación deba implementarse cerca de sus datos.

  • Infraestructura y servicios heredados
    Al igual que los datos pueden ser difíciles de trasladar a la nube, parte de la infraestructura heredada también es difícil de trasladar. Aunque estos servicios heredados son poco prácticas, la capacidad de modernizarlos alrededor de ellos permite a las organizaciones aumentar la velocidad de desarrollo.

  • Opciones para desarrolladores:
    Las organizaciones suelen beneficiarse de poder proporcionar a los desarrolladores la posibilidad de elegir en los servicios administrados en la nube que consumen. En general, las opciones permiten que los equipos se muevan más rápido con herramientas que se adaptan mejor a sus necesidades a expensas de tener que administrar recursos adicionales asignados a cada proveedor.

  • Necesidades de procesamiento local y perimetral
    Por último, cuando las organizaciones desean adoptar prácticas de modernización de aplicaciones en entornos de trabajo más tradicionales, como almacenes, pisos de fábrica, tiendas minoristas, significa que se necesita administrar muchas más cargas de trabajo en muchos más elementos de la infraestructura.

Escala

Debido a que GKE puede escalar clústeres a más de 5,000 nodos, estos límites rara vez se convierten en una razón para operar varios clústeres. Antes de que un clúster alcance los límites de escalabilidad, las organizaciones suelen decidir romper los servicios en varios clústeres. Para los clústeres que alcanzan los límites de escalabilidad, ejecutar una aplicación en varios clústeres puede facilitar algunos desafíos, pero con la complejidad agregada de administrar varios clústeres.