Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
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 Google Cloud
componentes y las funciones 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.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-07-31 (UTC)"],[],[],null,["While it is generally a best practice to use as few clusters as possible,\norganizations choose to deploy multiple clusters to achieve their technical and\nbusiness objectives for a variety of reasons. At a minimum, most organizations\nseparate their non-production from their production services by placing them in\ndifferent clusters. In more complex scenarios, organizations might choose\nmultiple clusters to separate services across tiers, locales, teams, or\ninfrastructure providers.\n\nMost reasons for adopting multiple clusters fall into three categories\nof requirements:\n\n- **Isolation:** separating the control plane and data plane of services, primarily to improve reliability or address security needs\n- **Location:** placing services in specific locations to address availability, latency, and locality needs\n- **Scale:** especially in the context of Kubernetes clusters, scaling services beyond the practical limits imposed by a single cluster\n\nWe look at these in more detail in the following sections.\n\nIn many cases, organizations need to balance several of these requirements\nsimultaneously. As you think about your own organization, remember that our\ngeneral recommendation is to use as few clusters as possible. Determine which\nof the multi-cluster needs are the highest priority for your organization and\ncannot be compromised, and then make appropriate tradeoffs to create a\nmulti-cluster architecture.\n\nIf you find your organization considering a *cluster per service-model* or a\n*cluster-per-team* mode, you might want to consider the management burden\nimposed on the operators of such a system.\n[Fleets](/kubernetes-engine/fleet-management/docs/fleet-concepts) and the Google Cloud\n[components and features that support them](/kubernetes-engine/fleet-management/docs)\nstrive to make managing multiple clusters as easy as possible, but there is\nalways some additional management complexity with more clusters.\n\nIsolation\n\nIn this context, *isolation* refers to separation of the control plane and/or\ndata plane, both of which can be achieved by running multiple clusters. However,\ndepending on implementation, this separation likely also extends to data plane\nisolation. Isolation usually comes up when considering the following:\n\n- **Environment** \n\n More often than not, organizations run their development, staging/test, and production\n services across separate clusters, often running on different networks and cloud\n projects. This separation is done to avoid accidental disruption of production\n services and prevent access to sensitive data during development or testing.\n\n- **Workload tiering** \n\n Often organizations that have many complex applications tier their\n services, choosing to run their more critical services on separate clusters from\n their less critical ones. In such an environment, these more critical services\n and their clusters are treated with special consideration around access,\n security, upgrades, policy, and more. An example of this tiering is separating\n *stateless* and *stateful* services by placing them on separate clusters.\n\n- **Reduced impact from failure** \n\n When organizations want to limit the impacts of an operator mistake, cluster\n failure, or related infrastructure failure, they can split their services\n across multiple clusters.\n\n- **Upgrades** \n\n When organizations are concerned about potential issues with upgrading in-place\n (that is, upgrading automation failure, application flakiness, or the ability to\n roll back), they can choose to deploy a copy of their services in a new cluster.\n Upgrading in this fashion requires planning or automation to make it possible,\n being sure to address traffic management and state replication during the\n upgrade process.\n\n- **Security/regulatory separation** \n\n Organizations can choose to isolate services for many reasons, including keeping\n workloads subject to regulatory requirements separate from less-sensitive ones,\n or running third-party (less-trusted) services on separate infrastructure from\n first-party (trusted) services (clusters).\n\n- **Tenant separation** \n\n Separating tenants into multiple clusters is often done for a variety of reasons,\n including security isolation, performance isolation, cost accounting, and\n even ownership.\n\nLocation\n\n- **Latency** \n\n Certain services have latency requirements that must be met by physically\n locating that workload in a specific location (or geography). This need can\n occur if upstream services or end-users are sensitive to latency, but can also\n easily occur if the workload itself is sensitive to downstream service latency.\n\n- **Availability** \n\n Running the same service across multiple availability zones in a single-cloud\n provider (or across multiple providers) can provide higher overall availability.\n\n- **Jurisdiction** \n\n Data residency and other jurisdictional processing requirements can require\n compute and storage to live within a specific region, requiring infrastructure\n to be deployed in multiple data centers or cloud providers.\n\n- **Data gravity** \n\n A large corpus of data, or even certain database instances, can be difficult,\n impossible, or even inadvisable to consolidate in a single cloud provider or\n region. Depending on the processing and serving requirements, an application\n might need to be deployed close to its data.\n\n- **Legacy infrastructure/services** \n\n Just as data can be difficult to move to the cloud, some legacy infrastructure\n is similarly difficult to move. Although these legacy services are immobile, deploying additional clusters for the development of new services allows organizations to increase development velocity.\n\n- **Developer choice** \n\n Organizations often benefit from being able to provide developers choice in\n the cloud-managed services that they consume. Generally, choice lets teams move\n more quickly with tools that are best-suited to their needs at the expense of\n needing to manage additional resources allocated in each provider.\n\n- **Local/edge compute needs** \n\n Finally, as organizations want to adopt application modernization practices in\n more traditional work environments, like warehouses, factory floors, retail\n stores, and so on, this necessitates managing many more workloads on many more\n pieces of infrastructure.\n\nScale\n\nBecause GKE can scale clusters to more than\n[5000 nodes](/kubernetes-engine/docs/concepts/planning-large-workloads#above-5000),\nthese limits rarely become a reason to operate multiple clusters. Before a\ncluster reaches scalability limits, organizations often decide to distribute\nservices across multiple clusters. For clusters that do reach scalability\nlimits, running an application across multiple clusters can ease some\nchallenges, but with the added complexity of managing multiple clusters."]]
