이 페이지에서는 GKE 멀티 클러스터 서비스(MCS)의 작동 방법에 대한 개요를 제공합니다. MCS 사용 방법을 알아보려면 멀티 클러스터 서비스 구성을 참조하세요.
MCS 개요
Kubernetes의 익숙한 서비스 객체를 사용하면 단일 Kubernetes 클러스터의 범위 내에서 서비스를 검색하고 액세스할 수 있습니다. 하지만 일부 경우에는 상태 관리, 개인정보 보호, 확장성, 가용성, 데이터 주권 요구사항을 해결하기 위해 애플리케이션을 여러 클러스터로 분할해야 할 수 있습니다. MCS를 사용하면 여러 클러스터에 걸쳐진 Kubernetes 애플리케이션을 빌드할 수 있습니다.
MCS는 기존 서비스 객체를 활용하는 Google Kubernetes Engine(GKE)을 위한 클러스터 간 서비스 검색 및 호출 메커니즘입니다. 이 기능이 사용 설정된 서비스는 가상 IP를 사용하여 클러스터 간에 검색 및 액세스할 수 있으며, 클러스터에서 액세스할 수 있는 ClusterIP 서비스의 동작과 일치합니다. 기존 서비스와 마찬가지로, MCS는 커뮤니티 기반 및 개방형 API와 호환되기 때문에 워크로드를 포팅할 수도 있습니다.
MCS는 GKE의 기능입니다. MCS는 Fleet 클러스터에서 내보낸 각 서비스의 Cloud DNS 영역과 레코드를 구성합니다. Fleet을 사용하면 GKE 클러스터를 논리적으로 그룹화 및 정규화하여 인프라 관리를 쉽게 수행하고 MCS와 같은 멀티 클러스터 기능 사용을 지원할 수 있습니다. Fleet 관리 문서에서 Fleet의 이점과 만드는 방법에 대해 자세히 알아보세요.
내보낸 서비스에는 유형에 관계없이 항상 Cloud DNS 레코드가 하나씩 있으며, 내보낸 헤드리스 유형 서비스에는 StatefulSet의 포드를 포함하여 호스트 이름이 있는 각 백엔드 포드에 대한 레코드가 있습니다.
Cloud DNS를 사용하면 추가 요금이 발생합니다. Cloud DNS 가격 책정에 따라 요금이 청구됩니다.
MCS를 사용하여 서비스를 내보내려면 서비스와 동일한 네임스페이스와 이름을 사용하여 ServiceExport 커스텀 리소스를 만드세요. MCS는 Fleet의 각 클러스터에 서비스를 자동으로 가져옵니다. MCS에서 서비스를 가져오면 다음이 생성됩니다.
서비스와 동일한 네임스페이스 및 이름을 사용하는 ServiceImport 커스텀 리소스
서비스와 동일한 네임스페이스를 사용하는 Endpoints 객체와 무작위 이름
MCS 사용 이점
MCS를 사용하면 다음 이점이 있습니다.
고가용성: 여러 리전의 클러스터 간에 동일한 서비스를 실행함으로써 내결함성이 향상됩니다. 한 클러스터의 서비스를 사용할 수 없게 되면 다른 클러스터로 요청을 장애조치하고 처리할 수 있습니다. MCS를 사용하면 각 클러스터의 서비스 간 통신을 관리하고, 컨테이너화된 애플리케이션의 가용성을 향상시킬 수 있습니다.
스테이트풀(Stateful) 및 스테이트리스(Stateless) 서비스: 스테이트풀(Stateful) 및 스테이트리스(Stateless) 서비스는 운영 종속성 및 복잡성이 서로 다르며, 운영상의 장단점도 서로 다릅니다. 일반적으로 상태 관리가 없으면 워크로드 확장, 업그레이드, 마이그레이션이 더 쉽고 가용성도 더 높습니다. MCS는 스테이트풀(Stateful) 및 스테이트리스(Stateless) 워크로드에 대해 클러스터를 구분하고 이를 서로 독립적이고 격리된 상태로 유지해서 쉽게 관리할 수 있게 해줍니다.
공유 서비스: 더 높은 가용성을 얻고, 스테이트풀(Stateful) 및 스테이트리스(Stateless) 서비스를 효과적으로 관리하고, 데이터 주권 요구사항을 더 쉽게 준수하기 위해서는 Kubernetes 클러스터를 개별적으로 만드는 것이 일반적입니다. 하지만 Prometheus를 사용한 모니터링 또는 저장소에 보안 비밀 관리 사용과 같은 많은 서비스가 모든 클러스터간에 자주 공유됩니다. 고유 로컬 서비스 복제본을 요구하는 각 클러스터 대신 MCS는 모든 작동하는 클러스터에 사용되는 공통 공유 서비스를 개별 클러스터에 쉽게 설정할 수 있게 해줍니다.
마이그레이션: 기존 애플리케이션을 컨테이너화된 마이크로서비스 기반의 아키텍처로 현대화하기 위해서는 여러 Kubernetes 클러스터 간에 서비스를 배포해야 하는 경우가 많습니다. MCS는 이러한 서비스 간의 통신을 연결하는 데 도움이 되는 메커니즘을 제공하여, 애플리케이션을 쉽게 마이그레이션할 수 있게 해줍니다. 이 방법은 동일한 서비스를 서로 다른 두 개의 클러스터에 배포할 수 있고 한 클러스터 또는 애플리케이션에서 다른 클러스터 또는 애플리케이션으로 트래픽을 전환할 수 있기 때문에 특히 유용합니다.
다음 단계
북-남 및 동-서 트래픽 방향에 대한 서비스를 제공하는 멀티 클러스터 인그레스 자세히 알아보기
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[],[],null,["# Multi-cluster Services\n\n[Autopilot](/kubernetes-engine/docs/concepts/autopilot-overview) [Standard](/kubernetes-engine/docs/concepts/choose-cluster-mode)\n\n*** ** * ** ***\n\nThis page provides you with an overview of how GKE multi-cluster\nServices (MCS) works. To learn how to use MCS, see\n[Configuring multi-cluster Services](/kubernetes-engine/docs/how-to/multi-cluster-services).\n\nOverview of MCS\n---------------\n\nKubernetes' familiar [Service](/kubernetes-engine/docs/concepts/service)\nobject lets you discover and access a Service within the\nconfines of a single Kubernetes cluster. However, sometimes you might want to\nsplit applications into multiple clusters, to address state management, privacy,\nscalability, availability, and data sovereignty requirements. With MCS, you can\nbuild Kubernetes applications that span multiple clusters.\n\nMCS is a cross-cluster Service discovery and invocation\nmechanism for Google Kubernetes Engine (GKE) that leverages the existing Service\nobject. Services enabled with this feature are discoverable and accessible\nacross clusters with a virtual IP, matching the behavior of a\n[ClusterIP Service](/kubernetes-engine/docs/concepts/service#services_of_type_clusterip)\naccessible in a cluster. Just like your existing Services, MCS is\ncompatible with community-driven and open APIs, ensuring your workloads remain\nportable.\n\nMCS is a feature of GKE. MCS configures Cloud DNS zones and\nrecords for each exported Service in your [fleet clusters](/kubernetes-engine/fleet-management/docs). A fleet lets you logically group and normalize your GKE clusters, making administration of infrastructure easier and enabling the use of multi-cluster features such as MCS. You can learn more about the benefits of fleets and how to create them in the [fleet management documentation](/kubernetes-engine/fleet-management/docs).\n\nExported Services regardless of type always have one Cloud DNS record, and exported Headless type services have records for each backend Pod with a hostname, including Pods in StatefulSets.\nUsing Cloud DNS incurs additional charges. You are billed according to\n[Cloud DNS pricing](https://cloud.google.com/dns/pricing).\n\nTo export a Service with MCS, create a ServiceExport custom resource using the same\nnamespace and name as the Service. MCS automatically imports the Service to each\ncluster in the fleet. When MCS imports a Service, it creates:\n\n- A ServiceImport custom resource using the same namespace and name as the Service.\n- An Endpoints object using the same namespace as the Service and a random name.\n\nBenefits of using MCS\n---------------------\n\nUsing MCS provides you with the following benefits:\n\n- **High availability**: Running the same Service across clusters in multiple regions provides you with improved fault tolerance. If a Service in a cluster is unavailable, the request can fail over and be served from other clusters. With MCS, it's possible to manage the communication between Services across clusters, to improve the availability of your containerized applications.\n- **Stateful and stateless Services**: Stateful and stateless Services have different operational dependencies and complexities and present different operational tradeoffs. Typically, the absence of state management makes it easier to scale, upgrade, and migrate a workload with higher availability. MCS lets you separate clusters for stateful and stateless workloads and make them independent, isolated, and easier to manage.\n- **Shared Services** : It's common to create separate Kubernetes clusters to get higher availability, better management of stateful and stateless Services, and easier compliance with data sovereignty requirements. However, many Services such as [monitoring with Prometheus](/stackdriver/docs/managed-prometheus) or [using secrets management with Vault](https://www.cloudskillsboost.google/focuses/1210?parent=catalog) are often shared among all clusters. Instead of each cluster requiring its own local Service replica, MCS makes it easier to set up common shared Services in a separate cluster that all functional clusters use.\n- **Migration**: Modernizing an existing application into a containerized microservice-based architecture often requires you to deploy Services across multiple Kubernetes clusters. MCS provides you with a mechanism to help bridge the communication between those Services, making it easier to migrate your applications. This is especially helpful as you can deploy the same Service to two different clusters and traffic is allowed to shift from one cluster or application to another.\n\nWhat's next\n-----------\n\n- Learn more about [Multi Cluster Ingress](/kubernetes-engine/docs/concepts/multi-cluster-ingress), which provides Services for north-south and east-west traffic directions.\n- Learn more about [Cloud Service Mesh](/anthos/service-mesh), which provides you with finer-grained control over routing and traffic shaping."]]
