Dashboard Access

There are several options for accessing the Kasten K10 dashboard.

Access via kubectl

By default, the K10 dashboard will not be exposed externally. To establish a connection to it use the following kubectl commands.

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

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

Note

If you installed K10 with a different release name than k10 (specified via the --name option in the install command), the above URL should be modified to replace the last occurrence of k10 with the specified release name. The revised URL would look like http://127.0.0.1:8080/<release-name>/#/

If you are running on GKE and want to access the dashboard without local kubectl access, you can use the following advanced GKE console instructions:

Accessing via a LoadBalancer

If you would like to expose the K10 dashboard via an external load balancer, you will need to configure an authentication method. The currently supported options are Basic Authentication, Token Authentication, or OpenID Connect Authentication.

To configure the K10 dashboard to be exposed through the default LoadBalancer and potentially a DNS entry, please use the following helm options. If you have not yet installed K10, add the options to the install command for your environment. Alternatively, you can upgrade the installation as follows:

# example uses Token Authentication method
$ helm upgrade k10 kasten/k10 --namespace=kasten-io \
    --reuse-values \
    --set externalGateway.create=true \
    --set auth.tokenAuth.enabled=true

Configuring DNS

The K10 dashboard will be available at the /k10/ URL path of the DNS or IP address setup using the below options.

Note

If you installed K10 with a different release name than k10 (specified via the --name option in the install command), the dashboard will be available at the /<release-name>/ URL path.

Using ExternalDNS

If your Kubernetes cluster is already using ExternalDNS and has it properly configured, you should add the following options to automatically configure a DNS entry for the load balancer.

--set externalGateway.externalGateway.fqdn.type=external-dns \
--set externalGateway.fqdn.name=<my-desired.dns.name>

Manually adding a DNS entry

If your environment does not support ExternalDNS, first find the LoadBalancer's public DNS/IP address:

$ kubectl --namespace kasten-io get service gateway-ext \
   -o jsonpath='{.status.loadBalancer.ingress[].hostname}'

You can then optionally setup a DNS record that points from a desired FQDN to the LoadBalancer DNS or IP address from above.

Adding Custom Annotations

In certain scenarios, custom annotations on the LoadBalancer be required. These can be added as a part of the install process too. For example, if an annotation of the form service.beta.kubernetes.io/aws-loadbalancer-internal: 0.0.0.0/0 was needed, add it to a values file as follows:

cat > value.yaml <<EOF
externalGateway:
  annotations:
    service.beta.kubernetes.io/aws-loadbalancer-internal: 0.0.0.0/0
EOF

and then use --values in the helm install command:

--values value.yaml

Existing Ingress Controller

If there is already an Ingress controller installed and the goal is to expose the K10 dashboard through it, the following option must be specified with the helm install command:

--set ingress.create=true

By default, the Ingress object is created with the name {release-name}-ingress. To use a different name, specify the following option:

--set ingress.name="<custom-name>"

It is necessary to follow the specific Ingress controller guidelines to expose an external endpoint for the k10-ingress Kubernetes Ingress object that will be installed in the kasten-io namespace as part of the Helm installation.

Additionally, an Ingress class can be chosen for the Ingress object by specifying the following option to the helm command:

--set ingress.create=true --set ingress.class=nginx

In some environments, additional Ingress annotations might be required. Required annotations can be added during install via the ingress.annotations option. For example, the below option will add nginx.ingress.kubernetes.io/force-ssl-redirect: "true" to the K10 Ingress resource.

--set ingress.annotations."nginx.ingress.kubernetes.io/ssl-redirect"="true"

By default, the Ingress is configured with the default path /<release-name>/. A custom path can be specified for the Ingress using the following option:

--set ingress.urlPath="/<custom-path>"

# With custom Ingress path, prometheus baseURL and prefixURL
# options also need to be updated with the same <custom-path> prefix.

--set prometheus.server.baseURL="/<custom-path>/prometheus/" \
--set prometheus.server.prefixURL="/<custom-path>/prometheus/"

Note

If you want to expose pre-installed K10 with ingress, the path in the ingress specs must be set to the release-name used while installing K10.

To redirect the traffic that does not match the default path, a defaultBackend can be optionally configured for the Ingress. There are two possible options for configuring the defaultBackend:

  1. Using a backing service:

# When specifying a service port name
--set ingress.defaultBackend.service.enabled=true \
--set ingress.defaultBackend.service.name="<service-name>" \
--set ingress.defaultBackend.service.port.name="<port-name>"

# When specifying a service port number
--set ingress.defaultBackend.service.enabled=true \
--set ingress.defaultBackend.service.name="<service-name>" \
--set ingress.defaultBackend.service.port.number=<port-number>

  1. Using a resource backend:

--set ingress.defaultBackend.resource.enabled=true \
--set ingress.defaultBackend.resource.kind="<resource-kind>" \
--set ingress.defaultBackend.resource.name="<resource-name>"

# Optionally, a resource API group can be specified
--set ingress.defaultBackend.resource.apiGroup="<resource-api-group>"

Access via OpenShift Routes

To access the K10 dashboard via an OpenShift Route, an authentication method needs to be configured. The currently supported authentication options are Basic Authentication, Token Authentication, Active Directory, Openshift Authentication,or OpenID Connect Authentication.

The following Helm options can be used to configure the K10 dashboard to be exposed through an OpenShift Route and potentially a DNS entry. If K10 is not yet installed, add the options to the helm install command for the environment. Alternatively, the installation can be upgraded as follows:

# This example uses the Token Authentication method
$ helm upgrade k10 kasten/k10 --namespace=kasten-io \
    --reuse-values \
    --set route.enabled=true \
    --set auth.tokenAuth.enabled=true

The following option will auto-generate a route hostname as a subdomain to the existing FQDN. A host name can be explicitly with the route with the following option:

--set route.host=<A FQDN of your choice with proper DNS entry>

The ability to use the kubectl proxy method described above or an externally accessible endpoint is still there but their configuration depends on the specific cluster configuration.

Additionally, the path for the Route object can be specified by using the following option:

--set route.path="/<custom-path>"

# With custom route path, prometheus baseURL and prefixURL
# options also need to be updated with the same <custom-path> prefix.

--set prometheus.server.baseURL="/<custom-path>/prometheus/" \
--set prometheus.server.prefixURL="/<custom-path>/prometheus/"

Note

If you want to expose pre-installed K10 with route, the path in the route specs must be set to the release-name used while installing K10.

SSL/TLS with the Route can enabled by specifying the following option:

--set route.tls.enabled=true

Additionally, to specify the TLS insecureEdgeTerminationPolicy or termination Route parameters, the following option needs to be specified:

--set route.tls.termination=<reencrypt/edge/passthrough>
--set route.tls.insecureEdgeTerminationPolicy=<disable/redirect/allow>