 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
CHICAGO — Incoming traffic looking to access your network and platform probably uses the network’s ingress. But the ingress carries with it scaling, availability and security issues.
For instance, said Mike Stefaniak, senior product manager at NGINX, in this episode of The New Stack Makers podcast, once you have several teams working on the same ingress, inside the same Kubernetes cluster, “It’s a lot of hands on the same resource. And that can cause a lot of friction between the teams.
“And I’ve definitely been on teams before where they have knocked out other teams because oh, we made an update all that ended up changing it in such a way that no traffic can get in now. Oh, crap. It’s all hands on deck and we’ve got an incident.”
A network ingress is something of a blunt instrument, Stefaniak and Kate Osborn, a software engineer at NGINX, suggested in this episode of TNS Makers recorded On the Road at KubeCon + CloudNative Con North America.
“One of the biggest issues is it’s not extensible,” Osborn said. “So it’s a very simple resource. But there’s a bunch of complex routing that people want to do. And in order to do that, they’ve had to add custom annotations”
The introduction of the open source Kubernetes Gateway API into general availability in October offers an alternative to network ingress for incoming traffic. NGINX has also introduced the NGINX Gateway Fabric, which offers an implementation for the Kubernetes Gateway API, using NGINX as the data plane.
First proposed at KubeCon four years ago, version 1.0 of the Kubernetes Gateway API offers advantages over network ingress.
For starters, said Osborn, “it is extensible. There are points on multiple gateway API resources where you can reference a policy, which is a [custom resource definition], so that you actually get the nice validation there that you don’t get from annotations, and different implementations can create their own policies. And you can attach them there to make it extensible.”
In addition, every resource has an associated role, avoiding the problem of “multiple hands on the same resource” that Stefaniak referenced.
As Osborn clarified, “You can really cleanly apply [a role-based access control] policy, which keeps it more secure, and allows you to control what you care about without messing up anyone else that might be sharing the infrastructure.”
As the Kubernetes Gateway API begins to be adopted by developers, Stefaniak said he expects the early use cases to be greenfield, because network ingress use is so prevalent.
“Ingress has been around for a very long time, and probably will stay around for a very long time,” he said. “Because there’s companies that use it today has a lot of features, a lot of maturity behind it.”
Still, Osborn said, “the Gateway has a unique opportunity to unite the North-South traffic with the East-West. And there’s a GAMMA Initiative within the Gateway group that’s working on just that — being able to encompass all types of traffic in and out of the cluster. That’d be really cool to do that with one single, very expressive, role-oriented API. There’s lots of possibilities there.”
Check out the entire episode to learn more about the Kubernetes Gateway API. And connect with the community to help build the next version.
