클러스터 노드 머신, 네트워크, 기타 기본 요건의 설정을 완료했다면 Google Distributed Cloud를 설치할 준비가 되었습니다. 다음 단계에서는 만들 클러스터의 종류를 결정하고 사용할 도구를 선택하게 됩니다.
클러스터 유형 선택
Google Distributed Cloud에서 관리자 클러스터(클러스터의 리소스 제어용)와 사용자 클러스터(워크로드 실행용)를 포함한 다양한 종류의 클러스터를 만들 수 있습니다. 중앙 집중화된 위치에서 관리하려는 동일한 데이터 센터에 여러 클러스터가 있는 경우 및 다른 팀 간 또는 개발 및 프로덕션 워크로드 간에 격리가 필요한 대규모 배포의 경우 관리자 및 사용자 클러스터 배포를 사용하는 것이 좋습니다.
또한 Google Distributed Cloud를 단일 독립형 클러스터로 실행하여 사용자 클러스터 및 관리자 클러스터로 작동할 수 있습니다. 독립형 클러스터는 시스템 리소스 요구사항을 크게 줄여주는 에지 프로필을 지원하며 리소스 제약조건이 높은 에지 기기에 권장됩니다.
Google Distributed Cloud를 사용하면 관리 작업과 워크로드를 결합한 하이브리드 클러스터를 만들 수 있을 뿐 아니라 다른 사용자 클러스터를 제어할 수도 있습니다.
각 구성마다 이점이 있습니다. 개발할 구성을 결정하는 방법에 대한 자세한 내용은 배포 모델 선택을 참조하세요.
클러스터를 만들 도구 선택
클러스터를 만들고 클러스터 수명 주기를 관리하기 위한 도구를 선택할 수 있습니다.
bmctl: 온프레미스 데이터 센터의 관리자 워크스테이션에서 실행하는 명령줄 도구
Google Cloud 콘솔, Google Cloud CLI 또는 Terraform: 이들 표준 도구는 Google Cloud인프라에서 실행되는 GKE On-Prem API를 사용하며 통칭하여 GKE On-Prem API 클라이언트라고 합니다.
요구사항에 가장 적합한 도구를 결정하는 방법에 대한 자세한 내용은 클러스터를 만들 도구 선택을 참조하세요.
클러스터 생성 프로세스에는 실행 전 검사 및 머신 초기화가 포함됩니다. 머신 초기화 단계 후 클러스터 생성이 실패하면(실행 전 검사를 오류 없이 통과한 경우라도) 클러스터를 삭제해야 합니다. 이렇게 하면 노드가 초기 상태로 돌아갑니다. 클러스터를 삭제한 후에는 필요한 구성을 변경한 후에 다시 클러스터 생성을 시도할 수 있습니다.
클러스터 생성 프로세스는 클러스터가 생성될 때 상태 점검을 실행합니다. 이 마지막 단계를 통해 클러스터가 정상 작동 상태인지 확인합니다. 클러스터가 모든 상태 점검을 통과하지 못하면 만들기 작업이 실패합니다. 모든 상태 점검을 통과하면 만들기 작업이 성공적으로 완료됩니다.
확장성 계획
새 클러스터를 만들기 전에 확장성에 영향을 미치는 측정기준을 이해해야 합니다. 클러스터의 포드에 예약할 수 있는 IP 주소 수(clusterNetwork.pods.cidrBlocks)와 같은 일부 측정기준은 변경할 수 없으므로 클러스터를 만들 때 이러한 측정기준을 계획해야 합니다. 확장성 측정기준 및 클러스터 수직 확장 방법에 대한 자세한 내용은 Google Distributed Cloud 클러스터 확장을 참조하세요. 클러스터의 최대 설정에 대한 일부 제한사항과 권장사항은 할당량 및 한도를 참조하세요.
[[["이해하기 쉬움","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-01(UTC)"],[],[],null,["When you have finished setting up cluster node machines,\n[your network](/kubernetes-engine/distributed-cloud/bare-metal/docs/how-to/plan-ip-addresses), and\nthe other [prerequisites](/kubernetes-engine/distributed-cloud/bare-metal/docs/installing/install-prereq), you're\nalmost ready to install Google Distributed Cloud. The next step is to decide what\nkinds of clusters to create and choose which tool to use.\n\nChoose a cluster type\n\nYou can create different kinds of clusters in Google Distributed Cloud, including\n**admin** clusters (to control the resources of your clusters) and **user**\nclusters (to run workloads). We recommend admin and user cluster deployments\nif you have multiple clusters in the same data center that you want to manage\nfrom a centralized place, and for larger deployments that need isolation between\ndifferent teams or between development and production workloads.\n\nYou can also run Google Distributed Cloud as a single **standalone** cluster,\nwhich serves as a user cluster and as an admin cluster. A standalone cluster\nsupports the edge profile, which has significantly reduced system resource\nrequirements and is recommended for edge devices with high resource constraints.\nIn addition, Google Distributed Cloud lets you create **hybrid** clusters that\ncombine administration tasks and workloads, as well as controlling other user\nclusters.\n\nEach of these configurations has their own advantages and benefits. For more\ninformation on deciding which configuration to develop, see\n[Choose a deployment model](/kubernetes-engine/distributed-cloud/bare-metal/docs/installing/install-prep).\n\nChoose a tool to create clusters\n\nYou have your choice of tools for creating clusters and managing\ncluster lifecycle:\n\n- The command-line tool `bmctl`, which you run on your admin workstation in your on-premises data center.\n- The Google Cloud console, Google Cloud CLI, or [Terraform](https://www.terraform.io/). These standard tools use the GKE On-Prem API, which runs on Google Cloud infrastructure, and collectively they are referred to as the *GKE On-Prem API clients*.\n\nFor information on deciding which tool best suits your needs, see\n[Choose a tool to create clusters](/kubernetes-engine/distributed-cloud/bare-metal/docs/installing/cluster-lifecycle-management-tools).\n\nMore information\n\nFor more information on creating and configuring clusters, see the\nfollowing:\n\n- Admin clusters:\n\n - [Create admin clusters using GKE On-Prem API clients](/kubernetes-engine/distributed-cloud/bare-metal/docs/installing/creating-clusters/create-admin-cluster-api)\n - [Create admin clusters using `bmctl`](/kubernetes-engine/distributed-cloud/bare-metal/docs/installing/creating-clusters/admin-cluster-creation)\n- User clusters\n\n - [Create user clusters using GKE On-Prem API clients](/kubernetes-engine/distributed-cloud/bare-metal/docs/installing/creating-clusters/create-user-cluster-api)\n - [Create user clusters using `bmctl`](/kubernetes-engine/distributed-cloud/bare-metal/docs/installing/creating-clusters/user-cluster-creation)\n- [Create standalone clusters](/kubernetes-engine/distributed-cloud/bare-metal/docs/installing/creating-clusters/standalone-cluster-creation)\n\n- [Create hybrid clusters](/kubernetes-engine/distributed-cloud/bare-metal/docs/installing/creating-clusters/hybrid-cluster-creation)\n\nAbout the creation process\n\nThe cluster creation process includes preflight checks and machine\ninitialization. If cluster creation fails after the machine initialization phase\n(even if preflight checks passed without errors), you must\n[delete the cluster](/kubernetes-engine/distributed-cloud/bare-metal/docs/how-to/reset-nodes). This returns the node to\na clean state. After deleting the cluster, you can re-attempt to create the\ncluster after making any needed configuration changes.\n\nThe cluster creation process runs health checks when the cluster has been\ncreated. This last step verifies that the cluster is in good operating\ncondition. If the cluster doesn't pass all health checks, the create operation\nfails. When all health checks pass, the create operation finishes successfully.\n\nPlan for scalability\n\nBefore you create a new cluster, you need to understand the dimensions that\naffect scalability. Some dimensions, such as the number of IP addresses that you\ncan reserve for Pods in your cluster (`clusterNetwork.pods.cidrBlocks`), are\nimmutable, so you need to plan for them when you create a cluster. For more\ninformation about scalability dimensions and how to scale up a cluster, see\n[Scale up Google Distributed Cloud\nclusters](/kubernetes-engine/distributed-cloud/bare-metal/docs/how-to/scale). For information about some of the\nrestrictions and recommendations for maximum settings for your cluster, see\n[Quotas and limits](/kubernetes-engine/distributed-cloud/bare-metal/docs/limits)."]]