Cloud-Market Town was the largest trading post for a hundred miles around. At its center stood the Central Ledger House, and whether a deal was real or not came down to one thing: whether it was written into the Ledger. Once it was written in, the deal was final — nobody could unwind it.

But the Ledger House wasn’t open to the public. Every cart that wanted its goods entered into the Ledger first had to pass through the East Gate. Two officials stood there, day in and day out.

The first was the Annotator. He never turned a cart away, but he’d lift the tarp on every single one and add a few notes to the manifest — if the merchant forgot to list an origin, he’d fill in the customary default; if the tax amount was missing, he’d pencil in the standard rate; if town rule required this kind of cart to travel with an “escort wagon,” he’d hitch one on right there. By the time he was done, the manifest looked a bit different from when the cart arrived.

The second was the Inspector. He stood just past the Annotator, and he never touched anything — only checked. He went through the town’s rules line by line against the final manifest, the one the Annotator had already amended: was the weight right, was the tax filled in, was the escort wagon attached. If even one line failed, the cart was turned back on the spot, no exceptions — and that entry would never appear in the Ledger House’s book at all.

There was an unspoken rule in town: every cart, no matter how small, had to go through the full sequence — Annotator first, Inspector second — before it could enter. Even a single basket of cabbage.

The trouble was, these two officials also napped, took leave, or got pulled away by the mayor for other errands. So what was the East Gate supposed to do when that happened? Over the years, the town had tried two different policies, each carved into a stone tablet on either side of the gate.

The left tablet read: “Better empty than wrong” — if an official wasn’t at his post, the gate simply closed. Not a single cart got through until he came back. Lines could stretch for miles and goods piled up outside the walls, but the Ledger House would never end up with an entry nobody had actually checked.

The right tablet read: “Better wrong than empty” — if an official wasn’t there, the gate stayed open and carts rolled straight through into the Ledger. The market never stalled, but nobody could say for sure whether some of what got waved through during that window was underweight, untaxed, or missing its escort.

—by now you’ve probably recognized it: this East Gate arrangement is really Kubernetes/OpenShift’s admission webhook mechanism, and its failurePolicy setting: Ignore (fail open, “better wrong than empty”) versus Fail (fail closed, “better empty than wrong”).

What it is, and why it matters Whenever someone submits an object to the API server — creating or updating a Pod, a ConfigMap, whatever — that object passes through a chain of admission webhooks before it’s actually written to etcd. First come the mutating webhooks, which can modify the object itself (filling in defaults, injecting a sidecar container). Then come the validating webhooks, which only inspect the final result and can reject the request outright if it fails a check. This chain is the chokepoint where cluster-wide policy gets enforced — OPA/Gatekeeper policy checks and Istio’s automatic sidecar injection both run through it. But it’s also a real risk: each webhook call is a network round-trip that adds latency to every single request, and if the Service or Pod backing a webhook becomes unavailable or times out, failurePolicy decides the cluster’s fate. Set it to Fail, and that entire class of resource may become impossible to create cluster-wide. Set it to Ignore, and your policy silently stops being enforced during the outage — with nobody the wiser.

Metaphor mapping

• Central Ledger House → etcd (the persistent store)
• East Gate → the API server’s admission control entry point
• The Annotator → mutating admission webhook
• The Inspector → validating admission webhook
• Annotator-then-Inspector order → the fixed order of the admission chain (mutating runs before validating)
• Filling defaults / hitching an escort wagon → the mutation a webhook applies to the object (defaults, sidecar injection, etc.)
• Checking the manifest line by line → the validating webhook’s check logic
• The two stone tablets for when officials are absent → failurePolicy: Ignore (fail open) vs Fail (fail closed)
• Long lines outside the gate vs. bad goods slipping into the Ledger → the availability cost of fail-closed vs. the safety cost of fail-open