mesh

mesh copied to clipboard

Proposal

Maesh provides DNS-resolvable endpoints for use with service to service communications, but does not provide a user-friendly service for referencing in ingress objects or IngressRoutes.

Background

Having ingress traffic supported in the mesh, as the ingress controllers should be using the mesh too.

This would involve creating a service in the user's namespace that would forward to maesh pods.

This would also have to have the same ports as the maesh shadow service.

Do we need really need another service?

My thinking is that we can use the current shadow services and rework their names to something more user-friendly and easily guessable from a user point of view. This will avoid us to maintain another set of services and potential issues to keep everything in sync.

I agree with @kevinpollet's proposal. If we improve the shadow-service name, it can be perfectly guessable by the user. It could be something like {name}-{namespace}-maesh, so it mimic what we do with DNS {name}.{namespace}.maesh.

The potential issue I see with the name {name}-{namespace}-maesh is that it might be impossible to parse it to retrieve the corresponding service name, but I'm sure that we can find something else.

Btw, I think that it's more maintainable and cleaner to add the corresponding service name as metadata in the shadow service.

We moved to the non friendly name, because it was clashing with existing names in user clusters :-/ So I think, that could be hard...

As I said {name}-{namespace}-maesh would be hard to parse but I haven't thought that it must be parsable for our DNS rule. I think that's why the 6d61657368 separator has been introduced, see #378 and #381.

If it's doable, I think it's better to avoid managing another kind of services. Btw, I'm a bit unsure that those new services should be created in the user namespace.

If I'm not wrong the issue is when we are rewriting the DNS answer because we have to retrieve the service name from the shadow service name. The following issue could help us to avoid the answer parsing: https://github.com/coredns/coredns/issues/2389.

The custom separator was required due to regex parsing of the DNS request.

test-service.test-namespace would get parsed as test-service-test.namespace when we use the {name}-{namespace}-maesh format.

The issue here is that when a service is referenced in an ingress object, we want it to be a stable name. It also has to be in the same namespace as the ingress object.

We don't want to make a user do this:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: test-ingress
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          serviceName: maesh-test-service-6d61657368-test-namespace
          servicePort: 80

In this case, it would be much better to have a simple service name with -maesh appended:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: test-ingress
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          serviceName:test-service-maesh
          servicePort: 80

This service would not be used with DNS, only for use with ingress and CRD objects that the user would be interacting with the service directly.

My bad, I didn't know that the service referenced in an Ingress object has to be in the same namespace. 😞

So, I'm with you that the only way to do it is to create services with the name format: {name}-{namespace}-maesh in the same namespace as the corresponding user service.

Thoughts, maybe to avoid the creation of a ton of services in the user namespace, we could imagine having an opt-in annotation to say that this service needs a {name}-{namespace}-maesh companion that could be referenced in an Ingress object?