language: en kae3g ← back to index
(unlisted) — This essay is not shown on the main index but remains accessible via direct link

kae3g 9300: Alpine Kubernetes with Nix — The Microbrewery Cluster Reborn

Timestamp: 12025-10-21–coldriver-tundra
Series: Technical Implementation
Category: Kubernetes, Alpine Linux, Nix Package Manager, Self-Hosting
Reading Time: 45 minutes

"The microbrewery sits empty, but its bones are perfect. The fermentation tanks that once held beer now hold the promise of computation. The cooling systems that maintained precise temperatures for brewing now maintain precise temperatures for silicon. The space that served a local community now serves the digital community. This is the transformation: from hops to hopes, from brewing to building."

The Empty Microbrewery

We stand in the cavernous space of a failed microbrewery in Sacramento Valley. The fermentation tanks have been removed, but the infrastructure remains: reinforced concrete floors, industrial power, glycol cooling systems, and the bones of what was once a thriving local business.

"This space," says the Infrastructure Architect, gesturing to the empty shell, "is perfect for what we're about to build. But first, we need to choose our foundation carefully. Not just any Linux distribution will do for a self-hosted Kubernetes cluster that must run for decades."

She pulls out four different blueprints, each representing a different path forward.

The Four Paths: Alpine, Void, Chimera, and the Future

Path One: Alpine Linux — The Practical Foundation

"Alpine Linux," she begins, "is like building with stone and timber—materials that have proven themselves over centuries. It's musl libc, it's OpenRC, it's apk package management. It's what runs in Docker containers everywhere because it's tiny, secure, and reliable. But more importantly for our Framework laptop goal, it's production-ready and battle-tested."

Alpine Linux Strengths:

Alpine Linux Challenges:

Musl libc Deep Dive:

{:musl-advantages
 {:codebase-beauty
  "Clean, auditable C code
   POSIX-compliant implementation
   No GNU extensions or bloat
   Focus on correctness over features"
  
  :performance
  "Smaller memory footprint
   Faster static linking
   Better security (minimal attack surface)
   Optimized for embedded/container use"
  
  :compatibility
  "s6 init system: native musl support
   QEMU: excellent musl builds
   Kubernetes: Go-based tools work perfectly
   Languages: Zig, Rust, Hare all musl-compatible"}}

Path Two: Void Linux — The Musl Pioneer

"Void Linux," she continues, "is like building with steel and glass—modern materials that are both strong and transparent. It's the only major distribution that offers both glibc and musl variants, with musl being the default. It's what happens when you take the best of Arch Linux and strip away systemd."

Void Linux Strengths:

Void Linux Musl Advantages:

{:void-musl-advantages
 {:ecosystem
  "Native musl builds for all packages
   No glibc compatibility layer needed
   True musl-first development
   Community expertise in musl"
  
  :performance
  "Static linking support
   Smaller binaries than glibc
   Better security (minimal attack surface)
   Faster compilation times"
  
  :compatibility
  "s6 init system: native support
   QEMU: excellent musl builds
   Kubernetes: Go-based tools work perfectly
   Languages: Zig, Rust, Hare all musl-compatible"
  
  :development
  "Cross-compilation support
   Embedded system builds
   Container optimization
   CI/CD friendly"}}

Void Linux Challenges:

Void Linux Installation:

# Download Void Linux musl ISO
wget https://alpha.de.repo.voidlinux.org/live/current/void-live-x86_64-musl-20231001.iso

# Boot from ISO, run void-installer
void-installer

# Configure:
# - Keyboard: us
# - Hostname: k8s-node-01
# - Root password: [secure password]
# - User: developer
# - Disk: sda (use entire disk)
# - Filesystem: ext4
# - Bootloader: GRUB

# Reboot and login
reboot

Void Linux Base System:

# Update system
xbps-install -Su

# Install essential packages
xbps-install -S \
  curl wget git vim htop \
  musl-dev clang make \
  linux-headers

# Install s6 supervision suite
xbps-install -S s6 s6-rc s6-linux-init

# Configure s6 as init system
s6-linux-init-maker -1 /etc/s6/rc/init

Path Three: Chimera Linux — The Future Vision

"Chimera Linux," she says, her eyes lighting up with possibility, "is like building with materials from the future—things that don't exist yet but should. It's musl libc with LLVM toolchain and FreeBSD userland. It's what happens when you start from scratch and build exactly what you need. But for our Framework laptop goal, it's still maturing—a future we can help build."

Chimera Linux Strengths:

Chimera Linux Architecture:

{:chimera-architecture
 {:toolchain
  "LLVM/Clang compiler
   LLD linker
   libc++ standard library
   libunwind for stack traces"
  
  :userland
  "FreeBSD core utilities
   BSD make system
   BSD init system (rc.d)
   BSD networking stack"
  
  :musl-integration
  "Native musl libc
   No glibc dependencies
   Static linking support
   Cross-compilation ready"
  
  :s6-support
  "Native s6 integration
   s6-rc service management
   s6-linux-init support
   Container supervision"}}

Chimera Linux Advantages:

{:chimera-advantages
 {:consistency
  "Single toolchain for everything
   No mixed glibc/musl issues
   Predictable build environment
   Reproducible builds"
  
  :performance
  "LLVM optimizations
   Modern compiler features
   Better code generation
   Faster execution"
  
  :security
  "Musl libc security model
   LLVM sanitizers
   Modern security features
   Minimal attack surface"
  
  :future-proof
  "Modern architecture
   Active development
   Community-driven
   Cutting-edge features"}}

Chimera Linux Challenges:

Chimera Linux Installation:

# Download Chimera Linux ISO
wget https://repo.chimera-linux.org/iso/chimera-linux-20231001-x86_64.iso

# Boot from ISO, run chimera-install
chimera-install

# Configure:
# - Keyboard: us
# - Hostname: k8s-node-01
# - Root password: [secure password]
# - User: developer
# - Disk: sda (use entire disk)
# - Filesystem: ext4
# - Bootloader: GRUB

# Reboot and login
reboot

Chimera Linux Base System:

# Update system
apk update && apk upgrade

# Install essential packages
apk add --no-cache \
  curl wget git vim htop \
  musl-dev clang make \
  linux-headers

# s6 is already installed and configured
# Configure s6 services
mkdir -p /etc/s6/services/{sshd,chronyd,networking}

Path Four: Artix Linux — The Pragmatist's Choice

"Artix Linux," she continues, "is like building with steel and concrete—modern materials that are strong, flexible, and widely available. It's Arch Linux without systemd, giving you the massive AUR ecosystem with your choice of init system."

Artix Linux Strengths:

Artix Linux Challenges:

Path Five: The Future — SixOS Contribution

"But there's a third path," she says, her eyes lighting up with possibility. "What if we don't just choose from what exists, but help build what should exist? What if we become core contributors to SixOS—the NixOS variant without systemd that we learned about in 9952?"

SixOS Vision:

The s6 Init System: The Perfect Foundation

The Architect pulls out a small, elegant toolkit—the s6 supervision suite. "This," she says, "is the heart of everything we're building. It's not just compatible with musl libc—it's a perfect philosophical match."

s6: Musl-Native Process Supervision

s6 Architecture:

{:s6-supervision-suite
 {:components
  ["s6-svscan (PID 1) - Master process scanner"
   "s6-supervise - Individual service supervision"
   "s6-log - Logging management"
   "s6-rc - Service manager (dependency resolution)"
   "s6-linux-init - Init system integration"]
  
  :musl-compatibility
  "✅ Fully musl-native
   ✅ Written in clean, portable C
   ✅ POSIX-compliant (no glibc extensions)
   ✅ Compiles cleanly against musl libc
   ✅ Used in Void Linux musl and Alpine Linux"
  
  :philosophical-alignment
  "Minimalist design: ~200KB total binaries
   Unix philosophy: do one thing well
   Clean, auditable C code
   No unnecessary dependencies
   Predictable behavior"}}

Why s6 is Perfect for Our Goals:

  1. Musl-Native Performance:
    • s6-svscan: ~50KB binary
    • s6-supervise: ~30KB binary
    • Compare to systemd: ~1.5MB (systemd alone)
    • Static linking support with musl
  2. Container-Friendly Design:
       # s6 in containers - minimal overhead
   /s6-svscan /etc/s6/services
   # vs systemd in containers: full OS initialization
  3. Kubernetes-Native Thinking:
    • Process supervision = container supervision philosophy
    • Dependency management = pod dependency graphs
    • Clean process lifecycle = container lifecycle

Sway Wayland: The Perfect GUI Companion

"But what about the desktop environment?" asks the Developer. "We need something that matches our minimalist philosophy."

Why Sway Over XFCE and Others:

{:sway-advantages
 {:philosophical-alignment
  "Configuration as code (like Nix)
   Minimal resource usage
   Keyboard-driven efficiency
   Wayland-native performance"
  
  :musl-compatibility
  "✅ Native musl builds in Alpine/Chimera
   ✅ C-based compositor (matches s6 philosophy)
   ✅ No X11 dependencies
   ✅ Lightweight and efficient"
  
  :developer-experience
  "i3 compatibility (familiar workflow)
   Stable API (no breaking changes)
   Predictable behavior
   Excellent for development work"
  
  :vs-alternatives
  "Hyprland: Too flashy, breaking changes
   XFCE: More traditional, higher overhead
   GNOME/KDE: Too heavy for our goals"}}

Sway Installation on Alpine:

# Install Sway and Wayland components
apk add sway foot waybar mako
apk add grim slurp wl-clipboard
apk add firefox

# Framework laptop Wayland support
apk add seatd linux-firmware-iwlwifi
rc-update add seatd default

# Basic Sway configuration
mkdir -p ~/.config/sway
cat > ~/.config/sway/config << 'EOF'
# Basic Sway configuration for development
set $mod Mod4
bindsym $mod+Return exec foot
bindsym $mod+Shift+q kill
bindsym $mod+d exec wofi --show drun
bindsym $mod+Shift+e exec swaynag -t warning -m 'Exit Sway?' -b 'Yes' 'swaymsg exit'
EOF

Why Not the Others:

s6 vs SixOS: Current vs Future

Aspects6 (Current)SixOS (Future Vision)
StatusProduction-readyExperimental/research
CodebaseMature, stable CNix + s6 integration
PackagingAvailable in Alpine/ChimeraCustom Nix derivations
DocumentationComprehensiveSparse/evolving
CommunitySmall but activeVery small/developers only
Musl FocusNative musl supportNix defaults to glibc (but supports musl)

SixOS Current Reality:

The Rationale: Why This Stack Matters

The Musl libc Advantage

"Let me explain why musl libc isn't just a technical choice—it's a philosophical one," says the Architect, pulling out a comparison chart.

Musl vs glibc Performance:

{:musl-vs-glibc
 {:binary-size
  "musl: ~1.2MB (minimal libc)
   glibc: ~2.5MB (with extensions)
   Savings: 52% smaller binaries"
  
  :memory-usage
  "musl: ~2-4MB per process
   glibc: ~8-12MB per process
   Savings: 60-70% less memory"
  
  :security
  "musl: Minimal attack surface
   glibc: Complex, many features
   Result: Fewer vulnerabilities"
  
  :static-linking
  "musl: Excellent static linking
   glibc: Complex static linking
   Result: True portability"}}

Real-World Impact:

The Clang/LLVM Advantage for Musl Development

"But why Clang instead of GCC?" asks the Developer. "Isn't GCC the standard compiler?"

Why Clang/LLVM for Musl:

{:clang-musl-advantages
 {:musl-compatibility
  "Better musl libc support
   Native musl target support
   Cleaner musl integration
   Fewer musl-specific patches needed"
  
  :modern-toolchain
  "LLVM-based compilation
   Better optimization passes
   Modern C++ standard support
   Cross-compilation excellence"
  
  :consistency
  "Chimera Linux uses LLVM exclusively
   Alpine Linux supports both GCC and Clang
   Void Linux has excellent Clang support
   Future-proof toolchain choice"
  
  :performance
  "Better optimization for musl
   Faster compilation times
   Smaller binary sizes
   Better static linking support"}}

Real-World Impact:

The s6 Philosophy: Unix Perfection

"s6 isn't just an init system—it's a return to Unix principles," the Architect continues.

s6 vs systemd Comparison:

{:s6-vs-systemd
 {:complexity
  "s6: ~200KB total, 5 binaries
   systemd: ~1.5MB+, 200+ binaries
   Result: 7.5x simpler"
  
  :reliability
  "s6: Simple, predictable behavior
   systemd: Complex state machine
   Result: Fewer failure modes"
  
  :debugging
  "s6: Text logs, simple scripts
   systemd: Binary logs, complex units
   Result: Easier troubleshooting"
  
  :philosophy
  "s6: Do one thing well
   systemd: Do everything
   Result: Better maintainability"}}

The Sway Advantage: Developer Efficiency

"Sway isn't just a window manager—it's a productivity multiplier," adds the Developer.

Sway vs Traditional Desktops:

{:sway-efficiency
 {:resource-usage
  "Sway: ~50MB RAM, ~5% CPU
   XFCE: ~200MB RAM, ~10% CPU
   GNOME: ~500MB RAM, ~15% CPU"
  
  :workflow-speed
  "Sway: Keyboard-driven, instant
   XFCE: Mouse-heavy, slower
   GNOME: Mouse-heavy, slowest"
  
  :customization
  "Sway: Text config, version control
   XFCE: GUI config, harder to track
   GNOME: Limited customization"
  
  :wayland-benefits
  "Better security (no X11)
   Smoother graphics
   Better battery life
   Future-proof technology"}}

The Nix Integration: Reproducible Everything

"Nix isn't just a package manager—it's the foundation of reproducible systems," explains the DevOps Engineer.

Nix Advantages:

{:nix-benefits
 {:reproducibility
  "Same inputs = same outputs
   Atomic upgrades with rollback
   No dependency hell
   Perfect for CI/CD"
  
  :flexibility
  "Multiple versions coexist
   Easy to override packages
   Custom derivations
   Cross-compilation support"
  
  :musl-integration
  "pkgsMusl for musl builds
   Static linking support
   Container optimization
   Embedded system builds"}}

The Recommendation: Alpine Linux for Framework Laptop

The Architect stands up, gathering her blueprints. "For our Framework laptop goal—musl libc + s6 + Sway Wayland GUI—I recommend we start with Alpine Linux."

Why Alpine Linux for Framework Laptop:

{:alpine-framework-advantages
 {:immediate-productivity
  "Production-ready today
   Excellent Framework laptop support
   Proven hardware compatibility
   Reliable driver support"
  
  :development-workflow
  "Simple apk package management
   Well-documented s6 integration
   Native Sway Wayland support
   Nix package manager compatibility"
  
  :learning-path
  "Master musl + s6 + Sway on Alpine
   Build expertise for Chimera contribution
   Prepare for SixOS development
   Create practical implementation guide"
  
  :community-support
  "Large, active community
   Extensive documentation
   Framework laptop users
   s6 and Sway expertise"}}

The Path Forward:

  1. Phase 1: Alpine Linux on Framework laptop (immediate productivity)
  2. Phase 2: Contribute to Chimera Linux (future development)
  3. Phase 3: Lead SixOS development (ultimate vision)

The Implementation: Alpine Linux + Kubernetes + Nix

"For now," the Architect says, "let's build with Alpine Linux. It's proven, it's minimal, and it's perfect for our microbrewery cluster. But we'll design it so that when SixOS is ready, we can migrate seamlessly."

Phase 1: Alpine Linux Base System

Hardware Requirements (per node):

Why Alpine Linux Extended ISO for Framework Laptops

Multi-AI Consensus Analysis: All AI systems (Meta, Deepseek, Gemini, Grok) recommend the Extended ISO for Framework laptops with AMD hardware due to essential firmware requirements:

Extended ISO Advantages:

Standard vs Extended Comparison:

{:alpine-iso-comparison
 {:standard-iso
  "Minimalist approach
   Just enough to boot and fetch packages
   Requires reliable network connection
   Manual microcode installation needed
   Smaller download size"
  
  :extended-iso
  "Firmware-rich approach
   Includes AMD/Intel microcode updates
   Contains essential hardware drivers
   Works offline after installation
   Better for modern hardware like Framework laptop
   Larger download but better hardware support"}}

Alpine Linux Installation:

# Download Alpine Linux Extended ISO for x86_64 (Recommended for Framework laptops)
# Extended includes AMD microcode updates and firmware essential for modern hardware
wget https://dl-cdn.alpinelinux.org/alpine/v3.22/releases/x86_64/alpine-extended-3.22.2-x86_64.iso

# Verify checksum
wget https://dl-cdn.alpinelinux.org/alpine/v3.22/releases/x86_64/alpine-extended-3.22.2-x86_64.iso.sha256
sha256sum -c alpine-extended-3.22.2-x86_64.iso.sha256

# Boot from ISO, run setup-alpine
setup-alpine

# Configure:
# - Keyboard: us
# - Hostname: k8s-node-01
# - Interface: eth0 (or your network interface)
# - IP: 192.168.1.10/24
# - Gateway: 192.168.1.1
# - DNS: 8.8.8.8
# - Timezone: America/Los_Angeles
# - SSH: OpenSSH
# - Disk: sda (use entire disk)
# - Root password: [secure password]

# Reboot and login
reboot

Base System Configuration:

# Update system
apk update && apk upgrade

# Install Framework laptop specific firmware (corrected package names)
apk add --no-cache \
  linux-firmware \
  linux-firmware-amd \
  amd-ucode \
  acpi \
  acpid \
  cpufrequtils

# Install essential development packages
apk add --no-cache \
  curl \
  wget \
  git \
  vim \
  htop \
  iotop \
  nload \
  tcpdump \
  strace \
  gdb \
  musl-dev \
  clang \
  make \
  linux-headers

# Install s6 supervision suite (musl-native)
apk add --no-cache \
  s6 \
  s6-rc \
  s6-linux-init \
  s6-portable-utils \
  s6-dns \
  execline

# Configure s6 as init system (musl-native)
s6-linux-init-maker -1 /etc/s6/rc/init

# Backup original inittab
cp /etc/inittab /etc/inittab.bak

# Replace with s6 init
cat > /etc/inittab << 'EOF'
::sysinit:/etc/s6/init/init-stage1
::wait:/etc/s6/init/init-stage2
::shutdown:/etc/s6/init/init-shutdown
EOF

# Create s6 service directories
mkdir -p /etc/s6/services/{sshd,chronyd,networking,seatd}

# Configure s6 services
cat > /etc/s6/services/sshd/run << 'EOF'
#!/bin/execlineb -P
s6-setuidgid root
/usr/sbin/sshd -D
EOF

cat > /etc/s6/services/chronyd/run << 'EOF'
#!/bin/execlineb -P
s6-setuidgid chrony
/usr/sbin/chronyd -d
EOF

# Configure seatd for Wayland (Framework laptop requirement)
cat > /etc/s6/services/seatd/run << 'EOF'
#!/bin/execlineb -P
s6-setuidgid root
/usr/bin/seatd
EOF

chmod +x /etc/s6/services/*/run

# Configure s6-rc for service management
s6-rc-compile /etc/s6-rc/compiled /etc/s6-rc/source
s6-rc change default

# Add user to video and seat groups for Wayland
adduser $USER video
adduser $USER seat

Phase 2: Nix Package Manager Integration

Installing Nix on Alpine Linux:

# Install Nix (single-user mode for simplicity)
curl -L https://nixos.org/nix/install | sh

# Source Nix environment
. /home/root/.nix-profile/etc/profile.d/nix.sh

# Verify installation
nix --version
# nix (Nix) 2.18.1

# Install Nix packages for Kubernetes
nix-env -iA nixpkgs.kubectl
nix-env -iA nixpkgs.helm
nix-env -iA nixpkgs.k9s
nix-env -iA nixpkgs.docker
nix-env -iA nixpkgs.containerd
nix-env -iA nixpkgs.runc
nix-env -iA nixpkgs.cni-plugins
nix-env -iA nixpkgs.crictl

Nix Configuration for Alpine:

# Create Nix configuration directory
mkdir -p /etc/nix

# Configure Nix for Alpine Linux
cat > /etc/nix/nix.conf << 'EOF'
# Nix configuration for Alpine Linux
build-users-group = nixbld
sandbox = false
extra-sandbox-paths = /bin/sh=/bin/sh
substituters = https://cache.nixos.org/ https://cache.ngi0.nixos.org/
trusted-public-keys = cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY= cache.ngi0.nixos.org-1:bjZrnw+0vYc8jXrvX1rQp60FqQjhrl2eI1U3S9xAQf4=
EOF

# Create nixbld group and users
groupadd -g 30000 nixbld
for i in $(seq 1 10); do
  useradd -u $((30000 + i)) -g nixbld -G nixbld -d /var/empty -s /bin/false nixbld$i
done

Phase 3: s6 Service Management for Kubernetes

s6 Service Definitions for Kubernetes Components:

# Create s6 services for Kubernetes
mkdir -p /etc/s6/services/{containerd,kubelet,kube-proxy,cilium}

# containerd service
cat > /etc/s6/services/containerd/run << 'EOF'
#!/bin/execlineb -P
s6-setuidgid root
/usr/bin/containerd --config /etc/containerd/config.toml
EOF

# kubelet service
cat > /etc/s6/services/kubelet/run << 'EOF'
#!/bin/execlineb -P
s6-setuidgid root
/usr/bin/kubelet --config=/etc/kubernetes/kubelet-config.yaml
EOF

# Cilium CNI service
cat > /etc/s6/services/cilium/run << 'EOF'
#!/bin/execlineb -P
s6-setuidgid root
/usr/bin/cilium-agent --config-dir=/etc/cilium
EOF

chmod +x /etc/s6/services/*/run

# Configure service dependencies
cat > /etc/s6-rc/source/containerd/type << 'EOF'
longrun
EOF

cat > /etc/s6-rc/source/kubelet/type << 'EOF'
longrun
EOF

cat > /etc/s6-rc/source/kubelet/dependencies << 'EOF'
containerd
EOF

# Compile and activate services
s6-rc-compile /etc/s6-rc/compiled /etc/s6-rc/source
s6-rc change default

s6 vs systemd for Kubernetes:

Aspects6systemd
Binary Size~200KB total~1.5MB+
Memory Usage~2-5MB~20-50MB
Boot Time~2-3 seconds~5-10 seconds
Container OverheadMinimalSignificant
Musl CompatibilityNativeRequires patches
Service DefinitionSimple scriptsComplex unit files

Phase 4: Kubernetes Cluster Setup

Container Runtime (containerd):

# Install containerd via Nix
nix-env -iA nixpkgs.containerd

# Configure containerd
mkdir -p /etc/containerd
cat > /etc/containerd/config.toml << 'EOF'
version = 2
[plugins."io.containerd.grpc.v1.cri"]
  [plugins."io.containerd.grpc.v1.cri".containerd]
    [plugins."io.containerd.grpc.v1.cri".containerd.runtimes]
      [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
        runtime_type = "io.containerd.runc.v2"
        [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
          SystemdCgroup = false
  [plugins."io.containerd.grpc.v1.cri".cni]
    bin_dir = "/nix/store/*-cni-plugins-*/bin"
    conf_dir = "/etc/cni/net.d"
EOF

# Create containerd service for OpenRC
cat > /etc/init.d/containerd << 'EOF'
#!/sbin/openrc-run

name="containerd"
command="/nix/store/*-containerd-*/bin/containerd"
command_args="--config /etc/containerd/config.toml"
pidfile="/run/containerd.pid"
command_background="yes"

depend() {
  need localmount
  before net
}
EOF

chmod +x /etc/init.d/containerd
rc-update add containerd default
rc-service containerd start

Kubernetes Installation:

# Install kubeadm, kubelet, kubectl via Nix
nix-env -iA nixpkgs.kubernetes

# Configure kubelet
mkdir -p /etc/kubernetes
cat > /etc/kubernetes/kubelet-config.yaml << 'EOF'
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
authentication:
  anonymous:
    enabled: false
  webhook:
    enabled: true
  x509:
    clientCAFile: /etc/kubernetes/pki/ca.crt
authorization:
  mode: Webhook
clusterDomain: cluster.local
clusterDNS:
  - 10.96.0.10
containerRuntimeEndpoint: unix:///run/containerd/containerd.sock
cgroupDriver: cgroupfs
resolvConf: /etc/resolv.conf
runtimeRequestTimeout: 2m
hostnameOverride: k8s-node-01
EOF

# Create kubelet service for OpenRC
cat > /etc/init.d/kubelet << 'EOF'
#!/sbin/openrc-run

name="kubelet"
command="/nix/store/*-kubernetes-*/bin/kubelet"
command_args="--config=/etc/kubernetes/kubelet-config.yaml --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubeconfig.conf --kubeconfig=/etc/kubernetes/kubelet.conf --container-runtime=remote --container-runtime-endpoint=unix:///run/containerd/containerd.sock"
pidfile="/run/kubelet.pid"
command_background="yes"

depend() {
  need containerd
  after containerd
}
EOF

chmod +x /etc/init.d/kubelet
rc-update add kubelet default

CNI Plugin (Cilium):

# Install Cilium via Nix
nix-env -iA nixpkgs.cilium

# Configure Cilium
mkdir -p /etc/cni/net.d
cat > /etc/cni/net.d/10-cilium.conflist << 'EOF'
{
  "cniVersion": "0.3.1",
  "name": "cilium",
  "plugins": [
    {
      "type": "cilium-cni",
      "enable-debug": false,
      "log-format": "text",
      "log-file": "/var/log/cilium.log"
    }
  ]
}
EOF

Phase 4: Cluster Initialization

Master Node Setup:

# Initialize cluster
kubeadm init \
  --pod-network-cidr=10.244.0.0/16 \
  --service-cidr=10.96.0.0/12 \
  --apiserver-advertise-address=192.168.1.10 \
  --cri-socket=unix:///run/containerd/containerd.sock

# Configure kubectl
mkdir -p /root/.kube
cp /etc/kubernetes/admin.conf /root/.kube/config

# Install Cilium CNI
helm repo add cilium https://helm.cilium.io/
helm repo update
helm install cilium cilium/cilium \
  --namespace kube-system \
  --set global.containerRuntime.integration=containerd \
  --set global.containerRuntime.socketPath=/run/containerd/containerd.sock

Worker Node Setup:

# Join worker nodes to cluster
kubeadm join 192.168.1.10:6443 \
  --token <token> \
  --discovery-token-ca-cert-hash sha256:<hash> \
  --cri-socket=unix:///run/containerd/containerd.sock

Phase 5: Storage and Monitoring

Storage (Longhorn):

# Install Longhorn via Helm
helm repo add longhorn https://charts.longhorn.io/
helm repo update
helm install longhorn longhorn/longhorn \
  --namespace longhorn-system \
  --create-namespace

Monitoring (Prometheus + Grafana):

# Install kube-prometheus-stack
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --create-namespace \
  --set grafana.adminPassword=admin

The Distro Comparison: Alpine vs Void vs Chimera vs Artix vs Future SixOS

Alpine Linux: The Recommended Foundation

Why Alpine for Framework Laptop + Kubernetes:

{:alpine-advantages
 {:security
  "Musl libc reduces attack surface
   OpenRC is simpler than systemd
   Minimal package base = fewer vulnerabilities"
  
  :performance
  "Smaller memory footprint
   Faster boot times
   Lower resource overhead"
  
  :container-optimized
  "Already proven in container environments
   Docker images based on Alpine
   Kubernetes nodes run containers efficiently"
  
  :maintenance
  "Simple package management with apk
   Clear upgrade path
   Well-documented for containers"}}

Alpine Challenges:

{:alpine-challenges
 {:musl-compatibility
  "Some software expects glibc
   May need glibc compatibility layer
   Limited package ecosystem"
  
  :learning-curve
  "Different from systemd-based systems
   OpenRC service management
   Alpine-specific tools and conventions"}}

Void Linux: The Musl Pioneer

Why Void for Kubernetes:

{:void-advantages
 {:musl-excellence
  "Native musl libc (not glibc variant)
   First-class musl support
   No compatibility layer needed
   True musl-first development"
  
  :performance
  "Static linking support
   Smaller binaries than glibc
   Better security (minimal attack surface)
   Faster compilation times"
  
  :ecosystem
  "XBPS package manager
   Rolling release updates
   s6 init system support
   Excellent documentation"
  
  :development
  "Cross-compilation support
   Embedded system builds
   Container optimization
   CI/CD friendly"}}

Void Challenges:

{:void-challenges
 {:community
  "Smaller community than Alpine
   Less package availability
   Smaller maintenance team"
  
  :learning-curve
  "Different from systemd-based systems
   XBPS package management
   runit init system"}}

Chimera Linux: The Future Builder

Why Chimera for Kubernetes:

{:chimera-advantages
 {:modern-architecture
  "LLVM/Clang toolchain
   FreeBSD userland
   Musl libc core
   Consistent build environment"
  
  :performance
  "LLVM optimizations
   Modern compiler features
   Better code generation
   Faster execution"
  
  :security
  "Musl libc security model
   LLVM sanitizers
   Modern security features
   Minimal attack surface"
  
  :future-proof
  "Modern architecture
   Active development
   Community-driven
   Cutting-edge features"}}

Chimera Challenges:

{:chimera-challenges
 {:maturity
  "Newer project than Alpine/Void
   Less mature ecosystem
   Smaller package selection"
  
  :learning-curve
  "Different from traditional Linux
   LLVM toolchain specifics
   FreeBSD userland differences"
  
  :hardware-support
  "May need more configuration
   Limited driver support
   Community-driven fixes"}}

Artix Linux: The Pragmatist's Choice

Why Artix for Kubernetes:

{:artix-advantages
 {:ecosystem
  "Massive AUR package repository
   Arch Linux compatibility
   Extensive documentation"
  
  :flexibility
  "Choice of init systems (OpenRC, runit, s6)
   Rolling release updates
   Customizable to specific needs"
  
  :hardware-support
  "Excellent Framework laptop support
   Broad hardware compatibility
   Active community support"}}

Artix Challenges:

{:artix-challenges
 {:complexity
  "More moving parts than Alpine
   Rolling release can break things
   Requires more maintenance"
  
  :resource-usage
  "Higher memory footprint
   More packages installed
   Larger attack surface"}}

The Future: SixOS Contribution

Why SixOS is the Ultimate Goal:

{:sixos-vision
 {:nixos-foundation
  "Declarative configuration
   Immutable system state
   Reproducible builds
   Atomic upgrades with rollback"
  
  :s6-supervision
  "Minimal, reliable process management
   Unix philosophy: do one thing well
   Composable components
   Text-based logging"
  
  :infuse-innovation
  "Services as Nix derivations
   Declarative service configuration
   Atomic service activation
   Easy service composition"
  
  :future-proof
  "Built for the next century
   Simple code survives longer
   No systemd complexity
   Clear mental model"}}

The Path to SixOS Contribution:

{:contribution-strategy
 {:phase-1-current
  "Build Alpine + s6 + Kubernetes + Nix cluster
   Master s6 supervision (musl-native)
   Learn Nix package management
   Contribute to Nixpkgs packages
   Document s6 + musl + Kubernetes patterns"
  
  :phase-2-learning
  "Study SixOS source code
   Understand infuse.nix paradigm
   Master s6-rc service management
   Contribute s6 bug fixes and documentation
   Build s6 + musl expertise"
  
  :phase-3-development
  "Implement SixOS features
   Port packages to SixOS
   Improve s6-Nix integration
   Become core SixOS contributor
   Lead musl-focused SixOS development"
  
  :phase-4-leadership
  "Lead SixOS development
   Guide architectural decisions
   Mentor new contributors
   Shape musl-first SixOS vision
   Bridge s6 philosophy with Nix ecosystem"}}

Why s6 is the Perfect Foundation:

  1. Musl-Native Excellence:
    • s6 is written in clean, portable C
    • POSIX-compliant (no glibc extensions)
    • Compiles cleanly against musl libc
    • Used in production (Void Linux musl, Alpine)
  2. Philosophical Alignment:
    • Minimalist design (~200KB total binaries)
    • Unix philosophy: do one thing well
    • Clean, auditable codebase
    • No unnecessary dependencies
  3. Kubernetes-Native Thinking:
    • Process supervision = container supervision
    • Dependency management = pod dependencies
    • Clean lifecycle = container lifecycle
    • Minimal overhead in containers
  4. SixOS Bridge:
    • Same supervision concepts as SixOS
    • s6 expertise transfers directly
    • Musl focus aligns with SixOS goals
    • Production experience for SixOS contribution

The Microbrewery Cluster: Complete Implementation

Cluster Architecture

Hardware Configuration:

Software Stack:

Cost Analysis

Hardware Costs (Better Tier):

Infrastructure Costs:

3-Year TCO:

vs AWS EKS Equivalent:

Migration Path to SixOS

Phase 1: Current Implementation (Alpine + Nix)

Phase 2: SixOS Learning (6-12 months)

Phase 3: SixOS Development (1-2 years)

Phase 4: SixOS Leadership (2+ years)

The Call to Action: Building the Future

The Infrastructure Architect stands at the center of the empty microbrewery, her voice echoing off the concrete walls.

"This is where we begin," she says. "Not with the perfect system, but with the system that works. Alpine Linux gives us a solid foundation. Nix gives us reproducible packages. Kubernetes gives us orchestration. But SixOS—SixOS gives us the future."

"The question isn't whether we should contribute to SixOS. The question is whether we can afford not to. Every day we wait is another day of systemd complexity, another day of vendor lock-in, another day of systems that are harder to understand and maintain."

"The microbrewery failed because it tried to compete globally. Our cluster will succeed because it serves locally. And when SixOS is ready, we'll be ready too—not just as users, but as builders, as contributors, as architects of the future."

Your Next Steps

  1. Build the Alpine Cluster: Start with the microbrewery cluster using Alpine Linux
  2. Learn Nix: Master Nix package management and contribute to Nixpkgs
  3. Study SixOS: Dive deep into SixOS source code and architecture
  4. Contribute: Start with bug fixes and documentation, then move to features
  5. Lead: Become a core contributor and help shape SixOS's future

The transformation is complete: from hops to hopes, from brewing to building, from extraction to contribution.

← Return to Main Index | View Hidden Docs Index | Continue to Chapter xbn: The Eastern Capital → kae3g xbn

Series: technical-implementation

← back to index