Categorygithub.com/bensolo-io/rollouts-plugin-trafficrouter-glooplatform

# Packages

No description provided by the author

# README

Gloo Platform Plugin for Argo Rollouts

This plugin is POC-quality and Argo Rollouts was recently released as alpha in 1.5. You have been warned!

This repo contains a POC implementation of an Argo Rollouts plugin to support the Gloo Platform API.

Patterns were based on the K8s gateway api plugin found here.

Rollouts Concepts

Think of Argo Rollout CR like a replacement for the K8s Deployment CR. The Rollout contains 2 primary configs:

  • a pod template similar to what you would use in a Deployment
  • the configs and strategy for the Rollout operation (steps, weights, pauses, etc.)

While you can reference a Deployment as a way to get the pod template details, Rollouts still will not manage the referenced deployment directly.

Here is the workflow:

  • Create stable and canary (or blue / green) k8s services
  • Create gateway/ingress resources that route to the stable service
  • Do NOT create a deployment :)
  • Create a Rollout that contains a pod template that would have been used in a deployment

Example

kubectl apply -f ./examples/demo-api-initial-state kubectl label ns gloo-Rollout-demo istio.io/rev=1-17-2

watch -n 0.5 'curl localhost:8888/demo'

kubectl apply -f ./examples/0-Rollout-initial curl localhost:8888/demo -s | jq -c kubectl apply -f ./examples/1-Rollout-first-change curl localhost:8888/demo -s | jq -c

Gloo UI UX

  • UI displays pod name b/c there is no deployment object with Rollouts; only Rollout CR -> replicasets; please upvote this issue https://github.com/argoproj/argo-Rollouts/issues/2779 for supporting generation of deployment CRs
    • There may be other issues in Gloo due to missing deployment metadata; will require eng research

TODO

  • support different forwardTo.destination.kinds
  • account for a matched destination already having "static" (non-canary) weighted routing
  • implement label selectors for RouteTable and Route lookup
  • handle different destination types between stable and canary
  • remove canary destination when Rollout is complete (right now just sets to 0 weight)
  • clean up duplicated code in getHttpRefs
  • handle named ports
  • add more advanced features to the rollout metadata that is passed to our plugin; i.e. this section could be enhanced with other Gloo capabilities:
      trafficRouting:
        plugins:
          solo-io/glooplatformAPI:
            routeTableName: default
            routeTableNamespace: gloo-mesh
            destinationKind: SERVICE
            destinationNamespace: gloo-rollout-demo