Helm based Installation¶

Prerequisites¶

Before installing K10 on Red Hat OpenShift, please ensure that the install prerequisites are met.

K10 Install¶

Depending on your OpenShift infrastructure provider, you might need to provide access credentials as specified elsewhere for public cloud providers.

You will also need to add the following argument to create the SecurityContextConstraints for K10 ServiceAccounts.

$ helm install k10 kasten/k10 --namespace=kasten-io \
    --set scc.create=true

OpenShift on AWS¶

When running OpenShift on AWS, please configure these policies before running the install command below.

$ helm install k10 kasten/k10 --namespace=kasten-io \
    --set scc.create=true \
    --set secrets.awsAccessKeyId="${AWS_ACCESS_KEY_ID}" \
    --set secrets.awsSecretAccessKey="${AWS_SECRET_ACCESS_KEY}"

OpenShift and CSI¶

Note

The feature flag mentioned below is only required for OpenShift 4.4 and earlier.

To use OpenShift and K10 with CSI-based volume snapshots, the VolumeSnapshotDataSource feature flag needs to be enabled. From the OpenShift management console, as an administrator, select Administration → Cluster Settings → Global Configuration → Feature Gate → YAML. The resulting YAML should look like:

apiVersion: config.openshift.io/v1
kind: FeatureGate
metadata:
  annotations:
    release.openshift.io/create-only: 'true'
name: cluster
spec:
  customNoUpgrade:
    enabled:
      - VolumeSnapshotDataSource
  featureSet: CustomNoUpgrade

      
    

Accessing Dashboard via Route¶

As documented here, the K10 dashboard can also be accessed via an OpenShift Route.

Authentication¶

OpenShift OAuth server¶

As documented here, the OpenShift OAuth server can be used to authenticate access to K10.

Using OAuth Proxy¶

As documented here, the OpenShift OAuth proxy can be used for authenticating access to K10.

Kanister Sidecar Injection on OpenShift 3.11¶

To use the K10 Kanister sidecar injection feature on OpenShift 3.11, make sure that the MutatingAdmissionWebhook setting is enabled. If not, follow the steps below to enable it:

On a control plane node, add the following config to the admissionConfig.pluginConfig section of the /etc/origin/master/master-config.yaml file:

MutatingAdmissionWebhook:
  configuration:
    apiVersion: v1
    disable: false
    kind: DefaultAdmissionConfig

      
    

Restart control plane services with:

$ master-restart api && master-restart controllers

Validating the Install¶

To validate that K10 has been installed properly, the following command can be run in K10's namespace (the install default is kasten-io) to watch for the status of all K10 pods:

$ kubectl get pods --namespace kasten-io --watch

It may take a couple of minutes for all pods to come up but all pods should ultimately display the status of Running.

$ kubectl get pods --namespace kasten-io
NAMESPACE     NAME                                    READY   STATUS    RESTARTS   AGE
kasten-io     aggregatedapis-svc-b45d98bb5-w54pr      1/1     Running   0          1m26s
kasten-io     auth-svc-8549fc9c59-9c9fb               1/1     Running   0          1m26s
kasten-io     catalog-svc-f64666fdf-5t5tv             2/2     Running   0          1m26s
...

      
    

In the unlikely scenario that pods that are stuck in any other state, please follow the support documentation to debug further.

Validate Dashboard Access¶

By default, the K10 dashboard will not be exposed externally. To establish a connection to it, use the following kubectl command to forward a local port to the K10 ingress port:

$ kubectl --namespace kasten-io port-forward service/gateway 8080:8000

The K10 dashboard will be available at http://127.0.0.1:8080/k10/#/.

For a complete list of options for accessing the Kasten K10 dashboard through a LoadBalancer, Ingress or OpenShift Route you can use the instructions here.