English

NKS End Of Life (EOL)

Contributors ebarcott

To support our new direction, we’re concluding development and ending availability of the NetApp Kubernetes Service (NKS). You can read more about this decision on our website.

At the end of the transitional period, April 30, 2020, users will not be able to log in to the NKS site. Any active clusters will be left running at the provider site. We have judged this to be the least disruptive way to handle the transition.

Note
We strongly recommend you download your cluster’s kubeconfig file and SSH keys before the shutdown.

Migration Suggestions and Tips

Volumes

If you have volumes, please follow these instructions:

  • Detach the volumes from the current nodes.

  • Manually add the existing volumes to the new K8s cluster. More information on this process can be found in the official Kubernetes documentation.

  • Modify your pods to consume the volumes.

Note
If you have a volume type hostpath in use, that data should be manually migrated to the new cluster.

Load Balancer Services

  • Determine which services at your cluster are using cloud provider load balancers.

  • Find the CNAMEs you set up at your DNS for those services.

  • Create the same services at the new cluster. This will create a new set of load balancers.

  • After the entire load is running at the new cluster, modify your CNAME entries to point to the new load balancers.

Ingress

  • Determine the IP that the ingress is exposing. This is the node’s IP address.

  • Find the CNAMEs you set up for that IP address.

  • Create the ingress at the new cluster, and retrieve the node’s new IP address.

  • After the entire load is running at the new cluster, modify your CNAME entries to point to the new IP address.

Redirect the Dashboard From NKS to Local for an On-Prem Cluster

If you would like to keep your on-premises deployments running, rather than having to set up and migrate new clusters, you will want to redirect the NKS cluster dashboard so that it’s exposed locally, rather than through the NKS service.

Note
After you download the cluster’s kubeconfig file from NKS, you have complete admin control over the cluster.

The NKS cluster’s dashboard is being redirected through a proxy. One option is to kill the namespace and redeploy the dashboard, but an easier solution is to access the dashboard by running kubectl proxy.

You can find instructions on accessing the dashboard here on GitHub. The installation already has a dashboard user, so when you get to the step of creating a sample user, you don’t need to create a new one.

Use kubectl get svc -A | grep dashboard to check the dashboard’s namespace:

 % kubectl get svc -A |grep dashboard
kube-system   kubernetes-dashboard                ClusterIP      10.3.0.68    <none>                                                                    443/TCP                      203d

The dashboard’s namespace is in the first column of the results. In this example, the dashboard’s namespace is kube-system.

You will need to get the bearer token. You can do this by running the command:

kubectl -n kube-system describe $(kubectl -n kube-system get secret -n kube-system -o name | grep namespace) | grep token

Then you can access the dashboard by running kubectl proxy. Open the dashboard with http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/ and copy and paste the token in for authentication.

To avoid having to proxy the dashboard every time you want to use it, you can edit the dashboard service to switch from a ClusterIP to a NodePort. You can find an example of how to do this here. However, you will need to change kube-system to kubernetes-dashboard in the commands.

You might also have to edit the dashboard-metrics-scraper service. If you do, set the nodePort to 32415.