Configure K10 to use AWS Application Loadbalancer (ALB)

This article provides an example on how to configure ALB for accessing K10s UI. This article assumes that ALB ingress controller has already been installed and configured, if not please complete it first.

There are multiple ways to configure access to Kasten K10 dashboard, ingress, routes(in case of OCP cluster), external gateway (Cloud providers load balancer) are some of commonly used ones.

What is an ALB

An Application Load Balancer functions at the application layer, the 7th layer of the OSI model.

It evaluates the listener rules and routes the traffic to the target group as and when it receives a request. It supports host-based as well as path-based routing. These rules can be configured or fine tuned using specific annotations.

The AWS Load Balancer Controller creates ALBs and necessary supporting AWS resources whenever a Kubernetes ingress resource is created on the cluster with the `kubernetes.io/ingress.class: alb` annotation. The ingress resource configures the ALB to route HTTP or HTTPS traffic to different pods within the cluster. 

How to install K10 with AWS ALB

Below are the helm values that can be used to configure the ALB listener rules and health checks with a Kasten K10 install

cat <<EOF > k10values.yaml
secrets:
#to configure AWS keys for direct integration if the in-tree provisioner is used as a provisioner in storageClass
awsAccessKeyId: XXXXXXXXXXX
awsSecretAccessKey: **SECRET**
auth:
#Enabling external access to K10 using ingress required authentication to be enabled. Enabled token auth for simplicity
tokenAuth:
  enabled: true
ingress:
create: true
host: k10.example.kasten.io
#setting this path type to prefix will set the listener rules to allow the paths with the prefix k10/*
pathType: Prefix
annotations:
  #AWS Load Balancer Controller supports the following traffic modes.
  #instance mode- Registers nodes within your cluster as targets for the ALB. Traffic reaching the ALB is routed to NodePort for your service and then proxied to your pods
  #ip mode - Registers pods as targets for the ALB. Traffic reaching the ALB is directly routed to pods for your service.
  alb.ingress.kubernetes.io/target-type: ip
  #scheme can be internal or internet-facing
  alb.ingress.kubernetes.io/scheme: internet-facing
  #By default, the success code is 200, but you can optionally specify additional success codes for redirects while configuring health checks.
  alb.ingress.kubernetes.io/success-codes: 200,302,303
  #path to perform loadbalancer healthchecks. K10s gateway by default uses /k10/ path(this changes based on the helm release name that is used for installing k10)
  alb.ingress.kubernetes.io/healthcheck-path: /k10/
  #annotation to let the ALB ingress controller know that it needs to provision an ALB loadbalancer.
  kubernetes.io/ingress.class: alb
  #To share an application load balancer across multiple service resources using IngressGroups
  #To join an ingress to a group, add the following annotation to a Kubernetes ingress resource specification.
  #alb.ingress.kubernetes.io/group.name: my-group
EOF

 

Install K10 with the below command using the ALB values mentioned above.

helm install k10 kasten/k10 --create-namespace --namespace=kasten-io -f k10values.yaml