AI Intermediate: Infrastructure & Agentic SystemsDay 8 of 30 · Week 2: Kubernetes Foundation for MLOps
Course outline▾

Week 2 · Kubernetes Foundation for MLOps

  1. Day 8K3d and Lightweight Kubernetes — Running Multi-Node Clusters on 16 GB of RAM
  2. Day 9Kubernetes Core for Machine Learning: Pods, Deployments, and Headless Services
  3. Day 10Persistent Volumes (PV/PVC): Managing Heavy Model Weights and Vector Stores
  4. Day 11StatefulSets for Vector Databases: Deploying Milvus or Qdrant in Kubernetes
  5. Day 12Auto-Scaling AI Inference: Using Horizontal Pod Autoscalers (HPA) for Spiky API Traffic
  6. Day 13Helm Charts: Packaging, Versioning, and Updating AI Deployments
  7. Day 14Week 2 Capstone: Deploying a Highly Available Local AI Application on K3d

Week 3 · High-Performance Networking & Security Mesh

  1. Day 15AI Network Bottlenecks: Transitioning from iptables to eBPF
  2. Day 16Cilium & eBPF: Sub-Millisecond Routing for Heavy AI Microservices
  3. Day 17Service Mesh 101: Installing Istio over Your Local Cluster
  4. Day 18Envoy Proxy as an AI Gateway: Load Balancing and Terminating LLM Prompts
  5. Day 19Zero-Trust mTLS: Encrypting Traffic Between Autonomous Agents
  6. Day 20API Rate Limiting & Egress Control: Preventing Agents from Exfiltrating Data
  7. Day 21Distributed Tracing: Debugging Agent Workflows with Jaeger and OpenTelemetry

Week 4 · Enterprise Agents & CI/CD Workflows

  1. Day 22Introduction to MLOps: Bridging AI Development with Continuous Integration
  2. Day 23GitOps with ArgoCD: Automated, Self-Healing AI Deployments
  3. Day 24Building Ephemeral AI Sandboxes: Secure Execution Environments for Agent Code
  4. Day 25Multi-Agent Orchestration Frameworks: Exploring Mastra, LangGraph, and CrewAI
  5. Day 26Tool-Calling in Production: Connecting Agents Securely to Internal Databases
  6. Day 27MLOps Guardrails: Evaluating Agents and Preventing Hallucinations in Real-Time
  7. Day 28Continuous Training Pipelines: Connecting Data Ingestion to Automated Model Retraining
  8. Day 29Managing Technical Debt and Infrastructure Drift in Enterprise AI
  9. Day 30The AI-Native Platform: Scaling from a Sandbox Environment to Global Cloud Architecture
Open the course page →

Day 8: K3d and Lightweight Kubernetes — Running Multi-Node Clusters on 16 GB of RAM

2026-11-14 · 7 min read

Week 2 moves the stack onto Kubernetes. The first obstacle is the cluster itself. Standard distributions such as kubeadm or OpenShift can take 4 to 8 GB of RAM for the control plane before a single workload runs, which is most of a 16 GB laptop.

K3s and k3d

K3s is a CNCF-certified lightweight Kubernetes. It removes legacy cloud-provider drivers, in-tree storage plugins and alpha feature gates, and for a single server it can use an embedded SQLite datastore instead of etcd. It keeps full Kubernetes API compatibility, so the manifests you write here work on bigger clusters later.

k3d runs K3s inside Docker containers: one container per node.

CONTROL-PLANE MEMORY BEFORE ANY WORKLOAD (APPROXIMATE)kubeadm / OpenShift class4 to 8 GBK3s (k3d)roughly 0.5 to 1 GBK3s is CNCF-certified Kubernetes with the legacy parts removed:· no legacy cloud-provider drivers· no in-tree storage plugins, no alpha feature gates· SQLite as the datastore for a single server (instead of etcd)· same Kubernetes API, so your manifests carry over
FIG 1 · A full Kubernetes control plane can consume several GB of RAM before it runs a workload. K3s is far lighter. Figures are approximate, so check yours with docker stats.
K3D: KUBERNETES NODES AS DOCKER CONTAINERS ON A 16 GB HOSTDocker on the hostk3d-proxyload balancer :80 :443k3d-server-0API server, SQLitek3d-agent-0kubelet, containerdk3d-agent-1kubelet, containerdmodel-serving podsvector DB podskubectl get nodes -o wide → 1 server + 2 agents, Readyall inside one machine
FIG 2 · k3d runs each Kubernetes node as a Docker container, so a multi-node cluster fits on a laptop. A proxy container exposes ports 80 and 443.

Describing the cluster

A config file makes the cluster reproducible.

# k3d-config.yaml
apiVersion: k3d.io/v1alpha5
kind: Simple
metadata:
  name: ai-cluster
servers: 1
agents: 2
image: rancher/k3s:v1.30.0-k3s1
ports:
  - port: 80:80
    nodeFilters: [loadbalancer]
  - port: 443:443
    nodeFilters: [loadbalancer]
options:
  k3s:
    extraArgs:
      - arg: --disable=traefik          # we install our own ingress later (Envoy or Cilium)
        nodeFilters: [server:0]
      - arg: --disable=servicelb
        nodeFilters: [server:0]
  kubeconfig:
    updateDefaultKubeconfig: true
    switchCurrentContext: true
ONE FILE DESCRIBES THE CLUSTERapiVersion: k3d.io/v1alpha5kind: Simplemetadata: { name: ai-cluster }servers: 1 agents: 2image: rancher/k3s:v1.30.0-k3s1ports: 80:80 and 443:443 → loadbalancerk3s extraArgs: --disable=traefik, --disable=servicelbpin the imagereproducible versionservers + agentsreal multi-node schedulingdisable traefik, servicelbinstall your own Envoy or Ciliumk3d cluster create --config k3d-config.yamlup in about half a minute, removed with: k3d cluster delete ai-cluster
FIG 3 · A declarative config pins the K3s version, sets one server and two agents, publishes ports through the proxy and disables the bundled ingress and service load balancer.
k3d cluster create --config k3d-config.yaml
kubectl get nodes -o wide
docker stats --no-stream --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.MemPerc}}"

The first command creates one server and two agents, and the cluster is usually ready in well under a minute. The second shows the three nodes as Ready, and the third shows how much memory each node container uses, so you can budget the rest of the machine for workloads. Remove everything with k3d cluster delete ai-cluster.

Disabling Traefik and the service load balancer is a choice for this series, because later lessons install Envoy and Cilium. If you just want an ingress working quickly, leave Traefik enabled, as the Week 2 capstone does. Also note that a plain k3d cluster does not expose a GPU to its nodes. GPU workloads need extra setup, so on a laptop it is normal to use CPU-friendly engines here.

Why real nodes matter

Because k3d creates actual multiple nodes, you get true multi-node scheduling on one machine: taints, tolerations and anti-affinity all behave as they would in production. You can keep stateful vector databases and stateless inference pods on separate nodes, so a noisy model pod cannot starve the database.

TRUE MULTI-NODE SCHEDULING ON ONE LAPTOPagent-0agent-1qdrant-0statefulqdrant-1statefulvllm-0statelessvllm-1stateless✗Taints, tolerations and anti-affinity keep stateful and stateless pods apart.A noisy inference pod cannot starve the vector database on the same node.
FIG 4 · Because k3d creates real nodes, you can practise taints, tolerations and anti-affinity locally, so stateful vector databases and stateless inference pods stay on separate nodes.

A cluster that boots in seconds and disappears with one command makes experiments cheap, which is exactly what you want while learning.

Run it yourself

This is the exact example from the video. This really creates a K3d cluster from the file and deletes it again. I used host port 18080 to avoid clashes on my laptop.

apiVersion: k3d.io/v1alpha5
kind: Simple
metadata:
  name: ai-demo
servers: 1
agents: 1
image: rancher/k3s:v1.35.5-k3s1
ports:
  - port: 18080:80
    nodeFilters: [loadbalancer]
options:
  k3s:
    extraArgs:
      - arg: --disable=traefik
        nodeFilters: [server:0]

Run it:

k3d cluster create --config k3d-config.yaml

Output I got while recording the video:

ai-demo 1/1 1/1 true
k3d-ai-demo-agent-0 Ready
k3d-ai-demo-server-0 Ready
containers: 3
80/tcp -> 0.0.0.0:18080
traefik pods: 0

Coming Up Next

Day 9: Kubernetes core for machine learning: pods, Deployments and headless services.

#Kubernetes #K3d #K3s #DevOps #CloudNative #PlatformEngineering #LocalDev #MLOps