[[["容易理解","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 (世界標準時間)。"],[],[],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."]]