Exercise 6: Deploy workloads via Fleet¶

Time: 20 min
Previous: Exercise 5: Provision a cluster

You now have four running nodes:

vertex-hub-01 on edge1 (Elemental-provisioned K3s)
edge2 registered but not yet assigned to a cluster
edge3 running RKE2 standalone (not yet in Rancher)
edge4 running K3s standalone (not yet in Rancher)

Fleet is already watching for clusters with the right labels. A GitRepo called vertex-bank-app is pre-configured to target any cluster labeled demo=true and edge-type=x86-cluster.

The vertex-bank-app GitRepo points at the local Gitea instance on the EIB VM, not GitHub. Fleet syncs from http://192.168.122.20:3000/gitea/vertex-bank-app.git every 15 seconds. No internet access is needed.

# Confirm the GitRepo source
ssh -i /root/.ssh/id_ed25519 root@192.168.122.9 \
  "kubectl --kubeconfig=/etc/rancher/k3s/k3s.yaml \
   get gitrepo vertex-bank-app -n fleet-default \
   -o jsonpath='{.spec.repo}'"

6.1 Trigger Fleet deployment on vertex-hub-01¶

edge1 already has the demo=true and edge-type=x86-cluster labels from the labeling step in Exercise 5. Once the cluster is active and imported into Rancher's fleet-default workspace, Fleet picks it up automatically.

Check in Rancher UI: Continuous Delivery > Git Repos > vertex-bank-app. When vertex-hub-01 appears in the target clusters section and status moves to Active, Fleet is deploying the app.

If it does not appear automatically:

ssh -i /root/.ssh/id_ed25519 root@192.168.122.9 \
  "kubectl label cluster vertex-hub-01 -n fleet-default \
   demo=true edge-type=x86-cluster --overwrite"

6.2 Import edge3 and edge4 into Rancher¶

edge3 and edge4 are running standalone clusters that Rancher does not know about yet. Import them:

In Rancher UI: Cluster Management > Import Existing. Give each cluster a name (vertex-branch-rke2, vertex-branch-k3s). Rancher generates a kubectl apply command with a registration manifest. Run it on each node:

# On edge3 (RKE2)
ssh -i /root/.ssh/id_ed25519 root@192.168.122.33 \
  "kubectl apply -f <paste-the-registration-manifest-url>"

# On edge4 (K3s)
ssh -i /root/.ssh/id_ed25519 root@192.168.122.34 \
  "kubectl apply -f <paste-the-registration-manifest-url>"

Once imported, label them for Fleet:

ssh -i /root/.ssh/id_ed25519 root@192.168.122.9 "
  kubectl label cluster vertex-branch-rke2 -n fleet-default \
    demo=true edge-type=x86-cluster --overwrite
  kubectl label cluster vertex-branch-k3s -n fleet-default \
    demo=true edge-type=x86-cluster --overwrite
"

Fleet deploys vertex-bank-app to each cluster the moment the labels match. Go to Continuous Delivery > Git Repos > vertex-bank-app and watch the bundle status update per cluster.

6.3 Verify deployment¶

vertex-bank-app is a Node.js web terminal that shows live Kubernetes cluster vitals. Once Fleet deploys it, find the NodePort and open it in a browser:

# Check fleet bundle status
ssh -i /root/.ssh/id_ed25519 root@192.168.122.9 \
  "kubectl get bundle -n fleet-default | grep vertex-bank"

# Find the NodePort on edge1
ssh -i /root/.ssh/id_ed25519 root@192.168.122.9 \
  "kubectl get svc -A | grep vertex-bank"

Open http://192.168.122.31:<nodeport> for the edge1 deployment.

What you just built¶

Four nodes, four images, two provisioning paths, one management plane.

The image-first model: every node in this lab booted from a purpose-built disk image. No manual SSH config, no package installs, no configuration management applied to a running system. The image IS the configuration. If a node breaks, you re-image it. If a new site opens, you ship the image.

Why two paths exist: Elemental (edge1/edge2) is for sites where you do not know the node's final role at image-build time. You build one generic SL Micro image, ship it everywhere, and the management cluster decides what each node becomes after it registers. EIB standalone (edge3/edge4) is for sites where the role is known upfront: you bake K3s or RKE2 into the image and the node is a cluster the moment it boots.

Why TPM matters: without TPM, a cloned disk can register as any node in your fleet. With auth: tpm, the registration token is derived from hardware. You can revoke a specific node's registration by deleting its MachineInventory. Physical theft of the hardware does not compromise other nodes.

Why Hauler is there: in a real deployment, remote sites have unreliable internet. Hauler is a portable artifact store. Populate it once at HQ, copy it to a USB drive, and the site's nodes pull everything locally. In this lab, Hauler was pre-populated by the instructor. In production, you run hauler store sync to update and redistribute.

Two-minute comparison¶

	Elemental (edge1/edge2)	EIB standalone (edge3/edge4)
Node role decided	At provisioning time (after registration)	At image-build time
Cluster control	Rancher provisions and manages K8s	Node runs its own K8s; optionally imported
Onboarding	Automatic via TPM phone-home	Manual import or pre-registered via EIB
Good for	Mixed-role sites, large fleets, dynamic scaling	Fixed-function nodes, strict airgap, predictable workloads
Recovery	Re-register = re-provision from management	Re-image = re-flash disk