I Created A Kubernetes Cluster Using Old Android Phones

I Created A Kubernetes Cluster Using Old Android Phones

INTRODUCTION

When was the last time you stared at a drawer full of obsolete smartphones and wondered whether they could still be useful? For many of us, those devices become relics, gathering dust while our primary workstations handle the heavy lifting of development, testing, and production workloads. Yet the rapid decline in hardware costs and the surge of interest in low‑cost homelab experiments have turned that drawer into a goldmine of potential.

In this article I will walk you through the entire journey of transforming two retired Google Pixel 3a phones into a fully functional Kubernetes cluster. The project hinges on PostmarketOS, an open‑source, community‑driven Linux distribution that breathes new life into Android devices, and K3s, a lightweight, production‑grade Kubernetes distribution optimized for edge and resource‑constrained environments.

Why does this matter to a seasoned DevOps engineer or an infrastructure enthusiast?

• Self‑hosted experimentation – Building a cluster on repurposed hardware gives you a sandbox to test deployment strategies, CI/CD pipelines, and observability tooling without touching production resources.
• Resource efficiency – Modern Kubernetes clusters often require substantial VM or bare‑metal capacity. By leveraging low‑power ARM devices, you can run multiple clusters in parallel while staying within modest power budgets.
• Edge‑centric use cases – IoT gateways, remote monitoring stations, and edge AI inference points benefit from the same orchestration capabilities that large‑scale data centers enjoy, but on a fraction of the cost.

Throughout this guide you will learn:

1. The architectural choices that make PostmarketOS and K3s a natural fit for old Android phones.
2. How to prepare the devices, flash the operating system, and install the Kubernetes control plane and worker components.
3. Configuration patterns for networking, storage, and security that scale from a two‑node homelab to larger edge deployments.
4. Practical troubleshooting techniques for common issues such as network latency, storage provisioning, and container runtime quirks.
5. Best practices for monitoring, backup, and future upgrades in a self‑hosted context.

By the end of this piece you should have a clear mental model of how to replicate the experiment, a set of reproducible commands, and a deeper appreciation for the flexibility of modern container orchestration when paired with creative hardware reuse.

---

UNDERSTANDING THE TOPIC

PostmarketOS – The Linux Foundation for Android Devices

PostmarketOS (PMOS) is a community‑maintained Linux distribution built on top of Alpine Linux, designed specifically to extend the usable lifespan of Android smartphones. Its primary goals are:

• Mainline kernel support – By using upstream Linux kernels, PMOS eliminates the proprietary driver stack that typically ties Android devices to a single Android version.
• Package‑centric installation – The distribution ships with apk, Alpine’s package manager, enabling straightforward installation of containers, networking tools, and development utilities.
• Community‑driven device support – Hundreds of device trees and configuration patches are contributed by volunteers, allowing a wide range of smartphones to be supported.

For homelab purposes, PMOS provides a lean, headless environment that can be accessed via SSH, VNC, or a serial console. Its small footprint (often under 500 MB for a minimal installation) makes it ideal for devices with limited eMMC storage and modest RAM.

K3s – The Lightweight Kubernetes Distribution

Rancher Labs introduced K3s as a fully compliant, production‑ready Kubernetes distribution that trims down the traditional stack to a few megabytes of binary files. Key characteristics include:

• Single binary – The entire control plane (etcd, API server, scheduler, controller manager) and the worker components can be launched with a single k3s executable.
• Embedded etcd – K3s ships with a built‑in etcd binary compiled for static linking, removing the need for a separate data store.
• Minimal dependencies – It relies on containerd rather than Docker, reducing the attack surface and simplifying resource consumption.
• Edge‑optimized – Features such as systemd‑less operation, lightweight CNI plugins, and support for ARM architectures make it a natural fit for devices like the Pixel 3a.

K3s maintains full API compatibility with upstream Kubernetes, meaning all standard manifests, kubectl commands, and Helm charts work unchanged. This compatibility is crucial for anyone looking to experiment with deployment strategies, service meshes, or GitOps tooling in a constrained environment.

Why Combine PMOS and K3s?

The synergy between these two projects stems from three practical considerations:

1. ARM64 Compatibility – Both PMOS and K3s ship pre‑compiled binaries for ARM64, eliminating the need for cross‑compilation or emulation layers.
2. Low Memory Footprint – K3s can run with as little as 512 MiB of RAM for a single‑node cluster, which aligns with the 3 GB RAM profile of the Pixel 3a.
3. Networking Simplicity – PMOS provides a straightforward networking interface that can be leveraged to expose the K3s API server to the local LAN or a VPN, facilitating remote management.

Together, they enable a complete Kubernetes control plane to run on hardware that historically only powered a mobile OS, turning a discarded smartphone into a miniature data center node.

Comparison with Alternative Approaches

Approach	Hardware Requirements	Complexity	Community Support	Typical Use Cases
Full‑size VMs (e.g., Ubuntu, CentOS)	2 CPU, 4 GB RAM each	Medium‑High	Broad (official docs)	Production workloads, large clusters
Docker Desktop on a laptop	4 CPU, 8 GB RAM	Low	Strong (Docker)	Local development, CI pipelines
PMOS + K3s on Android	2 CPU, 3 GB RAM per device	Medium (requires flashing)	Niche but growing (PMOS, K3s)	Edge, homelab, IoT gateways

The primary trade‑off is the additional effort required to flash and configure the devices. However, the payoff is a truly portable, low‑power Kubernetes environment that can be replicated across multiple phones, providing a unique testbed for multi‑node topologies without purchasing dedicated hardware.

---

PREREQUISITES

Before embarking on the transformation, gather the following hardware, software, and network prerequisites.

Hardware Checklist

Item	Minimum Specification	Remarks
Pixel 3a (or similar)	ARM64 processor, 3 GB RAM, 64 GB eMMC storage	Ensure the device boots into fastboot mode.
USB‑C to USB‑A cable	–	Required for flashing and ADB connectivity.
Power supply	5 V ≥ 2 A	Stable power prevents unexpected reboots during flashing.
Local network (Wi‑Fi or Ethernet via OTG)	–	Provides connectivity for SSH and K3s API exposure.
Optional: USB hub with Ethernet adapter	–	Useful if the phone lacks native Ethernet.

Software Stack

Component	Version (as of writing)	Purpose
adb (Android Debug Bridge)	1.0.41	Communicates with the device during flashing.
fastboot	1.0.41	Low‑level flashing utility for PMOS images.
ssh (OpenSSH)	8.9p1	Remote management of the device after OS installation.
curl	7.88.1	Used for downloading PMOS artifacts and K3s binaries.
git	2.40.1	Optional for cloning configuration repositories.
kubectl	1.28.0	Interacts with the K3s cluster.
helm	3.13.0	Package manager for Kubernetes manifests (optional).

All tools should be installed on a workstation that can reach the devices over the network. Linux or macOS hosts are recommended; Windows users can employ WSL2 for a comparable environment.

Network and Security Considerations

1. Static IP Allocation – Assign each phone a static IP address within your LAN (e.g., 192.168.1.101 and 192.168.1.102) to simplify DNS resolution for the K3s API server.
2. Firewall Rules – Restrict inbound traffic to the K3s API port (6443) and etcd metrics endpoint (2379) to trusted IP ranges or a VPN.
3. SSH Hardening – Disable password authentication after initial setup; use SSH key pairs exclusively.
4. TLS for K3s – Enable the built‑in TLS cert management in K3s to encrypt internal traffic, especially when exposing services beyond the LAN.

Pre‑Installation Checklist

• Verify that the Pixel 3a devices are recognized by adb devices.
• Unlock the bootloader (if not already unlocked) using fastboot oem unlock.
• Download the appropriate PMOS image for the Pixel 3a (e.g., pmos-phosh-image-arm64-pixel3a.img).
• Flash the image to the device’s system partition using fastboot flash system <image>.img && fastboot reboot.
• Confirm SSH access with the default postmarketos user and a known password (root or postmarketos).
• Update the device’s package index (apk update) and upgrade installed packages (apk upgrade).

Only after these steps are successfully completed should you proceed to the K3s installation.

---

INSTALLATION & SETUP

The following sections detail the exact commands and configuration files needed to transform a freshly flashed Pixel 3a into a K3s node. The process is identical for each device, with the only variation being the node’s hostname and IP address.

1. Preparing the Base System

Log in via SSH using the device’s IP address:

ssh postmarketos@192.168.1.101

Once connected, perform the following initial configuration steps:

# Set a unique hostname for the node
hostnamectl set-hostname pmos-node-01

# Configure a static IP (adjust netmask and gateway as needed)
cat <<EOF > /etc/network/interfaces
auto eth0
iface eth0 inet static
    address 192.168.1.101
    netmask 255.255.255.0
    gateway 192.168.1.1
    dns-nameservers 8.8.8.8 8.8.4.4
EOF

# Restart networking
/etc/init.d/networking restart

Note – Replace 192.168.1.101 with the appropriate address for each device.

2. Installing K3s

K3s provides a single binary that bundles all necessary components. The recommended installation method on ARM64 devices is to download the pre‑compiled binary and place it in /usr/local/bin.

# Create a directory for binaries if it does not exist
mkdir -p /usr/local/bin

# Download the latest stable K3s release for ARM64
curl -L https://github.com/k3s-io/k3s/releases/download/v1.28.2+k3s1/k3s-arm64 -o /usr/local/bin/k3s
chmod +x /usr/local/bin/k3s

# Verify the binary works
k3s version

The output should display something akin to:

 version/v1.28.2+k3s1 (revision 4e5f6c9d) 

2.1 Enabling the K3s Service

Create a systemd service file to ensure K3s starts on boot:

# /etc/systemd/system/k3s.service
[Unit]
Description=Lightweight Kubernetes
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/k3s server \
  --write-kubeconfig-enabled \
  --disable-agent \
  --disable=traefik \
  --node-ip=192.168.1.101 \
  --cluster-cidr=10.42.0.0/16 \
  --service-cidr=10.43.0.0/16 \
  --flannel-backend=vxlan \
  --log-level=2
Restart=on-failure
LimitNPROC=1024
LimitNOFILE=1048576

[Install]
WantedBy=multi-user.target

Explanation of key flags

• --write-kubeconfig-enabled – Generates a kubeconfig file at /etc/rancher/k3s/k3s.yaml for local kubectl usage.
• --disable-agent – Reduces overhead by not installing the agent on the same node.
• --disable=traefik – Traefik is omitted to keep the footprint minimal; you can enable it later if you need an ingress controller.
• --node-ip – Binds the node to its static IP, preventing accidental selection of an undesired interface.

Enable and start the service:

systemctl daemon-reload
systemctl enable k3s
systemctl start k3s

2.2 Verifying the Control Plane

Check the status of the K3s service and confirm that the control plane components are running:

systemctl status k3s
journalctl -u k3s -f

You should see logs indicating successful API server startup, etcd leader election, and scheduler initialization.

2.3 Adding Additional Nodes

Repeat the installation steps on the second Pixel 3a, but configure it as an agent (worker) rather than a