Lightweight Kubernetes Alternatives - For Developers Who Want Sleep

So you want Kubernetes but don't want to hate your life?

Look, full Kubernetes is like buying a Formula 1 car to drive to Starbucks. Sure, it's impressive, but you'll spend every weekend debugging why the engine won't start instead of actually getting coffee. I've watched senior devs quit rather than deal with etcd corruption at 3am one more time.

There's a middle ground - lightweight Kubernetes that doesn't make you want to quit engineering. K3s, K0s, MicroK8s - these actually start when you run the install script. No, really.

The Full Kubernetes Problem (What You Already Know)

Regular Kubernetes eats resources like a teenager eats pizza - constantly and way more than you budgeted for:

• You need like 6 VMs minimum for "high availability" (which goes down anyway)
• Control plane wants 8GB+ of RAM before you even deploy Hello World
• etcd decides to corrupt itself exclusively on Sunday mornings
• Every Kubernetes upgrade breaks that one addon your entire app depends on
• AWS EKS costs more than your developer salaries and you still get paged when it breaks

Either you hire someone to get woken up at 3am when etcd shits itself, or your senior devs hate their lives because they're debugging CNI plugins instead of building features customers want. Most teams aren't Netflix, but somehow we all think we need Netflix-level infrastructure complexity.

What Lightweight Kubernetes Actually Offers

Lightweight K8s distributions strip out the complexity while keeping the core functionality:

What you keep:

• Standard Kubernetes APIs (your kubectl commands work)
• Pod scheduling and auto-scaling capabilities
• Service discovery and networking
• ConfigMaps, Secrets, and persistent storage
• Helm chart compatibility
• Most of the ecosystem tools you want

What gets simplified:

• Single binary installation (no complex setup procedures)
• Embedded etcd or alternative storage (no separate etcd cluster)
• Reduced memory footprint (2-4GB total vs 8GB+ for full K8s)
• Built-in load balancing and ingress
• Simplified networking (fewer CNI plugin headaches)

What you lose:

• Enterprise features that sound important but you'll never use
• The exciting 3am pages about control plane failures
• Bragging rights at meetups about how complex your infrastructure is

Resource Usage Reality Check

Running these in production for a couple years now. Here's what actually happens:

Full Kubernetes - the resource vampire:
Control plane eats like 6GB before you deploy a single pod. Each worker node wants another few gigs. Three-node cluster? You're looking at 15GB minimum just so kubectl works. And etcd will somehow fill up your entire disk.

K3s - actually reasonable:
Server node uses like 1.5GB when it's actually doing work. Agents use maybe 500MB-1GB. Three-node cluster? Around 4GB total and SQLite doesn't eat your disk.

K0s - security-focused:
Controller around 1.2GB, workers stay lean at 500MB. Three-node cluster runs fine on under 3GB total. Uses embedded etcd which is more predictable than SQLite when things break.

MicroK8s - Ubuntu's approach:
Single node wants 2GB+ because snap packages are bloated. Each additional node adds another gig or so. Budget around 4-6GB for three nodes plus snap overhead.

The Cost Reality

AWS EKS - the money pit:
Control plane costs $70/month for black boxes you can't SSH into when they break. Three t3.medium workers? Like $90 more. Load balancers destroy your AWS bill because you need multiple ALBs since AWS networking is garbage. You're looking at $250+ per month before you deploy a single container.

Self-managed K3s on cloud:
Three t3.small instances cost maybe $45/month. One ALB for $18/month. EBS storage for $15/month. Total: around $80/month. Best part? When shit breaks at 2am, you can actually SSH in and fix it.

On-premises lightweight K8s:
Three servers you bought on eBay? Free compute except for power. Infrastructure cost: basically nothing. Downside? When a disk dies on Sunday, guess who's driving to the office? But at least you can physically kick the servers when they misbehave.

I've seen teams cut their AWS bills in half switching from EKS to self-managed K3s. Turns out debugging a simple system is easier than debugging a complex one. Who would have thought?

The Real-World Adoption Numbers

K3s (Rancher/SUSE):

• Wide adoption across organizations worldwide
• CNCF Sandbox project since 2020
• Used by organizations like Volkswagen and others for edge computing
• Latest stable releases track current Kubernetes versions

MicroK8s (Canonical):

• Growing adoption across enterprises
• Default Kubernetes on Ubuntu systems
• Enterprise deployments in telecom and finance
• Tracks upstream Kubernetes releases closely

K0s (Mirantis):

• Growing adoption in enterprise edge deployments
• CNCF-certified since 2021
• Part of Mirantis Kubernetes Engine (MKE) platform
• Stays current with Kubernetes releases

Who Should Consider Lightweight Kubernetes

You should definitely use this if:

• You've got 5-50 engineers who want to ship code, not debug infrastructure
• You're running 3-20 services that need to not crash when one gets restarted
• You're doing edge computing or IoT where full K8s would eat all your resources
• You need dev/test environments that don't cost more than production
• Your team knows enough K8s to be dangerous but not enough to debug etcd
• You want to escape Docker Compose hell but not enter Kubernetes hell

Probably overkill (stick with simpler solutions):

• Single application deployments
• Teams under 5 people with simple web apps
• Pure batch processing workloads
• Organizations with zero container orchestration experience

You actually need full Kubernetes if:

• You're running 100+ microservices and already have the therapy budget to match
• You need multi-tenant isolation because you don't trust your users (smart)
• You've got dedicated platform engineers who enjoy being paged at night
• Compliance requires specific Kubernetes flavors (my condolences)

The Migration Path That Actually Works

From Docker Compose → Lightweight K8s:

• Your container images work exactly the same (thank god)
• Kompose converts your docker-compose.yml files, though the output is usually garbage you'll need to clean up
• Add features like auto-restart and scaling when you're not panicking about basic deployment
• Timeline: 2-4 weeks if you're lucky, 2-4 months if you're realistic

From Full Kubernetes → Lightweight K8s:

• Your existing YAML manifests work unchanged
• Remove complex operators and custom resources you don't need
• Simplify networking and storage configurations
• Timeline: 1-3 weeks for migration

To Full Kubernetes (when you outgrow lightweight):

• All your apps and configurations remain compatible
• Add control plane complexity gradually
• Timeline: Plan for 6-8 weeks minimum

Start simple and only add complexity when you're being paid enough to deal with it. If you outgrow K3s, you can migrate to full Kubernetes without rewriting everything.

Enough theory. Let's figure out which lightweight option will cause you the least suffering.

The theory sounds great, but where do lightweight Kubernetes distributions actually work in practice? Here are real deployments that show when to use each option.

K3s in Production: The Success Stories

Real-World Migration Pattern - SaaS Companies Moving from EKS

I keep seeing the same thing: companies that thought EKS would solve their problems, now spending more on infrastructure than their actual product. The upgrades that break shit, the networking that nobody understands, and senior devs who spend more time on kubectl than actual coding.

The usual disasters:

• EKS upgrades that break your ingress and nobody knows why
• Load balancer costs that somehow hit $300/month just for ping checks
• Junior devs afraid to deploy because the last time they tried, the entire staging environment died
• Senior devs who've become accidental infrastructure experts instead of building features

What actually worked: Ditched EKS, moved to K3s on three t3.medium instances behind one ALB. Same apps, same containers, but suddenly deployments don't require a prayer circle.

The lesson: "Enterprise-grade" infrastructure is useless if it's too complicated for your team to deploy to. They went from spending entire days debugging etcd to maybe an hour a week restarting pods. That's what you call a win.

Chick-fil-A's Restaurant Setup

Chick-fil-A stuck K3s in every restaurant, which sounds insane until you realize they needed something that works when the teenager managing the store doesn't know what kubectl is.

How they do it: Single K3s node per location with local storage, syncing to corporate when the internet isn't complete garbage (which is often in restaurants). They built for the assumption that connectivity will be terrible.

The reality they don't mention: Managing thousands of edge clusters is a nightmare that requires insane automation. When K3s dies, customers can't buy chicken, which means angry customers calling corporate, which means someone's getting fired.

K0s for Enterprise Edge: Security-First Deployments

Enterprise Financial Services Pattern

Large financial institutions are increasingly using K0s for edge deployments in branch offices, processing centers, and ATM networks for customer-facing applications and compliance monitoring systems.

Security requirements:

• FIPS 140-2 compliance for cryptographic modules
• Air-gapped deployments (no internet connectivity)
• Centralized security policy management
• Audit trails for regulatory compliance

Why K0s fits: Built-in security features, minimal attack surface, and Mirantis enterprise support for financial services compliance requirements.

Deployment model: 3-node K0s clusters per major region (high availability), single-node K0s for smaller branches, all managed through Mirantis Kubernetes Engine.

Typical results: Improved uptime across distributed deployments, easier regulatory compliance, and reduced operational overhead for branch office IT support.

Manufacturing and Industrial IoT Pattern

Industrial organizations use K0s to orchestrate containers running IoT applications in manufacturing facilities. Factory floors often have dedicated lightweight clusters managing sensors and automated systems.

Industrial requirements:

• Real-time processing (sub-10ms latencies)
• 24/7/365 uptime (factory downtime costs $50,000/hour)
• Harsh environmental conditions
• Integration with legacy industrial systems

Technical architecture: K0s clusters on ruggedized edge hardware with local storage, processing sensor data locally and syncing aggregated results to cloud systems.

Key insight: K0s resource efficiency allows full Kubernetes orchestration on industrial PCs with limited RAM, often replacing custom automation software.

MicroK8s for Development: The Ubuntu Advantage

Ubuntu Development and CI/CD Pattern

Canonical and Ubuntu-focused organizations use MicroK8s extensively for development workflows and CI/CD pipelines. The snap ecosystem integration makes it natural for Ubuntu-centric environments.

Development workflow:

• Developers push code to GitHub
• CI system spins up MicroK8s clusters on-demand
• Packages are built in isolated container environments
• Tested across Ubuntu LTS versions automatically
• Published to snap store if all tests pass

Why MicroK8s fits: Native Ubuntu integration, snap package ecosystem, ability to quickly create/destroy clusters, and built-in addon management for testing dependencies.

Typical scale: Multiple concurrent MicroK8s clusters during peak build times, with significant container image throughput for automated testing workflows.

Telecom and Network Function Testing

Telecom companies use lightweight Kubernetes for network function virtualization testing. They need to simulate complex network topologies and test containerized network functions before production deployment.

Testing requirements:

• Multiple Kubernetes versions simultaneously
• Complex networking (multiple interfaces, VLANs)
• GPU acceleration for network processing
• Rapid cluster provisioning for parallel testing

Architecture: MicroK8s clusters on bare-metal servers with GPU support, using Canonical's MAAS for automated provisioning and testing orchestration.

K3d and Kind: Development Environment Excellence

E-commerce Development Pattern

Large-scale platforms like e-commerce systems often use K3d for local development. Developers need to run multiple service versions locally to test changes across different configurations without conflicts.

Developer experience:

• k3d cluster create shopify-dev spins up full platform in 60 seconds
• Hot code reloading via volume mounts
• Multiple platform versions side-by-side
• Full integration with production services

Technical setup: K3d clusters with custom networking to route external dependencies (payments, shipping) through development proxies, enabling full-stack local testing.

Large-Scale Testing Pattern

Major tech companies use kind extensively for testing Kubernetes operators and custom resources before deploying to production infrastructure.

Testing pipeline:

• Every pull request triggers kind cluster creation
• Operators deployed and tested against multiple Kubernetes versions
• Chaos engineering tests run automatically
• Clusters destroyed after testing completes

Typical scale: Hundreds or thousands of kind clusters created/destroyed daily for CI/CD testing against multiple Kubernetes versions simultaneously.

Edge Computing: Where Lightweight K8s Dominates

Retail Edge Computing Pattern

Retail chains are migrating from traditional POS systems to K3s-orchestrated containers running on edge hardware in stores, following the same patterns as Chick-fil-A's restaurant deployment.

Business requirements:

• Offline operation during network outages
• Real-time inventory updates
• Payment processing integration
• Centralized management for updates

Technical architecture:

• Single-node K3s per store on Intel NUC devices
• Local SQLite for transaction storage
• Sync to cloud systems when connectivity available
• Remote management through Rancher

Typical benefits: Significant reduction in POS system downtime, faster feature deployments, and substantial savings in operational support costs.

Smart City and IoT Pattern

Smart city projects use K3s to orchestrate traffic management systems and IoT infrastructure, processing real-time sensor data for traffic optimization and emergency response.

Infrastructure constraints:

• Outdoor hardware installations
• Limited power and cooling
• Cellular connectivity (variable bandwidth)
• Real-time processing requirements

Deployment model: Single-node K3s running on fanless edge computers, processing video streams locally and communicating with central traffic control systems.

Impact: Measurable improvements in traffic flow and emergency response times, all running on lightweight Kubernetes infrastructure that operates reliably.

Migration Stories: From Full Kubernetes to Lightweight

Startup Migration Pattern - The Kubernetes Reality Check

Small fintech and SaaS companies often get trapped in "production-ready" EKS setups that become operational nightmares. Monthly AWS costs can hit thousands while senior engineers waste time on infrastructure instead of features.

The breaking points:

• EKS upgrade killed payment processing on Black Friday (someone got fired)
• Istio service mesh that nobody understood and everyone was afraid to touch
• Monitoring stack that used more CPU than the app it was monitoring
• Storage that randomly failed during business hours because AWS
• Deployments that required sacrificing a goat and hoping for the best

What they actually did:

• Deleted Istio with extreme prejudice (nobody missed it)
• Killed the monitoring stack that was monitoring itself more than the app
• Bought t3.large instances and installed K3s with one command
• Burned the Helm charts and went back to kubectl apply like civilized people
• Gave up on containerized databases and just used RDS

The results: AWS bill dropped by more than half, deployments actually worked, and people stopped quitting because of the on-call rotation. Migration took like 3 weeks because they kept finding more stuff to delete.

The truth: "Cloud native" is usually marketing speak for "needlessly complex." Most companies don't need service mesh - they need their app to start when they deploy it.

The Decision Framework Based on Real Usage

Choose K3s when:

• Production workloads at edge locations
• IoT and resource-constrained environments
• You need proven stability and large community
• ARM64/Raspberry Pi deployments
• Teams familiar with Rancher ecosystem

Choose K0s when:

• Enterprise security requirements
• FIPS compliance needed
• Mirantis support is valuable
• Minimal resource footprint is critical
• Building commercial edge products

Choose MicroK8s when:

• Ubuntu-centric environment
• Development and testing primary use case
• Canonical support ecosystem
• Local development on workstations
• Learning Kubernetes concepts

Choose K3d/kind when:

• Pure development environments
• CI/CD testing pipelines
• Quick experimentation
• Multiple cluster testing
• Kubernetes development work

The pattern is clear: lightweight Kubernetes distributions excel where operational simplicity matters more than feature completeness, and where resource constraints make full Kubernetes impractical.

These real-world examples probably sparked some questions about practical implementation. Let's address the most common concerns and misconceptions teams have when considering the switch.

Enough theory. Here's how to actually get this working without losing your mind, plus the stuff that will go wrong (because it always does).

Quick Start: K3s in 10 Minutes

Scenario: You want to test K3s on a single server to see how it works.

## Single command install (Ubuntu/Debian)
## See: https://docs.k3s.io/quick-start
curl -sfL https://get.k3s.io | sh -

## Check if it's running
sudo k3s kubectl get nodes

## Get the kubeconfig for your local kubectl
sudo cat /etc/rancher/k3s/k3s.yaml > ~/.kube/config
sed -i 's/127.0.0.1/YOUR_SERVER_IP/g' ~/.kube/config

## Deploy a test application
kubectl create deployment nginx --image=nginx
kubectl expose deployment nginx --port=80 --type=LoadBalancer

What just happened: You installed a complete Kubernetes cluster and somehow it actually worked on the first try. If that didn't work, welcome to the debugging club - check the next section.

Production K3s Setup: High Availability

Scenario: You need a production-ready K3s cluster with high availability.

Architecture: 3 server nodes + 2 agent nodes across different availability zones.

Step 1: First Server Node

## On server1 - the first control plane node
curl -sfL https://get.k3s.io | sh -s - server \
    --cluster-init \
    --tls-san=k3s-cluster.yourdomain.com \
    --datastore-endpoint=\"mysql://k3s:password@tcp(database.yourdomain.com:3306)/k3s\"

## Get the node token for other servers
sudo cat /var/lib/rancher/k3s/server/node-token

Step 2: Additional Server Nodes

## On server2 and server3
curl -sfL https://get.k3s.io | sh -s - server \
    --server https://server1:6443 \
    --token NODE_TOKEN_FROM_STEP1 \
    --tls-san=k3s-cluster.yourdomain.com \
    --datastore-endpoint=\"mysql://k3s:password@tcp(database.yourdomain.com:3306)/k3s\"

Step 3: Worker Nodes

## On agent1 and agent2
curl -sfL https://get.k3s.io | K3S_URL=https://k3s-cluster.yourdomain.com:6443 \
    K3S_TOKEN=NODE_TOKEN_FROM_STEP1 sh -

Step 4: Load Balancer Configuration

## nginx.conf for load balancing K3s API
upstream k3s_servers {
    server server1:6443 max_fails=3 fail_timeout=10s;
    server server2:6443 max_fails=3 fail_timeout=10s;
    server server3:6443 max_fails=3 fail_timeout=10s;
}

server {
    listen 6443;
    proxy_pass k3s_servers;
    proxy_timeout 10s;
    proxy_connect_timeout 5s;
}

Production tips:

• Use external database (MySQL/PostgreSQL) because SQLite will eventually piss you off
• Configure TLS certificates or everything will scream about security
• Set up monitoring because you need to know when things die
• Use Ansible or Terraform because doing this shit manually gets old fast

K0s Production Deployment

Scenario: Enterprise deployment with security requirements and FIPS compliance.

Step 1: Generate K0s Configuration

## k0s-config.yaml
apiVersion: k0s.k0sproject.io/v1beta1
kind: ClusterConfig
metadata:
  name: k0s-cluster
spec:
  api:
    address: 192.168.1.100
    port: 6443
    k0sApiPort: 9443
  controllerManager:
    extraArgs:
      enable-hostpath-provisioner: \"true\"
  scheduler:
    extraArgs:
      bind-address: \"0.0.0.0\"
  storage:
    type: etcd
    etcd:
      peerAddress: 192.168.1.100
  network:
    kubeProxy:
      mode: \"ipvs\"
    podCIDR: \"10.244.0.0/16\"
    serviceCIDR: \"10.96.0.0/12\"
  podSecurityPolicy:
    defaultPolicy: \"restricted\"

Step 2: Install K0s Controllers

## Download and install k0s
## See: https://docs.k0sproject.io/stable/install/
curl -sSLf https://get.k0s.sh | sudo sh

## Install first controller
sudo k0s install controller --config k0s-config.yaml
sudo k0s start

## Generate token for additional controllers
sudo k0s token create --role=controller

## On additional controller nodes
sudo k0s install controller --token CONTROLLER_TOKEN_HERE --config k0s-config.yaml
sudo k0s start

Step 3: Add Worker Nodes

## Generate worker token from controller
sudo k0s token create --role=worker

## On worker nodes
sudo k0s install worker --token WORKER_TOKEN_HERE
sudo k0s start

Step 4: Enable FIPS Mode (Enterprise Security)

## Enable FIPS on all nodes
## See: https://docs.k0sproject.io/stable/configuration/
sudo k0s config create --enable-fips

## Restart services
sudo k0s restart

MicroK8s for Development Teams

Scenario: Development team wants local Kubernetes that matches production.

Step 1: Installation

## Ubuntu/Debian
## See: https://microk8s.io/docs/getting-started
sudo snap install microk8s --classic

## Add user to microk8s group
sudo usermod -a -G microk8s $USER
newgrp microk8s

## Enable essential addons
## See: https://microk8s.io/docs/addons
microk8s enable dns dashboard registry

Step 2: Development Workflow Integration

## Set up kubectl alias
sudo snap alias microk8s.kubectl kubectl

## Configure local registry for development
microk8s enable registry

## Build and push local images
docker build -t localhost:32000/myapp:latest .
docker push localhost:32000/myapp:latest

## Deploy with local image
kubectl create deployment myapp --image=localhost:32000/myapp:latest

Step 3: Multiple Environment Setup

## Create separate MicroK8s instances for different environments
sudo snap install microk8s --name=microk8s-dev --classic
sudo snap install microk8s --name=microk8s-staging --classic

## Switch between environments
alias kubectl-dev='microk8s-dev.kubectl'
alias kubectl-staging='microk8s-staging.kubectl'

Storage Configuration: Getting Persistent Volumes Right

The most common pain point in lightweight K8s is storage. Here's how to configure it properly.

K3s Local Storage

## local-storage-class.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: local-path
provisioner: rancher.io/local-path
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Delete

## example-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-data
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: local-path
  resources:
    requests:
      storage: 10Gi

Cloud Storage Integration

## AWS EBS CSI Driver for K3s
## See: https://github.com/kubernetes-sigs/aws-ebs-csi-driver
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-ebs-csi-driver/master/deploy/kubernetes/overlays/stable/ecr/kustomization.yaml

## Create EBS storage class
kubectl apply -f - <<EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-gp3
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  encrypted: \"true\"
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
EOF

Networking: Making Services Accessible

Default networking in lightweight K8s is simpler, but you need to understand how to expose services properly.

K3s Built-in Load Balancer

## nginx-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx-lb
spec:
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

What happens: K3s automatically assigns an external IP using its built-in Klipper load balancer. No cloud provider configuration needed.

Ingress Configuration

## ingress-example.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    traefik.ingress.kubernetes.io/rule-type: \"PathPrefixStrip\"
spec:
  rules:
  - host: myapp.local
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx-lb
            port:
              number: 80

Note: K3s includes Traefik ingress controller by default. No additional installation required.

Monitoring and Observability

Essential monitoring for lightweight K8s that doesn't require a dedicated platform team.

Prometheus + Grafana Stack

## Add Prometheus Helm repository
## See: https://github.com/prometheus-community/helm-charts
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

## Install with resource limits appropriate for small clusters
helm install prometheus prometheus-community/kube-prometheus-stack \
  --set prometheus.prometheusSpec.resources.requests.memory=\"1Gi\" \
  --set prometheus.prometheusSpec.resources.limits.memory=\"2Gi\" \
  --set grafana.resources.requests.memory=\"200Mi\" \
  --set grafana.resources.limits.memory=\"400Mi\"

Simple Logging with Loki

## Install Loki stack
## See: https://grafana.com/oss/loki/
helm repo add grafana https://grafana.github.io/helm-charts
helm install loki grafana/loki-stack \
  --set grafana.enabled=true \
  --set prometheus.enabled=true \
  --set prometheus.alertmanager.persistentVolume.enabled=false

CI/CD Integration

How to integrate lightweight K8s with your existing CI/CD pipeline.

GitHub Actions Example

## .github/workflows/deploy.yml
name: Deploy to K3s
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    
    - name: Build Docker image
      run: |
        docker build -t myapp:${{ github.sha }} .
        docker tag myapp:${{ github.sha }} myapp:latest
    
    - name: Setup kubectl
      uses: azure/setup-kubectl@v3
    
    - name: Configure K3s access
      run: |
        mkdir -p ~/.kube
        echo \"${{ secrets.KUBE_CONFIG }}\" | base64 -d > ~/.kube/config
    
    - name: Deploy to cluster
      run: |
        kubectl set image deployment/myapp myapp=myapp:${{ github.sha }}
        kubectl rollout status deployment/myapp

GitLab CI Example

## .gitlab-ci.yml
stages:
  - build
  - deploy

variables:
  DOCKER_DRIVER: overlay2
  KUBECONFIG: /tmp/kubeconfig

deploy_production:
  stage: deploy
  image: bitnami/kubectl:latest
  before_script:
    - echo \"$KUBE_CONFIG_BASE64\" | base64 -d > $KUBECONFIG
  script:
    - kubectl apply -f k8s/
    - kubectl rollout restart deployment/myapp
  only:
    - main

Troubleshooting Common Issues

The problems you'll actually encounter and how to fix them (learned from 3am debugging sessions).

The good news: Lightweight Kubernetes breaks in less creative ways than full K8s. When shit goes wrong (and it will), it's usually out of memory, storage won't mount, or the network is fucked. No more "etcd split-brain at 3am" panic attacks.

Pod Stuck in Pending

## The 3am debugging workflow (coffee required)
kubectl describe pod <pod-name>  # Start here or you're wasting time
kubectl get events --sort-by=.metadata.creationTimestamp

## It's usually one of these:
## 1. Out of resources (classic)
kubectl top nodes  # If this hangs, metrics-server is dead
kubectl describe node <node-name>  # Look for angry red warnings

## 2. Storage is being weird
kubectl get pv,pvc
kubectl describe pvc <pvc-name>  # \"ProvisioningFailed\" = storage is fucked
## Pro tip: local-path needs the directory to exist (I learned this the hard way)

## 3. You typo'd something
kubectl logs <pod-name> -c <container-name>
## \"ImagePullBackOff\" = you fucked up the image name

Service Not Accessible

## Debug services
kubectl get svc,endpoints
kubectl describe service <service-name>

## Test connectivity from within cluster
kubectl run debug --image=busybox --rm -it -- sh
## Inside the pod: wget -O- nginx-lb

## Check ingress
kubectl get ingress
kubectl describe ingress <ingress-name>

Node Resource Issues

## Check if nodes are angry
kubectl describe nodes

## Nuclear option when everything is broken
kubectl delete pods --field-selector=status.phase=Succeeded
kubectl delete pods --field-selector=status.phase=Failed
docker system prune -a  # This takes forever but might save your ass

Migration Checklist

Step-by-step process for migrating existing applications to lightweight K8s.

Pre-Migration Assessment

• Inventory all current services and their resource requirements
• Identify data that needs persistent storage
• Document external dependencies and integrations
• Plan DNS and network routing changes
• Set up backup and rollback procedures

Migration Steps

1. Set up lightweight K8s cluster (1-2 days if nothing breaks)
2. Migrate stateless services first (1-2 weeks because storage is a nightmare)
3. Configure persistent storage (2-3 days of pure suffering)
4. Migrate stateful services (1-2 weeks plus therapy)
5. Update DNS and load balancing (1 day of praying)
6. Monitor and optimize (forever)

Post-Migration Validation

• All services are running and healthy
• External integrations work correctly
• Performance meets requirements
• Backup and disaster recovery tested
• Team training completed

Don't be a hero. Start with a single-node K3s cluster and make sure you can deploy without breaking everything. Once you stop panicking every time you run kubectl, then maybe add more nodes.

That's it. You know enough to get started and fail in less spectacular ways. The resources section has links for when you hit the weird edge cases (and you will).