Direct Cluster Endpoints are a feature to avoid the central Loft instance and directly connect to a connected Loft cluster. By default, all Kubernetes contexts that are created through Loft will route all Kubernetes traffic (such as
kubectl get pods etc.) through the central Loft instance.
This allows Loft to handle authentication, authorization, auditing, sleep mode activity etc.
However, if you have multiple connected clusters in a Loft instance that are spread across the globe, the traffic redirection through the central Loft gateway can increase request delay. A solution to this are direct cluster endpoints, which avoid rerouting traffic to the central Loft instance and rather handle authentication, authorization etc. directly within the connected cluster through the installed Loft agent.
Exposing the Direct Cluster Endpoint
The Direct Cluster Endpoint feature is bundled into the automatically installed loft agent and can be enabled via an annotation on the connected cluster object.
In order for the direct cluster endpoint to work correctly, you need to expose the Loft agent either via an Ingress or a LoadBalancer / NodePort service first. The easiest way is to create an
ingress.yaml like this and apply it via
Then apply the ingress via
As kubectl requires an HTTPS connection, the direct cluster endpoint has to be reachable by HTTPS as well. By default, the ingress will use a self-signed certificate, however this is insecure and it is recommended to use either cert-manager to issue a Let's Encrypt certificate or to use a trusted self signed certificate.
After creating the ingress, please make sure that the direct cluster endpoint is reachable:
Enable a Direct Cluster Endpoint
In order to tell Loft to use a direct cluster endpoint for a connected cluster, you will need to add an annotation to the cluster object.
The following annotations can be specified:
- loft.sh/direct-cluster-endpoint: This is the domain name that should be used to connect to the cluster directly. This usually corresponds to the ingress host that you have specified earlier. As soon as this annotation is set, the direct cluster endpoint for the connected cluster is turned on and will be preferred in future over the central Loft instance
- loft.sh/direct-cluster-endpoint-insecure (Optional): If this is
true, Loft will create Kubernetes contexts with
insecure-skip-tls-verify: truefor this endpoint
- loft.sh/direct-cluster-endpoint-ca-data (Optional): Base64 encoded ca cert of the direct cluster endpoint
Using a Direct Cluster Endpoint
If a direct cluster endpoint is enabled via the
loft.sh/direct-cluster-endpoint annotation on a connected cluster, the Loft commands
loft use space,
loft use cluster,
loft use vcluster,
loft create space and
loft create vcluster will now use the direct cluster endpoint instead of the central Loft gateway.
The CLI will also notify you when running one of the above commands if a direct cluster endpoint is used:
You can then check which server is contacted by running:
As you can see,
kubectl now routes the traffic directly to the direct cluster endpoint instead of the central Loft instance.