Background

Your Kubernetes deployment hosts the Fuzzball web UI. By default, the web UI isn’t directly exposed to the outside world. In a bare-metal environment like the one created in the RKE2 Installation Guide, access to the web UI is provided through a load balancer implemented using MetalLB, which makes the web UI accessible on the same network as your cluster nodes. Since your local machine most likely resides on a different network, you’ll need to “bridge” the gap between your local machine and the network where your Fuzzball installation resides.

Here’s a simplified diagram of the “bridge” that we’ll build:

Your Local Machine: Your laptop, desktop, or workstation where you want to use the Fuzzball Web UI
SSH Tunnel: A secure, encrypted connection established using the SSH protocol
Server Node: The node within your Fuzzball cluster that runs the Kubernetes deployment hosting the UI
LoadBalancer: A Kubernetes service that distributes network traffic to the web UI pods
Fuzzball-UI: The web application that serves the web UI for interacting with Fuzzball

Demonstrating Internal Connectivity

Let’s explore how this works in practice, starting from the server node. On the Server Node (where you have kubectl configured), we’ll fetch the HTML content of the Fuzzball Web UI page from within the cluster - just like a web browser would. This will confirm that the Ingress, LoadBalancer, and web UI are all functioning properly.

First, get the Ingress hostname. We’ll use kubectl to find the Fuzzball UI Ingress:

# kubectl get ingress -n fuzzball | { head -n 1; grep -w "ui"; }
NAME                        CLASS   HOSTS                               ADDRESS     PORTS     AGE
fuzzball-admin-ui           kong    ui-admin.10.0.0.99.nip.io           10.0.0.99   80, 443   3d2h
fuzzball-ui                 kong    ui.10.0.0.99.nip.io                 10.0.0.99   80, 443   3d2h

Notice that two hosts are returned. This is because Fuzzball serves two web applications for managing and using the platform: the Admin UI and the User UI.

Now that we know the URL hosting the Fuzzball Admin UI, let’s fetch the HTML content using curl:

# curl http://ui-admin.10.0.0.99.nip.io
<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <link rel="icon" type="image/svg+xml" href="/favicon-32x32.png" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Fuzzball Cluster Admin</title>
    <script type="module" crossorigin src="/assets/index-DaZ4HEGv.js"></script>
    <link rel="stylesheet" crossorigin href="/assets/index-BV7GULUg.css">
  </head>
  <body>
    <div id="root"></div>
  </body>
</html>

If you don’t get output similar to the one above, this indicates a problem somewhere in the internal network path, and you’ll need to troubleshoot before proceeding with the SSH tunnel. This curl test is a crucial first step to ensure the foundation is solid.

SOCKS Proxy method

As we proved above, the Server Node can directly access the Fuzzball web UI (through the Ingress and LoadBalancer). This characteristic makes the Server Node suitable as the “bridge” to connect to the Fuzzball UI from our local machine.

In the next chapters, you’ll learn how to create a SOCKS proxy tunnel to the Server Node and configure your browser to use it, enabling access to the Fuzzball UI from your local machine in a web browser.