Kubernetes networking, handled.
We help platform teams adopt service meshes and move from Ingress to the Gateway API. We'll assess what you have, write a real plan, and do the work with your engineers, not around them.
Book a consultation See servicesThe problem
The cluster edge is shifting under your feet
ingress-nginx is retired. The controller sitting in front of most production Kubernetes clusters no longer gets new features or guaranteed security fixes. If you're running it, you now own a migration to the Gateway API. That means a new resource model, a new controller, and a pile of annotations that don't translate cleanly.
Meanwhile, service-to-service traffic keeps getting more complicated. mTLS requirements, multi-cluster routing, and observability gaps all point toward a service mesh, which is a powerful tool that's easy to adopt badly.
None of this is unsolvable. It's just rarely anyone's day job. It happens to be ours.
Services
Deep help on a narrow set of problems
Ingress to Gateway API migration
We move you off ingress-nginx, or whatever legacy controller you're running, and onto the Gateway API. First we inventory your Ingress resources and annotations, then we pick a Gateway implementation that fits your platform, then we cut traffic over piece by piece with both stacks running in parallel. No big-bang switchover, no weekend heroics.
Service mesh adoption & operations
Thinking about Istio, Linkerd, or Cilium? We'll help you figure out whether you actually need a mesh before you commit to running one. If the answer is yes, we design the rollout with you: mTLS, traffic policy, upgrade strategy, and the observability you'll need to operate it without guessing.
Kubernetes networking advisory
Sometimes you just want experienced eyes on a design before you commit to it. We review north-south and east-west architecture: load balancing, multi-cluster connectivity, DNS, network policy, and traffic management. You get honest feedback and specific recommendations, in writing.
How we work
Fixed scope, no open-ended retainers
Assess
We start by mapping what you actually have: controllers, meshes, annotations, traffic patterns. A lot of it is usually fine. The point is figuring out what really needs to change.
Plan
You get a written plan with clear phases, rollback points, and honest effort estimates. Your team reviews it and pokes holes in it before anything moves.
Migrate & enable
We do the work with your engineers, pairing through the cutover. When we leave, your team knows how to run the new stack because they helped build it.
Why Mesa Ops Partners
Practitioners, not a bench
Independent
We don't resell anything, and nobody pays us a kickback. If Envoy Gateway fits you better than Istio, we'll say so. If the boring option is the right one, we'll say that too.
Production-grounded
We've run Kubernetes networking in production. Our advice comes from upgrades that broke traffic at 2 a.m., not from conference talks.
Enablement-first
The goal is your team running the stack without us. Every engagement ends with runbooks, documented decisions, and engineers who understand why things are set up the way they are.
Narrow on purpose
We do Kubernetes networking: ingress, Gateway API, and service mesh. That's it. We'd rather be great at one thing than okay at ten.
FAQ
Common questions
How long does an Ingress to Gateway API migration take?
Most single-cluster migrations take two to six weeks. The big variables are how many Ingress resources you have and how much controller-specific annotation logic they carry. We run the old and new stacks side by side, so the cutover happens in small, reversible steps rather than one scary weekend.
Why do I need to migrate off ingress-nginx?
The project is retired, so it no longer gets feature development or guaranteed security fixes. An unmaintained proxy at the edge of your cluster is a risk that only grows. The supported path forward in the Kubernetes community is the Gateway API with an actively maintained implementation.
Do I actually need a service mesh?
Honestly, often no, and we'll tell you if that's the case. A mesh earns its complexity when you need mTLS between services, fine-grained traffic policy, or consistent L7 observability across a lot of teams. If your needs are narrower than that, simpler options usually win, and part of our job is helping you make that call.
Which Gateway API implementation should I choose?
It depends on your platform. Teams that lean on cloud load balancers often use their provider's implementation. Teams that want portability tend to look at Envoy Gateway, Cilium, or Istio's gateway. We don't have a horse in that race, so the recommendation comes from your traffic, your tooling, and your team's capacity.
How do engagements work?
Fixed scope, three steps. We assess your current stack, write a plan with rollback points your team can review, then execute it together. When it's done, it's done. We don't do open-ended retainers.
Get started
Tell us where things stand
Send a note about where your cluster networking is today. We'll show up to the first call with questions, not a pitch deck.
Book a consultation kacey@mesaopspartners.com