Use configmap to configure the data source of filter framework

[yingjianjian]

What type of PR is this?

/kind feature

What this PR does / why we need it:

Use configmap to configure the data source of filter framework

Which issue(s) this PR fixes:

Fixes #699

[rambohe-ch]

@yingjianjian Very appreciate for making pull request of #699 , at first please merge two commits into one commit.

[yingjianjian]

Merged

[rambohe-ch]

/assign @zzguang

[yingjianjian]

fixed

[rambohe-ch]

@zzguang PTAL

[zzguang]

Generally, it looks good to me, but I have a suggestion I am not sure whether it makes sense:
defaultFilterCfg = map[string]string{
MasterServiceFilterName: "kubelet/services#list;watch",
EndpointsFilterName: "nginx-ingress-controller/endpoints#list;watch",
DiscardCloudServiceFilterName: "kube-proxy/services#list;watch",
ServiceTopologyFilterName: "kube-proxy/endpointslices#list;watch",
}
For the current FilterNames, MasterServiceFilterName and DiscardCloudServiceFilterName are both services filtering for different components, how about combining them together into a single "ServicesFilterName", then in the filter manager, it checks all the components that registers the service resource to decide whether to do the services filtering operation. This aims to de-couple the resources and components completely, so that if a new component wants to add filtering for a current resource in future, it won't need to add new filter name any more.
If the suggestion is reasonable, the filter names will be named clearly by the resources names, and the current filter names can be refined like below:
ServicesFilterName: "kubelet/services#list;watch",
ServicesFilterName: "kube-proxy/services#list;watch",
EndpointsFilterName: "nginx-ingress-controller/endpoints#list;watch",
EndpointslicesFilterName: "kube-proxy/endpointslices#list;watch",

This suggestion is just a reference for you, just ignore it if I am wrong, thanks!

[rambohe-ch]

Generally, it looks good to me, but I have a suggestion I am not sure whether it makes sense: defaultFilterCfg = map[string]string{ MasterServiceFilterName: "kubelet/services#list;watch", EndpointsFilterName: "nginx-ingress-controller/endpoints#list;watch", DiscardCloudServiceFilterName: "kube-proxy/services#list;watch", ServiceTopologyFilterName: "kube-proxy/endpointslices#list;watch", } For the current FilterNames, MasterServiceFilterName and DiscardCloudServiceFilterName are both services filtering for different components, how about combining them together into a single "ServicesFilterName", then in the filter manager, it checks all the components that registers the service resource to decide whether to do the services filtering operation. This aims to de-couple the resources and components completely, so that if a new component wants to add filtering for a current resource in future, it won't need to add new filter name any more. If the suggestion is reasonable, the filter names will be named clearly by the resources names, and the current filter names can be refined like below: ServicesFilterName: "kubelet/services#list;watch", ServicesFilterName: "kube-proxy/services#list;watch", EndpointsFilterName: "nginx-ingress-controller/endpoints#list;watch", EndpointslicesFilterName: "kube-proxy/endpointslices#list;watch",

This suggestion is just a reference for you, just ignore it if I am wrong, thanks!

@zzguang I think we need to name filter based on the function of filter, not the resource of filter. so it's a good idea to keep MasterServiceFilterName and DiscardCloudServiceFilterName unchanged, because only from the name meaning of filters end users can decide to use this filter or not. if we combine these two meaningful filters into service filter, i think that end user will feel confused.

btw: based on the function of filters, i think we can merge endpoints filter for ingress controller into serviceTopology filter for traffic control. and we can optimize this merge in another pull request.

[zzguang]

Okay, I just feel a little confusing about the filter naming rule, if we name it by the feature name, then the "EndpointsFilterName" doesn't follow this rule, and if another feature/component wants to add endpoints filtering in future, it may lead to some un-consistent concepts.
As you say, I think we can merge it at current stage, and optimize it in another PR in future.

[rambohe-ch]

/lgtm
/approve

[openyurt-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: rambohe-ch, yingjianjian

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [rambohe-ch]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[rambohe-ch]

Fixes #773