Derek Coleman & Associates Inc logoDerek Coleman & Associates Inc

Home / Support / K3s Lightweight Kubernetes on Ubuntu 24.04 LTS

K3s Lightweight Kubernetes on Ubuntu 24.04 LTS — Support & Quick Start

Single-node K3s (CNCF-certified lightweight Kubernetes) on Ubuntu 24.04 LTS — kubectl-ready minutes after deploy.

Email support Product page Azure Marketplace listing

Fixed on image version 2026.917.0337 (published 2026-09-17)

First boot switches the VM's own firewall on: ufw is enabled with the rules K3s documents for a node that keeps ufw on — 22, 80 and 443 allowed, the pod (10.42.0.0/16) and service (10.43.0.0/16) networks allowed, and 6443 deliberately not allowed — and first boot re-proves the cluster through it (node Ready, CoreDNS running, the ingress answering on :80) before it reports done. The current image (2026.1001.1516, K3s v1.36.5+k3s1) keeps this; its image-verify run found ufw active with 6443 not allowed.

If you deployed this VM before 2026-09-17, it came from the older image and is not changed by the new publication — redeploy from the current Marketplace version, or apply the one-time repair below:

  1. On a VM deployed from an earlier image `sudo ufw status` prints `Status: inactive`, so the Kubernetes API on 6443 — which the admin kubeconfig accesses as full cluster-admin — is protected only by your Network Security Group. Keep the NSG scoped to your own address until the firewall is on.
  2. To switch it on yourself, apply the same rules the fixed first boot applies (commands below), leaving 6443 unallowed, then re-check `sudo k3s kubectl get nodes` and `sudo k3s kubectl -n kube-system get pods` — a firewall enabled without the two CIDR rules breaks in-cluster DNS.
sudo sed -i 's/^DEFAULT_FORWARD_POLICY=.*/DEFAULT_FORWARD_POLICY="ACCEPT"/' /etc/default/ufw
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow from 10.42.0.0/16 to any
sudo ufw allow from 10.43.0.0/16 to any
sudo ufw --force enable

Image change: see the pull request.

Source: the Marketplace live version set for this offer, read from Partner Center on 2026-09-17. New deployments take the newest version by default.

At a glance

Application ports80 and 443 (the bundled Traefik ingress) are open in the VM's own firewall — open them in the Network Security Group and your Ingress routes are reachable. 6443 (Kubernetes API) is deliberately NOT opened: the kubeconfig is full cluster-admin, so the API stays on the node
Service(s)k3s
Configuration/etc/rancher/k3s/k3s.yaml (kubeconfig, root-only, full cluster-admin)
Logsjournalctl -u k3s -f
VersionK3s v1.36.5+k3s1 (Kubernetes 1.36; bundled Traefik 3.7.13 ingress, CoreDNS 1.14.7)
PlatformUbuntu 24.04 LTS

Quick start

  1. SSH into the VM with the username and key you chose at deploy.
  2. K3s runs as the `k3s` systemd service; verify with `sudo k3s kubectl get nodes`. The VM firewall is active: 80/443 allowed for ingress, 6443 not allowed.
  3. Allow 80 and 443 in the Network Security Group, then deploy a workload and an Ingress with kubectl or Helm — Traefik 3.7 is already running as the default ingress controller, so http://<VM-IP>/ reaches your route (it answers 404 until you create one). Traefik custom resources such as IngressRoute and Middleware use `apiVersion: traefik.io/v1alpha1`; the Traefik 2 group `traefik.containo.us` is not served.
  4. Copy /etc/rancher/k3s/k3s.yaml (rewrite the server IP) to use kubectl from your workstation over a 6443 rule scoped to your own address.

First login

  1. No web login exists. SSH in and run `sudo k3s kubectl get nodes` — the node reports Ready once first boot has enabled the service.
  2. First boot also enables the VM's firewall (ufw) with the rules K3s documents for a node that keeps ufw on — 22, 80 and 443 allowed, the pod (10.42.0.0/16) and service (10.43.0.0/16) networks allowed, and 6443 deliberately not allowed — then re-checks that the node is still Ready, CoreDNS is running and the ingress answers on :80 before it reports done.
  3. For remote kubectl, copy /etc/rancher/k3s/k3s.yaml over SSH, rewrite the server address, and open 6443 to your own address only — both in the NSG and with `sudo ufw allow from <your-ip> to any port 6443`. Never open it to 0.0.0.0.

Still stuck?

Email support@dcassociatesgroup.com (response within 1 business day) or send a message via the contact form. Include the offer name, VM size, region, and any log output — sudo journalctl -u <service> -n 100 usually tells the story.