Starting a Server Node
The first server node bootstraps the cluster and hosts the control plane.
Syntax
k3s server [flags]The very first node you install is a server. It creates the datastore, generates the certificates, and produces the node token that other machines use to join.
Where things land
- Data and state:
/var/lib/rancher/k3s - Kubeconfig:
/etc/rancher/k3s/k3s.yaml - Node token:
/var/lib/rancher/k3s/server/node-token
By default the server also schedules workloads. For a small cluster that is fine. On larger clusters you may add --node-taint to keep the control plane free of application Pods.
Example
# Start a server manually (the install script normally does this)
sudo k3s server \
--write-kubeconfig-mode 644 \
--node-name server-1
# Find the token new nodes will need to join
sudo cat /var/lib/rancher/k3s/server/node-tokenWhen to use it
- A team spins up their first k3s server node on a cloud VM and uses it as the sole control-plane for a staging cluster.
- An administrator starts a server node with TLS SAN flags so remote kubectl clients can connect using the server's public IP.
- A developer launches the k3s server in the foreground with debug logging to trace startup issues during initial configuration.
More examples
Start server with default settings
Launches the k3s control plane; the first run bootstraps the cluster and generates the node token and kubeconfig.
k3s server
# Or via systemd after install:
systemctl start k3s && kubectl get nodesAdd TLS SAN for public IP
Adds the server's public IP to the TLS certificate so remote clients can connect securely without certificate errors.
curl -sfL https://get.k3s.io | \
INSTALL_K3S_EXEC='--tls-san 203.0.113.10' sh -
kubectl cluster-infoRetrieve node token and kubeconfig
Reads the join token (needed by agent nodes) and the admin kubeconfig generated when the server bootstrapped.
cat /var/lib/rancher/k3s/server/node-token
cat /etc/rancher/k3s/k3s.yaml
Discussion