Are you planning to replace Ingresses and/or service mesh specs with Gateway API?

@jordangregory9852

Жыл бұрын

Yes, I am :) I’ll just wait till it’s faster lol

@DevOpsToolkit

Жыл бұрын

That's correct. It's still too early to adopt it, but not too early to experiment and prepare.

@dirien

Жыл бұрын

Yes! Started to use contour instead of nginx and will switch to gateway soon!

@PS-xn8ej

Жыл бұрын

do this give me some more visibility about services like in kiali ?

@DevOpsToolkit

Жыл бұрын

No. This is all about standardization of the spec. As a results, we should be able to specify what we need independently of the implementations.

Writing you from 2024 - my Customer wants me to deploy Istio, I think Gateway is what I need. Your channel is a treasure!

Just wanted to note that I thoroughly enjoy your content and know how much effort goes into making one . Thank you for what you do.

@DevOpsToolkit

Жыл бұрын

Thanks a ton for saying that. It helps me to keep going to know that my work is useful to others.

These are my favorite type of videos! Keeping me ahead of the game. Thank you!!

Great video, love to see the word "silly" in almost all examples!

Great video, Viktor. I find your videos very informative & easy to follow. I wanted to know about k8s-GA and the first thing i did was to search for it in your channel :) Thank you!

People, don't be lazy and hit the 'like' button. With 15K views a I can't believe there so low likes... Viktor, i have seen many videos in your channel, they are very educative and adds a lot of value to the environment. Thank you for all the effort you make on those! Regarding Gateway API, I see a lot of fast development in all the providers, I hope to see this a mainstream soon. Thanks for being in the cutting edge and sharing all this topics with nice examples!

I’ll keep an eye on this, I’ll be definitely doing some test on my cluster with this. I agree that service mesh are really complicated, my team doesn’t want to implement any service mesh due to the overhead as we only need some simple features. I will probably try to suggest this when it’s a bit more mature. Great video!

@LampJustin

Жыл бұрын

Btw Check out cilium they have a very very low overhead service mesh based on bpf tech ;)

@DevOpsToolkit

Жыл бұрын

API Gateway is all about the spec, and not implementation. Cilium is already working on adopting it.

That's very exciting! That'd probably also mean that you could have middleware such as a oauth/oidc gateway in the middle with whatever provider you use

@DevOpsToolkit

Жыл бұрын

True. That'll depend on implementations of the API.

I guess that some miss-use of annotations will be present between implementations again in order to be more competitive on the market by providing more features than specs offer. BTW looking forward to see you in Belgrade's conference this autumn :)

IMO It’s the most exciting k8s feature in last few years. I’m tired of my traffic controller of choice not being supported by this tool or partially supported by this other tool. Too bad I’m mostly using EKS, so probably won’t be mature enough for next 2 years 😅

@DevOpsToolkit

Жыл бұрын

Judging by the rate of advancement, I think we'll see stable implementations much sooner than that.

@fenarRH

Жыл бұрын

@@DevOpsToolkit Jun said EKS, not any distro that you like Lol

@DevOpsToolkit

Жыл бұрын

True. I overlooked that part of the message. My guess is that EKS will not support it out of the box for a long while (if ever). But, using one from one of the vendors should do.

Thank you, very informative. It seems to me this will also replace load balancers so I'll definitely wait for MetalLB to support this before I touch it. The name is a bit unfortunate since it'll make it hard to google, so generic.

It'd be interesting an update to this video.

Thanks!

@DevOpsToolkit

Жыл бұрын

Thanks a ton

It would be nice to have that with pod-to-pod communication (east-west). linkerd does not come with gateway so this could be a nice combination

Interesting times! Do you think that this will have any affect on the number of implementations available and their features? Are there any implementations you think will do well or badly out of this new standard?

@DevOpsToolkit

Жыл бұрын

It's too soon to say which implementation will prevail. For now, the focus is on having a standard spec on top of which we will see different implementations. The important part is to have a standard spec instead of having every project/vendor inventing its own.

I'm not sure you made the case for service mesh replacement. SMI (service mesh interface) already exists for east-west traffic (with mTLS). But there is a lot of overlap. See GAMMA Initiative.

@DevOpsToolkit

Жыл бұрын

SMI is indeed an attempt to standardize, but it never got widely adopted (beyond linkerd and a few other projects). My hope is that gateway API will succeed where SMI failed (adoption). So far, judging by the list of those working on it's implementations, it is looking very positive.

@joebowbeer

Жыл бұрын

@@DevOpsToolkit SMI, which resulted from a collaboration of Microsoft, Bouyant, HashiCorp, Solo, Kinvolk, and Weaveworks, has a different spin on the impact of their spec-first effort and its relationship with GA. See GAMMA Initiative. Any replacement of service mesh appears to be much farther out than a replacement for ingress. I'm no expert on this, but I can't find support in the online docs for the idea that GA is eating service meshes. It's not clear to me how GA will ever do east-west mTLS.

@DevOpsToolkit

Жыл бұрын

@@joebowbeer You're right. Officially, Gateway API does not mention service meshes. That's only my interpretation of where it's going. The way I see it, service meshes emerged as a way to remedy deficiencies of Ingress and Service specs, which is the same objective Gateway API has. As a result, we can see it containing some of the features currently available in Ingresses and others available in service meshes (e.g., weights). All that being said, it's in early stages and it's hard to predict where it will end up in, lets say, a year. The spec will continue evolving but that's the least of my concerns. What matters is for it to get wide adoption and we seem to be on a good track with that. As for SMI... I love it. That was (and still is) one of my main arguments in favor or LinkerD over Istio. I was convinced that it'll become a standard adopted by (almsot) everyone but now I'm not so sure. To be clear, I want it to become that. We'll see. So, I can't say for certain that Gateway API will "eat" service mesh nor that SMI will become the standard everyone will use. What I can say is that we desperately need a spec that encompases all networking-related "stuff" in Kubernetes. Right now, it's fragmented between Ingresses, service meshes, etc. That's probably my wishful thinkings though.

@lhxperimental

Жыл бұрын

​@@DevOpsToolkit Was about the write the same comment as OP. As I see it, service meshes have existed before Kubernetes in form of projects like Netflix Zuul + Spring Eureka. They provided - Service Discovery, Load Balancing/Shedding, Resilience, Rate Limiting, Short Circuiting etc. Since Kubernetes provides many of these features out of the box, IMO, Service Meshes should have just stopped existing at least inside Kubernetes.But perhaps the project maintainers didn't want to be unemployed so they retrofitted it for Kubernetes. mTLS, retry logic, observability are the some value adds that SM provides but IMO the key features that SM provided in non K8S environment was service discovery, Load Balancing/Shedding and Resilience. I had done a small PoC on Zuul before getting into K8S. It was really nice to see what Zuul could do. But after finding K8S, Zuul feels pointless. When SMs were running outside K8S there was no cluster boundary so mTLS made sense. I am not fan of in-cluster communication over mTLS. I mean where do you start trusting the traffic? If your intra cluster traffic is not safe you have bigger problems. I feel its more of a carried over feature

@DevOpsToolkit

Жыл бұрын

I agree. Internal mTLS is not as important as the one for external facing apps so it's not the end of the world if one does not have it. On the other hand, it's almost free (negligible maintenance work) so there is also no good reason not to use it, outside of potential performance penalty.

What about the other features of service mesh like control plane, observabity ? Any side car proxying in the Gateway?

@DevOpsToolkit

Жыл бұрын

That would be the domain of a specific implementation. Gateway API is mostly focused on trying to provide a universal API without diving into implementations.

Жыл бұрын

@@DevOpsToolkit It seems to me that Gateway API is only modeling/generalising a subset of the SM features, namely the ingress traffic, but regardless of provider implementations it doesn't do anything with pod-to-pod networking (that's where sidecars become relevant and cilium might have promising future insights) or egress networking. That won't make SM go out of scope.

@DevOpsToolkit

Жыл бұрын

You're right. It does not make sm go away, or even ingress itself. There's still a long way for it to go and we are yet to see how it will look like in its final form.

Could you recommend a good learning material for K8S for Spring Boot developers? Much appreciated.

@DevOpsToolkit

Жыл бұрын

I do not focus on any specific language when talking about kubernetes since it's not directly related to any. Learn kubernetes independently of spring boot and you should have not trouble running your apps packaged as container images.

How are api authorizations handled with gateway APIs? Can we integrate with an IAM solution that provides OAuth-JWT based authorization?

@DevOpsToolkit

Жыл бұрын

You can (or soon should be) able to do everything you normally do with Ingresses or service meshes. The only difference is that now there is a standard spec instead of each project coming up with it's own CRDs (specs).

Do you have any plan on covering Traefik Mesh?

@DevOpsToolkit

Жыл бұрын

It's on my TODO list, but I cannot say when I'll get to it. For every video I do, 3 items are added to the list so I gave up on planning and focus only on the next one.

@cristianocolangelo9920

Жыл бұрын

@@DevOpsToolkit I imagine!

seems intersting but from what I understand it's not doing mtls which is really a service-mesh feature?

@DevOpsToolkit

Жыл бұрын

It does :)

@adrien-barret

Жыл бұрын

@@DevOpsToolkit hooooo ok so service mesh start to be useless so ;) can you make a video on a how to mtls in w/ api gateway ?

@DevOpsToolkit

Жыл бұрын

Service mesh is not becoming useless. It stays. What changes is how we define it. Instead of using implementation specific spec, now we are getting a standard spec that does not depend on an implementation. The manifests should be the same no matter which implementation you choose.

Hi Viktor. Is there an advantage of using Istio with Istio Gateway/Gateway API over standard Nginx Ingress Controller with Istio?

@DevOpsToolkit

6 ай бұрын

There is no significant difference without going into nitty-gritty details that are not important for the majority. The main one would be that with Istio Gateway, you don't need a separate Ingress but, on the other hand, with Istio Gateway you are, in a way, forced to meshify all apps that are exposed to the outside world and that is often not what many of us want. Now, that was NGINX vs. Istio Gateway. Gateway API is a new standard (new API) that will replace Ingress API and most Ingress solutions are now offering the option to define stuff both using Ingress and Gateway API spec.

@vangelkrstevski566

6 ай бұрын

Thanks! That clarifies things@@DevOpsToolkit

gg game 🤠

Do you have video on service mesh ? Searching for good video related to service mesh.

@DevOpsToolkit

Жыл бұрын

Something like kzread.info/dash/bejne/lZ6cxJmYpdrgdM4.html ?

@CanadaTimes_

Жыл бұрын

@@DevOpsToolkit thanks

Great explanation! I always thought that API Gateway and Gateway API are the same thing. QUESTION: unrelated to Cabernets, how about turning a regular REST API into a Gateway API? Again, unrelated to Kubernetes but rather instead of having an API Gateway routing calls to other APIs, just turning an existing API into API Gateway and making it both, an API Gateway and an API. Disclaimer: to me, this makes no sense but if requirement is like that and no choice, is there any pro points for such design or best thing is to run away from the place lol?

@DevOpsToolkit

Жыл бұрын

I'm not sure I understood what you meant by "regular REST API into a Gateway API". Gateway API is forwarding requests entering your cluster to destination services (among many other things) so if a request for REST API enters the cluster it'll be forwarded to the app that responds back to the client. Now, since I'm not sure I understood your question I'm not sure whether I'm answering it or complicating it even more. If you can clarify it a bit more I'd be more than happy to give a better answer.

@dinobulja

Жыл бұрын

@@DevOpsToolkit say I have a SpringBoot REST API CarAPI that doesCRUD on a database. Then someone comes up with a requirement and says “hey, we want this existing CarAPI to also get us the list of planets in our solar system. To do so, it will call couple of other downstream APIs and for that reason, we want to make it also an API Gateway ( say Zuul or Spring Cloud Gateway ). Hope that explains. Again, to me, I see zero pros of this approach or why would anyone ever wants to do this instead of adding an API Gateway in front of CarAPI but that’s the requirement.

@DevOpsToolkit

Жыл бұрын

@@dinobulja I'm guessing something like that (aggregation) should be done by a third-party and not by the service you developed. If that's the case, than you would need something else. Cluster API (and Ingress before it) does not have the goal to do that. That would be "API Gateway" of some kind (and yes, the names are confusing). I'm not sure that a good idea though. Such solutions were common in the past and are now mostly gone. More often than not, they tend to fail to reduce complexity (quite the opposite).

@dinobulja

Жыл бұрын

@@DevOpsToolkit that’s exactly my point and I had a feeling that this is some old obsolete way of doing things, just don’t know how to change that way of thinking

We need to do a Spiffe video....

@DevOpsToolkit

Жыл бұрын

It's coming...

Istio also supports gateway api. Gateway API is still in beta.

@stanrock8015

Жыл бұрын

Made that comment before I saw your last few min. 😜. Going to be a worthwhile upgrade.

Can't I already do all of this in Traefik? (tho it's a bit funky)

@DevOpsToolkit

Жыл бұрын

There is nothing new introduced in cluster API. That is not the goal. The objective is to standardize the networking API and let other providers (including traefik) come up with implementations of that API. Most of those providers already have all those, and quite a few other features developed but you, as a user, have to use their API. Soon, the implementations will stay more or less the same but the API will be common.

Eventually, we will succeed in reinventing OpenShift.

How do i connect kubernetes with gcp api gateway

@DevOpsToolkit

5 ай бұрын

Are you referring to kubernetes gateway API (the one in this video) or GCP API Gateway? If it's the later... I'm not sure... I haven't tried to connect it with kubernetes and I'm not even sure that's possible.

hmmm... ive been waiting about 12 minutes and still no external IP assigned.... any ideas why?

@DevOpsToolkit

5 ай бұрын

What do you get when you describe it? Events should point you towards the issue.

@jonneal3

5 ай бұрын

@@DevOpsToolkit Thanks for the quick response man! Wow lol! Yeah ill check that out and try that and post back shortly! Thanks!

I don’t understand what is the really difference between this tool to Emissary-ingress?

@DevOpsToolkit

Жыл бұрын

The difference is in the spec. We are finally getting a standard that is independent of implementations.

@barakarzuan7682

Жыл бұрын

@@DevOpsToolkit that’s really nice and impressive, but from here to production and a lot of features that we got from all another tools in the same niche there’s long way…

@DevOpsToolkit

Жыл бұрын

We're not there yet, but we are getting there very fast.

@maksimtsilov6391

Жыл бұрын

I don't think this has anything to do with features. It's more about each tool in the past having to use their own CRDs because the current k8s resources (such as Ingress) are too limiting. This way, there will be a standard set of (core) resources, that may be enough to replace any custom CRDs for Ingress Controllers and (possibly) Service Meshes.

Do apigateway needs any database or storage, when a Terraform code is written for it?

@DevOpsToolkit

Жыл бұрын

You should not need terraform. The point is that we are getting a standard spec that does not depend on any implementation.

@kadapa-rl6jg

Жыл бұрын

Ok.. thankyou

Rate Limit by REDIS ? Redirection Rules? Config Snippet?

@DevOpsToolkit

Жыл бұрын

That's all part of the spec. Now it's up to specific implementations to do the last mile.

@amirchip

Жыл бұрын

also retries, circuit-breaker , etc. which some service meshes implement.

@DevOpsToolkit

Жыл бұрын

That is or will be part of the spec. Also, it's made in a way that can be extended by providers with any additional info they might need.

"An emotional attachment to Ingress"... You mean the single worst part of k8s, which must have asked storage to hold its beer for that badge of honor. Long live Gateway API, I guess?

@DevOpsToolkit

2 ай бұрын

Long live gateway API.

I have zero attachment to ingress. Less than zero attachment to service mesh.

Please don't call it kube cattle 😂😂 it's either kube control or kube C T L

@DevOpsToolkit

Жыл бұрын

Note taken. Will do starting from the next video. Thanks for the tip.

first comment!

no mTLS no party

@DevOpsToolkit

Жыл бұрын

mTLS does not depend on a spec (besides, maybe, a bool field) so that's all up to implementations of the API Gateway.

Thanks!

@DevOpsToolkit

5 ай бұрын

Thanks a ton