Chapter 1. Preparing to deploy OpenShift Container Storage
Deploying OpenShift Container Storage on OpenShift Container Platform using local storage devices provided by IBM Power Systems enables you to create internal cluster resources. This approach internally provisions base services. Then, all applications can access additional storage classes.
Only internal Openshift Container Storage clusters are supported on IBM Power Systems. See Planning your deployment for more information about deployment requirements.
Before you begin the deployment of Red Hat OpenShift Container Storage using local storage, ensure that your resource requirements are met. See requirements for installing OpenShift Container Storage using local storage devices.
On the external key management system (KMS),
- Ensure that a policy with a token exists and the key value backend path in Vault is enabled. see enabling key value backend path and policy in vault.
- Ensure that you are using signed certificates on your Vault servers.
After you have addressed the above, follow the below steps in the order given:
1.1. Requirements for installing OpenShift Container Storage using local storage devices
Node requirements
The cluster must consist of at least three OpenShift Container Platform worker nodes in the cluster with locally attached storage devices on each of them.
- Each of the three selected nodes must have at least one raw block device available to be used by OpenShift Container Storage.
- The devices to be used must be empty, that is, there should be no persistent volumes (PVs), volume groups (VGs), or local volumes (LVs) remaining on the disks.
You must have a minimum of three labeled nodes.
Each node that has local storage devices to be used by OpenShift Container Storage must have a specific label to deploy OpenShift Container Storage pods. To label the nodes, use the following command:
$ oc label nodes <NodeNames> cluster.ocs.openshift.io/openshift-storage=''
See the Resource requirements section in Planning guide.
1.2. Enabling key value backend path and policy in Vault
Prerequisites
- Administrator access to Vault.
-
Choose a unique path name as the backend
paththat follows the naming convention since it cannot be changed later.
Procedure
Enable the Key/Value (KV) backend path in Vault.
For Vault KV secret engine API, version 1:
$ vault secrets enable -path=ocs kv
For Vault KV secret engine API, version 2:
$ vault secrets enable -path=ocs kv-v2
Create a policy to restrict users to perform a write or delete operation on the secret using the following commands:
echo ' path "ocs/*" { capabilities = ["create", "read", "update", "delete", "list"] } path "sys/mounts" { capabilities = ["read"] }'| vault policy write ocs -Create a token matching the above policy:
$ vault token create -policy=ocs -format json
