On GKE Autopilot, a NetworkPolicy blocks the API server and Postgres takes the blame

A team deploying a PostgreSQL cluster with the CloudNativePG operator on GKE Autopilot hit an admission webhook timeout that stopped the cluster from ever being created ^[1]. The interesting part is where the fault was not: the problem was first seen with EnterpriseDB Postgres for Kubernetes, but the authors report the cause was not specific to EDB or to PostgreSQL at all, and instead came down to how Kubernetes control-plane traffic interacts with restrictive NetworkPolicies on Autopilot ^[2][3].

The error message points squarely at Postgres, which is why this burns time. The API server returns a failure calling webhook `mcluster.cnpg.io`, with a `dial tcp <webhook-ip>:9443: i/o timeout` against the CNPG webhook service ^[5]. Everything an operator would normally check was fine: the webhook Pod was running, the Service was healthy, DNS resolved, and other Pods in the cluster connected to the webhook without trouble ^[6]. One client could not reach it, and it was the Kubernetes API server ^[7]. That is the diagnostic signature worth memorising: a webhook that is healthy and reachable from application Pods while the API server reports timeouts ^[13].

The environment was GKE Autopilot on Kubernetes v1.35 with the CNPG operator and admission webhooks enabled ^[4]. The same deployment worked on a GKE Standard cluster ^[8], which is the shape of an infrastructure difference rather than a workload bug. Google's own documentation tells you to allow control-plane traffic using the cluster's `masterIpv4CidrBlock` when writing firewall rules for admission webhooks ^[9]. On Autopilot the control plane is fully managed by Google and that control-plane IP range is not exposed to the customer in the same way ^[10], so the documented recipe does not have an ingredient you can obtain.

The dead ends are instructive because they are the ones most people try first. Moving the webhook port from 9443 to 443 did not help; raising the webhook timeout from 10 seconds to 30 did not help; reviewing and updating firewall rules did not help ^[11]. Tripling the timeout budget changes nothing when there is no path at all ^[17]. Setting `failurePolicy: Ignore` did clear the symptom, and the authors are explicit that this is not a production answer ^[12], which is correct: it converts a blocked admission call into an unvalidated one, on the resource type least suited to skipping validation.

The blast radius is wider than one database. The writeup lists the CNPG operator, EDB Postgres for Kubernetes, applications built on CloudNativePG, other Kubernetes workloads using admission webhooks, and any workload protected by restrictive NetworkPolicies on Autopilot ^[14]. Any operator you install into a namespace with a tight policy is exposed to the same class of failure, and it will surface as that operator's bug.

What to watch: the authors say they took this to the Google Cloud Support networking team ^[15], and the article states it covers the NetworkPolicy change that resolved the issue ^[16]. The text supplied to this desk breaks off mid-sentence at exactly that point, before the policy itself is shown ^[18], so treat the specific rule as unverified until you read it. In the meantime the actionable part is the triage order: when a custom resource creation times out on a webhook, test reachability from the control plane separately from reachability from Pods, and compare Autopilot against Standard before touching the operator.