Questions on unified access entry and feature requests about openfunction

[lizzzcai]

Hi @wanjunlei, thanks for your reply.

Yes, with the new unified access entry, I can use it for path-based routing, which meets the request. Perhaps in the future can support a more flexible domain defination like domainTemplate.

For example,
currently, we are using istio virtual service to expose our service, formats like api.example.com/user1-ns1/service1, or api.example.com/unique-serviceName1 or service1-user1-ns1.seving.example.com(host-based routing).

For this case service1-user1-ns1.seving.example.com, in the currently knative + istio gateway:

I can create a config my domain:

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-domain
  namespace: knative-serving
data:
  # These are example settings of domain.
  # example.org will be used for routes having app=prod.
  example.org: |
    selector:
      app: prod
  # Default value for domain, for routes that does not have app=prod labels.
  # Although it will match all routes, it is the least-specific rule so it
  # will only be used if no other domain matches.
  example.com: ""

And then define a domtainTemplate:

domain-template: "{Name}-{Namespace}.serving.{Domain}"

All my new services will be exposed on URL with the above format.

For the current format:

http://<domain-name>.<domain-namespace>/<function-namespace>/<function-name>

I probably need to add on a virtual service on top of it to expose it. like:

service1-user1-ns1.seving.example.com -> example.com/user1-ns1/service1
or 
service1-user1-ns1.seving.example.com -> example.com/user1-ns1/service1

If OpenFunction can provide a similar user experience, that will be a great advantage.

---

@tpiperatgod @benjaminhuo

Can we use istio-gateway as the unified access entry (link to point 1)? As service mesh is very popular and it will be good to support it (similar to knative)
Benjamin: Istio is kind of heavy, and knative serving itself is using Kourier to replace it.

Istio is quite heavy, but it is very popular as well. I haven't tested if openFunction works with istio, If there is a demand on this, I will open a new feature request for this.

Benjamin: Yes, other ingress controller are supported by specifying ingressClass, we'll add a doc to elaborate on this

Benjamin: We would like to use Kourier as the recommended ingress controller for openfunction,

I think the scope of OpenFunction probably doesn't need to involve the gateway, but just using them.

If OpenFunction can switch between different ingress gateway, then that will be great. again similar like knative.

Sorry to keep comparing OpenFunction with Knative😅. Both are very good products and I hope that OpenFunction can take some of the good features from Knative and make itself better.🙂

[benjaminhuo]

@lizzzcai Thanks for the detailed description!
We'll think about what you're suggesting

[benjaminhuo]

domainTemplate

@lizzzcai We're considering renaming Domain CRD to Gateway CRD and adding support to Host and Path. The Gateway CRD design will be similar to the K8s gateway CRD and the default underlying controller will be APISIX, thanks for your suggestion

[benjaminhuo]

domainTemplate

@lizzzcai We're considering renaming Domain CRD to Gateway CRD and adding support to Host and Path. The Gateway CRD design will be similar to the K8s gateway CRD and the default underlying controller will be APISIX, thanks for your suggestion

Hi @benjaminhuo , thanks for your update. APISIX is a good project as well, hope to see it soon. When you said the default controller, is it means it can switch/support other controllers as well like Kourier, as you mentioned above.

Other controllers can be supported but maybe not Kourier because it doesn't support Ingress or gateway... , refer to knative-extensions/net-kourier#702

[benjaminhuo]

@lizzzcai I'm trying to answer some of your concerns:

Description A clear and concise description of what the feature is.

Hi OpenFunction, I saw the new feature of the unified access entry was added #158. I have some queries on this feature and also have some requirements not sure if it can be supported by this feature.

1. in the docs, the default ingress controller is nginx-ingress, is there any other ingress is supported? if yes, how to switch it and is there any example.

Benjamin: Yes, other ingress controller are supported by specifying ingressClass, we'll add a doc to elaborate on this

2. Can user use Kubernetes gateway API ref.

Benjamin: Good point, we'd like to support gateway API as long as it's getting mature and popular enough

3. Can we use istio-gateway as the unified access entry (link to point 1)? As service mesh is very popular and it will be good to support it (similar to knative)

Benjamin: Istio is kind of heavy, and knative serving itself is using Kourier to replace it.

4. Is OpenFunction planning to has its own gateway? Similar to Kourier

Benjamin: We would like to use Kourier as the recommended ingress controller for openfunction, but that need some tests to see if it can be integrated with ingress like others mentioned in https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/

[wanjunlei]

Description A clear and concise description of what the feature is.

Hi OpenFunction, I saw the new feature of the unified access entry was added #158. I have some queries on this feature and also have some requirements not sure if it can be supported by this feature.

1. in the docs, the default ingress controller is nginx-ingress, is there any other ingress is supported? if yes, how to switch it and is there any example.
2. Can user use Kubernetes gateway API ref.
3. Can we use istio-gateway as the unified access entry (link to point 1)? As service mesh is very popular and it will be good to support it (similar to knative)
4. Is OpenFunction planning to has its own gateway? Similar to Kourier

For the feature requests, I have the follow user story and want to discuss if OpenFunction can support it by the current unified access entry or in the future.

Host-based routing and path-based routing

We have deployed some services. for example, we have the following namespaces:

user1-ns1 user1-ns2 above are two namespaces but they are belonging to the same user (user1, so the services are crossing multiple namespaces).

within each namespace, we have two servings, service1 and service 2.

In current host-based routing, we have the following deployment URLs:

service1.user1-ns1.example.com service2.user1-ns1.example.com service1.user1-ns2.example.com service2.user1-ns2.example.com

What we expect is a path-based routing like the following:

api.example.com/user1-ns1/service1 api.example.com/user1-ns1/service2 api.example.com/user1-ns2/service1 api.example.com/user1-ns2/service2

or user1-ns1.example.com/service1 user1-ns2.example.com/service1

etc.

You can find the details of this in this thread: knative/serving#11997 (comment). Knative support host based routing but currently not support path-based routing. I hope that OpenFunction can support both as it is a demanding feature (can find it from the thread as well).

domainTemplate to easily define host-based/path-based routing

Ref:domainTemplate

domainTemplate: {{` "{{.Name}}-{{.Namespace}}.{{.Domain}}" `}}
pathBasedRoutingEnabled: True
pathTemplate: {{` "api.{{.Domain}}/{{.Namespace}}/{{.Name}}" `}} # user need to avoid conflict of the path by themselves.

Provide an easy way for user to config their custom domain.

DomainMapping to support multi domain DomainMapping. It is a very interesting feature especially in multi-tenancy use case.

Personally I hope OpenFunction can support gateway that are popular in the market and has a central place to config it easily (similar to how the Knative is configured)

Additional context NA

Now, we can access the function in this way.

http://<domain-name>.<domain-namespace>/<function-namespace>/<function-name>

[tpiperatgod]

4. Is OpenFunction planning to has its own gateway? Similar to Kourier

I think the scope of OpenFunction probably doesn't need to involve the gateway, but just using them.

[FeynmanZhou]

domainTemplate

@lizzzcai We're considering renaming Domain CRD to Gateway CRD and adding support to Host and Path. The Gateway CRD design will be similar to the K8s gateway CRD and the default underlying controller will be APISIX, thanks for your suggestion

@benjaminhuo

If possible, we could invite the maintainers from APISIX to help us to implement this part.

[lizzzcai]

domainTemplate

@lizzzcai We're considering renaming Domain CRD to Gateway CRD and adding support to Host and Path. The Gateway CRD design will be similar to the K8s gateway CRD and the default underlying controller will be APISIX, thanks for your suggestion

Hi @benjaminhuo , thanks for your update. APISIX is a good project as well, hope to see it soon. When you said the default controller, is it means it can switch/support other controllers as well like Kourier, as you mentioned above.

[benjaminhuo]

domainTemplate

@lizzzcai We're considering renaming Domain CRD to Gateway CRD and adding support to Host and Path. The Gateway CRD design will be similar to the K8s gateway CRD and the default underlying controller will be APISIX, thanks for your suggestion

@benjaminhuo

If possible, we could invite the maintainers from APISIX to help us to implement this part.

The gateway we're discussing basically use APISIX as one of our implementations, in another word, we simply use APISIX.
APISIX itself is implementing K8s gateway API, maintainers from APISIX could give us some advice about using it but there might be less chances for them to get involved in the dev of OpenFunction