由於需要在可靠性和安全性之間取捨,因此 GKE 強制執行作業會失敗。每當建立或更新 Pod 時,GKE 就會向二進位授權傳送要求。這包括 Pod 由較高層級的 Kubernetes 工作負載控制器 (例如 ReplicaSet 和 StatefulSet) 自動建立或更新的情況。如果 GKE 失敗並關閉,而非開啟,任何二進位檔授權服務中斷都會導致這些 Pod 停止執行。此外,如果 Pod 遭到拒絕,容錯移轉可能會導致連鎖性故障,因為重新導向的流量會使仍在執行的 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-09-04 (世界標準時間)。"],[[["\u003cp\u003eThis guide explains how to deploy container images to a GKE cluster with Binary Authorization enabled, using the same \u003ccode\u003ekubectl\u003c/code\u003e commands as clusters without this feature.\u003c/p\u003e\n"],["\u003cp\u003eBefore deploying, you must have the Binary Authorization API enabled and a GKE cluster with Binary Authorization enabled, as well as have updated the local \u003ccode\u003ekubeconfig\u003c/code\u003e to interact with the cluster.\u003c/p\u003e\n"],["\u003cp\u003eDeploying the image requires specifying the image path and digest, not a tag, to enable Binary Authorization's attestation verification process.\u003c/p\u003e\n"],["\u003cp\u003eIn the event that the GKE cannot reach the Binary Authorization server or encounters an error, it defaults to allowing the image deployment but logs the occurrence in Cloud Audit Logs, this is known as fail open.\u003c/p\u003e\n"],["\u003cp\u003eBinary Authorization has a breakglass feature that allows deployment of images that are in violation of the set policy.\u003c/p\u003e\n"]]],[],null,["# Deploy containers (GKE, Distributed Cloud)\n\nThis page explains how to deploy a container image to a GKE cluster (on\nGoogle Cloud or Google Distributed Cloud) where Binary Authorization is enabled.\nThe `kubectl` commands you use to deploy the image are the same as the ones you\nuse to deploy images to clusters that don't use Binary Authorization.\n\nBefore you begin\n----------------\n\nMake sure you have the Binary Authorization API enabled in your project and a\nGKE cluster with Binary Authorization enabled. See\n[setting up on Google Kubernetes Engine](/binary-authorization/docs/setting-up) or\n[setting up on Distributed Cloud](/binary-authorization/docs/setting-up-on-prem).\n\nInstall [`kubectl`](https://kubernetes.io/docs/tasks/tools/install-kubectl) for interacting with GKE.\n\nConfigure `kubectl`\n-------------------\n\nYou must update the local `kubeconfig` file for your `kubectl` installation.\nThis provides the credentials and endpoint information required to access the\ncluster in GKE or Distributed Cloud.\n\nTo configure `kubectl`, run the following `gcloud` command: \n\n### GKE\n\n```\ngcloud container clusters get-credentials \\\n --zone ZONE \\\n CLUSTER_NAME\n```\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eZONE\u003c/var\u003e: the name of the GKE zone where the cluster is running, for example, `us-central1-a`\n- \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e: the name of the cluster\n\n### Distributed Cloud\n\n```\ngcloud container fleet memberships get-credentials \\\n --location LOCATION \\\n MEMBERSHIP_NAME\n```\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eLOCATION\u003c/var\u003e: the location of the fleet membership of the GKE cluster, for example, `global`\n- \u003cvar translate=\"no\"\u003eMEMBERSHIP_NAME\u003c/var\u003e: the name of the fleet membership of the GKE cluster\n\nDeploy the container image\n--------------------------\n\nDeploy your container image as follows:\n\n1. Configure environment variables:\n\n POD_NAME=\u003cvar translate=\"no\"\u003ePOD_NAME\u003c/var\u003e\n IMAGE_PATH=\u003cvar translate=\"no\"\u003eIMAGE_PATH\u003c/var\u003e\n IMAGE_DIGEST=\u003cvar translate=\"no\"\u003eIMAGE_DIGEST\u003c/var\u003e\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003ePOD_NAME\u003c/var\u003e: the name you want to use for the GKE workload\n - \u003cvar translate=\"no\"\u003eIMAGE_PATH\u003c/var\u003e: path of the image in [Artifact Registry](/artifact-registry/docs), or another registry.\n - \u003cvar translate=\"no\"\u003eIMAGE_DIGEST\u003c/var\u003e: the digest of the image manifest.\n Example is as follows:\n\n - Artifact Registry:\n - Path: `us-docker.pkg.dev/google-samples/containers/gke/hello-app`\n - Digest: `sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567`\n\n To learn how to get the digest of an image in Artifact Registry, see\n [Managing images](/artifact-registry/docs/docker/manage-images#gcloud).\n2. Deploy your image using the `kubectl run` command.\n\n You must deploy the image using the digest rather than a tag like `1.0` or\n `latest`, as Binary Authorization uses the digest to look up\n [attestations](/binary-authorization/docs/key-concepts#attestations).\n\n To deploy the image, run the following `kubectl` command: \n\n ```\n kubectl run ${POD_NAME} \\\n --image ${IMAGE_PATH}@${IMAGE_DIGEST}\n ```\n\n Now, verify that the deployment was blocked by Binary Authorization: \n\n ```\n kubectl get pods\n ```\n\n You see your Pod listed.\n\nFail open\n---------\n\n\u003cbr /\u003e\n\nIf GKE is unable to reach the Binary Authorization\nserver for any reason, or if the server returns an error,\nGKE cannot determine whether Binary Authorization\nwould allow or deny the image. In this case, GKE fails open: it defaults to allowing the image to be deployed, but creates a log entry in\nCloud Audit Logs to record why the image was allowed.\n\nGKE enforcement fails open because of a tradeoff between\nreliability and security. GKE sends a request to the\nBinary Authorization whenever a Pod is created or updated. This includes\nscenarios where Pods are automatically created or updated by higher level\nKubernetes workload controllers, like ReplicaSets and StatefulSets. If\nGKE failed closed instead of open, any\nBinary Authorization outage would stop these Pods from running. Moreover,\nwhen Pods are denied, failover can lead to cascading failures as redirected\ntraffic overloads Pods that are still running. Any Binary Authorization\noutage could trigger a complete outage for your cluster, even without\ndeploying any new images.\n| **Note:** Operations that send enough requests to Binary Authorization to exceed the per-project, per-user, per-minute [quota](/binary-authorization/quotas) will trigger fail open. For example, testing whether Binary Authorization denies an image by trying to rapidly deploy that image repeatedly will cause the image to be allowed when the quota is exceeded. It is possible to [request additional\n| quota](/binary-authorization/quotas#quota_increases), if needed.\n\nDeploy images that violate the policy\n-------------------------------------\n\nBinary Authorization supports a feature known as *breakglass* that allows an image\nto be deployed, even if it violates the policy.\n\nFor more information, see [Using breakglass](/binary-authorization/docs/using-breakglass)\n\nClean up\n--------\n\nTo clean up, delete the Pod by executing the following command:\n\n\u003cbr /\u003e\n\n```\n kubectl delete pod ${POD_NAME}\n \n```\n\n\u003cbr /\u003e\n\nWhat's next\n-----------\n\n- Learn about [dry-run mode](/binary-authorization/docs/enabling-dry-run).\n- Learn how to [use CV](/binary-authorization/docs/overview-cv).\n- Learn how to [use legacy continuous validation](/binary-authorization/docs/using-cv) ([deprecated](/binary-authorization/docs/deprecations/cv-project-singleton-policy)).\n- Learn how to [use image digests in Kubernetes manifests](/architecture/using-container-image-digests-in-kubernetes-manifests)."]]