Welcome! In this new series of posts, we’ll be covering how to get started with working with NKS on NetApp HCI. In this series of posts describing an example DevOps pipeline infrastructure, we’ll be covering how to get started with cloud native DevOps on NetApp HCI, leveraging the NetApp Kubernetes Service on-premises.

For those with a need for speed here’s a video walkthrough.

 

Cluster Deployment Prerequisites

Before proceeding, there are a few requirements we’ll need to make sure are in place. Take a look at the NetApp HCI Requirements page, which covers these in detail. Once the NetApp HCI system is registered in Cloud Central as a deployable region, we can proceed.

Deploying a new cluster

If you’ve used NKS before to deploy a cluster against a major cloud provider, deploying a new HCI cluster follows a nearly identical process. First navigate to Control Plane > Clusters and click + Add Cluster in the upper-right corner:

On the provider page, click the NetApp HCI Icon:

note: if you dont see this icon available, your HCI has likely not been registered to NKS. See Enable NKS for HCI for details.

The following page will allow customization of cluster hardware, such as increasing the CPU/Mem of the nodes, or adding more worker nodes. The following instance sizes are available:

The region dialog will list the registered name of your HCI cluster.

On the following page, you can configure various aspects of the cluster- Customize the cluster name, set the K8S version, etc. For this example, we’ll stick with the default values.

 

After clicking ‘Submit’, NKS will start the cluster provisioning- in a few minutes, we’ll have a running cluster. Back on the NKS portal, our cluster will be ready to use once it reaches the ‘running’ state.

 

Cluster Access Options

The cluster details page provides a few ways for us to interact with the cluster, with available options listed in the side pane:

 

The Kubernetes Dashboard – Administration from Anywhere

The Kubernetes Dashboard provides a convenient interface for administering the cluster.

 

 

Unlike SSH and Kubectl, which rely on your client having a routable path to the cluster control plane, NKS provides access to the dashboard from anywhere. This works by establishing a secure connection between NKS and the dashboard service running inside the cluster.

This means we can use the dashboard to administer the cluster from anywhere with access to NKS – no need for VPN.

Cluster Hosts

On the vCenter administration page of the HCI cluster, we can see the virtual machines that have been deployed for the cluster:

Cluster ID
Take note of the prefix of the cluster machines- this is a unique ID generated for the cluster during creation. During cluster bootstrapping, NKS will provision a unique domain for the cluster using this id, which will take the form of: <cluster id>.nks.cloud.

 

Ingress Service Discovery
All subdomains of this domain will resolve to the IP of the cluster’s ingress controller. By registering our own applications behind an ingress controller in the cluster, we can automatically resolve the service endpoint using this domain:

➜ ✗ nslookup my-app.netr66lpfc.nks.cloud
Non-authoritative answer:
my-app.netr66lpfc.nks.cloud     
canonical name = netr66lpfc.nks.cloud
Name:   netr66lpfc.nks.cloud
Address: 10.61.185.88

We’ll explore this in more detail in a future post.

 

Trident Storage Classes

One of the benefits of using NKS with HCI is that by default, NKS can provision HCI volumes and dynamically expose them to cluster workloads via storage classes. It accomplishes this by using Trident.

From the cluster details page, click the Kubernetes Dashboard link on the left pane to access the kubernetes-dashboard service running on the cluster. From the dashboard, navigate to ‘Storage Classes’ to view the default storage classes NKS has configured:

Since these are backed by SolidFire storage present in the HCI, we can leverage the guaranteed performance offered by SolidFire QOS and expose them to application workloads running in the cluster. We’ll explore this in more detail in the future.

 

Conclusion

In this post, we covered how to get started with Kubernetes using NKS with HCI, and deployed a new K8s cluster to our data center.

In the next post in this series, we’ll be taking a look at how we can deploy an application development pipeline on top of our NKS clusters, using the integrated 3rd party Helm charts from the NetApp Kubernetes Services.

 

Non-authoritative answer:
my-app.netr66lpfc.nks.cloud     canonical name = netr66lpfc.nks.cloud.
Name:   netr66lpfc.nks.cloud
Address: 10.61.185.88
Joseph Christianson
Joseph is a Product Marketing Manager in DevOps for NetApp where he creates lively content and success stories for customers looking to become, "DevOps Ready." Prior to joining NetApp he worked in Product Management and as a Creative Marketing consultant. Outside of work, he spends his time in the Colorado sunshine as an active Scooterist.

Pin It on Pinterest