Canary and namespace interactions

[slack]

Opening this issue to track discussion raised by @grampelberg in #2

How should this interact with namespaces? One of the downsides to the current workflow is that deployment names end up changing and require a tool such as helm or kustomize. By allowing canaries between namespaces, it would be possible to keep names identical and simply clean up namespaces as new versions come out.

[christian-posta]

I'm thinking we'd need to support "virtual services" or virtual host more directly to achieve this?

[grampelberg]

Shouldn't need to. That said, there's a previous version of HTTPRouteGroup that supports virtual hosts.

[pchico83]

+1 for implementing support for different namespaces. We would need something like this:

kind: TrafficSplit
metadata:
  name: ab-test
spec:
  service: website
  matches:
  - kind: HTTPRouteGroup
    name: ab-test
  backends:
  - service: website
    namespace: blue
    weight: 0
  - service: website
    namespace: green
    weight: 100

To redirect traffic to a service running on a different namespace

[nicholasjackson]

@pchico83 This technical implementation makes sense to me I don't see any clash anywhere else in the spec by adding a namespaces field, I don't really have any objections here. However, if you don't mind could you explain your use case, would be super useful to get a picture of how you have set up your system so we can design a more accommodating spec in the future.

When this was originally put together I think there was an assumption that the splits would be across two versions of service and because they were really just a virtual separation of a collection of pods, they would be owned by the same team they would also be in the same namespace.

[pchico83]

@nicholasjackson sure. I am one of the founders of Okteto. Okteto is a development platform on top of Kubernetes. Our vision is that every developer should have her own namespace where she can deploy and live update a dev instance of an application. If you have many services running in your dev namespace, it makes sense to have a shared namespace by all the developers in a team and replicate just a few of these services on each developer namespace. Then, based on headers, the services running on the shared namespace redirects traffic to the proper developer namespace. For example, A, B and C are running on namespace integration. Developer 1 deploys B on her namespace, and the incoming traffic to B in the integration namespace is redirected to the developer 1 namespace based on a given header.

Azure dev spaces has something similar, they call it "Bridge to Kubernetes".

[nicholasjackson]

Gotcha, that is a pretty normal use case the thing that tripped up my thinking was more the use case of splitting traffic across two services in a different namespace. The Traffic Split in your example would send 100% of traffic to Developer Two (green) and 0% to Developer One (blue). It would not allow you to say sent requests with header blue to the blue service and requests with green to the green service.

Normally a Traffic Split would be used to facilitate Blue/Green or Canary deployments and these are normally owned by a single namespace.

Regardless of that, I do believe that Namespace should be supported as it allows services with the same name to co-exist in the cluster as is possible with standard K8s services, and would support the inclusion to the spec.

To route traffic to an upstream based on HTTP header, a TrafficTarget would normally be used, something like this:

kind: HTTPRouteGroup
metadata:
  name: developer-a-routes
  namespace: blue
spec:
  matches:
  - name: api
    headers:
    - namespace: "blue"

---
kind: TrafficTarget
metadata:
  name: developer-a-ingress
  namespace: blue
spec:
  destination:
    kind: ServiceAccount
    name: service-a
    namespace: blue
  rules:
  - kind: HTTPRouteGroup
    name: developer-a-routes
    matches: api
  sources:
  - kind: ServiceAccount
    name: ingress
    namespace: default

---
kind: HTTPRouteGroup
metadata:
  name: developer-b-routes
  namespace: green
spec:
  matches:
  - name: api
    headers:
    - namespace: "green"
   
---
kind: TrafficTarget
metadata:
  name: developer-b-ingress
  namespace: green
spec:
  destination:
    kind: ServiceAccount
    name: api
    namespace: green
  rules:
  - kind: HTTPRouteGroup
    name: developer-b-routes
    matches: api
  sources:
  - kind: ServiceAccount
    name: ingress
    namespace: default

[bridgetkromhout]

Closing due to project archival: https://www.cncf.io/blog/2023/10/03/cncf-archives-the-service-mesh-interface-smi-project/)