Advanced Install Options

Starter Edition and Licensing

By default, K10 comes with an embedded Starter Edition license. The starter edition license allows you to use the software on a cluster with at most 50 worker nodes for one month and then 3 nodes after the one month period. The starter edition license embedded in each release is valid for 12 months after which an update to the latest released version will be required which will extend the license. You can remove the node restriction by updating to Enterprise Edition and obtaining the appropriate license from the Kasten team.

Using A Custom License During Install

To install a license provided by Kasten that removes the node restriction, please add the following to any of the helm install commands.

...
          --set license=<license-text>

Upgrading Your License

If you already have K10 installed and want to change the license, you can easily do this via a helm upgrade. The version of K10 running needs to be specified below so that no unintentional upgrade of K10 occurs. You can obtain the current version of K10 by looking at the footer on the dashboard or running helm list.

$ helm upgrade k10 kasten/k10 \
    --set license=<license-text> \
    --reuse-values \
    --version=<current version>
$ helm upgrade k10 kasten/k10 --namespace=kasten-io \
    --set license=<license-text> \
    --reuse-values \
    --version=<current version>

Alternatively you can also do the following:

$ kubectl --namespace=kasten-io patch secret k10-license \
          --patch='{"data":{"license":"<license text>"}}'

Manually Creating or Using an Existing Service Account

The following instructions can be used to create a new Service Account that grants K10 the required permissions to Kubernetes resources and the use the given Service Account as a part of the install process. The instructions assume that you will be installing K10 in the kasten-io namespace.

# Create kasten-io namespace if have not done it yet.
$ kubectl create namespace kasten-io

# Create a ServiceAccount for k10 k10-sa
$ kubectl --namespace kasten-io create sa k10-sa

# Create a cluster role binding for k10-sa
$ kubectl create clusterrolebinding k10-sa-rb \
    --clusterrole cluster-admin \
    --serviceaccount=kasten-io:k10-sa

Following the SA creation, you can install K10 using:

$ helm install kasten/k10 --name=k10 \
    --set rbac.create=false \
    --set serviceAccount.create=false \
    --set serviceAccount.name=k10-sa
$ helm install k10 kasten/k10 --namespace=kasten-io \
    --set rbac.create=false \
    --set serviceAccount.create=false \
    --set serviceAccount.name=k10-sa

Pinning K10 to Specific Nodes

While not generally recommended, there might be situations (e.g., test environments, nodes reserved for infrastructure tools, or clusters without autoscaling enabled) where K10 might need to be pinned to a subset of nodes in your cluster. You can do this easily with an existing deployment by using a combination of NodeSelectors and Taints and Tolerations.

The process to modify a deployment to accomplish this is demonstrated in the following example. The example assumes that the nodes you want to restrict K10 to has the label selector-key: selector-value and a taint set to taint-key=taint-value:NoSchedule.

$ cat << EOF > patch.yaml
spec:
  template:
    spec:
      nodeSelector:
        selector-key: selector-value
      tolerations:
      - key: "taint-key"
        operator: "Equal"
        value: "taint-value"
        effect: "NoSchedule"
EOF

$ kubectl get deployment --namespace kasten-k10 | awk 'FNR == 1 {next} {print $1}' \
  | xargs -I DEP kubectl patch deployments DEP --namepsace kasten-k10 --patch "$(cat patch.yaml)"

Air-Gapped Installation

Air-gapped installation is supported if your Kubernetes cluster does not have access to either the K10 Helm charts repository or the K10 container image repositories. If this is a requirement, please refer to the following documentation for detailed instructions.

Complete List of K10 Helm Options

The following table lists the configurable parameters of the K10 chart and their default values.

Parameter

Description

Default

eula.accept

Whether to enable accept EULA before installation

false

eula.company

Company name. Required field if EULA is accepted

None

eula.email

Contact email. Required field if EULA is accepted

None

license

License string obtained from Kasten

None

rbac.create

Whether to enable RBAC with a specific cluster role and binding for K10

true

scc.create

Whether to create a SecurityContextConstraints for K10 ServiceAccounts

false

serviceAccount.create

Specifies whether a ServiceAccount should be created

true

serviceAccount.name

The name of the ServiceAccount to use. If not set, a name is derived using the release and chart names.

None

ingress.create

Specifies whether the K10 dashboard should be exposed via ingress

false

ingress.class

Cluster ingress controller class: nginx, GCE

None

ingress.host

FQDN (e.g., .k10.example.com) for name-based virtual host

None

ingress.urlPath

URL path for K10 Dashboard (e.g., /k10)

Release.Name

persistence.enabled

Use PVS to persist data

true

persistence.size

Size of an volume for K10 persistent services

20Gi

persistence.storageClass

Specified StorageClassName will be used for PVCs

None

secrets.awsAccessKeyId

AWS access key ID (required for AWS deployment)

None

secrets.awsSecretAccessKey

AWS access key secret

None

secrets.awsIamRole

ARN of the AWS IAM role assumed by K10 to perform any AWS operation.

None

secrets.googleApiKey

Non-default base64 encoded GCP Service Account key file

None

secrets.azureTenantId

Azure tenant ID (required for Azure deployment)

None

secrets.azureClientId

Azure Service App ID

None

secrets.azureClientSecret

Azure Service APP secret

None

secrets.ibmSoftLayerApiKey

IBM SoftLayer API key

None

secrets.ibmSoftLayerApiUsername

IBM SoftLayer API username

None

secrets.vsphereEndpoint

vSphere endpoint for login

None

secrets.vsphereUsername

vSphere username for login

None

secrets.vspherePassword

vSphere password for login

None

secrets.dockerConfigPath

Use --set-file secrets.dockerConfigPath=path_to_docker_config.yaml to specify docker config for image pull

None

clusterName

Cluster name for better logs visibility

None

metering.mode

Control license reporting (set to airgap for private-network installs)

None

externalGateway.create

Configures an external gateway for K10 API services

false

externalGateway.annotations

Standard annotations for the services

None

externalGateway.fqdn.name

Domain name for the K10 API services

None

externalGateway.fqdn.type

Supported gateway type: route53-mapper or external-dns

None

externalGateway.awsSSLCertARN

ARN for the AWS ACM SSL certificate used in the K10 API server

None

auth.basicAuth.enabled

Configures basic authentication for the K10 dashboard

false

auth.basicAuth.htpasswd

A username and password pair separated by a colon character

None

auth.basicAuth.secretName

Name of an existing Secret that contains a file generated with htpasswd

None

auth.tokenAuth.enabled

Configures token based authentication for the K10 dashboard

false