Latest report, No. 29: The API that takes ownership seriously
The best thing about the Kubernetes Gateway API isn’t a new feature. It’s the answer to a question the old APIs never asked: Who owns this?
- No.
- 29
- Date
- Topic
- Gateway-api
- Sources
- 6
Field notes from service mesh operations
Each report starts with a real situation from running Istio and Envoy, then shows the pattern behind it and what it means for platform and security leaders. All reports first appeared on LinkedIn, in German.
The best thing about the Kubernetes Gateway API isn’t a new feature. It’s the answer to a question the old APIs never asked: Who owns this?
Four posts later and no further than before? So which is it, Ambient or sidecar? It depends. On what? The following grid with five rows helps.
During the migration to Ambient, traffic can vanish from the dashboard without being gone. A staged plan with checkpoints catches that.
Ambient gets a lot right. For hard enterprise requirements, I’m staying with sidecars for now. The reason for that doesn’t show up in any benchmark.
A policy that looked harmless in review cuts connections in Ambient that it was meant to allow. The reason lies one layer down.
A proxy update in the sidecar model means: every pod restarts, or someone stacks the maintenance windows of twenty teams on top of each other.
The sign-off came from staging, green across the board. Three weeks later a path burns in production that staging never saw.
“The sidecar costs us too much.” or “It is negligible.” Two sentences from almost every mesh debate. Hardly anyone has measured them.
Sidecar upgrade sounds like infrastructure. For your pods it means: restart. For your clients it means: it depends.
The most important question in a mesh upgrade is not how you move forward. It is how you get back when the first wave creaks.
In many backlogs there is a ticket that is about to celebrate a birthday. It is called ‘mesh upgrade’ and has been wandering from sprint to sprint for months.
The workload certificates in your mesh are short-lived and rotate automatically. For years, without anyone looking. That is exactly why nobody looks at the rest of the chain anymore either.
The egress topic has barely hit the table when the reflex kicks in: “We will build an egress gateway, then everything runs through one place.” It is often decided before anyone asks what it is actually supposed to enforce.
On the inside, your mesh is now Zero Trust: mTLS on STRICT, default on deny. And towards the outside? There it calls whoever it wants.
After the move to STRICT in the previous report, every connection in the mesh is encrypted and mutually authenticated. Sounds like mission accomplished. Except: every workload is still allowed to talk to every other one.
“mTLS is enabled”, says the team. When asked, it turns out the mesh default has been on PERMISSIVE since the rollout. That is not enabled. That is a maybe.
On September 30, AWS turns off App Mesh. That’s no longer a deprecation warning. It’s a shutdown date.
Almost every mesh runs the same engine. Today I take it apart. Don’t fear the depth, there are exactly four parts.
Istio, Kuma, Consul, App Mesh, Gloo. Five names, and under the hood the same proxy five times: Envoy.
Ten Field Reports. Almost all of them had the same root cause. And it was never in Istio.
During an incident, most people open Grafana first. Everything green. That’s exactly where the team gets stuck.
Two teams last week: one guesses for three hours, one is done in twenty minutes. The difference isn’t talent. It’s this one path.
Most mesh incidents aren’t hard. They just look that way.
Closing the gap without taking away tenant autonomy.
Letting tenants create their own VirtualServices opens a door to MITM inside your own mesh.
From Soltau, live at CloudLand: who’s actually responsible in the mesh?
20, 100, 500+ configuration objects - and no one dares to delete a thing.
Istio ships a minor release every three months. Sounds predictable.
mTLS enabled everywhere, dashboards green - and nobody can say what actually runs encrypted.