Aunque, por lo general, es recomendable usar el menor número de clústeres posible, las organizaciones deciden implementar varios clústeres para alcanzar sus objetivos técnicos y empresariales por diversos motivos. Como mínimo, la mayoría de las organizaciones separan sus servicios de no producción de sus servicios de producción colocándolos en clústeres diferentes. En situaciones más complejas, las organizaciones pueden elegir varios clústeres para separar los servicios en distintos 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 fiabilidad o abordar las necesidades de seguridad.
- Ubicación: colocar servicios en ubicaciones específicas para abordar las necesidades de disponibilidad, latencia y localidad.
- Escala: sobre todo en el contexto de los clústeres de Kubernetes, los servicios de escalado superan los límites prácticos impuestos por un solo clúster.
En las siguientes secciones, analizaremos estos elementos con más detalle.
En muchos casos, las organizaciones deben equilibrar varios de estos requisitos simultáneamente. Cuando pienses en tu organización, recuerda que nuestra recomendación general es usar el menor número posible de clústeres. Determina cuáles de las necesidades de varios clústeres son las más importantes para tu organización y no se pueden poner en riesgo. Después, haz las concesiones adecuadas para crear una arquitectura de varios clústeres.
Si tu organización está pensando en usar un clúster por modelo de servicio o un clúster por equipo, te recomendamos que tengas en cuenta la carga de gestión que supondría para los operadores de ese sistema. Las flotas y los Google Cloud componentes y características que las respaldan simplifican todo lo posible la gestión de varios clústeres, pero siempre hay una complejidad de gestión adicional cuando se trata de más clústeres.
Aislamiento
En este contexto, el término aislamiento hace referencia a la separación del plano de control o del plano de datos, que se puede conseguir ejecutando varios clústeres. Sin embargo, en función de la implementación, es probable que esta separación también se extienda al aislamiento del plano de datos. El aislamiento suele surgir al plantearse lo siguiente:
Entorno
En la mayoría de los casos, las organizaciones ejecutan sus servicios de desarrollo, staging/prueba y producción en clústeres independientes, que suelen estar en redes y proyectos de nube diferentes. Esta separación se lleva a cabo para evitar interrupciones accidentales de los servicios de producción y para impedir 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 clasifican sus servicios por niveles y eligen ejecutar sus servicios más críticos en clústeres independientes de los menos críticos. En este entorno, estos servicios más críticos y sus clústeres reciben una atención especial en cuanto al acceso, la seguridad, las actualizaciones, las políticas y otros aspectos. Un ejemplo de esta estratificación es la separación de los servicios sin estado y con estado colocándolos en clústeres independientes.Impacto reducido en caso de fallo:
cuando las organizaciones quieren limitar el impacto de un error del operador, un fallo del clúster o un fallo de la infraestructura relacionada, pueden dividir sus servicios en varios clústeres.Actualizaciones
Si las organizaciones tienen dudas sobre posibles problemas al actualizar en el mismo sitio (es decir, fallos en la automatización de la actualización, inestabilidad de la aplicación o imposibilidad de revertir), pueden optar por implementar una copia de sus servicios en un nuevo clúster. Para actualizar de esta forma, es necesario planificar o automatizar el proceso, así como gestionar el tráfico y replicar el estado durante el proceso de actualización.Separación de seguridad o normativa:
las organizaciones pueden aislar servicios por muchos motivos, como mantener las cargas de trabajo sujetas a requisitos normativos separadas de las menos sensibles o ejecutar servicios de terceros (menos fiables) en una infraestructura independiente de los servicios (clústeres) propios (fiables).Separación de los inquilinos
La separación de los inquilinos en varios clústeres suele hacerse por varios motivos, como el aislamiento de seguridad, el aislamiento del rendimiento, la contabilidad de costes e incluso la propiedad.
Ubicación
Latencia
Algunos servicios tienen requisitos de latencia que se deben cumplir ubicando físicamente esa carga de trabajo en una ubicación (o zona geográfica) específica. Esta necesidad puede surgir si los servicios o los usuarios finales upstream son sensibles a la latencia, pero también puede ocurrir fácilmente si la propia carga de trabajo es sensible a la latencia del servicio downstream.Disponibilidad
Ejecutar el mismo servicio en varias zonas de disponibilidad de un solo proveedor de servicios en la nube (o en varios proveedores) puede proporcionar una mayor disponibilidad general.Jurisdicción
Los requisitos de residencia de los datos y otros requisitos de tratamiento jurisdiccionales pueden exigir que los recursos de computación y almacenamiento se encuentren en 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 los datos
Puede ser difícil, imposible o incluso desaconsejable consolidar un gran corpus de datos o determinadas instancias de bases de datos en un único proveedor o región de la nube. En función de los requisitos de procesamiento y servicio, es posible que una aplicación deba implementarse cerca de sus datos.Infraestructura o servicios antiguos
Al igual que los datos, la infraestructura antigua puede ser difícil de migrar a la nube. Aunque estos servicios antiguos no se pueden mover, desplegar clústeres adicionales para desarrollar nuevos servicios permite a las organizaciones aumentar la velocidad de desarrollo.Elección del desarrollador
Las organizaciones suelen beneficiarse de poder ofrecer a los desarrolladores la posibilidad de elegir los servicios gestionados en la nube que consumen. Por lo general, la opción de elegir permite a los equipos avanzar más rápido con las herramientas que mejor se adaptan a sus necesidades, pero a cambio de tener que gestionar recursos adicionales asignados a cada proveedor.Necesidades de computación local o en el perímetro
Por último, a medida que las organizaciones quieren adoptar prácticas de modernización de aplicaciones en entornos de trabajo más tradicionales, como almacenes, fábricas, tiendas, etc., se hace necesario gestionar muchas más cargas de trabajo en muchos más elementos de infraestructura.
Escalar
Como GKE puede escalar clústeres a más de 5000 nodos, estos límites rara vez son un motivo para operar varios clústeres. Antes de que un clúster alcance los límites de escalabilidad, las organizaciones suelen distribuir los servicios en varios clústeres. En el caso de los clústeres que alcanzan los límites de escalabilidad, ejecutar una aplicación en varios clústeres puede aliviar algunos problemas, pero conlleva la complejidad añadida de gestionar varios clústeres.