How to build a lightweight k3s HA cluster with external DB

Why choose k3s for edge computing and remote environments

Managing servers in remote locations, commonly known as edge computing, brings unique challenges ranging from internet instability to severe hardware constraints. Traditional Kubernetes, built for massive data centers, often demands too many resources to run comfortably on smaller computers or mini PCs installed at the edge of the network. This exact scenario is where k3s stands out as an intelligent and highly lean alternative for infrastructure engineers and enthusiasts.

In practice, k3s removes heavy and duplicated components that original Kubernetes carries by default, replacing them with simplified versions optimized for low resource consumption. This means you gain full container orchestration capabilities without wasting precious memory on unnecessary background processes. Before designing your edge infrastructure, it is also wise to understand how to calculate the real electrical power consumption of your homelab to prevent unexpected electricity bills or overloads.

The ideal architecture by separating the database from the cluster

When setting up a high-availability cluster, how system data is saved makes all the difference in keeping services online. The default Kubernetes method uses etcd, an internal key-value database that requires extremely fast and stable network connections among nodes to maintain consensus. In edge environments where internet links frequently fluctuate, maintaining a distributed etcd can cause severe instability and quorum loss.

The most robust solution to bypass this problem involves decoupling the database from the Kubernetes control plane by using an external relational database like PostgreSQL or MySQL managed separately. This way, k3s nodes point to a centralized, highly available database server, isolating cluster state from sudden individual node drops. If you ever face operational challenges with corrupted data, checking guidelines on how to automate PostgreSQL recovery helps keep your operations protected.

Preparing the environment and installing the first k3s node

Before getting your hands dirty, make sure your external database server is already accessible via the local network and properly configured with firewall rules to accept connections on the correct ports. The installation process of k3s with an external database uses a connection string similar to any modern application, specifying the IP address, port, user, password, and database name created specifically for the cluster.

To start the installation on the first server that will form the control plane, run the command below in your terminal, replacing the connection details with your real values:

curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server" K3S_DATASTORE_ENDPOINT="postgres://user:[email protected]:5432/k3s_cluster" sh -

This command automatically downloads the lean k3s binary, configures the operating system service, and connects the control plane directly to your external database. From that moment on, any metadata regarding pods, services, and cluster configurations is securely stored outside ephemeral edge nodes.

Adding new nodes to ensure high availability

With the first master node properly configured and communicating with the external database, the next step is adding additional nodes to ensure applications keep running even if a physical server fails. For this, you will need the secret token automatically generated during the first master server installation, usually located inside the system path.

Run the command below on the other nodes that will join the infrastructure, pointing to the IP of the first master server and using the corresponding token:

curl -sfL https://get.k3s.io | K3S_URL="https://192.168.1.10:6443" K3S_TOKEN="K10a1b2c3d4e...::server:abc123xyz" sh -

In practice, this means you can scale your edge infrastructure by adding as many computers as needed in a fast and standardized way. If any node suffers an irreparable hardware failure, you simply replace the machine and repeat the registration process without losing any central configuration, because all cluster state lives in the external database.

Operational best practices and edge monitoring

Keeping a cluster running outside a centralized data pool requires extra attention to local physical resource behaviors, such as disk space and processor temperatures. Because edge computing environments are often in remote locations, observability tools help diagnose failures before they impact end users. Moreover, ensuring a stable network without disk I/O bottlenecks is vital for the external database to respond quickly to constant Kubernetes requests.

In summary, structuring a cluster with k3s using an external datastore transforms traditional Kubernetes complexity into a lean, reliable solution perfectly suited for distributed edge projects. With a well-planned architecture, you achieve scalability and resilience without sacrificing smaller server performance.