argo-rollouts VS gateway-api

And support is on it's way for Argo Rollouts 🎉 https://github.com/argoproj/argo-rollouts/pull/2004

curl -LO https://github.com/argoproj/argo-rollouts/releases/latest/download/kubectl-argo-rollouts-linux-amd64 chmod +x ./kubectl-argo-rollouts-linux-amd64 sudo mv ./kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts kubectl argo rollouts version

kubectl create namespace argo-rollouts kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml

You can see in why argo section here what are the limitations of rolling updates and how rollouts solves it: https://github.com/argoproj/argo-rollouts

Argo Rollouts

Check the public users list https://github.com/argoproj/argo-rollouts/blob/master/USERS.md

Supplementary GitOps operators can also be used for deployment strategies, such as canary releases, A/B tests, and blue/green deployments, which have now been grouped under the term “progressive delivery”. The resources of most GitOps operators are not sufficient for this. One solution is Flagger. The tool that was launched by Weaveworks is now being developed as part of the Flux project. The Argo project also has an operator for this use case: Argo Rollouts. Both offer CRs for implementing progressive delivery strategies in interaction with various ingress controllers and service meshes.

It has already been a couple of years since the Kubernetes Ingress was defined as a “frozen” feature while further development will be added to the Gateway API.

Kubernetes provides two APIs to achieve this, the Ingress API and the Gateway API.

With all that said, K8s is not really meant to function as an API gateway to arbitrary services. You should look into API gateways such as NGINX, Kong or others, service meshes as others have already pointed out, or have a look at the K8s Gateway API the SIG is currently working on. The last one is in the early stages of adoption, but it could provide you with a nice way to do an API Gateway right in K8s.

Maybe there's something in the new fangled gateways.

Keep an eye on the Gateway API GAMMA Initiative as it is currently evolving with the goal of streamlining how services meshes can implement the Gateway API and reduce some overlap.

The selling point for me was ability to configure it using Kubernetes CRD's and future support of the Gateway API (under development - <https://gateway-api.sigs.k8s.io/>).

Developers can version their API now within helm charts or even yaml templates held along the code in their repositories.

-- https://gateway-api.sigs.k8s.io

While you're learning about ingresses, also look into the k8s Gateway API, which is the next generation. https://gateway-api.sigs.k8s.io/

The GatewayAPI model is quite different from the LB/ingress model, in the cluster it consists of gateway and route objects. Once the gateway is created routes connecting gateways to services are added. If you need to change how requests are distributed, the routes are updated but the gateway remains so the address and other configuration remains consistent. Gateways can be shared by multiple routes. Take a look at https://gateway-api.sigs.k8s.io/ its a bit terse but you will get the picture.