Google Kubernetes Engine (GKE)

Connect

Activate your license key and start the emulator with the Vera launcher, as in Activate Pro, then run these in a terminal of their own. They use Google Cloud’s address on your machine.

export VERA_ENDPOINT="http://localhost:8081"
export PROJECT_ID="example-project"
export GKE_BASE="$VERA_ENDPOINT/_gcp/container/v1/projects/$PROJECT_ID/locations/us-central1-a"

Requests go to $VERA_ENDPOINT/_gcp/container/v1/. The example uses a zonal cluster in us-central1-a. The project ID is local to the emulator and needs no Google Cloud account. This page uses REST for the whole lifecycle. gcloud works too, as in Supported features.

Example

Create a cluster with one node, read it back and list its node pools, then change the pool’s size and delete the cluster. The cluster gets a local Kubernetes control plane, but its nodes and pods are emulated records: no workload containers run.

curl --fail-with-body -X POST "$GKE_BASE/clusters" \
  -H "Content-Type: application/json" \
  -d '{"cluster":{"name":"example-cluster","initialNodeCount":1}}'

curl --fail-with-body "$GKE_BASE/clusters/example-cluster"

curl --fail-with-body "$GKE_BASE/clusters/example-cluster/nodePools"

The create returns a GKE operation that has already finished: its status is DONE and its operationType CREATE_CLUSTER, rather than the done: true of other Google Cloud APIs’ operations. Its name can be read back under $GKE_BASE/operations/.

The second request returns the cluster. These are selected fields from it. The port in endpoint is the one this cluster returned, from the range 16443–16452: use the value your cluster returns.

Response (selected fields)

{
  "status": "RUNNING",
  "currentNodeCount": 1,
  "endpoint": "127.0.0.1:16443"
}

The endpoint is the cluster’s Kubernetes API on your machine, on a port the Vera launcher publishes. Only ten ports are published, so don’t expect more than ten clusters’ endpoints to be reachable from your machine. The last request lists the cluster’s default node pool, default-pool.

Resize the node pool

curl --fail-with-body -X POST \
  "$GKE_BASE/clusters/example-cluster/nodePools/default-pool:setSize" \
  -H "Content-Type: application/json" -d '{"nodeCount":2}'

curl --fail-with-body "$GKE_BASE/clusters/example-cluster"

The cluster’s currentNodeCount becomes 2. No VMs or containers back the nodes.

Check the cluster with kubectl

This check is optional. It lists the cluster’s nodes with kubectl, from your machine, and needs kubectl and Python 3 (python3), which reads the cluster’s endpoint and CA certificate from the saved response. kubectl gets them on the command line, so your kubeconfig isn’t changed.

curl --fail-with-body "$GKE_BASE/clusters/example-cluster" -o cluster.json
GKE_SERVER=$(python3 -c 'import json; print("https://" + json.load(open("cluster.json"))["endpoint"])')
python3 -c 'import json,base64; print(base64.b64decode(json.load(open("cluster.json"))["masterAuth"]["clusterCaCertificate"]).decode(), end="")' > gke-ca.pem
kubectl --server="$GKE_SERVER" --certificate-authority=./gke-ca.pem \
  --token=vera-docs-test get nodes

kubectl lists the cluster’s emulated nodes. The token vera-docs-test is a local placeholder, not Google authentication: the cluster’s API accepts any nonempty bearer token (see Limitations). This check was tested with kubectl on Linux.

A kubeconfig that gcloud container clusters get-credentials writes is different: it runs gke-gcloud-auth-plugin for its credentials, so kubectl needs that plugin installed to use it.

Clean up

Delete the cluster. The rm removes the two files the kubectl check saves, if you ran it.

curl --fail-with-body -X DELETE "$GKE_BASE/clusters/example-cluster"
rm -f cluster.json gke-ca.pem

Supported features

The example, with its kubectl check, was run on Vera 1.2.2 on 8 November 2026, and so were gcloud’s cluster create, describe and get-credentials commands. The rest of this list was run on Vera 1.2.0-rc.3, apart from reading and deleting clusters with gcloud, which was run on Vera 1.2.0 preview. The API coverage marks the rest of the API from a review of the Vera 1.2.0 source and a few Vera 1.2.0-rc.3 and Vera 1.2.2 requests, with their limits in the notes: don’t read this list as support for other GKE settings, upgrades, fleets, Kubernetes manifests or workloads.

• Clusters through v1 zonal and location paths: create, list, read and delete. A new cluster reads back RUNNING, with an endpoint.
• Operations: read the finished operation that creating a cluster returns.
• Node pools: list the cluster’s default pool and change its node count.
• gcloud: gcloud container clusters create, describe and get-credentials worked on Vera 1.2.2, and gcloud 585.0.0 read and deleted existing clusters in Vera 1.2.0 preview, with the shared gcloud setup and CLOUDSDK_API_ENDPOINT_OVERRIDES_CONTAINER set to $VERA_ENDPOINT/_gcp/container/.
• A local Kubernetes API for each cluster, at its endpoint on your machine, whose nodes and pods are emulated records: no workload containers run.

Limitations

The main limits are below. A few more apply to every service, and the API coverage notes cover smaller differences.

• Workloads don’t run. Nodes and pods are emulated records: no workload containers run.
• Ten endpoint ports. The Vera launcher publishes ports 16443–16452 for clusters’ Kubernetes APIs, so only ten are published. Use the endpoint each cluster returns.
• Kubernetes clients were checked only on Linux. TLS requests and kubectl get nodes reached a cluster’s endpoint from the host, with its CA certificate and a placeholder token, as in the example. A kubeconfig from gcloud container clusters get-credentials also needs gke-gcloud-auth-plugin.
• Cluster security isn’t Google Cloud’s. From a review of the Vera 1.2.0 source, the cluster’s Kubernetes API accepts any nonempty bearer token as an administrator and refuses anonymous requests. getJwks returned an empty key set on Vera 1.2.0-rc.3, so tokens the cluster issues can’t be verified against it.
• Some operations only report completion. From a review of the Vera 1.2.0 source, startIpRotation, completeIpRotation and completeControlPlaneUpgrade return finished operations without rotating an IP or upgrading anything, updateMaster changes the version field only, and checkAutopilotCompatibility reports every existing cluster as compatible.
• Settings are records. Node counts and other cluster settings are stored, with no VMs, containers or workloads behind them. Autoscaling bounds, auto-repair and auto-upgrade are stored, with no workload-driven autoscaling, repair or upgrade schedule.
• v1beta1 is partial. The stable version, v1, is the example’s default. Selected v1beta1 methods use the stable implementation, and on Vera 1.2.2, v1beta1 list requests worked. Methods or fields with incompatible schemas can still answer 501, so this doesn’t establish complete v1beta1 coverage.

API coverage

Every method in Google Cloud's published v1 API (discovery document, revision 20261027), and whether the emulator implements it. Findings without a date are from testing on 5 November 2026. Local observation notes without a build or date are from Vera 1.2.0 preview, on 5 November 2026. Methods not checked earlier were assessed by a review of the Vera 1.2.0 source on 6 November 2026: source inspection describes an implementation and its known limits, not a successful run in a release build or a comparison with Google Cloud. Failures in a tested build are marked separately, and each note from this review names its evidence and date. The emulator also answers v1beta1 requests, which aren't listed here yet. What the statuses mean

projects.locations.clusters

21 of 21 implemented · 11 known differences

Method	Status	Notes
checkAutopilotCompatibility	Known difference	Source inspection: Vera 1.2.0 source, 6 November 2026 — always reports an existing cluster as compatible, without inspecting its workloads or settings. Local observation: Vera 1.2.0-rc.3, 6 November 2026 — for a new cluster, it answered HTTP 200 with a summary saying the cluster is compatible with Autopilot.
completeControlPlaneUpgrade	Known difference	Source inspection: Vera 1.2.0 source, 6 November 2026 — returns an operation that has already finished, after checking the cluster exists and the request is valid. It doesn't rotate an IP or upgrade the control plane.
completeIpRotation	Known difference	Source inspection: Vera 1.2.0 source, 6 November 2026 — returns an operation that has already finished, after checking the cluster exists and the request is valid. It doesn't rotate an IP or upgrade the control plane.
create	Known difference	Local observation: Vera 1.2.2, 8 November 2026 — the example's create answered with a CREATE_CLUSTER operation already DONE, and the cluster read back RUNNING with an endpoint on the host, such as 127.0.0.1:16443, in the 16443–16452 range the Vera launcher publishes. From the host, TLS requests to that endpoint and kubectl get nodes worked. Source inspection: Vera 1.2.0 source, 6 November 2026 — the cluster is backed by a local Kubernetes control plane whose nodes and pods don't run containers. Local observation: Vera 1.2.0-rc.3, 6 November 2026 — a create answered HTTP 200 with a CREATE_CLUSTER operation already DONE, and the cluster then read back RUNNING with a loopback endpoint.
delete	Implemented	Local observation: deletes the cluster record.
fetchClusterUpgradeInfo	Known difference	Source inspection: Vera 1.2.0 source, 6 November 2026 — returns empty upgrade and history lists, with no target versions or support dates. There's no upgrade planner.
get	Known difference	Local observation: Vera 1.2.2, 8 November 2026 — the example's cluster read back RUNNING with an endpoint on the host, such as 127.0.0.1:16443, in the 16443–16452 range the Vera launcher publishes, and with the CA certificate in masterAuth.clusterCaCertificate. From the host, TLS requests to that endpoint and kubectl get nodes with that certificate worked. Source inspection: Vera 1.2.0 source, 6 November 2026 — the cluster is backed by a local Kubernetes control plane whose nodes and pods don't run containers. Local observation: Vera 1.2.0-rc.3, 6 November 2026 — a create answered HTTP 200 with a CREATE_CLUSTER operation already DONE, and the cluster then read back RUNNING with a loopback endpoint.
getJwks	Known difference	Source inspection: Vera 1.2.0 source, 6 November 2026 — returns an empty key set, so it can't be used to verify tokens the cluster issues. Local observation: Vera 1.2.0-rc.3, 6 November 2026 — for an existing cluster, it answered HTTP 200 with {}.
list	Implemented	Local observation: lists the location's cluster records.
setAddons	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — stores the requested cluster setting and a new etag. Whether add-on controllers, network policy enforcement, logging and monitoring pipelines or maintenance act on it isn't established.
setLegacyAbac	Known difference	Source inspection: Vera 1.2.0 source, 6 November 2026 — stores the authentication settings only. The cluster's local Kubernetes API accepts any nonempty bearer token as an administrator and refuses anonymous requests, so these settings don't reproduce Google Cloud's authentication.
setLocations	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — updates the cluster's node locations and its node pools, and places the emulated nodes to match where supported. Nothing is physically relocated.
setLogging	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — stores the requested cluster setting and a new etag. Whether add-on controllers, network policy enforcement, logging and monitoring pipelines or maintenance act on it isn't established.
setMaintenancePolicy	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — stores the requested cluster setting and a new etag. Whether add-on controllers, network policy enforcement, logging and monitoring pipelines or maintenance act on it isn't established.
setMasterAuth	Known difference	Source inspection: Vera 1.2.0 source, 6 November 2026 — stores the authentication settings only. The cluster's local Kubernetes API accepts any nonempty bearer token as an administrator and refuses anonymous requests, so these settings don't reproduce Google Cloud's authentication.
setMonitoring	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — stores the requested cluster setting and a new etag. Whether add-on controllers, network policy enforcement, logging and monitoring pipelines or maintenance act on it isn't established.
setNetworkPolicy	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — stores the requested cluster setting and a new etag. Whether add-on controllers, network policy enforcement, logging and monitoring pipelines or maintenance act on it isn't established.
setResourceLabels	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — applies the supported settings, with fingerprint checks. Node and location changes reach the emulated nodes, but not every GKE feature a request field names takes effect.
startIpRotation	Known difference	Source inspection: Vera 1.2.0 source, 6 November 2026 — returns an operation that has already finished, after checking the cluster exists and the request is valid. It doesn't rotate an IP or upgrade the control plane. Local observation: Vera 1.2.0-rc.3, 6 November 2026 — for an existing cluster, it answered HTTP 200 with an UPDATE_CLUSTER operation that was already DONE.
update	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — applies the supported settings, with fingerprint checks. Node and location changes reach the emulated nodes, but not every GKE feature a request field names takes effect.
updateMaster	Known difference	Source inspection: Vera 1.2.0 source, 6 November 2026 — changes currentMasterVersion and returns a finished operation. The cluster's local Kubernetes API server keeps its version.

projects.locations.clusters.nodePools

11 of 11 implemented

Method	Status	Notes
completeUpgrade	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — serves the operation from the stored node pool and the supported request fields. The pool's nodes don't run containers, and its upgrade state and version fields are stored metadata: no node is reimaged and there's no upgrade planner.
create	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — changes the stored node pool and mirrors it to the cluster's emulated nodes and Compute Engine instance groups. Node labels and taints can affect where pods are scheduled, but pods don't run containers.
delete	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — changes the stored node pool and mirrors it to the cluster's emulated nodes and Compute Engine instance groups. Node labels and taints can affect where pods are scheduled, but pods don't run containers.
fetchNodePoolUpgradeInfo	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — serves the operation from the stored node pool and the supported request fields. The pool's nodes don't run containers, and its upgrade state and version fields are stored metadata: no node is reimaged and there's no upgrade planner.
get	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — reads the stored node pool, or returns its not-found error. The pool's nodes don't run containers.
list	Implemented	Local observation: lists the cluster's default-pool record.
rollback	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — serves the operation from the stored node pool and the supported request fields. The pool's nodes don't run containers, and its upgrade state and version fields are stored metadata: no node is reimaged and there's no upgrade planner.
setAutoscaling	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — stores and validates the autoscaling bounds. The emulated node count can be brought within them, but no workload-driven autoscaler runs.
setManagement	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — stores the autoUpgrade and autoRepair settings. No node is repaired, and there's no upgrade schedule.
setSize	Implemented	Local observation: changes the stored node count, which the cluster's currentNodeCount then shows. No nodes run.
update	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — serves the operation from the stored node pool and the supported request fields. The pool's nodes don't run containers, and its upgrade state and version fields are stored metadata: no node is reimaged and there's no upgrade planner.

projects.locations.operations

3 of 3 implemented

Method	Status	Notes
cancel	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — keeps the record of an operation that has already finished, and marks a long-running operation that's still running as cancelled.
get	Implemented	Local observation: reads the finished operation that creating a cluster returns.
list	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — lists the stored records in scope, with the supported filtering and pagination.

projects.locations

1 of 1 implemented

Method	Status	Notes
getServerConfig	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — reads the emulator's bundled catalog of versions and images, not Google Cloud's current list.

projects.locations.clusters.well-known

1 of 1 implemented · 1 known difference

Method	Status	Notes
getOpenid-configuration	Known difference	Source inspection: Vera 1.2.0 source, 6 November 2026 — returns fixed OpenID discovery metadata for an existing cluster. The key set it points to has no keys, so it isn't a working identity issuer. Local observation: Vera 1.2.0-rc.3, 6 November 2026 — for an existing cluster, it answered HTTP 200 with an issuer and a jwks_uri; that key set answered {}.

projects.aggregated.usableSubnetworks

1 of 1 implemented

Method	Status	Notes
list	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — lists the emulator's default and locally created Compute Engine subnetworks. It supports the networkProjectId filter, not arbitrary filter expressions.

projects.zones.clusters

19 of 19 implemented · 7 known differences

Method	Status	Notes
addons	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — stores the requested cluster setting and a new etag. Whether add-on controllers, network policy enforcement, logging and monitoring pipelines or maintenance act on it isn't established.
completeControlPlaneUpgrade	Known difference	Source inspection: Vera 1.2.0 source, 6 November 2026 — returns an operation that has already finished, after checking the cluster exists and the request is valid. It doesn't rotate an IP or upgrade the control plane.
completeIpRotation	Known difference	Source inspection: Vera 1.2.0 source, 6 November 2026 — returns an operation that has already finished, after checking the cluster exists and the request is valid. It doesn't rotate an IP or upgrade the control plane.
create	Implemented	Source inspection: Vera 1.2.2 source, 8 November 2026 — this zonal route wasn't replayed. It serves the same cluster records as projects.locations.clusters, whose replay on Vera 1.2.2 returned an endpoint on the host, in the 16443–16452 range the Vera launcher publishes, not an address inside the emulator's container. Source inspection: Vera 1.2.0 source, 6 November 2026 — keeps a cluster record backed by a local Kubernetes control plane whose nodes and pods don't run containers. Reads include a loopback endpoint only once that control plane has started. Local observation: Vera 1.2.0-rc.3, 6 November 2026 — a zonal create answered HTTP 200 with a CREATE_CLUSTER operation already DONE. The cluster then read back RUNNING with a loopback endpoint, and was deleted. No workload was run.
delete	Implemented	Source inspection: Vera 1.2.2 source, 8 November 2026 — this zonal route wasn't replayed. It serves the same cluster records as projects.locations.clusters, whose replay on Vera 1.2.2 returned an endpoint on the host, in the 16443–16452 range the Vera launcher publishes, not an address inside the emulator's container. Source inspection: Vera 1.2.0 source, 6 November 2026 — keeps a cluster record backed by a local Kubernetes control plane whose nodes and pods don't run containers. Reads include a loopback endpoint only once that control plane has started. Local observation: Vera 1.2.0-rc.3, 6 November 2026 — a zonal create answered HTTP 200 with a CREATE_CLUSTER operation already DONE. The cluster then read back RUNNING with a loopback endpoint, and was deleted. No workload was run.
fetchClusterUpgradeInfo	Known difference	Source inspection: Vera 1.2.0 source, 6 November 2026 — returns empty upgrade and history lists, with no target versions or support dates. There's no upgrade planner.
get	Implemented	Source inspection: Vera 1.2.2 source, 8 November 2026 — this zonal route wasn't replayed. It serves the same cluster records as projects.locations.clusters, whose replay on Vera 1.2.2 returned an endpoint on the host, in the 16443–16452 range the Vera launcher publishes, not an address inside the emulator's container. Source inspection: Vera 1.2.0 source, 6 November 2026 — keeps a cluster record backed by a local Kubernetes control plane whose nodes and pods don't run containers. Reads include a loopback endpoint only once that control plane has started. Local observation: Vera 1.2.0-rc.3, 6 November 2026 — a zonal create answered HTTP 200 with a CREATE_CLUSTER operation already DONE. The cluster then read back RUNNING with a loopback endpoint, and was deleted. No workload was run.
legacyAbac	Known difference	Source inspection: Vera 1.2.0 source, 6 November 2026 — stores the authentication settings only. The cluster's local Kubernetes API accepts any nonempty bearer token as an administrator and refuses anonymous requests, so these settings don't reproduce Google Cloud's authentication.
list	Implemented	Source inspection: Vera 1.2.2 source, 8 November 2026 — this zonal route wasn't replayed. It serves the same cluster records as projects.locations.clusters, whose replay on Vera 1.2.2 returned an endpoint on the host, in the 16443–16452 range the Vera launcher publishes, not an address inside the emulator's container. Source inspection: Vera 1.2.0 source, 6 November 2026 — keeps a cluster record backed by a local Kubernetes control plane whose nodes and pods don't run containers. Reads include a loopback endpoint only once that control plane has started.
locations	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — updates the cluster's node locations and its node pools, and places the emulated nodes to match where supported. Nothing is physically relocated.
logging	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — stores the requested cluster setting and a new etag. Whether add-on controllers, network policy enforcement, logging and monitoring pipelines or maintenance act on it isn't established.
master	Known difference	Source inspection: Vera 1.2.0 source, 6 November 2026 — changes currentMasterVersion and returns a finished operation. The cluster's local Kubernetes API server keeps its version.
monitoring	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — stores the requested cluster setting and a new etag. Whether add-on controllers, network policy enforcement, logging and monitoring pipelines or maintenance act on it isn't established.
resourceLabels	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — applies the supported settings, with fingerprint checks. Node and location changes reach the emulated nodes, but not every GKE feature a request field names takes effect.
setMaintenancePolicy	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — stores the requested cluster setting and a new etag. Whether add-on controllers, network policy enforcement, logging and monitoring pipelines or maintenance act on it isn't established.
setMasterAuth	Known difference	Source inspection: Vera 1.2.0 source, 6 November 2026 — stores the authentication settings only. The cluster's local Kubernetes API accepts any nonempty bearer token as an administrator and refuses anonymous requests, so these settings don't reproduce Google Cloud's authentication.
setNetworkPolicy	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — stores the requested cluster setting and a new etag. Whether add-on controllers, network policy enforcement, logging and monitoring pipelines or maintenance act on it isn't established.
startIpRotation	Known difference	Source inspection: Vera 1.2.0 source, 6 November 2026 — returns an operation that has already finished, after checking the cluster exists and the request is valid. It doesn't rotate an IP or upgrade the control plane.
update	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — applies the supported settings, with fingerprint checks. Node and location changes reach the emulated nodes, but not every GKE feature a request field names takes effect.

projects.zones.clusters.nodePools

10 of 10 implemented

Method	Status	Notes
autoscaling	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — stores and validates the autoscaling bounds. The emulated node count can be brought within them, but no workload-driven autoscaler runs.
create	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — changes the stored node pool and mirrors it to the cluster's emulated nodes and Compute Engine instance groups. Node labels and taints can affect where pods are scheduled, but pods don't run containers.
delete	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — changes the stored node pool and mirrors it to the cluster's emulated nodes and Compute Engine instance groups. Node labels and taints can affect where pods are scheduled, but pods don't run containers.
fetchNodePoolUpgradeInfo	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — serves the operation from the stored node pool and the supported request fields. The pool's nodes don't run containers, and its upgrade state and version fields are stored metadata: no node is reimaged and there's no upgrade planner.
get	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — reads the stored node pool, or returns its not-found error. The pool's nodes don't run containers.
list	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — lists the cluster's stored node pools, with the supported filtering and pagination. Their nodes don't run containers.
rollback	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — serves the operation from the stored node pool and the supported request fields. The pool's nodes don't run containers, and its upgrade state and version fields are stored metadata: no node is reimaged and there's no upgrade planner.
setManagement	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — stores the autoUpgrade and autoRepair settings. No node is repaired, and there's no upgrade schedule.
setSize	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — changes the stored node pool and mirrors it to the cluster's emulated nodes and Compute Engine instance groups. Node labels and taints can affect where pods are scheduled, but pods don't run containers.
update	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — serves the operation from the stored node pool and the supported request fields. The pool's nodes don't run containers, and its upgrade state and version fields are stored metadata: no node is reimaged and there's no upgrade planner.

projects.zones.operations

3 of 3 implemented

Method	Status	Notes
cancel	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — keeps the record of an operation that has already finished, and marks a long-running operation that's still running as cancelled. Local observation: Vera 1.2.0-rc.3, 6 November 2026 — cancelling a finished CREATE_CLUSTER operation answered HTTP 200, and reading the operation afterward returned it, still DONE.
get	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — reads the stored record, or returns its not-found error.
list	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — lists the stored records in scope, with the supported filtering and pagination.

projects.zones

1 of 1 implemented

Method	Status	Notes
getServerconfig	Implemented	Source inspection: Vera 1.2.0 source, 6 November 2026 — reads the emulator's bundled catalog of versions and images, not Google Cloud's current list.