CNS Manager is a diagnostic and self-service tool that helps detect and auto-remediate some of the known issues in storage control plane in vCenter. It also provides certain table stake features, such as svMotion and datastore decomission to complement the Cloud Native Storage solution offered in vCenter. CNS Manager exposes APIs that can be invoked by authorized users to detect issues.
This repository provides artifacts for deploying CNS manager in vanilla Kubernetes cluster, as well as the client sdk to invoke its endpoints.
CNS manager needs to be deployed in one of the Kubernetes clusters in the vCenter.
If there are multiple Kubernetes clusters in a vCenter, it's recommended that it be deployed in a dedicated admin-managed cluster, but it's not a must. However, the admin should be responsible to secure the Kubernetes cluster where CNS manager is deployed since it will have credentials to vCenter and the Kubernetes cluster.
Also if you want CNS manager to be highly available, deploy it on a Kubernetes cluster that's highly available itself.
Note : To deploy CNS manager from this repo, you can clone it on your machine and then set kubeconfig to point to the remote Kubernetes cluster where CNS manager needs to be deployed. Then follow the instructions for deployment.
The deployment is supported with two authentication mechanisms to limit who can access CNS manager APIs:
Basic Auth - The CNS manager admin can choose fixed credentials at the time of deployment. This auth mechanism is less secure than OAuth2 to be used in Production. Nevertheless, it can be used for a quick deployment to test the application and in air-gapped environments where the vCenter is not connected to the internet. See these instructions for basic auth deployment.
OAuth2 - With OAuth2, the authentication is delegated to an OIDC provider such as Gitlab, Github,Google etc. It does require creating an OAuth application on the OIDC provider before deploying CNS manager.
See these instructions for OAuth2 deployment.
You can enable TLS for your CNS Manager deployment with a few tweaks, so that the communication is encrypted between client(a browser, for instance) and the application.
See these deployment changes to enable TLS on CNS Manager. It can be done for both basicauth & OAuth2 deployments, and assumes you have the TLS key and certificate generated.
CNS manager relies on communicating with Kubernetes clusters for several functionalities it offers. It is therefore a pre-requisite to register all Kubernetes clusters in vCenter with CNS manager.
Note: CNS manager can support upto 32 Kubernetes clusters per vCenter. Please see supported scale for any recommended configurations for CNS manager.
The following section explains how to register a Kubernetes cluster with CNS manager. These steps are applicable to all Kubernetes clusters in the vCenter.
1. Generate a kubeconfig with minimal privileges for CNS manager:
scripts/get-kubeconfig.sh
generates a kubeconfig for CNS manager with minimal privileges required for its functioning. But if you're fine with providing admin kubeconfig for the cluster to be registered, you can skip kubeconfig generation part mentioned below and directly jump to cluster registration part. Note : The script may not work on all Kubernetes distributions if they don't adhere to the recommended steps for deploying vSphere CSI driver.
./get-kubeconfig.sh <kubeconfig_file_path> <output_file_name>
./get-kubeconfig.sh <kubeconfig_file_path> <output_file_name> <context name> <server URL>
2. Register cluster with CNS manager using kubeconfig:
/registercluster
API on CNS manager by uploading the kubeconfig file. You may also modify other input parameters for the API based on your cluster configuration.
The API can also be invoked from command line. Here is an example:
curl -X 'POST' "http://CNS-MANAGER-ENDPOINT/1.0.0/registercluster?csiDriverSecretName=vsphere-config-secret&csiDriverSecretNamespace=vmware-system-csi" -H 'accept: application/json' -H 'Content-Type: multipart/form-data' -F 'clusterKubeConfigFile=@output_file_name' -u "Admistrator:Admin123@"
Note: If a registered cluster later gets decommissioned or deleted from the vCenter, don't forget to deregister it from CNS manager as well. This will ensure a smooth execution of functionalities offered through CNS manager.
See the upgrade instructions if you're upgrading previously deployed cns-manager instance to a newer release.
Storage vMotion for CNS volumes
This feature allows migrating volumes from one datastore to another. Read here for more details about this feature.
Orphan volumes detection & deletion
This feature allows detecting/deleting orphan volumes that are not being used in any of the registered Kubernetes clusters on the vCenter. Read here for more details about this feature.
Orphan snapshots detection & deletion
This feature allows detecting/deleting orphan snapshots that are not being used in any of the registered Kubernetes clusters on the vCenter. Read here for more details about this feature.