Single-node K3s is a pragmatic choice for homelabs and lightweight production workloads, offering Kubernetes compatibility without the overhead of multi-node clusters.

Why Single-Node K3s Matters

Moving from Docker Compose to K3s gains you real Kubernetes APIs, declarative config management, and a clear path to scale. For homelabs or small services (monitoring stacks, CI runners, internal tools), it’s a low-friction way to modernize without overengineering.

Actionable Workflow

1. Install K3s:

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

   This drops a lightweight cluster with minimal dependencies.

2. Deploy Apps:
   Use Helm charts or kubectl manifests. Example:

   helm install myapp bitnami/nginx  
   

3. Handle Storage:
   For stateful apps:

   • Use local directories with hostPath volumes (simple but node-bound).
   • For future multi-node plans, deploy Longhorn or OpenEBS for block storage.

4. Backup:
   Schedule etcd backups:

   kubectl cp -n kube-system k3s-<node-id>:/etc/rancher/k3s/backend/db/etcd-snapshot.tar.gz ./etcd-snapshot.tar.gz  
   

Policy Example

# Example resource limits for homelab pods  
resources:  
  limits:  
    memory: "512Mi"  
    cpu: "500m"  
  requests:  
    memory: "256Mi"  
    cpu: "250m"  

Enforce via admission controllers or Helm values.

Tooling

• K3s: Lightweight Kubernetes distro.
• Helm: Package management for apps.
• Longhorn: Distributed block storage (for multi-node futures).
• OpenEBS: Container-native storage orchestration.
• Litestream: SQLite replication for cloud deployments.

Tradeoffs

• Pros: Low resource use (~500MB RAM idle), single binary install, real Kubernetes.
• Cons: No HA (single point of failure), limited scalability, SQLite struggles with network storage (use Litestream or migrate to PostgreSQL).

Troubleshooting

• Node Not Ready:

  kubectl describe node <node-name>  
  

  Check system resources, disk pressure, or Docker/K3s service status.

• Pod CrashLoop:

  kubectl logs <pod-name> --previous  
  

  Common fixes: Adjust memory limits, check volume mounts, validate image pulls.

• Storage Mount Failures:
  Ensure hostPath directories exist and have correct permissions (e.g., chown 1000:1000 /var/hostpath/data).

Final Verdict

Single-node K3s is worth it if you value Kubernetes compatibility, need to upskill on K8s, or plan to scale later. Just accept its limits: avoid stateful workloads that can’t tolerate single-node constraints, and always test backups. For SQLite-dependent apps, use Litestream in cloud setups or stick to local storage for now.

Source thread: Single node K3s is it worth it?