Any way to deal with istio/DestinationRule?

[caibirdme]

My team is using istio as service mesh, but feel it's too difficult to operate and upgrade, and we want to try linkerd. But after reading the doc and some tests, I found linkerd doesn't have the same ability as Istio DestinationRule. I don't know how to cope with it, and want some help. Here's my use case:

we use helm to deploy our service. For one service, different version are different Deployment but use the same Service, like:

Kind: Deployment
name: foo-v1
labels:
  // other-labels
  version: v1
---
Kind: Deployment
name: foo-v2
labels:
  // other-labels
  version: v2
---
Kind: Service
name: foo
spec:
  selector: other-labels

In this way, we can fix the service name, and all callers do not need to be aware of the service changes. Then, using Istio's DestinationRule mechanism, the service can be further subdivided into different subsets according to the labels of the pods in the service. When configuring splitting route rules, the following solutions can be easily implemented:

- match:
    header: v=v1
  target:
    name: foo-svc
    subset: v1
- match: 
    header: v=v2
  target:
    name: foo-svc
    subset: v2

I don't know how to achieve this in linkerd

[kflynn]

Linkerd can do header-based routing with HTTPRoute, though you'll need to tweak your Services a bit. The HTTPRoute pattern looks like this:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: foo-router
spec:
  parentRefs:
    - name: foo
      kind: Service
      group: ""
      port: 80
  rules:
  - matches:
    - headers:
      - name: "v"
        value: "v1"
    backendRefs:
      - name: foo-v1
        port: 80
  - matches:
    - headers:
      - name: "v"
        value: "v2"
    backendRefs:
      - name: foo-v2
        port: 80
  - backendRefs:
    - name: foo-fallback
      port: 80

(The last rule, going to foo-fallback, is the "header v doesn't have any matching value case" -- if you'd rather have a 404 if v isn't either v1 or v2, remove that last rule.)

Obviously we're not talking about label selectors anywhere in there. To have this work cleanly, you need Services set up:

• Service foo has no selector at all, so that it ends up with no Endpoints. Its sole purpose is to give a name to the HTTPRoute.
• Service foo-v1 has a selector that matches your v1 Deployment's Pods.
• Service foo-v2 has a selector that matches your v2 Deployment's Pods.
• If you include the last rule, Service foo-fallback matches any non-v1 and non-v2 Pods.

This is, obviously, a little different from how Istio does it! On the positive side, it's actually the more standard use of Kubernetes resources, and will hopefully be easier for newcomers to your system to follow. 🙂

[caibirdme]

Thx for your reply, that make sense. I agree with you that using fake serivce as the target might be a more k8s-native style. We should modify our CD pipeline to adopt this new way and try to use linkerd. Thx

[kflynn]

Let us know how it goes!! 🙂