Gateway API - Ingress And Service Mesh Spec Replacement?

Sdílet
Vložit
  • čas přidán 29. 06. 2024
  • Ingress and service mesh specifications are about to be replaced with Gateway API. Let's see it in action!
    #gatewayapi #kubernetes #ingress #servicemesh
    Consider joining the channel: / devopstoolkit
    ▬▬▬▬▬▬ 🔗 Additional Info 🔗 ▬▬▬▬▬▬
    ➡ Gist with the commands: gist.github.com/b9b963ba540ea...
    🔗 Gateway API: gateway-api.sigs.k8s.io
    🎬 How To Do Canary Deployments In Kubernetes Using Flagger And Linkerd?: • How To Do Canary Deplo...
    🎬 Argo Rollouts - Canary Deployments Made Easy In Kubernetes: • Argo Rollouts - Canary...
    ▬▬▬▬▬▬ 💰 Sponsoships 💰 ▬▬▬▬▬▬
    If you are interested in sponsoring this channel, please use calendly.com/vfarcic/meet to book a timeslot that suits you, and we'll go over the details. Or feel free to contact me over Twitter or LinkedIn (see below).
    ▬▬▬▬▬▬ 👋 Contact me 👋 ▬▬▬▬▬▬
    ➡ Twitter: / vfarcic
    ➡ LinkedIn: / viktorfarcic
    ▬▬▬▬▬▬ 🚀 Courses, books, and podcasts 🚀 ▬▬▬▬▬▬
    📚 Books and courses: www.devopstoolkitseries.com
    🎤 Podcast: www.devopsparadox.com/
    💬 Live streams: / devopsparadox
    ▬▬▬▬▬▬ ⏱ Timecodes ⏱ ▬▬▬▬▬▬
    00:00 Introduction To Gateway API
    02:10 Gateway API Gateway Classes
    06:28 Gateway API Gateways
    09:15 Gateway API Routes
    13:47 Canary Deployments With Gateway API
    18:57 Gateway API Pros And Cons
  • Věda a technologie

Komentáře • 106

  • @DevOpsToolkit
    @DevOpsToolkit  Před rokem +4

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

    • @jordangregory9852
      @jordangregory9852 Před rokem +2

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

    • @DevOpsToolkit
      @DevOpsToolkit  Před rokem +3

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

    • @dirien
      @dirien Před rokem +1

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

    • @PS-xn8ej
      @PS-xn8ej Před rokem +1

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

    • @DevOpsToolkit
      @DevOpsToolkit  Před rokem +1

      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.

  • @dmitriinadein4733
    @dmitriinadein4733 Před 5 měsíci +5

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

  • @saurabhabhishek5203
    @saurabhabhishek5203 Před rokem +11

    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
      @DevOpsToolkit  Před rokem +2

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

  • @discoline10191
    @discoline10191 Před rokem +1

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

  • @christianibiri
    @christianibiri Před rokem +2

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

  • @GM-qv1ql
    @GM-qv1ql Před rokem +1

    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!

  • @mauricioquerves5001
    @mauricioquerves5001 Před rokem +2

    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!

  • @Luther_Luffeigh
    @Luther_Luffeigh Před rokem +6

    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
      @DevOpsToolkit  Před rokem +1

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

    • @fenarRH
      @fenarRH Před rokem +1

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

    • @DevOpsToolkit
      @DevOpsToolkit  Před rokem

      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.

  • @JobStoit
    @JobStoit Před rokem +1

    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
      @DevOpsToolkit  Před rokem +1

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

  • @acartag7
    @acartag7 Před rokem +1

    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
      @LampJustin Před rokem +1

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

    • @DevOpsToolkit
      @DevOpsToolkit  Před rokem

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

  • @Basivera
    @Basivera Před rokem +2

    Thanks!

  • @crfadv
    @crfadv Před rokem +1

    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 :)

  • @zoop2174
    @zoop2174 Před rokem +1

    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.

  • @MrDujmanu
    @MrDujmanu Před 5 měsíci +1

    It'd be interesting an update to this video.

  • @joebowbeer
    @joebowbeer Před rokem +5

    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
      @DevOpsToolkit  Před rokem

      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
      @joebowbeer Před rokem +3

      @@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
      @DevOpsToolkit  Před rokem +3

      @@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
      @lhxperimental Před rokem +2

      ​@@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
      @DevOpsToolkit  Před rokem

      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.

  • @javisartdesign
    @javisartdesign Před rokem

    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

  • @MR-ew6uw
    @MR-ew6uw Před rokem +1

    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
      @DevOpsToolkit  Před rokem +1

      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.

  • @geowalrus
    @geowalrus Před rokem +3

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

    • @DevOpsToolkit
      @DevOpsToolkit  Před rokem +1

      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.

    •  Před rokem +1

      @@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
      @DevOpsToolkit  Před rokem

      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.

  • @blaiseutube
    @blaiseutube Před 10 měsíci +2

    Eventually, we will succeed in reinventing OpenShift.

  • @panchwall_devops
    @panchwall_devops Před rokem +1

    gg game 🤠

  • @dinobulja
    @dinobulja Před rokem +1

    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
      @DevOpsToolkit  Před rokem

      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
      @dinobulja Před rokem +1

      @@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
      @DevOpsToolkit  Před rokem

      @@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
      @dinobulja Před rokem +1

      @@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

  • @stanrock8015
    @stanrock8015 Před rokem +2

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

    • @stanrock8015
      @stanrock8015 Před rokem +1

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

  • @lamnot.
    @lamnot. Před rokem +1

    We need to do a Spiffe video....

  • @direstraitsul2
    @direstraitsul2 Před rokem +2

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

    • @DevOpsToolkit
      @DevOpsToolkit  Před rokem

      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).

  • @klassica
    @klassica Před 3 měsíci +1

    "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?

  • @dinobulja
    @dinobulja Před rokem +1

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

    • @DevOpsToolkit
      @DevOpsToolkit  Před rokem +1

      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.

  • @adrien-barret
    @adrien-barret Před rokem +2

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

    • @DevOpsToolkit
      @DevOpsToolkit  Před rokem +2

      It does :)

    • @adrien-barret
      @adrien-barret Před rokem +3

      @@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
      @DevOpsToolkit  Před rokem +4

      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.

  • @vangelkrstevski566
    @vangelkrstevski566 Před 7 měsíci +1

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

    • @DevOpsToolkit
      @DevOpsToolkit  Před 7 měsíci

      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
      @vangelkrstevski566 Před 7 měsíci

      Thanks! That clarifies things@@DevOpsToolkit

  • @jonneal3
    @jonneal3 Před 5 měsíci +1

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

    • @DevOpsToolkit
      @DevOpsToolkit  Před 5 měsíci

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

    • @jonneal3
      @jonneal3 Před 5 měsíci +1

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

  • @pratiksingh702
    @pratiksingh702 Před 5 měsíci +1

    How do i connect kubernetes with gcp api gateway

    • @DevOpsToolkit
      @DevOpsToolkit  Před 5 měsíci

      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.

  • @cristianocolangelo9920
    @cristianocolangelo9920 Před rokem +1

    Do you have any plan on covering Traefik Mesh?

    • @DevOpsToolkit
      @DevOpsToolkit  Před rokem +2

      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
      @cristianocolangelo9920 Před rokem +1

      @@DevOpsToolkit I imagine!

  • @blaiseutube
    @blaiseutube Před 10 měsíci +1

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

  • @CanadaTimes_
    @CanadaTimes_ Před rokem +1

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

  • @dougsellner9353
    @dougsellner9353 Před rokem +1

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

    • @DevOpsToolkit
      @DevOpsToolkit  Před rokem

      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.

  • @barakarzuan7682
    @barakarzuan7682 Před rokem +1

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

    • @DevOpsToolkit
      @DevOpsToolkit  Před rokem +1

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

    • @barakarzuan7682
      @barakarzuan7682 Před rokem +1

      @@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
      @DevOpsToolkit  Před rokem +1

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

    • @maksimtsilov6391
      @maksimtsilov6391 Před rokem +2

      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.

  • @vn7057
    @vn7057 Před rokem +1

    Rate Limit by REDIS ?
    Redirection Rules?
    Config Snippet?

    • @DevOpsToolkit
      @DevOpsToolkit  Před rokem

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

    • @amirchip
      @amirchip Před rokem +1

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

    • @DevOpsToolkit
      @DevOpsToolkit  Před rokem

      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.

  • @kadapa-rl6jg
    @kadapa-rl6jg Před rokem +1

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

    • @DevOpsToolkit
      @DevOpsToolkit  Před rokem

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

    • @kadapa-rl6jg
      @kadapa-rl6jg Před rokem +1

      Ok.. thankyou

  • @smerlos
    @smerlos Před rokem +3

    first comment!

  • @go-nzalo
    @go-nzalo Před rokem +1

    no mTLS no party

    • @DevOpsToolkit
      @DevOpsToolkit  Před rokem

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

  • @AndreaFlorio
    @AndreaFlorio Před rokem +4

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

    • @DevOpsToolkit
      @DevOpsToolkit  Před rokem +2

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

  • @mahmoudaminali3678
    @mahmoudaminali3678 Před 5 měsíci +1

    Thanks!