Should SMI have an Ingress API?

[lachie83]

I keep hearing from members of the community that "ingress and service-mesh is hard". From a quick sweep of ingress documentation across the different implementers of SMI, users either have a bunch of CRDs or a fully annotated Kubernetes Ingress in order to achieve ingress traffic to the service mesh.

Firstly - When I say Ingress, I mean North/South traffic onto the service mesh. I'm not yet concerned about East/West.

The question I would like to propose to the community is "Should SMI have an Ingress API"?

It is my position that SMI shouldn't have it's own Ingress API but instead see if we can leverage and integrate with the ongoing work that's happening in Kubernetes sig-network regarding what's currently known as ingress v2. The current goals of that project can be found in the API draft document. Specifically, these new set of APIs are designed to be generic and extensible.

I would like to propose that we take the time to review the ingress v2 API draft document keeping the following questions in mind:

• Does this sound implementable?
• Is there any other feedback we can provide to the draft document given the perspective that this group already has implementing the SMI APIs.
• Although not a primary goal, could ingress v2 provide a pathway to implementing an East/West interface. See Virtual Service/Router/Balancer type concept #37

If there is sufficient interest in collaborating with the goal of eventually implementing ingress v2, I would be more than happy to represent the SMI community in the upstream ingress v2 working group.

cc @grampelberg @olix0r @nicholasjackson @michelleN @ilevine @ibuildthecloud @aanandr

[nicholasjackson]

So I agree that ingress should be external to the SMI spec as this is already extensively covered within the K8s spec. The v2 ingress proposal looks very comprehensive too.

I also think the spec contains enough detail for mesh aware ingresses to be configured from a routing perspective, however there is a gap around how do you configure the gateway to use the mesh? The answer at the moment is you use the custom CRD for your ingress of choice. My feeling is that this is an installation step and therefore belongs in the domain of the ingress provider.

There is a large amount of cross over however for example:

kind: HTTPRoute
name: split-traffic
spec:
  rules:
  - match:
      host: foo.com
      path:
        prefix: /app
    action:
      destination:
        backend:
        kind: networking.x-k8s.io/TrafficSplit
        name: split-traffic
---
kind: networking.x.k8s.io/TrafficSplit
name: traffic-split-backends
destinations:
- backend:
    name: my-service
  weight: 50
- backend:
    name: my-service-canary
  weight: 10

These two objects are incredibly similar to the SMI objects, while one controls the behaviour of the ingress and the other the service mesh, this is going to be incredibly confusing for the practitioner.

I also question at what point does k8s.networking introduce access policy, reliability patterns, etc.

Let me play devils advocate, I am wearing my fire proof suit, so comment away. "Should SMI maintain it's own HTTPRouteGroup and TrafficSplit or be rolled into k8s networking and this group collaborate on that API?"

^^ Note that is a question not an opinion, I am not sure I have an answer.

[stefanprodan]

@lachie83 should we close this in favour of #123 ?

[danehans]

xref kubernetes-sigs/gateway-api#57

[danehans]

I agree with @nicholasjackson regarding #66 (comment). I have addressed the considerable overlap between the two projects in the Service APIs Slack channel here. I think it would be helpful if one or more SMI contributors can join a Service APIs community meeting to discuss how the two projects can potentially collaborate. I've added the topic to the agenda for our next meeting.

[grampelberg]

@danehans that's awesome, I'll be there!

[danehans]

@grampelberg I made note of your attendance so we address #66 (comment) first.

[danehans]

@lachie83 should we close this in favour of #123 ?

+1 @stefanprodan