Open dtomcej opened 4 years ago
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?
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.