Sign in Subscribe
Kubernetes

Going Mobile: Part 2

Liam Aikin

• 2 min read
Going Mobile: Part 2
Photo by Dan Cristian Pădureț / Unsplash

The Plan: The part that matters

Part 1: Identifying System Requirements

Based on the outlines from Part 1, the requirements for our system are as follows:

  1. Highly available, geographically distributed system
  2. Distributed replicated storage
  3. Ability to run argoCD, code-server, hakatime, and Nextcloud together, at a minimum

Part 2: Transforming Requirements into a Design For each requirement, I will outline the design decisions made:

Highly available, geographically distributed system:

  • Kubernetes: The best option for this requirement, with various distributions designed for different applications. I will use k3s, as it is lightweight and well-suited for this purpose.
  • Other options: Docker Swarm, Apache Mesos, Nomad, OpenShift

Distributed replicated storage:

  • Longhorn: In Part 1, I mentioned using GlusterFS, but I decided to switch to Longhorn. This change allows us to reduce the total number of geographical locations from 3 (required by GlusterFS to avoid split-brain) to 2, although it does reduce our fault tolerance. Longhorn is a lightweight and reliable distributed block storage system for Kubernetes, making it well-suited for our purpose.
  • Other options: GlusterFS (as mentioned in Part 1), Ceph, HDFS

Ability to run argoCD, code-server, hakatime, and Nextcloud together, at a minimum:

This requirement relates more to hardware specifications. My decision for hardware includes:

  • 2x Dell OptiPlex 7050 SFF Intel i5 6500 3.20GHz 16GB RAM
  • 2x SBC (4GB RAM) Raspberry Pi or equivalent

Part 3: Putting it Together

Below is the system diagram that I have settled on for the system:

Going Mobile System Design

Description of each object in the diagram:

  • Internet: Everything in this system is available on the internet.
  • VPN: Headscale comes in here as mentioned in Part 1. Headscale is the open-source implementation of Tailscale, allowing for self-hosted Tailscale VPNs. In this system, headscale will be hosted on a separate machine, most likely a VPS. The items within this system will communicate with each other via the headscale server.
  • Location: Represents a physical geographic location.
  • Control Plane Replication: Indicates how the control plane is distributed within the system.
  • Node: Represents a physical machine (SBC for the k3s server, OptiPlex for the k3s agent).
  • Longhorn: Represents the blocks within the Longhorn system used for distributed block storage.
  • GitOps: Indicates how application delivery and deployment will be managed via ArgoCD.
  • S3 Backup: Longhorn will back up data to S3 to provide disaster recovery in case both systems fail simultaneously.

Explore the series:

This post is part of the 'Going Mobile' series. Explore the series further: