이 페이지에서는 VMware용 Google Distributed Cloud(소프트웨어 전용)에 기존 컨테이너 레지스트리 서버를 구성하는 방법을 설명합니다.
이 페이지는 기술 인프라를 설정, 모니터링, 관리하는 관리자, 설계자, 운영자를 대상으로 합니다. Google Cloud 콘텐츠에서 참조하는 일반적인 역할 및 예시 태스크에 대해 자세히 알아보려면 일반 GKE 사용자 역할 및 태스크를 참조하세요.
개요
기본적으로 클러스터를 만들거나 업그레이드하는 중에 Google Distributed Cloud는 구성요소 액세스 서비스 계정을 사용하여 gcr.io/gke-on-prem-release에서 시스템 이미지를 가져옵니다.
원하는 경우 자체 컨테이너 레지스트리 서버를 제공하여 대신 비공개 레지스트리 서버에서 시스템 이미지를 가져오도록 할 수 있습니다.
Google Distributed Cloud는 안전하지 않은 컨테이너 레지스트리를 지원하지 않습니다. 컨테이너 레지스트리 서버를 시작할 때 인증서와 키를 제공해야 합니다. 인증서는 공개 인증 기관(CA)에서 서명하거나 자체 서명할 수 있습니다.
"ADDRESS": 비공개 레지스트리를 실행하는 머신의 IP 주소 또는 FQDN (정규화된 도메인 이름)입니다.
"CA_CERT": 비공개 레지스트리의 CA 인증서 공개 키입니다.
관리자 클러스터 만들기의 Terraform 탭에 있는 단계에 따라 Terraform 구성 파일과 계획을 확인한 다음 부트스트랩 클러스터를 만듭니다.
gkectl register bootstrap 명령어를 실행하면 gkectl에서 사용자 이름을 입력하라는 메시지가 표시된 후 비공개 레지스트리의 비밀번호를 입력하라는 메시지가 표시됩니다.
클러스터를 만드는 중에 비공개 레지스트리 서버에서 시스템 이미지를 가져옵니다.
고급 클러스터 및 전체 번들 제한사항
Google Distributed Cloud 번들은 전체 버전과 일반 버전 등 2가지 버전으로 제공됩니다. 관리자 워크스테이션에 있는 번들을 확인하려면 관리자 클러스터 구성 파일에서 bundlePath 필드를 확인합니다. 파일 이름이 -full로 끝나면 전체 번들이 관리자 워크스테이션에 있는 것입니다. 파일 이름이 -full로 끝나지 않으면 일반 번들이 관리자 워크스테이션에 있는 것입니다.
gkeadm 명령어를 사용하여 관리자 워크스테이션을 만든 경우 이 명령어는 전체 번들이 포함된 관리자 워크스테이션 VM을 만들고 관리자 클러스터 구성 파일에서 bundlePath 필드를 구성합니다.
고급 클러스터가 사용 설정된 경우 비공개 레지스트리에서 전체 번들을 사용하면 다음과 같은 제한사항이 적용됩니다.
버전 1.31: 비공개 레지스트리에서는 전체 번들이 지원되지 않습니다. 고급 클러스터에서 비공개 레지스트리를 사용하려면 다음 안내를 따르세요.
버전 1.32: 전체 번들을 사용할 수 있지만 gkectl prepare 명령어는 tar 파일 대신 gcr.io/gke-on-prem-release에서 이미지를 가져옵니다. 그러나 이 명령어는 클러스터를 만들거나 업그레이드하는 중에 비공개 레지스트리에서 시스템 이미지를 가져오도록 이미지를 비공개 레지스트리에 내보냅니다.
일반 클러스터와 고급 클러스터의 차이점
고급 클러스터는 표준 클러스터와 비교해 다음과 같은 몇 가지 주요 차이점이 있습니다.
비공개 레지스트리를 사용하면 이미지가 비공개 레지스트리의 호스트 이름이 아닌 gcr.io에서 가져오는 것으로 표시됩니다. 이미지는 실제로 비공개 레지스트리 서버에서 가져오지만 이 변경사항은 예상됩니다.
이미지 가져오기는 클러스터 내부의 private-registry-creds 보안 비밀이 아닌 비공개 레지스트리에 연결된 각 머신의 /etc/containerd/config.toml 파일에서 사용자 인증 정보를 사용합니다.
모든 gcr.io 이미지의 경우 클러스터는 먼저 비공개 레지스트리에서 가져오려고 시도합니다. 이미지가 비공개 레지스트리에 없으면 시스템은 인터넷을 통해 gcr.io에서 이미지를 가져옵니다. 이 대체를 중지하려면 noProxy을 설정하거나 방화벽 규칙을 사용하여 gcr.io 트래픽을 차단하세요.
[[["이해하기 쉬움","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,["This page explains how to configure an existing container registry server for\nGoogle Distributed Cloud (software only) for VMware.\n\nThis page is for Admins, Architects, and Operators who set\nup, monitor, and manage the tech infrastructure. To learn more about common\nroles and example tasks that we reference in Google Cloud content, see\n[Common GKE user roles and tasks](/kubernetes-engine/enterprise/docs/concepts/roles-tasks).\n\nOverview\n\nBy default during cluster creation or upgrade, Google Distributed Cloud pulls system\nimages from `gcr.io/gke-on-prem-release` using the\n[component access service account](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/service-accounts#component_access_service_account).\nOptionally, you can provide your own container registry server so that\nsystem images are pulled from your private registry server instead.\n\nGoogle Distributed Cloud doesn't support unsecured container registries. When you start\nyour container registry server, you must provide a certificate and a key. The\ncertificate can be signed by a public certificate authority (CA), or it can be\nself-signed.\n\nCreate a container registry server\n\nTo learn how to create a container registry server, see\n[Run an externally-accessible registry](https://docs.docker.com/registry/deploying/#run-an-externally-accessible-registry) in the Docker documentation.\n\nConfigure the registry\n\nTo use a private container registry, you can use either the `gkectl`\ncommand-line tool or Terraform. \n\n`gkectl`\n\nAdd the\n[`privateRegistry`](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/admin-cluster-configuration-file-latest#privateregistry-section)\nsection to the admin cluster configuration file before creating the cluster.\n\nWhen this section is filled in:\n\n- When you run the `gkectl prepare` command before cluster creation or upgrade,\n the command extracts the images from the tar file that is specified in the\n [`bundlePath`](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/admin-cluster-configuration-file-latest#bundlepath-field)\n field in your admin cluster configuration file and pushes the images to your\n private registry server.\n\n- During cluster creation or upgrade, the system images are pulled from your\n private registry server.\n\nTerraform\n\n1. Follow the steps in the Terraform tab in\n [Create an admin cluster](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/create-admin-cluster)\n to fill in your admin cluster configuration file.\n\n2. Add the following to the admin cluster configuration file:\n\n private_registry_config {\n address = \"\u003cvar translate=\"no\"\u003eADDRESS\u003c/var\u003e\"\n ca_cert = \"\u003cvar translate=\"no\"\u003eCA_CERT\u003c/var\u003e\"\n }\n\n Replace the following:\n - `\"`\u003cvar translate=\"no\"\u003eADDRESS\u003c/var\u003e`\"`: the IP address or FQDN (Fully Qualified\n Domain Name) of the machine that runs your private registry.\n\n - `\"`\u003cvar translate=\"no\"\u003eCA_CERT\u003c/var\u003e`\"`: the CA certificate public key for the\n private registry.\n\n3. Continue with the steps in the Terraform tab in\n [Create an admin cluster](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/create-admin-cluster)\n to verify the Terraform configuration file and plan and then create the\n bootstrap cluster.\n\n4. When you run the `gkectl register bootstrap` command, `gkectl` prompts\n you to enter the username and then the password for the private registry.\n\nDuring cluster creation, the system images are pulled from your private\nregistry server.\n\nLimitations with advanced clusters and the full bundle\n\nThere are two Google Distributed Cloud bundles available: full and regular. To determine\nwhich bundle is on your admin workstation, check the `bundlePath` field in your\nadmin cluster configuration file. If the filename ends in `-full`, the full\nbundle is on your admin workstation. If the filename doesn't end in `-full`, the\nregular bundle is on your admin workstation.\n\nIf you created your admin workstation using the `gkeadm` command, the command\ncreates the admin workstation VM with the full bundle on it, and configures the\n`bundlePath` field in the admin cluster configuration file.\n\nIf [advanced cluster](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/user-cluster-configuration-file-latest#enable-advanced-cluster-field)\nis enabled, there are limitations with using the full bundle with a private\nregistry, as follows:\n\n- Version 1.31: the full bundle isn't supported with a private registry. To use\n a private registry on an advanced cluster:\n\n 1. [Download](/kubernetes-engine/distributed-cloud/vmware/docs/downloads#bundle) the regular size bundle to your admin workstation.\n 2. Update the filename in the `bundlePath` field in the admin cluster configuration file.\n- Version 1.32: using the full bundle is supported, but the `gkectl prepare`\n command pulls images from `gcr.io/gke-on-prem-release` instead of the tar\n file. The command does, however, push the images to your private registry so\n that the system images are pulled from your private registry during cluster\n creation or upgrade.\n\nDifferences between normal clusters and advanced clusters\n\nAdvanced cluster introduces several key differences compared to standard\nclusters:\n\n- When you use a private registry, images appear to pull from `gcr.io`, not the hostname of your private registry. This change is expected, even though images actually pull from your private registry server.\n- Image pulls use credentials from the `/etc/containerd/config.toml` file in each machine that connects to the private registry, instead of from the `private-registry-creds` secret inside the cluster.\n- For all `gcr.io` images, the cluster first tries to pull from the private registry. If the image isn't in the private registry, the system pulls it from `gcr.io` over the internet. To stop this fallback, set up [`noProxy`](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/admin-cluster-configuration-file-latest#proxy-noproxy-field) or use firewall rules to block `gcr.io` traffic.\n\nTo check that images pull from the correct source, see [Verify images are pulled\nfrom your registry server](#verify_images_are_pulled_from_your_registry_server).\n\nVerify images are pulled from your registry server\n\nHow you verify that images are being pulled from your registry server depends\non whether advanced cluster is enabled.\n\n- If advanced cluster isn't enabled, run the following command:\n\n kubectl --kubeconfig \u003cvar translate=\"no\"\u003eADMIN_CLUSTER_KUBECONFIG\u003c/var\u003e get pods \\\n --all-namespaces -o jsonpath=\"{.items[*].spec['initContainers', 'containers'][*].image}\"\n\n Replace \u003cvar translate=\"no\"\u003eADMIN_CLUSTER_KUBECONFIG\u003c/var\u003e with the path of the\n kubeconfig file for your admin cluster.\n\n The output of this command displays all the images in your cluster. You can\n verify that all the Google Distributed Cloud images are from your own registry server.\n- If advanced cluster is enabled, do the following steps:\n\n You can determine whether `containerd` is pulling images from your local\n registry by examining the contents of a file called `config.toml` as shown in\n the following steps:\n 1. Log into a node and examine the contents of the file `/etc/containerd/config.toml`.\n 2. Check the `plugins.\"io.containerd.grpc.v1.cri\".registry.mirrors` field of the\n `config.toml` file to see whether your registry server is listed in the\n `endpoint` field.\n\n The following is an excerpt from an example `config.toml` file. \n\n version = 2\n root = \"/var/lib/containerd\"\n state = \"/run/containerd\"\n ...\n [plugins.\"io.containerd.grpc.v1.cri\".registry]\n [plugins.\"io.containerd.grpc.v1.cri\".registry.configs]\n [plugins.\"io.containerd.grpc.v1.cri\".registry.configs.\"gcr.io\"]\n [plugins.\"io.containerd.grpc.v1.cri\".registry.configs.\"privateregistry2.io\".tls]\n ca_file = '/etc/containerd/certs.d/privateregistry2.io/ca.crt'\n [plugins.\"io.containerd.grpc.v1.cri\".registry.mirrors]\n [plugins.\"io.containerd.grpc.v1.cri\".registry.mirrors.\"gcr.io\"]\n endpoint = [\"http://privateregistry.io\", \"http://privateregistry2.io\"]\n ...\n\n 3. If your registry mirror appears in the `endpoint` field, then the node is\n pulling images from your registry mirror rather than from\n Artifact Registry."]]
