Casos de uso de varios clústeres

Si bien usar la menor cantidad de clústeres posible suele ser una práctica recomendada, las organizaciones eligen implementar varios clústeres para lograr sus objetivos técnicos y comerciales por diversos motivos. Como mínimo, la mayoría de las organizaciones separan sus servicios productivos de los no productivos y los colocan en clústeres diferentes. En situaciones más complejas, las organizaciones pueden elegir varios clústeres para separar los 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 de requisitos:

  • Aislamiento: Separar el plano de control y el plano de datos de los servicios, principalmente para mejorar la confiabilidad o abordar las necesidades de seguridad.
  • Ubicación: Colocar servicios en ubicaciones específicas para abordar 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 analizaremos con más detalle en las siguientes secciones.

En muchos casos, las organizaciones deben equilibrar varios de estos requisitos de forma simultánea. Mientras piensas 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 mayor prioridad para tu organización y no se puede comprometer, y luego realiza las compensaciones adecuadas para crear una arquitectura de varios clústeres.

Si tu organización está considerando un modo de clúster por modelo de servicio o clúster por equipo, te recomendamos considerar la carga de administración que se impone sobre los operadores de dicho sistema. Las flotas y los componentes y funciones de Google Cloud que las respaldan se esfuerzan por facilitar la administración de varios clústeres, pero siempre se registra una cierta complejidad adicional de administración con más clústeres.

Aislamiento

En este contexto, el aislamiento se refiere a la separación del plano de control o del plano de datos, lo que se puede 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. El aislamiento suele surgir cuando se considera lo siguiente:

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

  • División de la carga de trabajo en niveles
    A menudo, las organizaciones que tienen muchas aplicaciones complejas dividen sus servicios en niveles y eligen ejecutar sus servicios más críticos en clústeres separados de aquellos menos críticos. En un entorno como este, estos servicios más críticos y sus clústeres se tratan con una consideración especial en torno al acceso, la seguridad, las actualizaciones, la política y mucho más. Un ejemplo de esta división en niveles es separar los servicios sin estado y con estado y colocarlos en clústeres separados.

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

  • Actualizaciones
    Cuando las organizaciones están preocupadas por posibles problemas con la actualización in situ (es decir, la falla en la automatización de una actualización, la falta confiabilidad de una aplicación o la capacidad de revertir), pueden optar por implementar una copia de sus servicios en un clúster nuevo. La actualización de esta manera requiere planificación o automatización para hacerlo posible, y asegurarse de abordar la administración del tráfico y la replicación de estado durante el proceso de actualización.

  • Seguridad o separación reglamentaria
    Las organizaciones pueden optar por aislar los servicios por varios motivos, como mantener las cargas de trabajo sujetas a requisitos regulatorios distintos de los menos sensibles o ejecutar servicios de terceros (menos confiables) en una infraestructura separada de servicios (clústeres) de origen (confiables)

  • Separación de usuarios
    La separación de usuarios en varios clústeres a menudo se realiza por diversos motivos, incluidos el aislamiento de seguridad, el aislamiento de rendimiento, la contabilidad de costos o incluso la propiedad.

Ubicación

  • Latencia
    Ciertos servicios tienen requisitos de latencia que deben cumplirse mediante la colocación física de esa carga de trabajo en una ubicación específica (o geografía). Esta necesidad puede ocurrir si los servicios ascendentes o los usuarios finales son sensibles a la latencia, pero también pueden ocurrir con facilidad 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 datos y otros requisitos de procesamiento jurisdiccional pueden requerir que el procesamiento y el almacenamiento residan dentro de una región específica, lo que requiere que la infraestructura se implemente en varios centros de datos o proveedores de servicios en la nube.

  • Gravedad de datos
    Un gran conjunto de datos o ciertas instancias de bases de datos pueden ser difíciles o imposibles de consolidar en un solo proveedor de nube o una sola región, e incluso puede ser desaconsejable hacerlo. Según los requisitos de procesamiento y entrega, puede que una aplicación necesite implementarse cerca de sus datos.

  • Infraestructura o servicios heredados
    Como los datos pueden ser difíciles de mover a la nube, cierta infraestructura heredada también es difícil de mover. Aunque estos servicios heredados no son móviles, la implementación de clústeres adicionales para el desarrollo de servicios nuevos permite a las organizaciones aumentar la velocidad de desarrollo.

  • Elección del desarrollador
    Las organizaciones suelen beneficiarse de poder proporcionar opciones para los desarrolladores en los servicios administrados por la nube que consumen. Por lo general, la elección permite que los equipos se muevan más rápido con las herramientas más adecuadas para sus necesidades a expensas de la administración de recursos adicionales asignados en 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 5000 nodos, estos límites rara vez se convierten en un motivo para operar varios clústeres. Antes de que un clúster alcance los límites de escalabilidad, las organizaciones suelen decidir distribuir 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.