GDC air-gapped 提供两个级别的管理平面 API，用于创建和管理两种 GDC 资源类型：全局 API 和区域 API。
全局 API 和区域 API 都是在不同端点提供的 Kubernetes 声明性 API，而 GDC 资源在 API 服务器中表示为 Kubernetes 自定义资源。全球 API 服务器共享一个分布在各个可用区中的 etcd 集群，以提供具有容错功能的强一致性，但与可用区 API 服务器相比，延迟更高，每秒写入查询次数 (QPS) 更少。在每个组织中，区域管理 API 服务器都会提供区域 API，供管理员和开发者管理区域资源；全局管理 API 服务器会提供全局 API，用于管理多区域资源。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-19。"],[[["\u003cp\u003eGoogle Distributed Cloud (GDC) air-gapped APIs are programmatic interfaces to GDC platform services, built on Kubernetes and using the Kubernetes Resource Model (KRM) for resource management.\u003c/p\u003e\n"],["\u003cp\u003eGDC APIs are of two types: Kubernetes-based, which are extensions of the open-source Kubernetes API and use HTTP-based RESTful APIs, and non-Kubernetes-based, such as Vertex pre-trained AI APIs, which may use HTTP or gRPC and have their own endpoints.\u003c/p\u003e\n"],["\u003cp\u003eGDC offers both global and zonal APIs, both being Kubernetes declarative APIs served at different endpoints, allowing for the management of resources across multiple zones or within a single zone, respectively.\u003c/p\u003e\n"],["\u003cp\u003eAccess to GDC APIs can be achieved through the \u003ccode\u003egdcloud\u003c/code\u003e CLI tools or the GDC console, with direct API use recommended for automated or programmatic access.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003ekubectl\u003c/code\u003e Kubernetes CLI is the main tool to work with the Kubernetes API and any Kubernetes-based APIs, using either the proxy mode or by passing an authentication token directly to the API server.\u003c/p\u003e\n"]]],[],null,["# Google Distributed Cloud air-gapped APIs overview\n\nGoogle Distributed Cloud (GDC) air-gapped application programming interfaces (APIs) are\nprogrammatic interfaces to the GDC platform services.\nGoogle builds the control-plane APIs on top of Kubernetes, using the\nKubernetes Resource Model (KRM). The control plane performs resource management\nfor services such as creation, deletion, and updates.\n\nSpecific services have these APIs and their own data-plane APIs, which are XML,\nJSON, or gRPC-based. This page covers these services in their respective\nsections.\n\nAbout GDC APIs\n--------------\n\nThere are two types of GDC APIs: those that are\nKubernetes-based and those that are not. Many GDC APIs\nare extensions to the open source Kubernetes API. They use Kubernetes custom\nresources and rely on the KRM. These APIs, like the Kubernetes API, are\nHTTP-based RESTful APIs, accepting and returning JSON as the default, or in\nProtobuf. The API endpoint is the relevant Kubernetes server.\n\nOther, non-Kubernetes based GDC APIs, such as the Vertex\npre-trained AI APIs, have their own endpoints. In addition to supporting HTTP,\nsome of these APIs may also be accessible by gRPC, the open-source remote-procedure\ncall framework. For more information on specific APIs, see their dedicated documentation\nin the vertical navigation menu.\n\nTo access GDC APIs, use the [gdcloud CLI tools](/distributed-cloud/hosted/docs/latest/gdch/resources/gdcloud-overview)\nor GDC console.\n\nAbout the Kubernetes API and the KRM\n------------------------------------\n\nAs many of the GDC APIs are extensions to the Kubernetes\nAPI and rely on the KRM, an understanding of these concepts help you take\nadvantage of GDC APIs to their full extent.\n\nThe Kubernetes API is fully declarative, and everything in the Kubernetes API\nis a resource that follows the KRM. API clients, both human and machine,\nact on those resources, often with create, read, update, and delete\n(CRUD) operations. The Kubernetes database stores the resource and\nrepresents the state of the system. Kubernetes continuously watches\nthose resources and reconciles the real state of the system with the desired\nstate. For example, if you update a `Deployment` resource to indicate that you\nwant five replicas of your container instead of four, Kubernetes detects\nthe change in the desired number of replicas and creates an additional\ncontainer.\n\nFor the core Kubernetes API, Kubernetes performs the reconciliation between\ndesired and real states itself. The Kubernetes API extensions are\ncustom resources that are not part of the core Kubernetes API. The custom\nsoftware continuously watches and interacts with the Kubernetes API and\nperforms the reconciliation.\n\nTo learn more about the Kubernetes API and the Kubernetes resource model, read\nthe official Kubernetes documentation.\n\n- Kubernetes API Overview, at [*https://kubernetes.io/docs/reference/using-api/*](https://kubernetes.io/docs/reference/using-api/)\n- Kubernetes API Concepts, at [*https://kubernetes.io/docs/reference/using-api/api-concepts/*](https://kubernetes.io/docs/reference/using-api/api-concepts/)\n- The Kubernetes Resource Model (KRM), at [*https://github.com/kubernetes/design-proposals-archive/blob/main/architecture/resource-management.md*](https://github.com/kubernetes/design-proposals-archive/blob/main/architecture/resource-management.md)\n\nGlobal and zonal APIs\n---------------------\n\nResources in GDC air-gapped are either zonal resources\nor global resources. Zonal resources operate within a single zone independently,\nand a zonal outage can affect some or all of the resources in that zone. Global\nresources operate with redundancy across multiple zones for fault tolerance.\n\nGDC air-gapped offers two levels of management plane\nAPIs to create and manage both GDC resource types:\nglobal APIs and zonal APIs.\n\nBoth global and zonal APIs are Kubernetes declarative APIs served at different\nendpoints, and GDC resources are represented as\nKubernetes custom resources in the API servers. The global API servers share a\nsingle etcd cluster distributed across zones to provide strong consistency with\nfault tolerance, at the cost of higher latency and reduced write queries per\nsecond (QPS) compared to the zonal API servers. In every organization, a\nzonal management API server provides the zonal API for administrators and\ndevelopers to manage zonal resources, and a global management API server\nprovides the global API to manage multi-zone resources.\n\nGDC APIs access\n---------------\n\nBoth the gdcloud CLI tools and the GDC console leverage\nthe GDC APIs. Google recommends that you use those to\nexplore GDC or to do one-off operations. However, if\nyou use automated or programmatic access to GDC, Google\nrecommends that you use the GDC APIs directly.\n\n### HTTP and gRPC support\n\nMost GDC APIs provide a JSON HTTP interface that you\ncall directly. The Kubernetes-based APIs use the Kubernetes\nclient libraries. Some non-Kubernetes GDC APIs have a\ngRPC interface, which provides improved performance and usability. Google also\nprovides client libraries for GDC APIs that aren't based\non Kubernetes.\n\nTo read more about gRPC, go to [*https://grpc.io/*](https://grpc.io/).\n\n### TLS encryption\n\nAll GDC APIs accept requests using the Transport Layer\nSecurity (TLS) encryption.\n\n- If you are using one of the Kubernetes or GDC client libraries, the library handles in-transit encryption for you.\n- If you are using your own HTTP or gRPC client, you must authenticate with GDC, which requires TLS. For gRPC, follow the instructions in the gRPC authentication guide at [*https://grpc.io/docs/guides/auth/*](https://grpc.io/docs/guides/auth/).\n\n| **Note:** GDC recommends that you use existing clients, especially ones Google provides, to interact with GDC APIs. Creating your own API client is an arduous software-engineering task that, if done incorrectly, might lead to unforeseen behaviors in your systems that are difficult to diagnose.\n\n### Access the Kubernetes API and Kubernetes-based APIs\n\nThe `kubectl` Kubernetes CLI is the primary way to work directly with the\nKubernetes API and any Kubernetes-based APIs.\n\n#### Access with kubectl\n\nWhen accessing the Kubernetes API for the first time, use the\nKubernetes command-line tool, `kubectl`.\n\nTo access a cluster, you need the cluster location information and the credentials\nto access it. See the [Sign in](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/iam/sign-in#cli)\nsection to learn how to get access to those credentials.\n\nExamine your current `kubectl` configuration and see the clusters to which you have\naccess: \n\n kubectl config view\n\n#### Direct access to the API with an HTTP client\n\nThe following are ways to directly access the REST API with an HTTP client like\n`curl`, `wget`, or a browser:\n\n- Rely on `kubectl` to handle the authentication by using it in proxy mode.\n- Handle the authentication yourself.\n\n##### Run kubectl proxy\n\nThe `kubectl proxy` command runs `kubectl` in a mode where it acts as a reverse\nproxy. This command connects to the `apiserver` and manages the authentication.\n\nRunning `kubectl` in proxy mode uses the stored API server location and\nverifies the identity of the API server using a certificate. This method guards\nagainst man-in-the-middle (MITM) attacks.\n\nThe following example shows how to use the `kubectl proxy` command: \n\n kubectl proxy --port=8080 &\n\nOnce the `kubectl` proxy is running, you can explore the API with `curl`, `wget`,\nor a browser, as shown in the following: \n\n $ curl http://localhost:8080/api/\n {\n \"versions\": [\n \"v1\"\n ],\n \"serverAddressByClientCIDRs\": [\n {\n \"clientCIDR\": \"0.0.0.0/0\",\n \"serverAddress\": \"10.0.1.149:443\"\n }\n ]\n }\n\n##### Run without kubectl proxy\n\nIf you don't want to run `kubectl` in proxy mode, you can pass an authentication\ntoken directly to the API server.\n\n1. List all possible Kubernetes clusters you have access to, as your kubeconfig\n file might have multiple contexts:\n\n kubectl config view \\\n -o jsonpath='{\"Cluster name\\tServer\\n\"}{range.clusters[*]}{.name}{\"\\t\"}{.cluster.server}{\"\\n\"}{end}'\n\n2. Export the name of the Kubernetes cluster you want to interact with from the\n previous output:\n\n export CLUSTER_NAME=\"\u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e\"\n\n3. Set the API server referring to the Kubernetes cluster name:\n\n APISERVER=$(kubectl config view -o jsonpath=\"{.clusters[?(@.name==\\\"$CLUSTER_NAME\\\")].cluster.server}\")\n\n4. Create a secret to hold a token for the default service account:\n\n kubectl apply -n \u003cvar translate=\"no\"\u003eNAMESPACE\u003c/var\u003e -f - \u003c\u003cEOF\n apiVersion: v1\n kind: Secret\n metadata:\n name: default-token\n annotations:\n kubernetes.io/service-account.name: default\n type: kubernetes.io/service-account-token\n EOF\n\n5. Wait for the token controller to populate the secret with a token:\n\n while ! kubectl describe secret default-token | grep -E '^token' \u003e/dev/null; do\n echo \"waiting for token...\" \u003e&2\n sleep 1\n done\n\n6. Set the token value:\n\n TOKEN=$(kubectl get secret $(kubectl get secrets | grep default | cut -f1 -d ' ') \\\n -o jsonpath='{.data.token}' | base64 --decode)\n\n7. To access the API, use the token with a tool like `curl` by adding the HTTP\n header `Authorization: Bearer $TOKEN` as shown in the following example:\n\n $ curl -k $APISERVER/api --header \"Authorization: Bearer $TOKEN\"\n\n The output is similar to the following: \n\n {\n \"kind\": \"APIVersions\",\n \"versions\": [\n \"v1\"\n ],\n \"serverAddressByClientCIDRs\": [\n {\n \"clientCIDR\": \"0.0.0.0/0\",\n \"serverAddress\": \"10.0.1.149:443\"\n }\n ]\n }"]]
