canonical: https://jentic.com/apis/googleapis.com/container

# Google Kubernetes Engine API

Google Kubernetes Engine (GKE) API lets developers provision and manage GKE clusters, node pools, and operations on Google Cloud. It exposes the full lifecycle of a managed Kubernetes control plane: create clusters in zonal or regional mode, scale node pools, upgrade master and node versions, configure addons such as HTTP load balancing or network policy, and rotate cluster credentials. The API also surfaces server configuration metadata describing the available Kubernetes versions and machine types per location. It is the canonical way to script GKE infrastructure outside of Terraform or the Cloud Console.

## For AI agents

Provision GKE clusters, resize node pools, upgrade Kubernetes versions, and rotate credentials so an agent can manage container workload infrastructure end to end.

## Scope

Does not deploy workloads, manage Kubernetes objects, or run kubectl commands - use only to manage GKE clusters and node pool infrastructure.

## Capabilities

- Create zonal or regional GKE clusters with custom networking, addons, and machine types
- Add, resize, autoscale, and delete node pools on existing clusters
- Upgrade the cluster master and node pools to a specific Kubernetes version
- Rotate cluster credentials including IP and master auth
- Enable or disable cluster addons such as HTTP load balancing, network policy, and Cloud Run integration
- Set legacy ABAC, monitoring, logging, and resource label configuration
- Inspect server config to discover supported Kubernetes versions and node images per zone

## Use cases

### Cluster Provisioning Automation

A platform team scripts GKE cluster provisioning so application teams can self-service via a web form. The Kubernetes Engine API creates the cluster with the team's chosen region, network, and addons, returns a long-running operation, and the automation waits for completion before handing over kubectl credentials. End-to-end provisioning takes around five minutes.

Example prompt: Create a regional cluster 'team-payments-prod' in europe-west1 with 3 nodes per zone, network policy enabled, and Kubernetes 1.30, then wait for the operation to complete.

### Scheduled Master and Node Upgrades

A weekly job calls clusters.update and nodePools.update to roll the master and worker fleet to the latest patch version of Kubernetes. The Kubernetes Engine API performs surge upgrades to keep workloads available. The job records each operation ID for audit logging.

Example prompt: Upgrade cluster 'prod-1' master to the latest 1.30 patch and roll its 'workers' node pool to the same version using surge=2.

### Capacity Right-Sizing

Cost-optimisation tooling reviews node pool utilisation each night and calls nodePools.setSize to rebalance fleets. The Kubernetes Engine API exposes setSize, autoscaling, and locations on every node pool so the tool can shift capacity between zones without redeploying workloads. Cluster autoscaler can be enabled or tuned through the same surface.

Example prompt: List node pools on cluster 'analytics-prod', and for any pool with average CPU under 30% over 24 hours, call setSize to halve its node count.

### Compliance Sweep for Legacy Clusters

A governance script enumerates every cluster across the project and flags any still running a deprecated Kubernetes minor version, an outdated node image, or with legacy ABAC enabled. The Kubernetes Engine API supplies cluster.get and serverConfig data to compute these checks. Results feed an internal compliance ticketing system.

Example prompt: List all clusters in the project, fetch each cluster's currentMasterVersion, and return any below 1.28.

### AI Agent Cluster Triage

An on-call AI agent receives a high latency alert and asks Jentic for the cluster's current node count, recent operations, and master version. The Kubernetes Engine API answers all three in seconds; the agent decides whether to escalate to a human or trigger a node pool resize through the same API.

Example prompt: For cluster 'prod-1' in us-central1-a, retrieve the current master version, last completed operation, and node count, then summarise whether a resize is warranted.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | /v1/projects/{projectId}/zones/{zone}/clusters | List clusters in a zone |
| POST | /v1/projects/{projectId}/zones/{zone}/clusters | Create a new cluster |
| GET | /v1/projects/{projectId}/zones/{zone}/clusters/{clusterId} | Get a specific cluster |
| POST | /v1/projects/{projectId}/zones/{zone}/clusters/{clusterId}/nodePools | Create a node pool |
| POST | /v1/projects/{projectId}/zones/{zone}/clusters/{clusterId}/addons | Update cluster addons |

## Key resources

- **Clusters** — Managed Kubernetes clusters with master, networking, and addon configuration
- **Node Pools** — Worker node groupings with machine type, autoscaling, and version controls
- **Operations** — Long-running operations covering cluster create, update, upgrade, and delete
- **Server Config** — Per-zone metadata listing supported Kubernetes versions and node images

## Why Jentic

- **Setup:** Wiring Kubernetes Engine by hand means setting up Google OAuth, exchanging a service account for short-lived cloud-platform tokens rather than embedding a JSON key, and building project and zone paths against container.googleapis.com. Through Jentic you install once, import the Kubernetes Engine API from the API Directory, store the Google credential once, and your agent calls it.
- **Permission scoping:** The API puts the project, zone, and cluster id in the URL path (/v1/projects/{projectId}/zones/{zone}/clusters/{clusterId}/...), so a rule can pin your agent to one project, zone, or cluster. You choose the operations it may call, so read-only listing and node pool creation can be allowed while cluster deletion is not included unless you add it.
- **Credential handling:** Your Google service account credential is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'create a GKE cluster' or 'resize a node pool', and Jentic returns the matching Kubernetes Engine operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Cloud Run API** — Run containers without managing a Kubernetes cluster
- **Container Analysis API** — Scan images deployed to GKE for vulnerabilities
- **Amazon EKS API** — Managed Kubernetes from a different cloud provider
- **Cloud Build API** — Build and push the container images that run on GKE

## FAQ

### What authentication does the Kubernetes Engine API use?

The GKE API uses Google OAuth 2.0 with the cloud-platform scope. Through Jentic the service account JSON key is stored encrypted in your Jentic One instance, and agents receive short-lived access tokens per request.

### Can I scale a node pool with the Kubernetes Engine API without recreating the cluster?

Yes. Call setSize on the node pool resource at /v1/projects/{projectId}/zones/{zone}/clusters/{clusterId}/nodePools to change the node count, or update its autoscaling configuration to let GKE size it automatically. The cluster keeps running through the change.

### What are the rate limits for the Kubernetes Engine API?

GKE applies per-project mutation quotas with stricter limits on cluster create, upgrade, and delete because each spawns a long-running operation. Read calls have higher allowances. Check the Cloud Console Quotas page for your project's exact ceilings.

### How do I create a GKE cluster through Jentic?

Run pip install jentic, search Jentic for 'create gke cluster', load the schema for clusters.create on container.googleapis.com, and execute it with your cluster spec (network, nodeConfig, initialNodeCount, region or zone).

### Does the Kubernetes Engine API let me deploy workloads to the cluster?

No. This API manages the cluster and node pools themselves. To deploy workloads onto a cluster you use the Kubernetes API on the cluster's master endpoint with kubectl or a client library.

### Can I limit what my agent is allowed to do with the Google Kubernetes Engine API?

Yes. Because you run Jentic One self-hosted, your own rules decide which operations and credentials the agent may use. Since this API carries the project, zone, and cluster id in the URL path, you can pin the agent to a single project, zone, or cluster. You can also allow only the operations you trust, such as listing clusters and creating node pools, while leaving cluster deletion out unless you add it.