Stop Your Local Kubernetes from Eating Your Laptop Alive

You know what sucks? Waiting 10 minutes for CI/CD to tell you that you forgot a comma in your YAML. Or having your shared dev cluster randomly crash during a demo because someone deployed a memory-leaking pod. Local Kubernetes development isn't just nice-to-have anymore - it's the difference between productive development and wanting to throw your laptop out the window.

Reality Check: Local k8s in 2025

Docker Desktop's Kubernetes integration still uses ridiculous amounts of memory and randomly stops working. Minikube will turn your laptop into a space heater. But if you know which tools don't suck, you can actually get a functional cluster running without maxing out your system resources.

The biggest game-changer? Tools like kind that start clusters in 30 seconds instead of the 5-minute VM boot times that made everyone give up. k3s runs in 512MB of RAM, which is a fucking miracle compared to the 4GB monsters we used to deal with.

Meanwhile, MicroK8s gives you a full Kubernetes installation that doesn't require Docker Desktop. k3d wraps k3s in containers for even faster iteration. And Rancher Desktop offers a Docker Desktop alternative that doesn't randomly break your setup.

Why Local Development Beats Shared Clusters

You Stop Waiting for Everything

Traditional workflow: Write code → git push → wait for CI → deploy to shared cluster → something breaks → debug → repeat. Total time wasted per fix: 15-20 minutes.

Local workflow: Write code → see it running locally in under a minute → fix issues immediately. When it works locally, it'll work in production (most of the time).

Stop waiting for CI/CD pipelines that take forever. Stop debugging networking issues that only happen in shared environments. Get your feedback loop down to seconds, not minutes.

Your AWS Bill Won't Kill You

Those shared dev clusters are expensive as hell. Our 5-person team hit $1,200 on EKS last month, and half the time the cluster was just sitting there doing nothing because Jenkins takes 20 minutes to deploy anything. GKE costs and AKS pricing add up fast when you're running multiple environments. Local development eliminates the "oh shit we left the cluster running all weekend" moments that tank your startup's budget.

Works When Everything Else Is Down

Local clusters work when your internet is shit, AWS is having another outage, or you're debugging on a plane. Can't count how many times the "cloud-first" strategy meant sitting around doing nothing because some service was down. GitHub status pages are bookmarked for a reason.

I once spent a weekend debugging why our 'highly available' shared dev cluster kept crashing during demos. Turned out someone deployed a memory leak that only triggered under specific conditions. The cluster would fail spectacularly whenever we tried to show the CEO our progress. Now everything runs locally first - if it crashes on my laptop, it's not going anywhere near production.

Catch the Real Issues Early

Production networking is weird. Storage behaves differently. Resource limits bite you in unexpected ways. Local clusters let you find these issues when you're not under pressure to fix production at 2am. Test your resource limits, ingress configs, and storage patterns before they become production incidents.

System Requirements (What You Actually Need)

Hardware Reality Check

• 8GB RAM: You can run a basic cluster, but Docker will compete with your browser for memory. Expect swapping and thermal throttling.
• 16GB RAM: Sweet spot for local development. Enough for a cluster plus your usual 47 Chrome tabs.
• 32GB RAM: You can run multiple clusters simultaneously without your laptop sounding like a jet engine.

CPU cores matter more than you think: 4 cores minimum or your cluster will take forever to start. 8 cores if you want hot reloading that doesn't make you wait.

SSD is mandatory: Don't even try this with a spinning disk. You'll wait 10 minutes for pods to start and hate your life. Performance comparisons show the dramatic difference storage makes.

Software Prerequisites (And What Will Break)

• Docker Desktop: Required for most tools. Will randomly update and break your setup. Docker Desktop pricing costs $7/month per user if you're not a tiny company.
• kubectl: Get the latest version or weird shit will break. Version skew between kubectl and cluster will ruin your day.
• VPN software: Will conflict with cluster networking. Corporate VPNs especially love to fuck with Docker networking.

Network Reality

Local clusters create their own network namespaces that will conflict with:

• Corporate VPNs (guaranteed networking hell)
• Existing Docker networks
• Port 6443 and 8080 (something is always using these)
• Your company's overly restrictive firewall

If you're on corporate WiFi, prepare for random networking failures that make no sense.

Architecture Overview: How Local Kubernetes Actually Works

Local Kubernetes environments use three main approaches:

VM-Based Solutions (Minikube)

Creates a virtual machine running Linux with a complete Kubernetes installation. Provides the most production-like environment but uses more system resources.

Container-Based Solutions (kind, k3d)

Runs Kubernetes components as containers on your host Docker daemon. Faster startup times and lower resource usage, but some networking limitations.

Native Installations (k3s, MicroK8s)

Installs Kubernetes directly on your host system. Highest performance but more complex to manage and clean up.

The choice between these approaches affects startup time, resource usage, networking capabilities, and how closely the environment matches production. We'll explore each option in detail with specific setup instructions and optimization tips.

Understanding the trade-offs between these approaches is crucial for selecting the right tool for your specific development needs and system constraints.

Here's how to set up local Kubernetes without losing your entire weekend to "Docker daemon not responding" errors. Each tool has its own special ways to break, so pick your poison and prepare for at least one restart cycle.

The official Kubernetes documentation covers most of these tools, but it's optimistically written by people who've never debugged a broken Docker installation at 2am. Here's the reality-tested version that includes what actually breaks and how to fix it.

Option 1: Minikube Setup (For When You Have Time to Debug)

Minikube has the most features but also the most ways to break. Good for learning, terrible when you just want something that works. Prepare for VM driver issues, memory problems, and mysterious networking failures.

Prerequisites Installation

macOS (using Homebrew):

## Install required tools - see [Homebrew formulae](https://formulae.brew.sh/) for latest versions
brew install kubectl minikube docker

## Start Docker Desktop (required for Minikube driver) - check [Docker Desktop for Mac](https://docs.docker.com/desktop/mac/)
open -a Docker

## Verify installations
kubectl version --client
minikube version
docker --version

Linux (Ubuntu/Debian):

## Install kubectl - see [official installation guide](https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/)
curl -LO \"https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl\"
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

## Install Minikube - see [Minikube releases](https://github.com/kubernetes/minikube/releases)
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube

## Install Docker - [Docker Engine on Ubuntu](https://docs.docker.com/engine/install/ubuntu/)
sudo apt-get update
sudo apt-get install docker.io
sudo systemctl start docker
sudo usermod -aG docker $USER

Windows (using Chocolatey):

## Run as Administrator - see [Chocolatey packages](https://chocolatey.org/packages)
choco install kubernetes-cli minikube docker-desktop

## Restart shell and verify - check [Docker Desktop for Windows](https://docs.docker.com/desktop/windows/)
kubectl version --client
minikube version

Minikube Cluster Creation

## This will probably fail the first time
minikube start \
  --driver=docker \
  --memory=4096 \
  --cpus=4 \
  --disk-size=20GB \
  --kubernetes-version=stable

## If you get driver issues (you will):
## 1. Restart Docker Desktop
## 2. Run: docker system prune -f
## 3. Pray to the container gods
## 4. Try again with --driver=none (last resort)

## If it actually starts, verify it's working
kubectl cluster-info
kubectl get nodes

## If nodes show \"NotReady\", wait 2 minutes and check again
## Seriously, just wait. Don't panic and restart everything

Essential Minikube Addons

## Enable useful addons
minikube addons enable dashboard
minikube addons enable metrics-server
minikube addons enable ingress
minikube addons enable registry

## View enabled addons
minikube addons list

## Access the dashboard
minikube dashboard

Option 2: kind Setup (Actually Works Most of the Time)

kind is the most reliable local Kubernetes tool. Starts fast, uses reasonable resources, and doesn't randomly break. If you just want to get shit done, use kind. Check the kind documentation for comprehensive setup guides.

kind Installation

macOS:

## Install using Homebrew
brew install kind kubectl

## Or using Go (if you have Go installed)
go install sigs.k8s.io/kind@latest

Linux:

## Download and install kind
curl -Lo ./kind https://kind.sigs.k8s.io/dl/latest/kind-linux-amd64
chmod +x ./kind
sudo mv ./kind /usr/local/bin/kind

## Install kubectl (if not already installed)
curl -LO \"https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl\"
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

Create kind Cluster

Single-node cluster (fastest startup):

## Create basic cluster
kind create cluster --name dev-cluster

## Verify cluster
kubectl cluster-info --context kind-dev-cluster
kubectl get nodes

Multi-node cluster (production-like):

## Create config file: kind-config.yaml
cat << 'EOF' > kind-config.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
  kubeadmConfigPatches:
  - |
    kind: InitConfiguration
    nodeRegistration:
      kubeletExtraArgs:
        node-labels: \"ingress-ready=true\"
  extraPortMappings:
  - containerPort: 80
    hostPort: 80
    protocol: TCP
  - containerPort: 443
    hostPort: 443
    protocol: TCP
- role: worker
- role: worker
EOF

## Create multi-node cluster
kind create cluster --config kind-config.yaml --name multi-node

kind Ingress Setup

## Install NGINX Ingress Controller
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/kind/deploy.yaml

## Wait for ingress controller to be ready
kubectl wait --namespace ingress-nginx \
  --for=condition=ready pod \
  --selector=app.kubernetes.io/component=controller \
  --timeout=90s

Option 3: k3s Setup (Lightweight Option)

k3s is perfect for resource-constrained environments or when you want the fastest possible Kubernetes experience.

k3s Installation

Linux (native installation):

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

## Copy kubeconfig for kubectl
sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config
sudo chown $USER:$USER ~/.kube/config

## Verify installation
kubectl get nodes
kubectl get pods --all-namespaces

macOS/Windows (using k3d - k3s in Docker):

## Install k3d
brew install k3d  # macOS
## or
wget -q -O - https://raw.githubusercontent.com/k3d-io/k3d/main/install.sh | bash  # Linux

## Create k3s cluster in Docker
k3d cluster create dev-cluster \
  --port 8080:80@loadbalancer \
  --port 8443:443@loadbalancer \
  --agents 2

## Verify cluster
kubectl get nodes

k3s Configuration Optimization

## Create optimized k3s configuration
sudo mkdir -p /etc/rancher/k3s
cat << 'EOF' | sudo tee /etc/rancher/k3s/config.yaml
cluster-init: true
write-kubeconfig-mode: \"0644\"
disable:
  - traefik  # Disable if you want to use different ingress
  - servicelb  # Disable if you want different load balancer
node-label:
  - \"node-type=development\"
EOF

## Restart k3s with new config
sudo systemctl restart k3s

Option 4: Docker Desktop Kubernetes

If you're already using Docker Desktop, enabling Kubernetes is the simplest option.

Enable Kubernetes in Docker Desktop

1. Open Docker Desktop Settings
2. Navigate to Kubernetes tab
3. Check "Enable Kubernetes"
4. Click "Apply & Restart"
5. Wait for Kubernetes to start (green indicator)

Verify Docker Desktop Kubernetes

## Check context
kubectl config current-context
## Should show: docker-desktop

## Verify cluster
kubectl get nodes
kubectl get pods --all-namespaces

Configure Docker Desktop Kubernetes

## Increase resource limits (in Docker Desktop settings)
## Memory: 4GB minimum, 8GB recommended
## CPU: 4 cores minimum

## Install useful tools
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.7.0/aio/deploy/recommended.yaml

## Create dashboard admin user
cat << 'EOF' | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  name: admin-user
  namespace: kubernetes-dashboard
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: admin-user
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: admin-user
  namespace: kubernetes-dashboard
EOF

Post-Installation Verification and Testing

Regardless of which tool you chose, verify your installation with these steps:

Basic Cluster Verification

## Check cluster status
kubectl cluster-info
kubectl get componentstatuses

## Verify nodes are ready
kubectl get nodes -o wide

## Check system pods
kubectl get pods --all-namespaces

## Test pod creation
kubectl run test-pod --image=nginx --restart=Never
kubectl wait --for=condition=Ready pod/test-pod
kubectl delete pod test-pod

Performance Testing

## Create a test deployment
kubectl create deployment nginx-test --image=nginx --replicas=3
kubectl expose deployment nginx-test --port=80 --type=ClusterIP

## Test scaling
kubectl scale deployment nginx-test --replicas=5
kubectl get pods -l app=nginx-test

## Clean up
kubectl delete deployment nginx-test
kubectl delete service nginx-test

Common Configuration Optimizations

Increase resource limits for all tools:

## For Minikube
minikube config set memory 8192
minikube config set cpus 6

## For kind - modify cluster config before creation
## For k3s - edit /etc/rancher/k3s/config.yaml
## For Docker Desktop - use GUI settings

Configure kubectl auto-completion:

## Bash
echo 'source <(kubectl completion bash)' >>~/.bashrc

## Zsh
echo 'source <(kubectl completion zsh)' >>~/.zshrc

## Fish
kubectl completion fish | source

Your local Kubernetes cluster is now ready for development. The next section covers common issues you might encounter and how to troubleshoot them effectively.

You got it running, congratulations. Now here's how to make it actually useful for development instead of a resource-hogging nightmare that crashes whenever you look at it wrong.

Development Workflow Integration

IDE Integration and Debugging

Your IDE might not completely suck at this. Here's the setup that won't drive you insane:

Visual Studio Code with Kubernetes Extension:

// .vscode/settings.json
{
  \"kubernetes.kubectlPath\": \"/usr/local/bin/kubectl\",
  \"kubernetes.namespace\": \"default\",
  \"kubernetes.autoCleanupOnDebugTerminate\": true,
  \"kubernetes.outputFormat\": \"yaml\",
  \"vs-kubernetes\": {
    \"vs-kubernetes.minikube-path\": \"/usr/local/bin/minikube\",
    \"vs-kubernetes.draft-path\": \"\",
    \"vs-kubernetes.helm-path\": \"/usr/local/bin/helm\"
  }
}

IntelliJ IDEA/WebStorm Kubernetes Plugin:
The JetBrains Kubernetes plugin actually works sometimes:

• Pod log streaming (when the connection doesn't timeout)
• YAML editing with validation (catches obvious mistakes)
• Cluster resource browsing (UI is clunky but functional)
• kubectl auto-completion (saves typing the same shit repeatedly)

Hot Reload and Fast Development Cycles

You want to see your changes without waiting 5 minutes for Docker builds and deployments. Here's what might actually work:

Skaffold (When It Doesn't Break):
Skaffold is amazing when it works. When it doesn't (which is often), your hot reload dreams turn into cold restart nightmares. Check the Skaffold troubleshooting guide for when (not if) things break.

## skaffold.yaml - this will work until it doesn't
apiVersion: skaffold/v4beta7
kind: Config
metadata:
  name: local-dev
build:
  artifacts:
  - image: my-app
    docker:
      dockerfile: Dockerfile
    sync:
      manual:
      - src: \"src/**/*.js\"
        dest: /app/src
  local:
    push: false
deploy:
  kubectl:
    manifests:
    - k8s/*.yaml
portForward:
- resourceType: service
  resourceName: my-app
  port: 3000
  localPort: 3000

Start development mode:

## This works great until file watching breaks
skaffold dev --port-forward

## When it inevitably breaks:
## 1. Ctrl+C to stop
## 2. skaffold delete
## 3. docker system prune -f
## 4. Try again and hope for the best

Tilt (Will Make Your Laptop Sound Like a Jet Engine):
Tilt is great for multi-service development but will consume all your CPU cores and make your fans scream. Use with adequate cooling.

Pro tip: Tilt will make your laptop sound like a jet engine taking off. I learned this during a video call when my fans kicked in and drowned out the entire meeting. The client thought someone was mowing the lawn in my office.

## Tiltfile - prepare for thermal throttling
docker_build('my-frontend', './frontend')
docker_build('my-backend', './backend')

k8s_yaml(['frontend/k8s.yaml', 'backend/k8s.yaml'])

## Port forwarding (when it works)
k8s_resource('frontend', port_forwards='3000:3000')
k8s_resource('backend', port_forwards='8080:8080')

## Live update - works great until it doesn't
docker_build(
  'my-frontend',
  './frontend',
  live_update=[
    sync('./frontend/src', '/app/src'),
    run('npm run build', trigger=['./frontend/package.json'])
  ]
)

## Pro tip: Tilt dev mode works until it doesn't,
## then you restart everything and hope it works again

Local Registry Setup

Skip pushing images to Docker Hub every damn time you make a change. Local registries save you from waiting for uploads that inevitably timeout.

Minikube Registry Setup:

## Enable built-in registry addon
minikube addons enable registry

## Configure local docker to use minikube's docker daemon
eval $(minikube docker-env)

## Build and tag images for local use
docker build -t my-app:dev .

## Deploy using local image (no pull)
kubectl run my-app --image=my-app:dev --image-pull-policy=Never

kind with Local Registry:

#!/bin/bash
## setup-kind-registry.sh

## Create registry container unless it already exists
reg_name='kind-registry'
reg_port='5001'
if [ \"$(docker inspect -f '{{.State.Running}}' \"${reg_name}\" 2>/dev/null || true)\" != 'true' ]; then
  docker run \
    -d --restart=always -p \"127.0.0.1:${reg_port}:5000\" --name \"${reg_name}\" \
    registry:2
fi

## Create kind cluster with registry config
cat <<EOF | kind create cluster --config=-
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
containerdConfigPatches:
- |-
  [plugins.\"io.containerd.grpc.v1.cri\".registry.mirrors.\"localhost:${reg_port}\"]
    endpoint = [\"http://${reg_name}:5000\"]
EOF

## Connect registry to cluster network
docker network connect \"kind\" \"${reg_name}\" || true

## Document local registry
kubectl apply -f - <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
  name: local-registry-hosting
  namespace: kube-public
data:
  localRegistryHosting.v1: |\
    host: \"localhost:${reg_port}\"
    help: \"https://kind.sigs.k8s.io/docs/user/local-registry/\"
EOF

Multi-Environment Management

Namespace-Based Environment Separation

Use Kubernetes namespaces to simulate different environments (dev, staging, testing) within your local cluster:

## Create environment namespaces
kubectl create namespace development
kubectl create namespace staging
kubectl create namespace testing

## Set default namespace for current context
kubectl config set-context --current --namespace=development

## Deploy to specific environments
kubectl apply -f app-config.yaml -n development
kubectl apply -f app-config.yaml -n staging

Environment-Specific Configurations:

## base/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
- deployment.yaml
- service.yaml

## overlays/development/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
- ../../base

namePrefix: dev-
namespace: development

patchesStrategicMerge:
- replica-count.yaml

## Apply environment-specific configs
kubectl apply -k overlays/development
kubectl apply -k overlays/staging

Configuration Management Strategies

Environment Variables and ConfigMaps:

## config-dev.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
  namespace: development
data:
  DATABASE_URL: \"postgresql://localhost:5432/devdb\"
  DEBUG_LEVEL: \"debug\"
  FEATURE_FLAGS: \"new-ui=true,beta-api=true\"
  
---
apiVersion: v1
kind: Secret
metadata:
  name: app-secrets
  namespace: development
type: Opaque
stringData:
  API_KEY: \"dev-api-key-12345\"
  JWT_SECRET: \"dev-jwt-secret\"

Helm for Template Management:

## Install Helm - see [Helm installation guide](https://helm.sh/docs/intro/install/)
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

## Create Helm chart for your application - check [Helm chart best practices](https://helm.sh/docs/chart_best_practices/)
helm create my-app

## Customize values for local development
cat << 'EOF' > values-local.yaml
replicaCount: 1
image:
  repository: my-app
  tag: \"dev\"
  pullPolicy: Never

service:
  type: NodePort
  port: 80

ingress:
  enabled: true
  hosts:
    - host: my-app.local
      paths:
        - path: /
          pathType: Prefix

resources:
  limits:
    cpu: 500m
    memory: 512Mi
  requests:
    cpu: 250m
    memory: 256Mi
EOF

## Deploy using local values
helm install my-app ./my-app-chart -f values-local.yaml

Performance Optimization Techniques

Resource Management Best Practices

Right-sizing Resource Requests and Limits:

## Optimized resource configuration for local development
apiVersion: apps/v1
kind: Deployment
metadata:
  name: efficient-app
spec:
  replicas: 1  # Single replica for local dev
  template:
    spec:
      containers:
      - name: app
        image: my-app:dev
        resources:
          requests:
            memory: \"64Mi\"    # Minimal viable allocation
            cpu: \"50m\"        # 0.05 CPU cores
          limits:
            memory: \"256Mi\"   # Prevent memory leaks from crashing cluster
            cpu: \"200m\"       # Allow bursting for development tasks

Cluster Resource Monitoring:

## Install metrics-server for resource monitoring - see [metrics-server docs](https://github.com/kubernetes-sigs/metrics-server)
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

## Monitor resource usage
kubectl top nodes
kubectl top pods --all-namespaces --sort-by=memory

## Set up resource quotas for development namespaces
kubectl apply -f - <<EOF
apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-quota
  namespace: development
spec:
  hard:
    requests.cpu: \"2\"
    requests.memory: 4Gi
    limits.cpu: \"4\"
    limits.memory: 8Gi
    persistentvolumeclaims: \"4\"
EOF

Storage Optimization

Efficient Persistent Volume Management:

## Create storage class for development (fast provisioning)
kubectl apply -f - <<EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-local
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: Immediate
eclaimPolicy: Delete
parameters:
  type: \"fast-ssd\"
EOF

Development Database Strategies:

## Ephemeral database for rapid testing
apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres-dev
spec:
  replicas: 1
  selector:
    matchLabels:
      app: postgres-dev
  template:
    metadata:
      labels:
        app: postgres-dev
    spec:
      containers:
      - name: postgres
        image: postgres:14-alpine
        env:
        - name: POSTGRES_DB
          value: \"devdb\"
        - name: POSTGRES_USER
          value: \"devuser\"
        - name: POSTGRES_PASSWORD
          value: \"devpass\"
        - name: PGDATA
          value: \"/tmp/pgdata\"  # Use tmpfs for speed (non-persistent)
        volumeMounts:
        - name: postgres-storage
          mountPath: /tmp/pgdata
        resources:
          requests:
            memory: \"128Mi\"
            cpu: \"100m\"
          limits:
            memory: \"512Mi\"
            cpu: \"500m\"
      volumes:
      - name: postgres-storage
        emptyDir: {}  # Fast, non-persistent storage

Testing and Quality Assurance

Automated Testing in Local Clusters

Integration Testing Pipeline:

#!/bin/bash
## test-pipeline.sh

set -e

echo \"Starting local cluster testing pipeline...\"

## Ensure cluster is running
kubectl cluster-info

## Deploy test environment
kubectl apply -f test-manifests/

## Wait for deployments to be ready
kubectl wait --for=condition=available --timeout=300s deployment/test-app

## Run integration tests
kubectl run test-runner \
  --image=test-runner:latest \
  --rm -i --restart=Never \
  --command -- /bin/sh -c \"npm run test:integration\"

## Run smoke tests
kubectl port-forward svc/test-app 8080:80 &
PF_PID=$!

sleep 5
## Test your app endpoints (replace with your actual endpoints)
## Example health check commands - replace with your health check endpoint:
## curl -f YOUR_APP_HOST/health || exit 1    # Replace with your health check endpoint
## curl -f YOUR_APP_HOST/api/status || exit 1  # Replace with your status endpoint

kill $PF_PID

## Cleanup test environment
kubectl delete -f test-manifests/

echo \"All tests passed!\"

Load Testing with k6:

// load-test.js
import http from 'k6/http';
import { check, sleep } from 'k6';

export let options = {
  stages: [
    { duration: '30s', target: 10 },  // Ramp up
    { duration: '1m', target: 10 },   // Stay at 10 users
    { duration: '30s', target: 0 },   // Ramp down
  ],
};

export default function() {
  let response = http.get('http://localhost:8080/api/health');
  check(response, {
    'status is 200': (r) => r.status === 200,
    'response time < 500ms': (r) => r.timings.duration < 500,
  });
  sleep(1);
}

Run load tests:

## Forward port to local machine
kubectl port-forward svc/my-app 8080:80 &

## Run load test
k6 run load-test.js

## Monitor cluster during load test
kubectl top pods
kubectl top nodes

This comprehensive setup provides a production-ready local development environment that scales with your needs and optimizes your Kubernetes development workflow. The final section addresses advanced troubleshooting scenarios you might encounter.