From 74798ecb09d059c1aae64dfdb55f5395f7b2024f Mon Sep 17 00:00:00 2001 From: Brad Hoekstra Date: Tue, 6 Nov 2018 10:20:37 -0500 Subject: Add comment about frameworks that could use this feature --- keps/sig-network/0031-20181017-kube-proxy-services-optional.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/keps/sig-network/0031-20181017-kube-proxy-services-optional.md b/keps/sig-network/0031-20181017-kube-proxy-services-optional.md index e7112ec0..ec4eb942 100644 --- a/keps/sig-network/0031-20181017-kube-proxy-services-optional.md +++ b/keps/sig-network/0031-20181017-kube-proxy-services-optional.md @@ -86,6 +86,8 @@ The envisioned cluster that will make use of this feature looks something like t * These small number of entry points into the cluster are a part of the service mesh * There are many micro-services in the cluster, all a part of the service mesh, that are only accessed from inside the service mesh +Higher level frameworks built on top of service meshes, such as [Knative](https://github.com/knative/docs), will be able to enable this feature by default due to having a more controlled application/service model and being reliant on the service mesh. + #### Design Currently, when ProxyServer starts up it creates informers for all Service (ServiceConfig) and Endpoints (EndpointsConfig) objects using a single shared informer factory. -- cgit v1.2.3