OpenShift 3.11

The recommended way to run StorageOS on an OpenShift 3.11 cluster is to deploy a daemonset with RBAC support.


  1. Ensure any firewalls permit the appropriate ports
  2. If your cluster enables SELinux, add the following permissions for each of the nodes that run StorageOS.
    setsebool -P virt_sandbox_use_fusefs on
    setsebool -P virt_use_fusefs on

    The -P option makes the change persistent after reboots.

  3. Ensure that your docker installation has mount propagation enabled per our mount propagation prerequisites
  4. Enable the MountPropagation flag by appending feature gates to the api and controller (you can apply these changes using the Ansible Playbooks)

Note: If you are using atomic installation rather than origin, the location of the yaml config files and service names might change.

  • Add to the KubernetesMasterConfig section (/etc/origin/master/master-config.yaml):

        - MountPropagation=true
        - MountPropagation=true
  • Add to the feature-gates to the kubelet arguments (/etc/origin/node/node-config.yaml):

      - MountPropagation=true

Warning: Restarting OpenShift services can cause downtime in the cluster.

  • Restart services in the MasterNode/s
    master-restart api
    master-restart controllers
    # Restart kubelet
    systemctl restart atomic-openshift-node.service
  • Restart service in all Nodes
    # Restart kubelet
    systemctl restart atomic-openshift-node.service

Install StorageOS operator

Our cluster operator is a Kubernetes native application developed to deploy and configure StorageOS clusters, and assist with maintenance operations. We recommend its use for standard installations.

The operator is a Kubernetes controller that watches the StorageOSCluster CRD. Once the controller is ready, a StorageOS cluster definition can be created. The operator will deploy a StorageOS cluster based on the configuration specified in the cluster definition.


The StorageOS Cluster Operator can be installed with two options.

  • Using Helm
  • Standard yaml manifests

(Option 1) Using Helm

helm repo add storageos
helm install storageos/storageoscluster-operator --namespace storageos-operator

The Helm chart can be found in the Charts public repository.

The StorageOS Cluster Operator source code can be found in the cluster-operator repository.

The helm server, tiller, needs privileges to be able to deploy the StorageOS Cluster Operator. You can add the service account to the cluster-admin role for simplicity or create a role that matches the cluster-operator requirements.

(Option 2) Standard yaml manifests

git clone storageos
cd storageos/openshift/deploy-storageos/cluster-operator

Verify the Cluster Operator Pod

[[email protected]]# oc -n storageos-operator get pod
NAME                                         READY     STATUS    RESTARTS   AGE
storageoscluster-operator-68678798ff-f28zw   1/1       Running   0          3m

The READY 1/1 indicates that stos resources can be created.

Create a Secret

Before deploying a StorageOS cluster, create a Secret defining the StorageOS API Username and Password in base64 encoding.

The API username and password are used to create the default StorageOS admin account which can be used with the StorageOS CLI and to login to the StorageOS GUI. The account defined in the secret is also used by Kubernetes to authenticate against the StorageOS API when installing with the native driver.

oc create -f - <<END
apiVersion: v1
kind: Secret
  name: "storageos-api"
  namespace: "default"
    app: "storageos"
type: ""
  # echo -n '<secret>' | base64
  apiUsername: c3RvcmFnZW9z
  apiPassword: c3RvcmFnZW9z

This example contains a default password, for production installations, use a unique, strong password.

You can define a base64 value by echo -n "mystring" | base64.

Make sure that the encoding of the credentials doesn’t have special characters such as ‘\n’. The echo -n ensures that a trailing new line is not appended to the string.

If you wish to change the default accounts details post-install please see Managing Users

Add scc (security context constraint) for StorageOS

oc adm policy add-scc-to-user privileged system:serviceaccount:storageos:storageos-daemonset-sa
oc adm policy add-scc-to-user privileged system:serviceaccount:storageos:storageos-statefulset-sa

Trigger a StorageOS installation

This is a Cluster Definition example.

oc create -f - <<END
apiVersion: ""
kind: StorageOSCluster
  name: "example-storageos"
  secretRefName: "storageos-api" # Reference the Secret created in the previous step
  secretRefNamespace: "default"  # Namespace of the Secret
    nodeContainer: "storageos/node:1.2.1" # StorageOS version
    memory: "512Mi"
    - matchExpressions:
      - key: ""
        operator: In
        - "true"

spec parameters available on the Cluster Operator configuration page.

You can find more examples such as deployments with CSI or deployments referencing a external etcd kv store. store for StorageOS in the Cluster Operator examples page.

If this is your first installation you may wish to follow the StorageOS Volume guide for an example of how to mount a StorageOS volume in a Pod.

Custom Installations

There are a variety of flavours, versions and particularities in the container orchestrator scope. Because of this, StorageOS installation procedures aim to be flexible so they can fit different needs depending on the environment, preferences or requirements. The StorageOS cluster operator simplifies the installation by implementing automated install. You can review and adapt the StorageOS install in the following examples. Feel free to extend and modify the publicly available examples.

Installation with Native Drivers (default)

The following github repository hosts installation examples.

git clone storageos
cd storageos/openshift/deploy-storageos

You can see various installation examples are available such as standard, CSI (Container Storage Interface) or etcd-as-svc. All of them have a that serves as a wrapper to trigger the manifest creation. Follow the according for each one of them for more details.

For advanced installations, it is recommended to refer to etcd-as-svc that will guide the user to deploy an etcd cluster deployed by the official Kubernetes etcd operator. Once an external etcd cluster has been created, then use the StorageOS cluster operator to finish the installation.