Rancher on Ubuntu 24.04 on Azure User Guide

Overview

Rancher is a Kubernetes management platform: a single control plane for provisioning, importing, observing and governing Kubernetes clusters wherever they run, with a full web dashboard, centralised authentication and RBAC, a built in Helm chart catalogue, and cluster wide monitoring, logging and policy. The cloudimg image ships Rancher 2.14.3, the free and open source Apache-2.0 release, installed the way upstream supports for real workloads: the official rancher-stable Helm chart deployed onto a single node K3s cluster running on the VM itself, with cert-manager issuing the TLS certificate. Upstream's Docker based install is explicitly not supported in production, so this image does not use it. Every container image the platform needs is pre-staged into the VM, so the cluster comes up on first boot without reaching out to a registry. Nothing ships with a known secret: a unique 24 character administrator password is generated for each VM on first boot, before the port is reachable. Backed by 24/7 cloudimg support.

Rancher is a trademark of its respective owner. This image is produced by cloudimg and is not affiliated with, endorsed by, or sponsored by SUSE or the Rancher project. It ships the free and open source Apache-2.0 software, unmodified.

What is included:

• Rancher 2.14.3 (the Apache-2.0 release), installed from the official rancher-stable Helm chart
• K3s v1.35.5+k3s1 as the underlying single node Kubernetes cluster, with embedded etcd, containerd, CoreDNS, Traefik and ServiceLB
• cert-manager v1.19.2, which issues the Rancher TLS certificate
• All Rancher, cert-manager and K3s container images pre-staged into the image, so the cluster starts offline on first boot
• A dedicated 64 GiB data volume mounted at /var/lib/rancher for cluster state and the container image store
• k3s.service and rancher-firstboot.service as systemd units, enabled and active on boot
• A unique 24 character administrator password generated per VM on first boot, never baked into the image
• A clean cluster on first boot: the build time cluster, its certificate authority and its join tokens are destroyed before the image is captured
• 24/7 cloudimg support

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet plus subnet in the target region. Rancher's own sizing guidance is the floor here: Standard_B4ms (4 vCPU / 16 GiB RAM) is the recommended size, because the VM runs both the Kubernetes control plane and the Rancher management server. NSG inbound: allow 22/tcp from your management network and 443/tcp for the dashboard and API (80/tcp is served too and redirects to 443). If you plan to import or provision downstream clusters, those clusters also need to reach this VM on 443/tcp.

This is a single node, non highly available Rancher server. It is well suited to evaluation, development, and managing a modest number of downstream clusters. For a production control plane that must survive the loss of a node, upstream recommends running Rancher on a three node cluster.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Rancher by cloudimg, and select Create. On Basics pick your subscription, resource group, region and size; under Administrator account choose SSH public key and paste your key; under Inbound port rules allow SSH (22) and HTTPS (443). Then Review + create and Create.

Step 2 - Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name rancher \
  --image <marketplace-image-urn> \
  --size Standard_B4ms \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard

az vm open-port --resource-group <your-rg> --name rancher --port 443 --priority 1010

Step 3 - Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the cluster and Rancher are running

On first boot the image generates a unique administrator password, starts K3s, restores the pre-staged container images, and rolls out Rancher and cert-manager. On a Standard_B4ms this takes a couple of minutes. Confirm K3s is active, the node is Ready, and the Rancher deployment is available:

systemctl is-active k3s
sudo k3s kubectl get nodes
sudo k3s kubectl -n cattle-system get deploy rancher

k3s reports active, the node reports Ready with role control-plane, and the rancher deployment reports 1/1 ready.

Rancher answers on 443, and 80 redirects to it. The liveness endpoint needs no credentials:

curl -sk -o /dev/null -w 'healthz:   HTTP %{http_code}\n' https://127.0.0.1/healthz
curl -sk -o /dev/null -w 'dashboard: HTTP %{http_code}\n' https://127.0.0.1/dashboard/
curl -s  -o /dev/null -w 'port 80:   HTTP %{http_code}\n' http://127.0.0.1/

Both HTTPS endpoints return 200 and port 80 returns 302, the redirect to HTTPS.

Rancher serves traffic through the Kubernetes ingress, which K3s publishes with ServiceLB using iptables DNAT rather than a process listening on the host. So ss -ltn will not show ports 80 and 443 even though both are served correctly. Test with curl, not with the listener table.

Step 5 - Secure by default: no login ships with the image

Rancher holds the keys to every cluster you attach to it, so it must never ship with a known password. The administrator password is generated uniquely for this VM on first boot, and the build time cluster, including its certificate authority and join tokens, is destroyed before the image is captured. Confirm that an unauthenticated caller cannot read the cluster inventory:

curl -sk -o /dev/null -w 'no credentials: HTTP %{http_code}\n' https://127.0.0.1/v3/clusters

It returns HTTP 401. Known default passwords are rejected, only this VM's generated password is accepted, and the underlying Kubernetes API refuses anonymous callers as well:

Your password is written to /root/rancher-credentials.txt, readable only by root:

sudo stat -c '%a %U:%G' /root/rancher-credentials.txt

It reports 600 root:root. View the access notes (the URL, the administrator login and password, and the API details) with:

sudo cat /root/rancher-credentials.txt

Step 6 - Sign in to the dashboard

Browse to https://<vm-public-ip>/. The VM uses a certificate issued by cert-manager for this VM, so your browser will warn on first visit; accept the warning, and replace the certificate with your own for production (see the final section). Rancher asks for the administrator password from your access notes.

Username:  admin
Password:  <the rancher.admin.pass value from /root/rancher-credentials.txt>

On first sign in Rancher asks for the server URL it should advertise to the clusters it manages, and asks you to accept the End User License Agreement. Set the URL to the address your downstream clusters will use to reach this VM, normally https://<vm-public-ip> or your own DNS name.

Rancher then opens on its home page, listing the clusters it manages. The local cluster is the K3s cluster running on this VM, shown Active with its Kubernetes version, node count and capacity.

Step 7 - Explore the cluster

Select the local cluster to open Cluster Explorer, Rancher's view of a single cluster: total resources, node and deployment counts, live pod, CPU and memory capacity, the health of etcd, the scheduler and the controller manager, and the cluster's event stream.

The Nodes view lists the machines in the cluster with their roles, Kubernetes version and live CPU and memory usage. On this image there is a single node, which carries the control plane role and runs your workloads.

Under Apps, Rancher ships a Helm chart catalogue wired to the Rancher, Partners and RKE2 repositories, so you can install monitoring, logging, service mesh, backup and third party applications into the cluster without leaving the dashboard.

Step 8 - Drive the cluster through Rancher's API

Everything the dashboard does is available over Rancher's REST API, and Rancher proxies the Kubernetes API of every cluster it manages. Authenticate with the per VM password to get a bearer token, then read the cluster back:

PASS=$(sudo grep '^RANCHER_BOOTSTRAP_PASSWORD=' /root/rancher-credentials.txt | cut -d= -f2-)
TOKEN=$(curl -sk -X POST 'https://127.0.0.1/v3-public/localProviders/local?action=login' \
  -H 'Content-Type: application/json' \
  -d "{\"username\":\"admin\",\"password\":\"$PASS\"}" \
  | python3 -c 'import sys,json;print(json.load(sys.stdin)["token"])')

curl -sk -H "Authorization: Bearer $TOKEN" https://127.0.0.1/v3/clusters/local \
  | python3 -c 'import sys,json;d=json.load(sys.stdin);print("cluster:",d["id"],"state:",d["state"],"k8s:",d["version"]["gitVersion"],"nodes:",d["nodeCount"])'

The login returns HTTP 201 with a bearer token, and the cluster reports state: active with its Kubernetes version and node count.

Rancher's cluster proxy at /k8s/clusters/<cluster-id> speaks the Kubernetes API for any cluster under management, so the same token drives real changes. Create a namespace through Rancher, confirm it landed in the cluster, then remove it:

PASS=$(sudo grep '^RANCHER_BOOTSTRAP_PASSWORD=' /root/rancher-credentials.txt | cut -d= -f2-)
TOKEN=$(curl -sk -X POST 'https://127.0.0.1/v3-public/localProviders/local?action=login' \
  -H 'Content-Type: application/json' \
  -d "{\"username\":\"admin\",\"password\":\"$PASS\"}" \
  | python3 -c 'import sys,json;print(json.load(sys.stdin)["token"])')
PROXY=https://127.0.0.1/k8s/clusters/local

curl -sk -o /dev/null -w 'create: HTTP %{http_code}\n' -X POST "$PROXY/api/v1/namespaces" \
  -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{"apiVersion":"v1","kind":"Namespace","metadata":{"name":"cloudimg-demo"}}'

sudo k3s kubectl get namespace cloudimg-demo

curl -sk -o /dev/null -w 'delete: HTTP %{http_code}\n' -X DELETE \
  "$PROXY/api/v1/namespaces/cloudimg-demo" -H "Authorization: Bearer $TOKEN"

The create returns HTTP 201, kubectl shows the namespace Active, and the delete returns HTTP 200.

For your own tooling, generate a long lived API key from the dashboard under the user menu, Account & API Keys, rather than reusing the sign in token. From your own machine:

curl https://<vm-public-ip>/v3/clusters \
  -H 'Authorization: Bearer <your-api-key>'

Step 9 - Add your existing clusters

The point of Rancher is managing clusters beyond this VM. From the home page choose Import Existing, name the cluster, and Rancher gives you a single kubectl apply command to run against that cluster. The cluster's agent connects outbound to the server URL you set in Step 6, so the downstream cluster does not need to be reachable from here, but it does need to reach this VM on 443/tcp. Once connected it appears alongside local with the same dashboard, catalogue, RBAC and policy tooling.

Create provisions new clusters instead, into a cloud provider or onto existing machines, using the node drivers Rancher ships.

Step 10 - Production: your own domain and certificate

For production, put Rancher on your own DNS name with a certificate your browsers and cluster agents already trust. Point a DNS record at the VM public IP, then set the server URL in the dashboard under Global Settings, server-url, to that name. To replace the certificate, supply your own through cert-manager or install it as the tls-rancher-ingress secret in the cattle-system namespace, following upstream's TLS documentation for the release you are running.

Because Rancher governs every cluster you attach, treat this VM as tier zero infrastructure. Restrict inbound access in your NSG to 443/tcp from the networks that need it (and 22/tcp from your management network only), keep /root/rancher-credentials.txt confidential, replace the initial administrator password with your own and add named user accounts, and back up /var/lib/rancher, which holds the cluster's etcd datastore and its certificate authority.

Support

This image is supported 24/7 by cloudimg. For help with deployment or configuration, contact support through cloudimg.co.uk.