DEV Community: Bertrand Atemkeng

How to Self Host A Kubernetes Cluster (Without Losing Your Mind)

Bertrand Atemkeng — Sat, 19 Jul 2025 17:18:02 +0000

A Beginner-Friendly Guide to Set Up Kubernetes Locally

When I first set out to set up a Kubernetes cluster on my own, I followed various online tutorials and blogs. Sounds easy, right? Except for one massive roadblock: setting up MetalLB. Most of the YouTube videos and guides I found assumed you’d be deploying your cluster on a cloud platform, where a load balancer is already baked in. But I was trying to set up a home lab on an old Lenovo T40 laptop — no cloud infrastructure, no fancy hardware, just what I had lying around.

If you’re anything like me, chances are your home lab is also built on a budget. Maybe you’re using some leftover hardware, or maybe you’ve found a ridiculously affordable VPC provider (I highly recommend checking out Webtropia for low-cost options). Either way, you probably don’t have access to dedicated load balancers or advanced networking devices.

After countless hours of tweaking and scouring the internet for a comprehensive guide to setting up MetalLB with basic hardware, I hit a wall. So, I got creative. In this blog, I’ll share how I managed to set up a Kubernetes cluster using k3s, kube-vip, and MetalLB — all on budget-friendly resources. Let’s dive in!

Tools You’ll Need

To replicate this setup, here’s what you’ll need:

k3s: A lightweight Kubernetes distribution.
k9s: A terminal-based tool for monitoring and administering your cluster.
kube-vip: For handling VIPs (Virtual IPs).
MetalLB: To act as a load balancer for your Kubernetes cluster.

Optional but handy tools:

A GUI-based tool like ArgoCD for managing workloads after installation.

Step-by-Step Guide to Setting Up Your Cluster

1. Provision Your VPCs

For this guide, I used three VPCs as the control plane for my Kubernetes cluster. You can extend this setup to add worker nodes as needed. If you don’t have physical hardware, consider using affordable VPC providers like Webtropia. The key is to have at least three nodes to achieve high availability.

2. Install k3s

On each of your nodes, install k3s:

curl -sfL https://get.k3s.io | sh -

For the master node, initialize the cluster and note down the token:

k3s server --cluster-init

For the additional nodes, join them to the cluster using the token:

k3s agent --server https://<master-node-ip>:6443 --token <your-token>

3. Configure MetalLB

MetalLB is a load balancer implementation for bare-metal Kubernetes clusters. Here’s how to set it up:

Install MetalLB:

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/main/manifests/metallb.yaml

Create a ConfigMap: Configure an IP address pool that MetalLB can use:

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
      - 192.168.1.240-192.168.1.250

Replace the addresses range with a range suitable for your network.

4. Set Up kube-vip

kube-vip simplifies high availability for your Kubernetes control plane. Install kube-vip as a DaemonSet:

kubectl apply -f https://kube-vip.io/manifests/kube-vip-ds.yaml

Then, configure kube-vip to manage the virtual IP for your control plane. For example:

kube-vip install \
  --vip 192.168.1.100 \
  --interface eth0 \
  --controlplane \
  --arp

5. Test Your Setup

Once everything is up and running, test your cluster by deploying a sample application:

kubectl create deployment nginx --image=nginx
kubectl expose deployment nginx --port=80 --type=LoadBalancer

Access the application through the load balancer’s IP address.

For detailed instructions, refer to the Kubernetes Documentation.

When Do You Actually Need Kubernetes?

Let’s be honest: Kubernetes isn’t for everyone. If you’re building a simple application or a prototype, Kubernetes is overkill. A few Docker containers or a lightweight VM setup might be all you need.

Kubernetes becomes valuable when scaling is a challenge. If your application has unpredictable spikes in usage or requires automatic scaling, Kubernetes’ orchestration capabilities are unmatched. But for predictable workloads, Docker Compose or Portainer might be a better choice.

Conclusion

Setting up Kubernetes on a budget is entirely possible, even without cloud infrastructure or expensive hardware. With tools like k3s, MetalLB, and kube-vip, you can create a fully functional cluster on old hardware or low-cost VPCs. While it might take some effort, the experience is incredibly rewarding and a great way to level up your skills.

Have you found better solutions or hit roadblocks in your own Kubernetes setup journey? Share them in the comments below — I’d love to hear your stories!

Resources That Helped Me (and Where I Got Stuck)

Why Local-First and Offline-First Software Is the Future

Bertrand Atemkeng — Thu, 26 Dec 2024 13:26:49 +0000

Why Local-First and Offline-First Software Is the Future

In an era dominated by always-online software and endless subscription models, it’s time to pause and reflect: Is this really the best way forward? While subscription models make powerful software more accessible—allowing users to pay only for what they need instead of bearing the upfront cost of full ownership—they also enable businesses to leverage cloud platforms to reduce infrastructure overhead and accelerate development, fostering innovation.

However, as users, developers, and business owners, we’ve grown accustomed to apps that demand constant internet access, collect vast amounts of data, and lock us into recurring fees. This raises an important question: Is this model sustainable for everyone? What if there’s a healthier, more balanced alternative? Enter local-first and offline-first design principles.

The Problem: The Hidden Costs of Always-Online Software

Always-online software has become the default. From note-taking apps to project management tools, most require a persistent internet connection. While this model offers convenience, it comes with significant downsides:

Connectivity Dependence: Without a stable internet connection, these tools become useless. Think about the frustration of losing access to critical files during a flight or a rural retreat.
Privacy Concerns: Centralized systems store sensitive user data on remote servers, increasing the risk of breaches and misuse.
Subscription Fatigue: Users face an ever-growing list of monthly payments. For developers, this model prioritizes retention over genuine user satisfaction.
Environmental Impact: Constantly syncing data to the cloud consumes energy, contributing to a growing carbon footprint [1].

For businesses, cloud-based applications necessitate subscription models to finance running costs before turning a profit. Startups often operate at a loss for extended periods, covering costs upfront or entirely. This frequently results in sacrificing user data to sustain operations.

In the end, the user bears the ultimate price—either by contributing to cloud costs through subscription fees or by involuntarily offering their data.

As someone who frequently travels for work, I’ve experienced firsthand how unstable internet connections can make it nearly impossible to get work done on the go. These challenges led me to critically rethink how software is built. Does an app really need to be online to function? Would an offline-first approach be better?

It’s clear this always-online approach isn’t as user-friendly or sustainable as we’ve been led to believe.

The Solution: Local-First and Offline-First Design Principles

Local-first and offline-first design offer a radical rethinking of software. Instead of treating the internet as a constant requirement, these principles prioritize autonomy, resilience, and privacy:

Local-First Software: Data is stored and processed on the user’s device by default. The cloud, when used, acts as a backup or synchronization tool—not the primary storage.
Offline-First Design: Apps are designed to function seamlessly without an internet connection. Users can access and edit their data offline, with changes syncing when connectivity is restored [2].

This approach isn’t just theoretical; it’s already being implemented in popular apps like WhatsApp and Spotify as well as in tools I’ve developed, such as Readme TTS, which lets users listen to articles offline, and NutriScan, which categorizes receipts without needing an internet connection.

The Benefits: Why This Matters

1. Empowering Users

With local-first software, users regain control over their data. Files and records stay on their devices unless explicitly shared, reducing dependence on third-party servers.

2. Resilience in Any Situation

Offline-first apps work anywhere, whether you’re traveling, experiencing network outages, or working in low-bandwidth areas. They’re designed to be reliable, no matter the circumstances.

3. Cost-Effectiveness

For both users and developers, the local-first approach eliminates the need for expensive server infrastructure and recurring cloud storage fees [3].

4. Better Privacy and Security

Storing data locally means fewer opportunities for breaches and less invasive data collection by corporations. This aligns with growing user demand for ethical, privacy-focused software [4].

5. Environmental Sustainability

By reducing reliance on constant cloud synchronization, local-first apps lower their energy consumption and carbon footprint [5].

The Vision: A Sustainable Software Ecosystem

Adopting local-first and offline-first principles isn’t just a technical decision—it’s a philosophical one. It’s about rejecting the status quo of “always online” in favor of creating tools that respect users’ autonomy, privacy, and time.

For solo developers and small teams, this model is especially empowering. By focusing on local-first solutions, they can build robust, user-friendly software without needing to maintain costly cloud infrastructure or compete in the cutthroat subscription economy. As someone building software, I’ve found that local-first design lets me prioritize quality over scalability.

Imagine a world where software works for users, not the other way around. Where apps are resilient, private, and genuinely helpful—even offline. That’s the promise of this movement.

The Case for the Cloud

Does this mean the cloud is the wrong place for building and deploying applications? Absolutely not. The cloud has undeniable benefits, particularly for businesses managing complex, scalable applications. It provides flexibility, accessibility, and the ability to quickly deploy solutions without upfront infrastructure costs. For many organizations, especially startups, cloud platforms enable rapid experimentation and scaling, making it easier to focus on delivering value without worrying about maintaining hardware.

The key is intentionality. Not every app needs to rely entirely on the cloud. Providers should critically evaluate which features truly benefit from cloud-based functionality and which could operate more effectively offline or locally. By thoughtfully balancing these approaches, we can create a more sustainable and user-friendly ecosystem—one that leverages the best of both worlds.

My Final Thoughts

It’s time to rethink how we build and use software. As developers, we have the tools and knowledge to create healthier alternatives. As users, we have the power to demand better.

Let’s embrace local-first and offline-first principles, not just as a design choice but as a commitment to a better future—for ourselves, our users, and even those indirectly impacted by our products.

References

[1] Environmental Impact

[2] Examples of Offline-First Apps and Architectures

[3] Cost Comparison Studies

[4] Trends in Privacy-Focused App Development

[5] Carbon Footprint of Always-Online Systems

Image Credits

Photo by Anna Shvets