토폴로지 도메인을 설정하려면 고급 클러스터를 사용 설정해야 합니다.
고급 클러스터 미리보기에는 다음과 같은 제한사항이 있습니다.
새 1.31 클러스터의 경우 클러스터 생성 시에만 고급 클러스터를 사용 설정할 수 있습니다.
고급 클러스터를 사용 설정한 후에는 클러스터를 1.32로 업그레이드할 수 없습니다. 테스트 환경에서만 고급 클러스터를 사용 설정하세요.
이 페이지는 회사 전략에 따라 IT 솔루션과 시스템 아키텍처를 정의하고, 사용자 권한과 관련된 정책을 만들고 관리하는 관리자 및 설계자를 대상으로 합니다. Google Cloud 콘텐츠에서 참조하는 일반적인 역할 및 예시 태스크에 대해 자세히 알아보려면 일반 GKE 사용자 역할 및 태스크를 참고하세요.
개요
토폴로지 도메인은 캠퍼스나 데이터 센터와 같은 동일한 논리적 또는 물리적 그룹에 속하는 것으로 간주되는 클러스터 노드 그룹입니다. 토폴로지 도메인은 상관관계가 있는 장애가 발생할 가능성이 있는 기본 하드웨어 또는 소프트웨어에 상응해야 합니다. 예를 들면 다음과 같습니다.
서로 다른 vCenter 서버와 같은 소프트웨어 오류
랙, 전원, 건물 등이 다른 하드웨어 장애
VMware용 Google Distributed Cloud (소프트웨어 전용)에서 클러스터를 만들 때 토폴로지 도메인을 설정하는 과정에서 토폴로지 라벨을 정의합니다.
클러스터 생성 후 토폴로지 라벨은 토폴로지 도메인의 노드 라벨에 채워집니다.
Kubernetes 클러스터 수준 기본 제약 조건 "topology.kubernetes.io/zone"를 토폴로지 라벨의 키로 사용합니다. 자세한 내용은 기본 제공 기본 제약 조건을 참고하세요.
토폴로지 라벨 키를 사용하여 배포, StatefulSet 또는 ReplicaSet에서 PodTemplate를 구성합니다. 포드 사양에서 토폴로지 라벨의 키를 topologySpreadConstraints.topologyKey 필드의 값으로 사용합니다. 이 키를 사용하면 Kubernetes 스케줄러가 토폴로지 도메인에 포드를 분산하여 고가용성을 보장하고 장애 발생 시 단일 영역에 과도하게 집중되는 것을 방지할 수 있습니다. Pod 사양에서 topologySpreadConstraints를 구성하는 방법에 대한 자세한 내용은 Kubernetes 문서의 Pod 토폴로지 분산 제약 조건을 참고하세요.
[[["이해하기 쉬움","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-07-31(UTC)"],[],[],null,["| **Preview**\n|\n|\n| This feature is subject to the \"Pre-GA Offerings Terms\" in the General Service Terms section\n| of the [Service Specific Terms](/terms/service-terms#1).\n|\n| Pre-GA features are available \"as is\" and might have limited support.\n|\n| For more information, see the\n| [launch stage descriptions](/products#product-launch-stages).\n\nThis page provides an overview of topology domains and guidelines for setting\nthem up.\n\nSetting up a topology domain requires that you enable\n[advanced cluster](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/admin-cluster-configuration-file-latest#enable-advanced-cluster-field).\nNote the following limitations with the advanced cluster preview:\n\n- You can enable advanced cluster at cluster creation time for new 1.31 clusters only.\n- After advanced cluster is enabled, you won't be able to upgrade the cluster to 1.32. Only enable advanced cluster in a test environment.\n\nThis page is for Admins and architects who define IT solutions and system\narchitecture in accordance with company strategy, and create and manage policies\nrelated to user permissions. To learn more about common roles and example tasks\nthat we reference in Google Cloud content, see\n[Common GKE user roles and tasks](/kubernetes-engine/enterprise/docs/concepts/roles-tasks).\n\nOverview\n\nA *topology domain* is a group of cluster nodes that are considered to be part\nof the same logical or physical grouping such as a campus or data center. A\ntopology domain should correspond to some underlying hardware or software\nthat has some possibility of correlated failure. For example:\n\n- Software failure such as different vCenter Servers\n- Hardware failure such as different racks, different power sources, and different buildings\n\nIn Google Distributed Cloud (software only) for VMware, as part of setting up a topology\ndomain when you create a cluster, you define a [topology\nlabel](/kubernetes-engine/distributed-cloud/vmware/docs/reference/vsphere-infrastructure-configuration-file#topology-domains-topology-labels).\nAfter cluster creation, the topology label is populated to labels of nodes in\nthe topology domain.\n\nTo make use of a topology domain, you have the following options:\n\n- Version 1.32 and higher: Configure cluster-level default topology spread\n constraints. For details, see\n [`schedulerConfiguration`](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/user-cluster-configuration-file-latest#scheduler-configuration-section).\n\n- Use the Kubernetes cluster-level default constraint,\n `\"topology.kubernetes.io/zone\"`, as the key in the topology label. For more\n information, see\n [Built-in default constraints](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/#internal-default-constraints).\n\n- Configure the `PodTemplate` in your Deployment, StatefulSet, or ReplicaSet,\n as applicable with the topology label key. In the Pod spec, you use the key\n in the topology label as the value for the\n `topologySpreadConstraints.topologyKey` field. This key lets the Kubernetes\n scheduler distribute Pods across the topology domain to ensure high\n availability and prevent over-concentration in any single area in case of\n failure. For more information on configuring `topologySpreadConstraints` in\n your Pod spec, see\n [Pod Topology Spread Constraints](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/)\n in the Kubernetes documentation.\n\nExample topology domain labels\n\nSuppose you create the following three topology domains when\n[creating a user cluster](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/create-user-cluster-topology-domains#fill_in_your_vsphere_infrastructure_configuration_file): \n\n ...\n topologyDomains:\n - name: \"topology-domain-1\"\n topologyLabels:\n \"topology.examplepetstore.com/zone\": \"zone-1\"\n ...\n\n ...\n topologyDomains:\n - name: \"topology-domain-2\"\n topologyLabels:\n \"topology.examplepetstore.com/zone\": \"zone-2\"\n ...\n\n ...\n topologyDomains:\n - name: \"topology-domain-3\"\n topologyLabels:\n \"topology.examplepetstore.com/zone\": \"zone-3\"\n ...\n\nAfter the cluster is created, you update the Pod spec, for example: \n\n ...\n topologySpreadConstraints:\n topologyKey: \"topology.examplepetstore.com/zone\"\n ...\n\nAt a high level, the Kubernetes scheduler uses\n`topology.examplepetstore.com/zone` to separate the cluster nodes into\ndifferent groups, `zone-1`, `zone-2`, and `zone-3`. Then the scheduler spreads\nthe Pods across these three node groups.\n\nGuidelines for Topology Domains Setup\n\nTo ensure effective use of all clusters resources by the Kubernetes scheduler,\nwe recommend the following guidelines:\n\n\u003cbr /\u003e\n\n- The topology domains need to be balanced. You should provide nearly equal amounts of CPU and RAM capacity in each topology domain.\n- Provide at least two and preferably three topology domains.\n- Don't spread by more than one topology key.\n- The nodes should have a similar size in each topology domain.\n- If you use [taints and tolerations](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/node-taints) for workload separation within a cluster, then each node group should meet the previous requirements.\n\nIf these guidelines aren't met, then the scheduler will still try to use the\nfull capacity of the cluster, but it might take longer to schedule Pods, and not\nall Pods will get the expected spreading behavior.\n\nWhat's next\n\n- [Create an admin cluster for use in topology domains](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/create-admin-cluster-topology-domains)\n- [Create a user cluster for use in topology domains](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/create-user-cluster-topology-domains)\n- [vSphere infrastructure configuration file](/kubernetes-engine/distributed-cloud/vmware/docs/reference/vsphere-infrastructure-configuration-file)"]]
