Installing on k3s

Installing on k3s

k3s is Homestead's preferred platform for home self-hosting and the most widely tested with Homestead. Start here when building a new home server or homelab.

k3s packages Kubernetes for a small footprint. It runs on supported Linux machines - an old desktop, a mini PC, a VM or ARM64 hardware. 2 cores and 4 GB of memory is a starting point; VMs and storage workloads need additional capacity. Begin with one machine and add hosts as your lab grows.

One script turns a bare machine into a k3s cluster with Longhorn storage and Homestead running on it.

What works on k3s

Everything Homestead does, with nothing Harvester-specific needed:

• Containers, App Store, Docker Compose, Portal, Resources - as anywhere.
• Volumes, disks, data protection, network shares - on Longhorn, which the script installs. With --no-longhorn apps still get volumes from k3s's local-path, but the Volumes and Data protection pages need Longhorn.
• Addresses - k3s's built-in load balancer (ServiceLB) publishes apps on the machines' own addresses. kube-vip, for a virtual IP per app, and Multus, for a VM's or container's own LAN address, are installed by Homestead after it starts, and macvtap - a VM's LAN address through the machine's NIC - once KubeVirt is there - see below.
• Helm - charts install through the Helm controller k3s already runs.
• Adding and removing machines - Cluster → Add a host gives this cluster's join lines; removing one gives k3s's uninstall steps.
• Virtual machines - with KubeVirt and CDI: add --kubevirt to the script, or install them later from Settings → Hardware and storage → Add-ons (see Virtual machines). The machines need hardware virtualisation for VMs to run at full speed.
• Longhorn later - started with --no-longhorn? Settings → Hardware and storage → Add-ons installs it once the machines have open-iscsi.

1. What you need

Homestead is tested with Ubuntu 26.04.1 LTS (minimal installation).

• One or more Linux machines with a 64-bit OS (Ubuntu Server 24.04 LTS, Debian 12, Rocky/Alma 9 or openSUSE Leap are all fine), curl, and root access. x86-64 or 64-bit ARM.
• A fixed address for each - static, or a DHCP reservation on your router.
• Disk for your data. Longhorn stores volumes under /var/lib/longhorn on each machine's system disk to begin with; give it more from Homestead later. Plan the disks before installing the OS - see Disks.
• Virtual machines are optional. k3s runs containers. To run VMs too, the machines need hardware virtualisation, and KubeVirt added afterwards - see Virtual machines.

Open these between the machines if a firewall runs on them: TCP 6443 (the Kubernetes API), UDP 8472 (the pod network), TCP 10250 (kubelet), and TCP 2379-2380 between servers (etcd). Longhorn also talks between machines on TCP 9500-9504.

2. The first machine

On the first machine:

curl -sfL https://raw.githubusercontent.com/homestead-lab/homestead/main/scripts/install.sh | sudo sh

Select Install Homestead, then Create a new cluster, then k3s (the other choice, RKE2, has its own guide). The installer checks the machine first (memory, disk, the internet, ports, the hostname, the clock, the firewall, /dev/kvm, an address from DHCP) and stops on anything that would make the install fail, saying what to put right.

It asks which address the other machines reach this one on, when it has more than one, and whether to install Longhorn, the node probe and KubeVirt. Where the system is on LVM with room, it asks how much of the free space Longhorn gets as a volume of its own (see Room for the system). It also asks for an address for Homestead and apps: an unused LAN address outside your router's DHCP range. Once kube-vip is running, Homestead reserves it, makes it the apps' default, and puts itself, its backup storage and shares on it. Homestead is then at http://<VIP>:8088 as well as on each node's address. Leave it empty to keep the nodes' own addresses and add a VIP later (see Networking). --vip 192.0.2.200 does the same for bootstrap-k3s.sh. The installation summary then shows the settings and the version of each component:

Each defaults to its current recommended release - k3s's stable channel, Longhorn's and CDI's newest release, KubeVirt's stable release, Homestead's newest. To install another version, select the component: the list comes live from k3s's release channels and from GitHub, and Enter a version manually takes any other.

Select Install, and it takes 5-10 minutes, with a progress bar.

It then:

1. installs what Longhorn needs on the host (open-iscsi and an NFS client), keeps multipathd off the devices Longhorn makes (below), caps the systemd journal at 1 GB, and - where the system is on LVM with room - mounts a logical volume of Longhorn's own at /var/lib/longhorn;
2. installs k3s with an embedded etcd, so more servers can join later;
3. asks k3s to install Longhorn (one copy of each volume, while there is one machine) and Homestead's own manifest;
4. asks Homestead to install kube-vip, Multus and the node probe once it is up;
5. waits for Homestead, takes the first etcd snapshot - k3s takes one only every 12 hours, and until then there is nothing to restore the cluster from - and prints its address, http://<this machine>:8088.

Open that address and create the first administrator.

The machine's own screen (not SSH) now shows a live status console in place of the login prompt - press Enter for the usual login. See Local host console.

The installer runs bootstrap-k3s.sh to do this. You can run it yourself instead, with no questions:

curl -sfL https://raw.githubusercontent.com/homestead-lab/homestead/main/scripts/bootstrap-k3s.sh | sudo sh -s - server

Options go after server:

Option	Does
--no-longhorn	uses k3s's built-in local-path storage instead: simpler, no copies, and each volume stays on the machine it was made on
--kubevirt	also installs KubeVirt and CDI, so Homestead can run virtual machines - emulated, and slow, if the machine has no hardware virtualisation (/dev/kvm)
--k3s-version v1.33.4+k3s1	pins k3s instead of its stable channel
--longhorn-version v1.9.1	pins Longhorn instead of its newest release
--kubevirt-version v1.6.0, --cdi-version v1.62.0	pin KubeVirt and CDI instead of their current releases
--homestead-version 2.8.118	pins Homestead instead of the newest release
--node-ip 192.0.2.10	the address k3s registers this machine by, when it has more than one
--longhorn-volume 200	the size in GB of Longhorn's own LVM volume at /var/lib/longhorn; auto (the default) takes the volume group's free space less a tenth kept for the system, none keeps Longhorn on the root filesystem. Works for agent and join too
--no-node-probe	leaves out the node probe (temperatures, drive health, each host's network interfaces); add it later under Settings → Hardware and storage → Add-ons

The script is safe to run again: each step finds what the last run left.

3. More machines

On each further machine, run the same line:

curl -sfL https://raw.githubusercontent.com/homestead-lab/homestead/main/scripts/install.sh | sudo sh

Select Install Homestead, then Join an existing cluster as a worker node (runs apps) or as a server node (control plane and etcd as well). It asks for the first machine's address and the cluster's token, checks it can reach the cluster before changing anything, and joins. Install the same k3s version as the existing servers: the summary uses the cluster's version where the cluster reports it, and otherwise lets you select it.

Or, with no questions, each joins with the first machine's address and its token. The token is on the first machine:

sudo cat /var/lib/rancher/k3s/server/node-token

As a worker (runs apps, not the control plane):

curl -sfL https://raw.githubusercontent.com/homestead-lab/homestead/main/scripts/bootstrap-k3s.sh | sudo sh -s - agent https://192.0.2.10:6443 <token>

As another server (control plane and etcd as well):

curl -sfL https://raw.githubusercontent.com/homestead-lab/homestead/main/scripts/bootstrap-k3s.sh | sudo sh -s - join https://192.0.2.10:6443 <token>

Use 192.0.2.10 as the first machine's address, and your token. Cluster → Add a host in Homestead shows these lines already filled in. Give it a server machine's own address, not the VIP for Homestead and apps: that VIP carries apps, not the cluster, so the machine joins through a server's address on 6443 (k3s) or 9345 (RKE2).

Two machines and quorum

For a two-machine home setup, prefer two independent single-node k3s clusters, then link them in Homestead. Each keeps its own control plane and workloads, so losing one does not remove the other's control plane. Linking provides one management experience; it does not replicate volumes or automatically restart one cluster's apps on the other.

With embedded etcd, quorum is a majority of the voting servers, not the total number of machines. Two servers do have quorum while both are online, but cannot tolerate either failing or being rebooted. Existing pods may continue running after quorum is lost; the cluster cannot reliably schedule replacements or process control-plane changes.

Layout	What happens when a machine fails?
Two linked one-node clusters	The other cluster remains independent; the failed cluster's workloads stay down until recovered
One server and one agent	Losing the server loses the control plane; the agent contributes no etcd vote
Two voting servers	Both votes are required; losing either loses quorum
Three voting servers	Two votes remain after one failure; workload recovery still needs suitable storage and spare capacity

One server plus an agent is a valid way to add compute when you accept a single control-plane failure point. It is not HA. These quorum rules describe embedded etcd, which Homestead's new-cluster installer uses; an external datastore has its own availability requirements. See K3s embedded-etcd HA and the etcd quorum FAQ.

Using a small third server

For one cluster, two main machines plus a suitable ARM64 Raspberry Pi or small PC can provide three etcd votes. Join it as a server, using the server join route above and matching the existing k3s version/configuration. Joining it as an agent adds compute, not a vote. It is a real etcd member storing cluster state, not a lightweight witness. Keep it on independent hardware; a VM on either main host would disappear with that host.

Use a 64-bit Linux OS, reliable power, wired networking and an SSD for the k3s datastore. K3s lists 2 cores and 2 GB RAM as the server baseline; 4 GB or more is a more practical planning allowance for Homestead's supporting services. Do not rely on a slow microSD card for etcd. Check the Pi OS cgroup requirements in the K3s hardware and Raspberry Pi guide.

Check the machine before it joins - the join guide shows this command for a server or a tiebreaker, and the installer runs the same checks itself:

curl -sfL https://raw.githubusercontent.com/homestead-lab/homestead/main/scripts/install.sh | sudo HS_ROLE=tiebreaker sh -s -- --check

It measures how fast the disk syncs (etcd needs under 10 ms - fio if installed, else dd), and checks the memory cgroup controller (on a Raspberry Pi, cgroup_enable=memory cgroup_memory=1 in /boot/firmware/cmdline.txt), the vxlan kernel module, swap, and on a Pi any under-voltage or throttling. It installs nothing.

On the on-board Ethernet of a Raspberry Pi 5, some kernels stall sending - the link stays up, nothing is sent, nothing is logged - until the Pi is power-cycled; the cluster rides it out on the other two votes. Until your kernel has the fix, sudo ethtool -K eth0 tso off sg off avoids it.

Keep ordinary apps, VMs and Longhorn replicas on the two larger hosts: configure placement/taints and Longhorn node/disk scheduling explicitly. K3s servers can run workloads by default; neither a server role nor a small machine's size automatically excludes it. System DaemonSets may still run there. Advanced users can configure a dedicated etcd server using K3s's role controls. Homestead's join guide (Cluster → Add a host) offers it as Tiebreaker (votes only): its command joins a regular server with the taint and label below and, on k3s, the other servers' cluster-wide settings - read from a server's k3s.io/node-args, never its token. The installer joins one with HS_ROLE=tiebreaker, setting the taint and label (on RKE2 the guide sends you there); it does not copy settings, which matter only where the first server was set up with ones of its own. To set one up by hand instead, mark it before k3s first starts, in /etc/rancher/k3s/config.yaml:

node-taint: ["node-role/tiebreaker=true:NoSchedule"]
node-label: ["node-role/tiebreaker=true"]

Homestead then treats it as holding a vote only: kube-vip never runs there, so no app's address is answered over its link, and its interface has no say in the one kube-vip announces on; it holds no Longhorn copies; and "If this host goes down" never offers it as a home for an app or a VM. If you added an affinity of your own to kube-vip's values to keep it off the small server, remove it: Homestead leaves values it did not write alone, and its own values already keep kube-vip off a tiebreaker.

Cluster lists the etcd members with a tiebreaker badge on such a host. With two members - no failure margin - Cluster and the setup guide offer Add a tiebreaker on k3s and RKE2, which opens the join guide with that role chosen; the health check says a tiebreaker would fix it.

The small server supplies control-plane quorum, not a third storage copy. With only two storage hosts, choose two replicas on different hosts rather than requesting an unplaceable third copy. Homestead counts only the hosts Longhorn stores on when it raises copies (below), so a small server Longhorn does not use - no Longhorn there, or scheduling turned off or an eviction asked on it or its disks - does not make it ask for a third. After a storage-host failure only one copy remains, and the surviving main host must fit the workloads. An ARM node does not make x86-only apps or VM guests portable. If using V2, review selective activation and Homestead's setup limitation before adding the small node.

If you already have an app host to spare, make it a server instead.

Making an app host a server

A cluster with one or two servers can gain an etcd vote from an app host it already has. In Nodes, open the host's Host actions and choose Make server…. It is offered on k3s with embedded etcd only.

The review checks first, and changes nothing while anything stops it:

• the host is a Ready app host, not a tiebreaker, and Homestead does not run on it;
• every etcd member is Ready, and the host runs the servers' k3s version;
• the servers' shared settings can be read;
• the host has its node password (/etc/rancher/node/password) and the kube-system/<host>.node-password.k3s Secret, so it comes back as the same Node;
• its apps fit on the other hosts, by CPU and by memory.

Then a job, in the job tray:

1. cordons the host and moves its apps off;
2. reads the server token from a server host and passes it to this host on its helper's input, never on a command line, into a root-only file the reinstall deletes. Afterwards the host keeps the token where every k3s server does (/var/lib/rancher/k3s/server/token, and the installer's /etc/systemd/system/k3s.service.env);
3. removes the k3s agent and installs a server with the cluster's settings and the host's own (--node-ip, --flannel-iface, labels and taints, kubelet arguments);
4. waits for the host to come back as an etcd member, then uncordons it.

The host is out of service for several minutes. It keeps its Node, labels, Longhorn disks and volume copies, and its local-path folders.

Nothing else may restart or update a host while this runs: a reboot, an OS update or a platform upgrade that is under way stops it at the review.

If the installer cannot be downloaded, nothing is removed and the host stays an app host. If the reinstall fails later, k3s is left as the installer left it: stopping a server that joined etcd would cost a vote, not save one. The job shows the last lines of /var/log/homestead-promote.log, and how to bring the host back as an app host.

Don't use Remove… for this: removing a host discards its volume copies, and with them any volume that has a single copy there.

Volume copies as the cluster grows

The script sets Longhorn up with one copy of each volume, which is all one machine can hold. As machines join, Homestead raises the default for new volumes - and its own data volume - with the hosts Longhorn can store a copy on, up to three, while it is still the installer's one copy, so a number you chose is kept. A host counts when Longhorn reports it Ready and allows scheduling on it and on one of its disks, with no eviction asked: a node kept only for etcd votes, with no Longhorn running there, does not, so two storage hosts keep two copies rather than asking for a third that cannot be placed. Existing volumes keep their count: Settings → Hardware and storage → Storage classes makes a class with three copies the default. Volumes shows each volume's copies - ×1 in orange is a volume a single failed disk would lose - and Changing a volume's storage class moves an existing one onto the new class.

A machine that joins later

The node probe, Longhorn, Multus, macvtap and KubeVirt run as DaemonSets and reach a new machine by themselves. What was set up when the cluster was one machine does not, so the leader brings each new one into line within ten minutes of it being Ready:

• multipathd. Ubuntu Server runs it, and it claims every plain /dev/sd* disk - Longhorn's volumes among them, whose mounts then fail as "already mounted or mount point busy". As Longhorn asks, /etc/multipath.conf gets devnode "^sd[a-z0-9]+" in its blacklist (a copy of the file is kept), unless the machine boots from a multipath device. iscsid, installed but stopped, is started.
• kube-vip's interface. Installed on one machine, kube-vip was told that machine's interface. Once the node probes report machines whose interfaces are named differently, the name is taken out and kube-vip finds each machine's own.
• Longhorn's copies, as above.

Host limits

A busy Kubernetes node runs out of inotify instances - each file watcher is one, a Linux host allows each user 128 by default, and on a node nearly everything runs as root - and whatever starts next cannot watch files. The script raises them to 8192 instances and 524288 watches in /etc/sysctl.d/90-homestead.conf, and Homestead does the same, once, on every k3s or RKE2 node that joined before (never lowering a higher value).

Disks

Longhorn starts on each machine's system disk, in /var/lib/longhorn, and keeps 30% of that filesystem free for the system. Plan the rest before installing the OS:

The machine has	At OS install	Then in Homestead
A second drive	Install on the first; leave the second blank	Nodes → Disks → Add to Longhorn on it: formatted (ext4 or XFS) and mounted safely, or kept as it is when it already holds Longhorn data
One drive	Choose LVM (Ubuntu Server's default) and give the root volume 64-128 GB; leave the rest of the volume group unallocated	Nothing: the installer mounts a volume of Longhorn's own at /var/lib/longhorn. Keep some of the group free for V2 and add it later with Use free space
One drive, plain partitions	Leave space unpartitioned after the last partition	Use free space makes a partition there, live, for V1 or V2
One drive, one root partition filling it	Nothing more to do	Longhorn stays in /var/lib/longhorn on the root filesystem, kept from filling it (see Room for the system)

• Why a filesystem of its own. Longhorn filling a separate volume cannot fill the system's filesystem. Use free space keeps a tenth of the volume group (at least 10 GB) unallocated, so the root volume can still grow (lvextend -r).
• What Homestead will not do. It never shrinks or moves a partition or filesystem of a running system; it only adds a partition in space nothing uses.
• Copies on one drive are not redundancy. A copy on the system's folder and one on /mnt/longhorn-os share a drive. For two copies on one machine, add a second drive and choose Copies go on: Different disks for the class - see Storage.
• V2 (SPDK) needs a whole drive of its own, given to it raw.
• Safe mounts. Homestead mounts a drive with nofail in /etc/fstab, and locks the empty folder, so a machine whose drive dies still starts and nothing lands on the system disk in its place. See Storage.

4. Addresses for apps

k3s's built-in load balancer, ServiceLB, publishes a LoadBalancer service on every machine's own address. So Homestead answers on http://<any machine>:8088, and each app is reached the same way on its own port. Two apps cannot both take port 80. The script does not install MetalLB, and nothing in Homestead needs it.

For an address per app, Homestead installs kube-vip, as Harvester uses, and Multus, which LAN networks need - and, once KubeVirt is installed, macvtap, which puts VMs on the LAN through the machines' own NIC without changing their network (or move a machine's NIC into a host bridge). The script requests both in Homestead's manifest (a homestead-install ConfigMap) and Homestead installs them through the Helm controller once it starts, at the chart versions it has tested; progress is shown in its job tray. Leave either out with --no-kube-vip or --no-multus, or pin a chart with --kube-vip-version 0.11.1 / --multus-version v4.3.102 (in the guided installer: HS_KUBEVIP=no, HS_MULTUS=no, HS_KUBEVIP_VERSION, HS_MULTUS_VERSION). Homestead records what it installed, so a component you remove later is not reinstalled.

An installation from before 2.8.221 shows Required components not installed under Settings → Hardware and storage → Add-ons and on Networking, with Install components. Both are upgraded under System → Cluster → Platform versions, one minor chart version at a time, keeping the values Homestead set.

kube-vip runs beside ServiceLB rather than replacing it: it takes only the Services given a VIP, and everything else - Homestead and Traefik included - stays on the machines' own addresses. Then:

1. Add the addresses apps may have under Networking → Workload VIPs, outside your router's DHCP range.
2. When deploying, editing, importing or exposing an app, choose Every node's own address, New automatic VIP (the next free one from your list) or Specific VIP.

kube-vip announces each VIP with ARP from one machine, on the interface the machines' default route uses; if another machine takes over, the address follows. To move an existing app to a VIP, remove its Service under Networking and Expose workload again with a VIP.

5. Without the script

The script only runs k3s's own installer and drops two files into /var/lib/rancher/k3s/server/manifests, which k3s applies itself. To do it by hand, install k3s your way, install Longhorn (or use local-path), and follow Installing on an existing cluster.

Next

Installing Homestead covers what the install made, first sign-in, updates and the node probe.

If something is stuck

Run the node doctor on the machine: the same line, then Check node health.

curl -sfL https://raw.githubusercontent.com/homestead-lab/homestead/main/scripts/install.sh | sudo sh

It checks the host and the cluster, lists what it found worst first, and offers a fix for each - see Troubleshooting. By hand:

• sudo k3s kubectl get pods -A - is anything not Running?
• sudo journalctl -u k3s -e - k3s's own log.
• Longhorn pods crash-looping usually means open-iscsi is missing or iscsid is not running: sudo systemctl enable --now iscsid.
• More in Troubleshooting.

Multus installation and upgrade diagnostics

Homestead installs both the Multus agents and the separate rke2-multus-crd chart, with version-pinned releases and k3s-specific CNI paths. Add-on readiness requires the network-attachment API and the current DaemonSet available on its scheduled nodes. A completed Helm job alone is not enough.

For older Homestead installs, Settings → Hardware and storage → Add-ons → Repair configuration corrects the known missing multusAutoconfigDir and installs a missing CRD dependency. It only handles Homestead's recognised configuration, not arbitrary customised CNIs. The diagnostic command collects both Helm logs and Multus agent errors.

If Homestead's own upgrade waits on data-permissions, inspect its init-container error. lookup ghcr.io means host DNS, not a missing app configuration. Check resolvectl status, resolvectl query ghcr.io, the host route and outbound HTTPS. Fix the host's persistent DNS/network configuration before retrying; do not remove the old serving pod or its volume just to clear an image-pull error.

Disk imports fail with a block-device permission error

If a VM disk stays in ImportInProgress and its importer reports blockdev: cannot open /dev/cdi-block-volume: Permission denied, the importer cannot access the block device allocated to its pod. This is a node runtime setting, before the image can download. See CDI's device ownership guidance.

New Homestead k3s and RKE2 installs enable nonroot-devices for servers and workers. On an existing cluster, add or update this setting in /etc/rancher/k3s/config.yaml on every node, preserving the other settings:

nonroot-devices: true

Check that the installed version supports it with k3s agent --help. Restart the matching service, one node at a time; restarting a node service can interrupt workloads on that node:

# Server node:
sudo systemctl restart k3s
# Worker node instead:
sudo systemctl restart k3s-agent

For RKE2, use /etc/rancher/rke2/config.yaml, check rke2 agent --help, and restart rke2-server or rke2-agent. Check that the node is Ready and that its generated containerd configuration has device_ownership_from_security_context = true before proceeding to the next node. Editing the generated config.toml itself does not persist across restarts. Older versions without the flag need an upgrade or the version-specific containerd template described in CDI's guide.

After the nodes are ready, inspect the affected importer and recreate only that failed pod. CDI will retry against the existing disk. For example:

kubectl -n lab get pods -o wide
kubectl -n lab delete pod 'importer-prime-<PVC-UID>'
kubectl -n lab get datavolume k3s-demo-server-1-disk -w

Use the actual importer name shown in your VM's events. Keep the PVC, DataVolume, and VM; deleting the disk is not part of this recovery. A failed Homestead cluster-build job will not turn successful retroactively: after the disks finish, inspect the retained VMs and bootstrap status before deciding whether another action is needed.

If the installer stops before showing a menu

The last message can say Installing whiptail even when that package has finished installing. On Ubuntu 26.04 with sudo-rs, curl | sudo sh can leave terminal-size and menu subprocesses stopped before the menu accepts input. The installer now asks you to press Enter in the main shell first, so sudo can hand over the terminal before a menu subprocess uses it. Reports and unattended installs skip this prompt. Terminal-size queries are read-only, with a 24-row fallback.

For an older installer, download it first so sudo starts with terminal input:

curl -fL https://raw.githubusercontent.com/homestead-lab/homestead/main/scripts/install.sh -o /tmp/homestead-install.sh
sudo sh /tmp/homestead-install.sh

Add --text to the saved-script command to use plain prompts.

From another SSH session, inspect the process tree and the package log:

ps -eo pid,ppid,tty,stat,etime,args --forest | grep -E 'stty|whiptail|apt-get|dpkg|sudo|sh -s'
sudo tail -n 40 /var/log/apt/term.log

A T in the process state means stopped, rather than downloading packages. If the log shows Setting up whiptail followed by Log ended, the package installation completed. If a package manager is still running, check its output and locks before attempting another installation; do not delete lock files. The optional menu-package attempt now shows its output, is limited to 120 seconds plus a 10-second termination grace period, and falls back to text prompts on failure. If interrupted during package configuration, inspect the package-manager state (sudo dpkg --audit on Debian/Ubuntu) before retrying.

To trace startup without changing the cluster, save the script and run it with --dry-run (exit at the first menu):

curl -fL https://raw.githubusercontent.com/homestead-lab/homestead/main/scripts/install.sh -o /tmp/homestead-install.sh
sudo sh -x /tmp/homestead-install.sh --dry-run

Cluster details in setup

On an existing node, setup's main menu shows the host IP, Kubernetes node versions, cluster members and internal IPs, the configured API endpoint, service VIPs, and the Longhorn manager and Homestead deployment readiness. Select Cluster details for the full lists. Members and VIPs wrap in the main menu; when they exceed the terminal height, More member/VIP addresses cycles through the remaining lines while component status and actions stay visible. The summary refreshes whenever you return to the main menu.

Assigned LoadBalancer addresses are distinguished from requested addresses that are still pending. The API endpoint can be a local address such as 127.0.0.1:6443; it is not necessarily a control-plane VIP. Component versions come from workload image tags; a digest-pinned image may not expose a version tag. Ready/desired replicas describe the component, not overall volume health. Use Check node health for the broader checks.

Discovery is read-only, with short timeouts. Unreachable or unauthorized queries show unavailable, while a successful lookup with no component shows not installed. Workers without administrator credentials direct you to run setup on a server node.