Gke Observability
GoogleOfficialPublished by Google
- Skill
- Tool integration
- Cloud and DevOps
- Apache-2.0
- No issues found
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
This skill provides a comprehensive reference for configuring and diagnosing observability in Google Kubernetes Engine (GKE). It covers the setup of Cloud Logging, Cloud Monitoring, and Managed Service for Prometheus (GMP). It includes guidance on monitoring control-plane components, worker nodes, and pod health, as well as troubleshooting common issues like missing metrics, alert evaluation failures, and API server latency. The skill emphasizes the 'golden path' for configuration while highlighting critical caveats regarding billing, IAM permissions, and the non-default status of control-plane metrics.
What it does
- Configures GKE logging and monitoring components via gcloud commands.
- Provides LQL queries for diagnosing control-plane logs and Kubernetes events.
- Offers PromQL queries for monitoring cluster health, latency, and resource usage.
- Troubleshoots Managed Service for Prometheus (GMP) issues like unhealthy scrape targets.
- Explains how to interpret control-plane health metrics and maintenance windows.
- Guides users on enabling Dataplane V2 flow observability.
When to use it
- When setting up monitoring and logging for a new or existing GKE cluster.
- When diagnosing GKE control-plane issues like API server latency or admission webhook failures.
- When troubleshooting missing metrics or misconfigured PodMonitoring resources.
- When investigating pod eviction, preemption, or scheduling bottlenecks.
- When verifying cluster health during maintenance windows or upgrades.
Advantages
- Provides a standardized 'golden path' for comprehensive GKE observability.
- Includes specific guidance on avoiding common pitfalls like accidental billing or IAM permission errors.
- Offers actionable diagnostic queries for both Cloud Logging and Prometheus metrics.
- Clearly distinguishes between system-level metrics and control-plane specific observability.
- Includes mandatory usage attribution for CLI commands to ensure proper tracking.
Usage examples
- “How do I enable full monitoring and logging for my GKE cluster?”
- The agent provides the gcloud command to update the cluster with the recommended monitoring and logging components, while warning about billing impacts and the need for specific IAM permissions.
- “Why are my Prometheus metrics missing in GKE?”
- The agent guides the user to check PodMonitoring configurations, rule evaluation failures, and monitoring permission errors using the provided troubleshooting reference.
- “How can I check if my GKE control plane is healthy?”
- The agent explains how to use the kubernetes.io/cluster/kcp_healthchecks metric and provides a PromQL query to calculate the success rate of control-plane probes.
- “Show me how to find OOMKilled events in my cluster logs.”
- The agent provides an LQL query for Cloud Logging that filters for resource type k8s_event and the specific reason OOMKilling.
Install
Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/google/gke-observability/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip gke-observability.zip -d .agents/skills
Documentation by Google
GKE Observability
This reference covers monitoring, logging, and metrics configuration and troubleshooting for Google Kubernetes Engine (GKE). The golden path enables comprehensive observability including control-plane metrics and Managed Service for Prometheus (GMP).
MCP Tools:
get_cluster,list_k8s_events,get_k8s_logs,get_k8s_cluster_info,describe_k8s_resource. CLI-only:gcloud container clusters update --monitoring=...,gcloud logging read
Usage Attribution
Do not run live kubectl, gcloud, or curl commands unless the user names a
target cluster/project or asks to inspect a live cluster (output commands and
queries with placeholders, and skip Usage Attribution).
Before running any live command, read Usage Attribution,
prefix gcloud with CLOUDSDK_METRICS_REQUEST_ATTRIBUTION="agent-skills/1.0 (skill:gke-observability)",
and append agent-skills/1.0 (skill:gke-observability) to User-Agent headers
(never in generated scripts, Terraform, or user-facing code).
Sub-Skill Reference Routing (Progressive Disclosure)
Complete Reference Index (no
scripts/directory or unlisted reference files exist — do not runlson the skill folder; read only the matching reference below when answering deep diagnostic, metric, log, or GMP questions):
Control-Plane Metrics, Storage, Webhooks & Capacity: Read for GKE control-plane (KCP) VM CPU or RAM/memory usage questions (not publicly exposed) and customer-visible alternatives; cluster etcd / etcd-compatible storage left, quota & per-resource scalability limits; admission webhook latency, system namespace/Lease/upgrade exclusions,
APIServicediscovery bloat, client discovery caching bursts (/apis/custom.metrics.k8s.io,/apis/metrics.k8s.io) & proactive GKE Recommender insights; watch storms; controller-manager workqueue & scheduler lag; or control-plane headroom, VM autoscaling & node-count pre-scaling, network egress, connections (65k, no per-replica metric) & Protobuf.Cloud Logging, Audit Attribution, APF & API Server Traces: Read for
kube-apiserverslow-requestTrace[logs (trace.go& KEP-647);httplog.goclient load (user_agent,verb,apf_iseats); Cloud Audit Log noisy-neighbor, heavyLIST& unindexed CRDfieldSelectorscan tail-latency attribution; API Priority and Fairness (APF)429/504/404throttling;409 Conflicthot objects (ConfigMap->Leaseheartbeats) &RenewDeadline / 2leader-election timeouts;pods/execsaturation, Konnectivity (No agent available), disabled Cloud KMS keys, or in-cluster GCP IAM OAuth token webhook authorizer saturation.Cluster/Node/Pod Health, Maintenance & Managed Prometheus (GMP): Read for control-plane availability (
kubernetes.io/cluster/kcp_healthchecksrate ratio & ruling out KCP outages); maintenance windows (in_maintenance_window), zonal resize downtime & cluster access errors (EOF/masterAuthorizedNetworksConfig); node readiness, registration (AUTO_REPAIR_NODES, Private Google Access) & persistent node-pool labels; pod startup timelines, crashing pod logs,tolerationSeconds: 0mass eviction & Autopilot preemption; or multi-burn-rate SLO alerting (GlobalRules) & GMP / Grafana /PodMonitoringmanifests & troubleshooting.
Golden Path Observability Defaults
| Setting | Golden Path Value | Notes |
|---|---|---|
loggingConfig components | SYSTEM_COMPONENTS, WORKLOADS | Full workload logging |
monitoringConfig components | SYSTEM_COMPONENTS, STORAGE, POD, DEPLOYMENT, STATEFULSET, DAEMONSET, HPA, JOBSET, CADVISOR, KUBELET, DCGM, APISERVER, SCHEDULER, CONTROLLER_MANAGER | Full suite including control-plane |
managedPrometheusConfig.enabled | true | Google-managed Prometheus |
advancedDatapathObservabilityConfig.enableMetrics | true | Dataplane V2 flow metrics |
loggingService | logging.googleapis.com/kubernetes | Cloud Logging |
monitoringService | monitoring.googleapis.com/kubernetes | Cloud Monitoring |
Enabling Full Monitoring & Logging
Include all four caveats whenever providing a --monitoring or --logging
command so users avoid accidental metric loss, surprise billing, or silent IAM
failures:
Control-plane metrics and logs are NOT enabled by default. State this outright:
API_SERVER,SCHEDULER, andCONTROLLER_MANAGERare off on every new cluster (as areDCGM,CADVISOR,KUBELET, and kube-statePOD,DEPLOYMENT,STATEFULSET,DAEMONSET,HPA,STORAGE,JOBSET). OnlySYSTEMis enabled by default. Link to https://docs.cloud.google.com/kubernetes-engine/docs/how-to/control-plane-metrics and https://docs.cloud.google.com/kubernetes-engine/docs/how-to/view-logs#control_plane_logs.The flag replaces, it does not append. Passing
--monitoringor--loggingoverrides the existing component list; pass the full desired list includingSYSTEM.Control-plane and kube-state metrics bill per sample ingested via Managed Service for Prometheus (GMP). Mention the cost impact on large clusters; use
--monitoring=SYSTEMin non-production to reduce cost.Verify APIs and IAM permissions (
PermissionDenied). Checkgcloud container clusters describe {cluster_name} --region {region} --format="yaml(loggingConfig,monitoringConfig)", ensurelogging.googleapis.comandmonitoring.googleapis.comare enabled, and verify the node service account / GKE service agent hasroles/monitoring.metricWriterandroles/container.defaultNodeServiceAgent.
CLI flag vs. API enum spelling (mixing them fails the command):
Component gcloud --monitoring=monitoringConfigAPI enumSystem SYSTEMSYSTEM_COMPONENTSAPI server API_SERVERAPISERVERController mgr CONTROLLER_MANAGERCONTROLLER_MANAGER
# Enable golden path monitoring and control-plane logging suite
gcloud container clusters update {cluster_name} --region {region} \
--monitoring=SYSTEM,API_SERVER,SCHEDULER,CONTROLLER_MANAGER,STORAGE,POD,DEPLOYMENT,STATEFULSET,DAEMONSET,HPA,JOBSET,CADVISOR,KUBELET,DCGM \
--logging=SYSTEM,WORKLOAD,API_SERVER,SCHEDULER,CONTROLLER_MANAGER \
--quiet
# Enable Managed Prometheus and Dataplane V2 flow/policy observability
gcloud container clusters update {cluster_name} --region {region} \
--enable-managed-prometheus \
--enable-dataplane-v2-flow-observability \
--quietCore GKE Metrics & Alerting Baseline
Explicitly name Google Cloud Monitoring when proposing dashboards and
alerts, and cover cluster/node CPU and memory capacity, pod restarts
(CrashLoopBackOff), volume space exhaustion, and API server latency
(apiserver_request_duration_seconds). Direct control-plane VM CPU/RAM metrics
are not publicly exposed — read
Control-Plane Metrics, Storage, Webhooks & Capacity
whenever asked about control-plane VM CPU/memory or deep control-plane metrics.
| Metric | Source | Use / Alert Threshold |
|---|---|---|
apiserver_request_duration_seconds | API Server (GMP) | Control-plane latency (Alert: P99 > 5s) |
scheduler_scheduling_attempt_duration_seconds | Scheduler (GMP) | Current GKE scheduling latency (scheduler_schedule_attempts_total{result="error"} > 0) |
container_cpu_usage_seconds_total | cAdvisor (Node) | Worker-node container CPU usage |
container_memory_working_set_bytes | cAdvisor (Node) | Worker-node container memory usage |
kubernetes.io/node/cpu/core_usage_time | Cloud Monitoring | Node CPU usage (kubernetes.io/node/memory/used_bytes for memory) |
kube_pod_status_phase | kube-state-metrics | Pod lifecycle phase (requires deploying GMP or self-managed kube-state-metrics) |
kube_pod_container_status_restarts_total | kube-state-metrics | Pod crash loops (Alert: > 5 in 10m; requires kube-state-metrics) |
kube_node_status_condition | kube-state-metrics | Node readiness (condition="Ready", status!="True"; or kubernetes.io/node/status_condition) |
kubelet_volume_stats_used_bytes / capacity | Kubelet | PVC capacity utilization (Alert: > 85%) |
DCGM_FI_DEV_GPU_UTIL | DCGM (GMP) | GPU utilization (Alert: > 95% sustained) |
Live Resource Usage & Cloud Logging Queries
Use kubectl top for live usage (no MCP or gcloud equivalent):
kubectl top pods --all-namespaces --sort-by=cpu
kubectl top nodes
kubectl top pods --containers -n {namespace}Use gcloud logging read (or Cloud Logging Log Explorer) with LQL filters:
# Control-plane component logs (requires API_SERVER / SCHEDULER / CONTROLLER_MANAGER enabled)
gcloud logging read 'resource.type="k8s_control_plane_component" AND resource.labels.cluster_name="{cluster_name}"' --project {project_id} --limit 50 --quiet
# Container errors: resource.type="k8s_container" AND resource.labels.container_name="{container_name}" AND severity>=ERROR
# OOMKilled events: resource.type="k8s_event" AND jsonPayload.reason="OOMKilling"
# FailedScheduling: resource.type="k8s_event" AND jsonPayload.reason="FailedScheduling"
# Cloud Audit Logs: resource.type="k8s_cluster" AND logName:"cloudaudit.googleapis.com"
# Dataplane V2 network policy / packet drop logs: logName:"policy_action" AND jsonPayload.disposition="DENY"Distributed Tracing, Profiling & Recent Additions
Cloud Trace & OpenTelemetry: Deploy the OpenTelemetry Collector (
googlecloudexporter with Workload Identity) or enable Managed OpenTelemetry for GKE (Preview) on GKE 1.34.1-gke.2178000+ (gcloud beta container clusters update {cluster_name} --region {region} --managed-otel-scope=COLLECTION_AND_INSTRUMENTATION_COMPONENTS).Cloud Profiler: Continuous low-overhead production CPU/memory profiling.
PSI (Pressure Stall Information) metrics: cAdvisor
container_pressure_{cpu,memory,io}_{waiting,stalled}_seconds_totalvia GMPClusterNodeMonitoring(GKE 1.35+).
Supporting Links
Files
- ATTRIBUTION.mdAdded by AutoGineer852 B
- LICENSELicence file added by AutoGineer11.1 KiB
- SKILL.md13.3 KiB
- references/attribution.md1.8 KiB
- references/cluster-node-pod-health-and-gmp.md12.9 KiB
- references/control-plane-metrics-and-storage.md14.2 KiB
- references/logging-audit-and-apiserver-traces.md13.8 KiB
references/logging-audit-and-apiserver-traces.md
Cloud Logging, Audit Attribution, APF & API Server Traces
Table of Contents
1. API Server Slow-Request Trace Logs (
trace.go) (Lines 11–54)2. Heavy API Clients (
httplog.go), Audit Attribution & SlowLISTs (Lines 56–117)3. API Priority & Fairness (APF) Throttling (
429/504/404) (Lines 119–143)4. Hot-Object
409 Conflicts & Leader-ElectionRenewDeadlineTimeouts (Lines 145–169)5.
pods/exec, Konnectivity, Cloud KMS & IAM Webhook Authorizer (Lines 171–211)
1. API Server Slow-Request Trace Logs (trace.go)
kube-apiserver component logs (API_SERVER) are an optional feature that is
not enabled by default and must be explicitly turned on
(--logging=SYSTEM,WORKLOAD,API_SERVER). State this and link to
https://docs.cloud.google.com/kubernetes-engine/docs/how-to/view-logs#control_plane_logs
when recommending apiserver log analysis.
Search for
traceorTraceentries: Queryapiservercomponent logs (resource.type="k8s_control_plane_component" AND resource.labels.component_name="apiserver") fortraceorTrace(e.g.,textPayload:"Trace[").Structure & interpretation:
kube-apiserveruses upstreamk8s.io/utils/trace(trace.go) to log requests exceeding a latency threshold (typically 500ms). The header records the operation ("List","Get","Create","Patch"),url,user-agent,audit-id,clientIP, start timestamp, andtotal time. Nested sub-traces appear in brackets[...]and steps exceeding the step threshold appear as---"<StepName>" <duration>ms.Distinguishing storage bottlenecks vs. slow-client serialization:
Slow backend storage (
etcd) read or write:cacher.GetList,List(recursive=true) etcd3, orGuaranteedUpdate etcd3(withinitial value restored/Txn call completed) dominatestotal time:I1015 11:36:56.835120 10 trace.go:236] Trace[123456789]: "List" url:/api/v1/pods,user-agent:my-controller/v1.0.0,audit-id:11111111-2222-3333-4444-555555555555,client:10.0.0.1 (15-Oct-2026 11:36:49.460) (total time: 7374ms): Trace[123456789]: ["List(recursive=true) etcd3" 6890ms (11:36:49.461)] Trace[123456789]: ---"Objects listed" 6891ms (11:36:56.352) Trace[123456789]: ---"SerializeObject" 480ms (11:36:56.832)Slow client / response serialization bottleneck:
"Objects listed"is fast, while"SerializeObject"and---"Write call succeeded"(or---"Write call failed") dominatetotal timebecause a slow or bandwidth-constrained client takes seconds to read a large payload:I1015 11:40:12.104512 10 trace.go:236] Trace[987654321]: "List" url:/api/v1/pods,user-agent:slow-watcher/v0.1,audit-id:aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee,client:10.0.0.2 (15-Oct-2026 11:40:01.002) (total time: 11102ms): Trace[987654321]: ---"Objects listed" 45ms (11:40:01.047) Trace[987654321]: ["SerializeObject" 11055ms (11:40:01.047)] Trace[987654321]: ---"Write call succeeded" 11054ms (11:40:12.101)
Upstream docs & future evolution (cite both): Link to https://github.com/kubernetes/utils/blob/master/trace/README.md for
trace.goand mention https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/647-apiserver-tracing (KEP-647: APIServer Tracing via OpenTelemetry) as a possible future change.
2. Heavy API Clients (httplog.go), Audit Attribution & Slow LISTs
httplog.goHTTP access logs: Requires enablingAPI_SERVERcomponent logs (--logging=SYSTEM,WORKLOAD,API_SERVER; link to https://docs.cloud.google.com/kubernetes-engine/docs/how-to/view-logs#control_plane_logs). State explicitly that thehttplog.golog structure is very stable across Kubernetes releases (making regex extraction and Log Analytics queries reliable), and include this example log line:I1015 11:36:56.835535 10 httplog.go:137] "HTTP" verb="GET" URI="/api/v1/namespaces/default/pods" latency="7.374935s" userAgent="my-controller/v1.0.0 (linux/amd64)" audit-ID="11111111-2222-3333-4444-555555555555" srcIP="10.0.0.1:12345" apf_pl="workload-low" apf_fs="everybody" apf_iseats=1 apf_fseats=0 apf_additionalLatency="0s" apf_execution_time="7.374765s" resp=200Key fields:
user_agent(userAgentin raw text) identifies the client binary/operator;verbseparates expensiveLISTor mutatingPATCH/UPDATEcalls from lightweightGETs;apf_iseats(withapf_fseatsandapf_execution_time) measures API Priority and Fairness (APF) concurrency seats occupied (apf_iseats * apf_execution_timereveals top concurrency consumers).
Noisy-neighbor attribution & slow/heavy
LISTqueries: Because Prometheus metrics omit caller/user-agent labels to prevent cardinality explosion, always pairapiserver_request_total(grouped byverb,resource, andcodeto quantify QPS/error spikes) with GKE Cloud Audit Logs (which attribute requests to callers out-of-the-box even when optionalAPI_SERVERlogs are off):sum by (verb, resource, code) (rate(apiserver_request_total[5m]))Query GKE Cloud Audit Logs (
cloudaudit.googleapis.com/activityanddata_access) andkube-apiserverTrace[/httplog.gologs, aggregating byprotoPayload.authenticationInfo.principalEmail,protoPayload.requestMetadata.callerSuppliedUserAgent, and target resource/namespace.Correlate audit log offender attribution with
apiserver_request_total(grouped byverb,resource, andcode),apiserver_request_duration_seconds(verb="LIST"),apiserver_response_sizes(verb="LIST"), per-resource storage size (apiserver_resource_size_estimate_bytesorkubernetes.io/master/apiserver/resource_size_estimate_bytes, grouped bygroupandresource), andapiserver_watch_list_duration_seconds.Remediation: Throttle or fix high-QPS client workloads, refactor or paginate expensive cluster-wide
LISTqueries (e.g.,external-dns,argocd-server, or custom operators listing all pods), useresourceVersion="0"(watch cache reads), or switch to cachedSharedInformerwatches.
Unindexed CRD custom
fieldSelectorscans & in-flight tail latency: Custom resources are stored as JSON and have no secondary indexes in backend storage or thekube-apiserverwatch cache for customfieldSelectorpaths (even whenspec.versions[].selectableFieldsis declared; onlymetadata.nameandmetadata.namespaceare indexed). EveryLISTwith a customfieldSelector(e.g., across 50,000 CRD instances) forceskube-apiserverto scan and JSON-deserialize every object into memory (unstructured.Unstructured) to evaluate the filter—acquiring multiple API Priority and Fairness (APF) concurrency seats (apf_iseatsinhttplog.go,apiserver_flowcontrol_priority_level_seat_utilization) for the full scan duration (apf_execution_time) and churning Go heap/garbage collection, which queues concurrent requests (apiserver_flowcontrol_request_wait_duration_seconds) and causes in-flight tail-latency regressions (apiserver_request_duration_seconds, visible in opt-inAPI_SERVERTrace[andhttplog.gologs). Replace customfieldSelectorLISTs with indexedlabelSelectors or watch via aSharedIndexInformerwith controller-sidecache.Indexers(IndexField).
3. API Priority & Fairness (APF) Throttling (429 / 504 / 404)
When workloads, batch job scripts, or CI runners fail with HTTP 429 Too Many Requests or 504 Gateway Timeout (context canceled):
Metrics to query: Query
apiserver_flowcontrol_rejected_requests_total,apiserver_flowcontrol_current_inqueue_requests,apiserver_flowcontrol_request_wait_duration_seconds, andapiserver_flowcontrol_priority_level_seat_utilizationgrouped bypriority_levelandflow_schema, plusapiserver_request_totalby status code (404,429,504) and verb (GET,LIST).Log attribution (
API_SERVERlogs): Enable control-plane logging (API_SERVERvia--logging=SYSTEM,WORKLOAD,API_SERVER) to pull detailed information onuser_agent(userAgent), target resources (URI/requestURI), and source IPs (src_ip/srcIP/sourceIPs) fromkube-apiserverlogs (or Cloud Audit Logs) for unpaginatedLISTcalls, tight404GETpolling loops, or single-digit millisecond?timeout=requests.How APF works & remediation: APF throttles noisy clients in lower-priority lanes (such as
workload-low) to protect critical system traffic (system,leader-election,node-high). Pace client burst QPS, replace tightGET/LISTpolling withSharedInformerwatches, add exponential backoff and client-side caching on404s, increase overly short client request timeouts, or isolate noisy service accounts into a dedicatedFlowSchemaandPriorityLevelConfiguration.
4. Hot-Object 409 Conflicts & Leader-Election RenewDeadline Timeouts
Hot-object write contention (
409 Conflict& slowPATCH/PUT): When runaway controllers fight over or hot-loop updates against a singleConfigMap,CustomResourceDefinition, orLease, query Cloud Audit Logs (cloudaudit.googleapis.com/activity) grouped byprotoPayload.resourceName,protoPayload.methodName(updateorpatch), andprotoPayload.requestMetadata.callerSuppliedUserAgent(orprotoPayload.authenticationInfo.principalEmail) and inspectkube-apiserverGuaranteedUpdateTrace[logs to pinpoint the hot object and responsible agent. Mitigate by reducing the operator's checkpoint/sync frequency (e.g., increasingrefreshInterval) and lowering client QPS; if pods or microservices write frequent status heartbeats or distributed locks into a single sharedConfigMap(causing serialized optimistic-concurrencyresourceVersioncontention and409 Conflictstorms), migrate per-replica heartbeats or locks to dedicatedcoordination.k8s.ioLeaseobjects.Leader-election
RenewDeadline / 2(?timeout=5s) timeouts: When third-party operators (e.g., KEDA, VictoriaMetrics) lose Lease leadership withcontext deadline exceededafter 5s despite higher general client timeouts, explain thatclient-go'sleaderelectionpackage sets the per-request HTTP timeout on LeasePUTrenewals toRenewDeadline / 2(so defaultRenewDeadline: 10senforces?timeout=5sonrequestURIin Cloud Audit Logs andTrace[logs). Increase the operator's leader-election flags (e.g.,--leader-elect-lease-duration=60sand--leader-elect-renew-deadline=40s).
5. pods/exec, Konnectivity, Cloud KMS & IAM Webhook Authorizer
Excessive
pods/execsaturating webhooks & Konnectivity: Whenwarden-validating.common-webhooks.networking.gke.ioadmission timeouts (10s) or500 error dialing backend: dial timeout, backstoperrors occur onkubectl exec, query Cloud Audit Logs forio.k8s.core.v1.pods.exec.get(connect) volume and correlate withapiserver_admission_webhook_admission_duration_secondsforwarden-validating(highpods/execvolume evaluates against admission webhooks and Konnectivity tunnels). Replacekubectl exec-based metrics scraping and health checks with Kubelet/metrics/cadvisor, Cloud Monitoring container metrics (k8s_container), and direct pod-to-pod HTTP/gRPC endpoints.Konnectivity (
No agent available), firewall, &ip-masq-agent: When webhook calls orkubectl exec/logsfail withNo agent availableorcontext deadline exceeded, checkkube-apiserverlogs (resource.type="k8s_control_plane_component") forNo agent availableor dial failures, inspectkonnectivity-agentpods (kubectl get pods -n kube-system -l k8s-app=konnectivity-agent), verify VPC firewall rules between the control-plane CIDR and node/pod CIDRs (ports10250,8132, and webhook ports), and check theip-masq-agentConfigMap so pod-to-API-server and API-server-to-webhook traffic is not masqueraded or blocked.Disabled Cloud KMS keys breaking encryption (
kms-provider-0/failed to get dek primitive): Inspectgcloud container clusters describe(databaseEncryptionconfig and error status) and query Cloud Audit Logs forcloudkms.googleapis.com(DisableCryptoKeyVersion,DestroyCryptoKeyVersion, orPermissionDeniedonEncrypt/Decrypt). Re-enable the disabledCryptoKeyVersion, verify the GKE service agent hasroles/cloudkms.cryptoKeyEncrypterDecrypter, and follow https://docs.cloud.google.com/kubernetes-engine/docs/how-to/encrypting-secrets#reencrypt-secrets to re-encrypt existing Secrets.In-cluster GCP IAM OAuth tokens saturating the GKE IAM webhook authorizer (
Failed to make webhook authorizer request): When high-QPS in-cluster clients (Helm, operators) authenticate with GCP IAM OAuth Bearer tokens without matching Kubernetes RBAC bindings,kube-apiserverinvokes the external GKE IAM webhook authorizer on every request, which throttles/times out under load. Inspect Cloud Audit Logs (authenticationInfoandauthorizationInfo) and migrate in-cluster workloads to native KubernetesServiceAccounttokens bound via Kubernetes RBAC (RoleBinding/ClusterRoleBinding) so authorization is evaluated locally in memory.
Requirements and compatibility
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Needs: Needs a command-line tool, Needs Node.js
Security
No issues found by our static scan· No issues found
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Published by
- Publisher
- Google (Official)
- Source
- google/skills · skills/cloud/gke-observability · commit 2194d3b
- Licence
- Apache License 2.0 (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
AutoGineer is not affiliated with or endorsed by Google.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download gke-observability.zip