Skip to content
This repository is currently being migrated. It's locked while the migration is in progress.

Latest commit

 

History

History
148 lines (104 loc) · 5.36 KB

README.MD

File metadata and controls

148 lines (104 loc) · 5.36 KB

StorageOS kubectl plugin

Go Report Card e2e test CodeQL GitHub Super-Linter Active PR's Welcome License

Administrating tool for your StorageOS clusters.

Installation

Pre-Requisites

  • Go 1.18+

Download released version

curl -sSLo kubectl-storageos.tar.gz \
    https://github.com/storageos/kubectl-storageos/releases/download/v1.4.0/kubectl-storageos_1.4.0_linux_amd64.tar.gz \
    && tar -xf kubectl-storageos.tar.gz \
    && chmod +x kubectl-storageos \
    && sudo mv kubectl-storageos /usr/local/bin/ \
    && rm kubectl-storageos.tar.gz

Build from source

git clone https://github.com/storageos/kubectl-storageos.git
cd kubectl-storageos
make build
cp ./bin/kubectl-storageos /usr/local/bin # directory on your $PATH

Usage

Install the latest version of StorageOS on your kubernetes cluster

kubectl storageos install

Install an ETCD Cluster and the latest version of StorageOS

Warning: This installation of ETCD is not production ready.

kubectl storageos install --include-etcd

Uninstall StorageOS from your kubernetes cluster

kubectl storageos uninstall

Uninstall both StorageOS and ETCD from your kubernetes cluster

The following process will not remove data stored in disk by StorageOS. If Etcd is removed, StorageOS Volumes won't be recoverable, but if the Etcd cluster is kept intact, the volumes and their data will be available after a reinstall.

kubectl storageos uninstall --include-etcd

The ETCD uninstall process refers only to an ETCD cluster installed by the StorageOS ETCD Cluster Operator.

Note: The StorageOS ETCD Cluster Operator is a fork of the Improbable Engineering ETCD Cluster Operator. As such, an instance of the latter operator running on the user's Kubernetes cluster can also be uninstalled by this command.

Upgrade StorageOS to the latest version

kubectl storageos upgrade

The upgrade commands uninstalls your existing StorageOS cluster and installs the latest StorageOS cluster.

Preflight checks

kubectl storageos preflight

A preflight check is a set of validations that can be run to ensure that a cluster meets the requirements to run StorageOS.

Config file

Flags can also be passed to the install, uninstall and upgrade commands via the kubectl storageos config file like so:

kubectl storageos install --config-path=/path/to/config

This command expects to find a config file named "kubectl-storageos-config.yaml"

The upgrade command reads the uninstall and install settings in the config spec to perform the upgrade. The following is an example of a config file that might be used for an upgrade with custom namespaces:

apiVersion: storageos.com/v1
kind: KubectlStorageOSConfig
metadata:
  name: kubectlstorageosconfig-sample
spec:
  install:
    storageOSOperatorNamespace: storageos-operator-new
    storageOSClusterNamespace: storageos-cluster-new
  uninstall:
    storageOSOperatorNamespace: storageos-operator-old

For an example config file, see config/samples/_v1_kubectlstorageosconfig.yaml.

Enable TLS

Install ETCD and StorageOS with TLS enabled

kubectl storageos install --include-etcd --etcd-tls-enabled

Install StorageOS and connect to an existing TLS enabled ETCD cluster

kubectl storageos install --etcd-tls-enabled

In order for StorageOS to connect to ETCD over HTTPS, a k8s secret must exist in the storageos-cluster-namespace with valid ETCD credentials. This secret can be created like so:

kubectl create secret generic <etcd-secret-name> -n <storageos-cluster-namespace> \
    --from-file=etcd-client-ca.crt=path/to/ca.crt \
    --from-file=etcd-client.crt=path/to/tls.crt \
    --from-file=etcd-client.key=path/to/tls.key

Note: The default etcd-secret-name is storageos-etcd-secret. Should you name your secret differently, you must pass the name to the install command via --etcd-secret-name

Recovery

Before uninstall and upgrade commands are executed, a number of manifests relative to the existing StorageOS cluster are written locally to disk in order for the user to manually recover the cluster should an error occur.

These manifests can be located at $HOME/.kube/storageos.