Gateway API - Ingress And Service Mesh Spec Replacement?

Поділитися
Вставка
  • Опубліковано 18 чер 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
  • Наука та технологія

КОМЕНТАРІ • 105

  • @DevOpsToolkit
    @DevOpsToolkit  Рік тому +4

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

    • @jordangregory9852
      @jordangregory9852 Рік тому +2

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

    • @DevOpsToolkit
      @DevOpsToolkit  Рік тому +3

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

    • @dirien
      @dirien Рік тому +1

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

    • @PS-xn8ej
      @PS-xn8ej Рік тому +1

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

    • @DevOpsToolkit
      @DevOpsToolkit  Рік тому +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 4 місяці тому +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 Рік тому +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  Рік тому +2

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

  • @discoline10191
    @discoline10191 Рік тому +1

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

  • @christianibiri
    @christianibiri Рік тому +2

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

  • @GM-qv1ql
    @GM-qv1ql Рік тому +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 Рік тому +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!

  • @crfadv
    @crfadv Рік тому +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 Рік тому +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.

  • @JobStoit
    @JobStoit Рік тому +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  Рік тому +1

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

  • @acartag7
    @acartag7 Рік тому +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 Рік тому +1

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

    • @DevOpsToolkit
      @DevOpsToolkit  Рік тому

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

  • @Luther_Luffeigh
    @Luther_Luffeigh Рік тому +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  Рік тому +1

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

    • @fenarRH
      @fenarRH Рік тому +1

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

    • @DevOpsToolkit
      @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.

  • @Basivera
    @Basivera Рік тому +2

    Thanks!

  • @javisartdesign
    @javisartdesign Рік тому

    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

  • @joebowbeer
    @joebowbeer Рік тому +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  Рік тому

      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 Рік тому +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  Рік тому +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 Рік тому +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  Рік тому

      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.

  • @MrDujmanu
    @MrDujmanu 4 місяці тому +1

    It'd be interesting an update to this video.

  • @MR-ew6uw
    @MR-ew6uw Рік тому +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  Рік тому +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 Рік тому +3

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

    • @DevOpsToolkit
      @DevOpsToolkit  Рік тому +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.

    •  Рік тому +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  Рік тому

      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.

  • @direstraitsul2
    @direstraitsul2 Рік тому +2

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

    • @DevOpsToolkit
      @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).

  • @dinobulja
    @dinobulja Рік тому +1

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

    • @DevOpsToolkit
      @DevOpsToolkit  Рік тому +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.

  • @dinobulja
    @dinobulja Рік тому +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  Рік тому

      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 Рік тому +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  Рік тому

      @@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 Рік тому +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

  • @panchwall_devops
    @panchwall_devops Рік тому +1

    gg game 🤠

  • @adrien-barret
    @adrien-barret Рік тому +2

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

    • @DevOpsToolkit
      @DevOpsToolkit  Рік тому +2

      It does :)

    • @adrien-barret
      @adrien-barret Рік тому +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  Рік тому +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 6 місяців тому +1

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

    • @DevOpsToolkit
      @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
      @vangelkrstevski566 6 місяців тому

      Thanks! That clarifies things@@DevOpsToolkit

  • @cristianocolangelo9920
    @cristianocolangelo9920 Рік тому +1

    Do you have any plan on covering Traefik Mesh?

    • @DevOpsToolkit
      @DevOpsToolkit  Рік тому +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 Рік тому +1

      @@DevOpsToolkit I imagine!

  • @stanrock8015
    @stanrock8015 Рік тому +2

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

    • @stanrock8015
      @stanrock8015 Рік тому +1

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

  • @CanadaTimes_
    @CanadaTimes_ Рік тому +1

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

    • @DevOpsToolkit
      @DevOpsToolkit  Рік тому +1

      Something like ua-cam.com/video/cjhb7_uwzDk/v-deo.html ?

    • @CanadaTimes_
      @CanadaTimes_ Рік тому +1

      @@DevOpsToolkit thanks

  • @blaiseutube
    @blaiseutube 10 місяців тому +2

    Eventually, we will succeed in reinventing OpenShift.

  • @dougsellner9353
    @dougsellner9353 Рік тому +1

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

    • @DevOpsToolkit
      @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.

  • @pratiksingh702
    @pratiksingh702 5 місяців тому +1

    How do i connect kubernetes with gcp api gateway

    • @DevOpsToolkit
      @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.

  • @lamnot.
    @lamnot. Рік тому +1

    We need to do a Spiffe video....

  • @klassica
    @klassica 2 місяці тому +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?

  • @jonneal3
    @jonneal3 5 місяців тому +1

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

    • @DevOpsToolkit
      @DevOpsToolkit  5 місяців тому

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

    • @jonneal3
      @jonneal3 5 місяців тому +1

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

  • @barakarzuan7682
    @barakarzuan7682 Рік тому +1

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

    • @DevOpsToolkit
      @DevOpsToolkit  Рік тому +1

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

    • @barakarzuan7682
      @barakarzuan7682 Рік тому +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  Рік тому +1

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

    • @maksimtsilov6391
      @maksimtsilov6391 Рік тому +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 Рік тому +1

    Rate Limit by REDIS ?
    Redirection Rules?
    Config Snippet?

    • @DevOpsToolkit
      @DevOpsToolkit  Рік тому

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

    • @amirchip
      @amirchip Рік тому +1

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

    • @DevOpsToolkit
      @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.

  • @kadapa-rl6jg
    @kadapa-rl6jg Рік тому +1

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

    • @DevOpsToolkit
      @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
      @kadapa-rl6jg Рік тому +1

      Ok.. thankyou

  • @blaiseutube
    @blaiseutube 10 місяців тому +1

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

  • @AndreaFlorio
    @AndreaFlorio Рік тому +4

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

    • @DevOpsToolkit
      @DevOpsToolkit  Рік тому +2

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

  • @smerlos
    @smerlos Рік тому +3

    first comment!

  • @go-nzalo
    @go-nzalo Рік тому +1

    no mTLS no party

    • @DevOpsToolkit
      @DevOpsToolkit  Рік тому

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

  • @mahmoudaminali3678
    @mahmoudaminali3678 5 місяців тому +1

    Thanks!