Interacting with a Trident container (NetApp) via CLI within a Openshift/Kubernetes cluster?

Question

Background

We're currently using NetApps Trident PV (Persistent Volume) orchestrator to dynamically create volumes on our NetApp ONTAP clusters for Pods running within our Openshift/Kubernetes environment.

NOTE: See links in the references section if you're unfamiliar with Trident + NetApp.

1. Native Built CLI

Most people will use the pre-built binary but this will only run tridentctl on Linux. Previously we'd been using the tridentctl command natively on a Linux system to interact with the Trident controller running within our cluster.

However, I'd like a more native method to do this from macOS. Currently NetApp does not ship a prebuilt tridentctl binary to do this.

2. Using Docker Image

Previously we'd been using the tridentctl command natively on a Linux system to interact with the Trident controller running within our cluster.

Here's my Trident Pod:

$ oc -n trident get pods
NAME                       READY     STATUS    RESTARTS   AGE
trident-6bdbdbc5dd-l8qtr   2/2       Running   14         6d

Remote shell into the Pod:

$ oc -n trident rsh trident-6bdbdbc5dd-l8qtr
Defaulting container name to trident-main.
Use 'oc describe pod/trident-6bdbdbc5dd-l8qtr -n trident' to see all of the containers in this pod.
/ #

Attempt to run tridentctl:

/ # tridentctl get backend
Error: could not find the Kubernetes CLI
/ #

3. Other Methods

I explored my options in vain but did not care for any of these:

• Build Trident from source
• Construct a new Dockerfile based on the Trident Docker image
• Roll my own Docker image with tridentctl + kubectl

References

• NetApp Trident Read the Docs
• Trident for Kubernetes (overview)
• NetApp Trident (Github)

Answer 1

There's apparently 2 methods one can use to leverage tridentctl to interact with a running Trident Pod in their Openshift/Kubernetes cluster.

1. Server string

The tridentctl CLI can be instructed to talk to whatever server you want remotely using the -s or --server argument. In this context you could use the approach of remote shelling into the Trident Pod and then directing it to interact with the local Trident Orchestrator daemon.

For example

$ oc -n trident rsh trident-6bdbdbc5dd-l8qtr
Defaulting container name to trident-main.
Use 'oc describe pod/trident-6bdbdbc5dd-l8qtr -n trident' to see all of the containers in this pod.
/ #

Now to interact:

/ # tridentctl -s 127.0.0.1:8000 get backend
+--------------------------+----------------+--------+---------+
|           NAME           | STORAGE DRIVER | ONLINE | VOLUMES |
+--------------------------+----------------+--------+---------+
| ontapnas_192.168.101.101 | ontap-nas      | true   |     389 |
+--------------------------+----------------+--------+---------+
/ #

2. Creating a Bash Function

To expand on the above method, one could construct a shell function or alias in Bash to streamline this interaction like so:

Openshift

tridentctl () {
    oc rsh -t -n trident -c trident-main \
        $(oc get pods -n trident -l app=trident.netapp.io -o jsonpath="{.items[].metadata.name}") \
        tridentctl -s 127.0.0.1:8000 $*
}

Kubernetes

tridentctl () {
    kubectl exec -t -n trident \
        $(kubectl get pods -n trident -l app=trident.netapp.io -o jsonpath="{.items[].metadata.name}") \
        -c trident-main -- tridentctl -s 127.0.0.1:8000 $*
}

With one of these functions set, you could then run the following command from your macOS system:

$ tridentctl get storageclass -o json
{
  "items": [
    {
      "Config": {
        "version": "1",
        "name": "basic",
        "attributes": {
          "backendType": "ontap-nas"
        },
        "storagePools": null,
        "additionalStoragePools": null
      },
      "storage": {
        "ontapnas_192.168.101.101": [
          "NA_01_aggr1",
          "NA_01_aggr2"
        ]
      }
    }
  ]
}

How it works

The above function merely determines the name of the Pod within the trident namespace and then remotely executes the command tridentctl using the same method above (from method #1) of connecting to the locally running Trident Orchestrator daemon within the Pod using the --server string.

The advantage with one of these approaches is that you simply can use a function/alias to codify it.

Caveats

Keep in mind that with the above shell function/alias approach will not work with commands such as this:

$ tridentctl create backend -f <backend-file>

because the files you'll be referencing with it, -f <backend-file>, will be local to the system where you'll be running the function/alias, but the tridentctl command will actually be executing within a Pod on another system. This Pod will not have access to your local system's filesystem.

Your only options in this situation will be to either copy the file into the Pod's /tmp filesystem and execute it from there or to redirect the contents of the file, <backend-file> through a pipe, (|), for example:

$ cat <backend-file> | tridentctl create backend -f -