K8S node discovery with filtering options

[apatozi]

Description:

The K8s discovery was working ok but not great for a real life scenario use case. There were the following problems:

• The security was not great because if you gave someone (a dev) access to use the dashboard, he could switch to any service inside any namespace in the k8s cluster.
• There were many services listed in the nodes section and most of those don't even have a CAP so they just bloat the list and give an Error if switched to.
• The listed services always did use the first found port defined in the k8s-service. This needed to change because sometimes when using tools to create your deployments and k8s-services you cannot control the order of the ports of the service.

Changes in this PR address the above issues by doing the following measures:

• Allowing to list nodes without the need for selecting a namespace but just using the namespace where ne dashboard is running. This opens the possibility to create a "ServiceAccount" that has only access inside the particular namespace. This improves the security because now I can give access separately to different developers for different environments that run in different k8s-namespaces.
• Filter out any not needed service by allowing to blacklist any service by adding dotnetcore.cap.visibility: hide. This was not enough because some services are created by an operator and I could not add the same label to those "rabbit-mq" services because the operator detected changes and replaced them instantly removing the label. This problem resulted in adding the "only whitelisted" mode by adding an option to the k8sDiscoveryOptions. This option shows only services containing the dotnetcore.cap.visibility: show label.
• The ports can now be selected by index or by name. This can be done by adding dotnetcore.cap.portIndex: '1' label on the desired service. If the index is outside of bounds then it will fall back to index 0 as it was. The ports can also be selected by name by using the dotnetcore.cap.portName: grpc label. The "Find by name" rule is stronger than the index. If no port is found with that name it will fall back to the "Find by Index" rule and after that to index 0 as said earlier. This opens the possibility to add more customization using ne k8s-labels.

Issue(s) addressed:

• not neccessary as I already did the PR

Changes:

• Possibility to filter out (hide) some nodes
• Possibility to show only the desired nodes. Very useful if some services are created by an operator and you cannot add labels to hide those. This "whitelist only" mode can be activated by an option added to the UseK8sDiscovery.
• Possibility to use another port than the first one in a k8s service. This can be done by adding some labels to the service. You can choose which port to use filtering by name or by index using according labels.

Affected components:

• CAP.Dashboar.K8s

How to test:

These changes can only be tested by running a project inside kubernetes. After setting up and having some test services in the list try the latter scenarios.

Scenario 1: Hide a node using label dotnetcore.cap.visibility: hide on a service.

• add label to the desired service
• refresh the CAP dashboard and the service should not appear anymore

Scenario 2: Hide all nodes if not explicitly shown

• Register the K8s Discovery with the option ShowOnlyExplicitVisibleNodes=True

  services.UseK8sDiscovery(opt =>{
    opt.ShowOnlyExplicitVisibleNodes = true;
  });

• Refresh the CAP dashboard and you should see no listed nodes
• Add the label dotnetcore.cap.visibility: show to the desired service
• Refresh the CAP dashboard to see only the desired service to be listed as node.

Additional notes (optional):

The GetNodes Method was always returning an empty list because the ns argument was always null in any case. I changed that method to return the list of the services that reside in the namespace of the K8s POD where the dashboard is running. This opens the possibility for the api-access ServiceAccount to not use a ClusterRole but only ose a Role that has access to the services inside the namespace where the dashboard runs. This is the only use case needed for my project as we have different namespaces for different enviorments inside the K8s.

Checklist:

• [x] I have tested my changes locally
• [x] I have added necessary documentation (if applicable)
• [x] I have updated the relevant tests (if applicable)
• [x] My changes follow the project's code style guidelines

Documentation updated.

Reviewers:

• Mention any reviewers you would like to review your PR. This can be helpful if you know someone who is familiar with the part of the codebase you're working on.

[yang-xiaodong]

Thanks for the PR, looks good. Can you add documentation about ShowOnlyExplicitVisibleNodes?

[apatozi]

Thanks for the PR, looks good. Can you add documentation about ShowOnlyExplicitVisibleNodes?

I found the documentation and added all the needed Information about the configuration option and the k8s labels that can be used to customize the view. I didn't do it in the beginning because I did open only with Visual Studio and did not find the docs at first.

For the Chinese part of the docs I did my best with google Translate but I strongly suggest for someone that speaks Chinese to check it out.