Building Your First Cloud-Native Kubernetes Cluster: A Beginner’s Journey with Talos Linux and Cilium

This content originally appeared on DEV Community and was authored by Chiqo Rifky Saputra

Transform your single VPS into a production-ready Kubernetes powerhouse

Who This Guide Is For: This is a starter guide specifically designed for learners with one VPS or cloud server for educational purposes. If you have multiple physical machines in a homelab setup, you’ll need different configurations and networking approaches.

Inspiration & Credits

Before we dive into this exciting journey, I want to give proper credit to Mischa van den Burg for his inspiring videos that motivated this comprehensive guide:

“The Kubernetes Homelab That Prints Job Offers – 2025” – His insights about how Kubernetes creates incredible learning opportunities and reignites passion for cloud-native computing.

“How To Learn Kubernetes in 2025” – Perfect for those still deciding whether it’s worth learning Kubernetes despite its complexity. If you have the passion to learn cloud-native computing, this is a great starting point!

Why This Matters: As Mischa demonstrates, building real-world Kubernetes projects isn’t just about learning—it’s about creating opportunities that can transform your career in DevOps and cloud engineering. Even with the complexity, the passion for cloud-native technology makes the journey worthwhile.

Introduction: Welcome to the Cloud-Native Revolution

Imagine you’re building a smart city. Traditional infrastructure is like having individual houses scattered everywhere—each with its own utilities, security systems, and maintenance crews. Cloud-native architecture, powered by Kubernetes, is like creating a modern apartment complex where everything is centralized, automated, and efficiently managed.

Today, we’re going to build your first Kubernetes cluster using two incredible technologies:

• Talos Linux: Think of it as the ultimate apartment building manager—secure, automated, and never sleeps
• Cilium: The smart networking system that connects everything with lightning speed

By the end of this guide, you’ll have a production-ready Kubernetes cluster running on a single VPS that can scale and adapt to your needs.

Why Kubernetes? Understanding the “Why” Before the “How”

The Restaurant Analogy

Imagine you own a restaurant. In the old days (traditional deployment), you had:

• One chef doing everything
• If the chef gets sick, the restaurant closes
• During rush hour, customers wait forever
• Scaling means hiring more chefs and buying more kitchens

With Kubernetes, your restaurant becomes a smart food court:

• Multiple specialized stations (containers) handle different tasks
• Automatic scaling: More pizza stations appear during lunch rush
• Self-healing: If one station breaks, another takes over instantly
• Resource sharing: All stations share the same utilities efficiently

Kubernetes Benefits

Feature	Benefit	Impact
Auto-Scaling	Automatically adjusts resources	Efficiency
Self-Healing	Restarts failed containers	Fast Recovery
Portability	Run anywhere consistently	Cost-Effective
Fast Deployment	Deploy in seconds, not hours	Speed
Declarative	Describe desired state	Reliability
Service Discovery	Apps find each other automatically	Connectivity

Why Kubernetes is Essential for Modern Applications

1. Scalability: Your app can grow from 10 to 10,000 users seamlessly
2. Reliability: If something breaks, Kubernetes fixes it automatically
3. Efficiency: Maximum resource utilization means lower costs
4. Portability: Run anywhere—cloud, on-premises, or hybrid
5. Developer Productivity: Focus on code, not infrastructure

Enter Talos Linux: The Security-First Operating System

The Fortress Analogy

Traditional Linux servers are like medieval castles with many doors, windows, and secret passages. Each entry point is a potential security risk. Talos Linux is like a modern bank vault:

• Single API entrance: Only one way in, heavily guarded
• No SSH backdoors: No secret passages for attackers
• Immutable: The vault structure can’t be modified from inside
• Self-updating: Automatically upgrades its security systems

Traditional Linux vs Talos Linux

Aspect	Traditional Linux	Talos Linux	Winner
Access Method	SSH Access	API Only	Talos
Shell Access	Full Shell	No Shell	Talos
System State	Mutable	Immutable	Talos
Updates	Manual Updates	Auto Updates	Talos
Attack Surface	Large	Minimal	Talos
Debugging	Easy	API-based	Depends

Talos Linux Advantages

Zero Attack Surface: No shell, no SSH, no unnecessary services
API-Driven: Everything managed through secure APIs
Immutable: OS can’t be tampered with at runtime
Kubernetes-Native: Built specifically for container workloads
Minimal Resources: Tiny footprint means more resources for your apps

Cilium: The Neural Network of Your Cluster

The Smart City Traffic System Analogy

Traditional networking (kube-proxy) is like having traffic lights at every intersection—functional but slow. Cilium is like having an AI traffic management system:

• eBPF Technology: Like having sensors everywhere that make instant decisions
• No Bottlenecks: Traffic flows smoothly without stopping at every light
• Security Built-in: Automatically blocks suspicious vehicles
• Observability: Real-time monitoring of all traffic patterns

Cilium eBPF Superpowers

Performance	Security	Observability
Kernel Speed	L3/L4/L7 Security	Deep Observability
Zero-Copy Networking	Network Policies	Real-time Metrics
Load Balancing	DDoS Protection	Traffic Visualization
High Throughput	Encryption	Network Debugging
Low Latency	Identity-based Security	Performance Analytics

Why Cilium Over Traditional CNI

Performance: eBPF runs in kernel space—blazingly fast
Security: Network policies enforced at the kernel level
Observability: Deep insights into network traffic
Load Balancing: Replaces kube-proxy with better performance

Our Architecture: The Blueprint

We’re building a single-node Kubernetes cluster that acts as both control plane and worker. Think of it as a studio apartment that’s perfectly organized—compact but fully functional.

Architecture Stack

Layer	Component	Features
Infrastructure	VPS (Single Node)	Your cloud server foundation
Operating System	Talos Linux (Immutable)	• API-driven management • Zero attack surface • Automatic updates
Orchestration	Kubernetes Control Plane + Worker	• etcd (cluster database) • API Server (cluster brain) • Scheduler (workload placement) • Kubelet (node agent)
Networking	Cilium CNI (eBPF)	• Pod-to-pod communication • Load balancing • Network security policies • Observability with Hubble
Applications	Your Workloads	• Web services • Databases • APIs • Microservices

Prerequisites: What You’ll Need

Before we start building, make sure you have:

Checklist:

• A VPS (DigitalOcean, Linode, Vultr, etc.) with at least 2GB RAM (this is for starter, you can upgrade later)
• talosctl installed on your local machine
• kubectl for Kubernetes management
• helm for package management
• Basic terminal knowledge (don’t worry, we’ll guide you through everything!)

Installing Required Tools

# Install talosctl (macOS)
brew install siderolabs/tap/talosctl

# Install kubectl
brew install kubectl

# Install helm
brew install helm

Step-by-Step Setup Guide

Phase 0: Preparing Your Configuration

First, let’s create our Talos configuration patch. This is like creating the blueprint for our smart building:

Create patch.yaml:

# Talos Linux Configuration Patch for Single Node VPS with Cilium CNI
# This patch configures Talos for a single-node setup with custom networking and storage

# Machine-specific configuration
machine:
  install:
    disk: /dev/vda # Primary disk for VPS installation
  network:
    interfaces:
      - interface: eth0 # Primary network interface on VPS

# Cluster configuration
cluster:
  # Allow workloads to be scheduled on control plane (single node setup)
  allowSchedulingOnControlPlanes: true # Required for single node - control plane acts as worker too

  network:
    cni:
      name: none # Disable default CNI - Cilium will provide networking
  proxy:
    disabled: true # Disable kube-proxy - Cilium will handle load balancing with eBPF

Phase 1: Talos Linux Installation

Step 0: Preparing Your VPS for Talos Installation

Before generating the configuration, you need to ensure your VPS can boot Talos Linux. You have several options:

Installation Methods:

Option 1: ISO Mounting (Most Common)

• Download the Talos Linux ISO from:
  • GitHub releases (official releases)
  • Talos Linux Factory (custom images for specific platforms)
• Mount it through your VPS provider’s control panel
• Boot from the mounted ISO

Option 2: Netboot (Provider-Specific)

• Some providers like Onidel VPS offer netboot options
• Check your VPS control panel for “Custom OS” or “Netboot” features
• Configure it to boot Talos Linux directly from the network

Option 3: Siderolabs Booter (Advanced)

• Use the siderolabs/booter tool for PXE boot
• Perfect for automated deployments or multiple machines
• Requires network boot capability on your VPS

# Example: Using siderolabs booter (if your VPS supports PXE)
docker run --rm --network host \
  ghcr.io/siderolabs/booter:v0.1.0

Important: Make sure your VPS successfully boots into the Talos Linux installation environment before proceeding to the next step. You should see the Talos maintenance mode interface.

Step 1: Generate Talos Configuration

# Replace YOUR_VPS_IP with your actual VPS IP address
talosctl gen config talos-cilium-single-node-cluster https://YOUR_VPS_IP:6443 \
  --config-patch @patch.yaml \
  --output-dir ./out

What’s happening here?

• We’re creating configuration files for our cluster
• The patch file customizes the setup for our single-node scenario
• All generated files go into the ./out directory

Step 2: Apply Configuration to Your VPS

# This installs Talos Linux on your VPS
talosctl apply -f ./out/controlplane.yaml -n YOUR_VPS_IP -i

Wait Time: Your VPS will reboot and install Talos Linux. This takes about 5-10 minutes. Grab a coffee!

Step 3: Bootstrap the Kubernetes Cluster

# This starts the Kubernetes control plane
talosctl bootstrap -n YOUR_VPS_IP -e YOUR_VPS_IP --talosconfig ./out/talosconfig

What’s bootstrapping?
Think of it as turning on the power in your smart building. All the systems come online and start talking to each other.

Step 4: Get Your Kubernetes Access Key

# This downloads the key to access your cluster
talosctl -n YOUR_VPS_IP -e YOUR_VPS_IP --talosconfig ./out/talosconfig kubeconfig ./out/kubeconfig

# Set up your local environment
export KUBECONFIG=./out/kubeconfig

Step 5: Verify Kubernetes is Running

kubectl get nodes

You should see something like:

NAME                STATUS     ROLES           AGE   VERSION
talos-xxx-xxx       NotReady   control-plane   1m    v1.28.x

Don’t panic about “NotReady”! This is normal—we haven’t installed networking yet.

Phase 2: Installing Cilium CNI

Now we’re going to install the nervous system of our cluster—the networking layer.

Step 1: Add Cilium Repository

helm repo add cilium https://helm.cilium.io/
helm repo update

Step 2: Install Cilium with Optimized Settings

helm install cilium cilium/cilium \
    --version 1.18.1 \
    --namespace kube-system \
    --set ipam.mode=kubernetes \
    --set securityContext.capabilities.ciliumAgent="{CHOWN,KILL,NET_ADMIN,NET_RAW,IPC_LOCK,SYS_ADMIN,SYS_RESOURCE,DAC_OVERRIDE,FOWNER,SETGID,SETUID}" \
    --set securityContext.capabilities.cleanCiliumState="{NET_ADMIN,SYS_ADMIN,SYS_RESOURCE}" \
    --set cgroup.autoMount.enabled=false \
    --set cgroup.hostRoot=/sys/fs/cgroup \
    --set operator.replicas=1 \
    --set kubeProxyReplacement=true \
    --set hubble.relay.enabled=true \
    --set hubble.ui.enabled=true \
    --set k8sServiceHost=YOUR_VPS_IP \
    --set k8sServicePort=6443

Understanding the Cilium Configuration Parameters

Let me break down what each of these parameters does and why they’re crucial for our Talos + Cilium setup:

Basic Installation Settings

--version 1.18.1                    # Specific Cilium version for stability
--namespace kube-system              # Install in the system namespace

IP Address Management (IPAM)

--set ipam.mode=kubernetes           # Let Kubernetes handle IP allocation

Why this matters: Instead of Cilium managing IPs directly, we let Kubernetes do it. Think of it like letting the hotel concierge assign room numbers instead of guests picking their own!

Security Capabilities

--set securityContext.capabilities.ciliumAgent="{CHOWN,KILL,NET_ADMIN,NET_RAW,IPC_LOCK,SYS_ADMIN,SYS_RESOURCE,DAC_OVERRIDE,FOWNER,SETGID,SETUID}"
--set securityContext.capabilities.cleanCiliumState="{NET_ADMIN,SYS_ADMIN,SYS_RESOURCE}"

What these do:

• NET_ADMIN: Manage network interfaces and routing
• SYS_ADMIN: System administration tasks
• NET_RAW: Create raw sockets for network operations
• CHOWN/FOWNER: Change file ownership
• KILL: Terminate processes
• IPC_LOCK: Lock memory pages

Why so many permissions? Cilium needs deep system access to manage networking at the kernel level. It’s like giving a master key to the building superintendent!

Control Groups (cgroups) Configuration

--set cgroup.autoMount.enabled=false # Don't auto-mount cgroups
--set cgroup.hostRoot=/sys/fs/cgroup  # Use host's cgroup filesystem

Talos-specific: Since Talos manages the system differently than traditional Linux, we need to tell Cilium exactly where to find the cgroup filesystem.

Single-Node Optimizations

--set operator.replicas=1            # Only one operator instance

Why only 1? In a multi-node cluster, you’d want multiple operators for high availability. But with just one node, multiple operators would just waste resources!

Kube-Proxy Replacement

--set kubeProxyReplacement=true      # Replace kube-proxy entirely

Game changer: This is where Cilium shines! Instead of using the traditional kube-proxy, Cilium handles all service load balancing with eBPF – much faster and more efficient!

Observability with Hubble

--set hubble.relay.enabled=true      # Enable Hubble relay
--set hubble.ui.enabled=true         # Enable Hubble web UI

What’s Hubble? Think of it as a security camera system for your network traffic. You can see exactly what’s talking to what, when, and why!

API Server Connection

--set k8sServiceHost=YOUR_VPS_IP     # Your VPS public IP
--set k8sServicePort=6443            # Kubernetes API port

Critical for single-node: Tells Cilium how to reach the Kubernetes API server from outside the cluster.

Pro Tip: Parameter Customization

Key Parameters You Might Want to Adjust

Remember: Each parameter serves a specific purpose in making Cilium work seamlessly with Talos Linux. Don’t randomly change them unless you understand the implications!

What do all these settings do?

• kubeProxyReplacement=true: Cilium replaces kube-proxy for better performance

• hubble.ui.enabled=true: Gives us a beautiful network monitoring dashboard

• operator.replicas=1: Optimized for single-node deployment

Step 3: Verify Everything is Working

# Check if Cilium pods are running
kubectl get pods -n kube-system -l k8s-app=cilium

# Check node status (should now be Ready!)
kubectl get nodes

# Check Cilium status
cilium status --wait

Success looks like:

NAME                STATUS   ROLES           AGE   VERSION
talos-xxx-xxx       Ready    control-plane   5m    v1.28.x

Congratulations! What You’ve Built

You’ve just created a production-ready Kubernetes cluster with:

Achievement Unlocked!

Component	Achievement	Status
Security	Talos Linux with zero attack surface	Complete
Performance	Cilium with eBPF networking	Complete
Efficiency	Single-node control plane + worker	Complete
Architecture	Cloud-native ready infrastructure	Complete
Observability	Built-in monitoring with Hubble	Complete
Ready for	Production workloads and scaling	Ready!

Understanding What You Built

The Magic Behind the Scenes

1. Talos Linux is running as your OS, managing everything through APIs
2. Kubernetes is orchestrating containers and managing resources
3. Cilium is handling all networking with eBPF superpowers
4. Your cluster can now run any containerized application

Your Journey Ahead

Category	Next Steps	Popular Tools
Web Applications	Deploy websites and APIs	React, Vue, Node.js
Databases	Persistent data storage	PostgreSQL, MongoDB, Redis
Monitoring	Observability stack	Prometheus, Grafana, Alerting
CI/CD Pipeline	Automated deployments	GitLab, GitHub Actions, ArgoCD
Ingress Controllers	External access	Traefik, NGINX, Istio
Security Hardening	Advanced security	Network policies, RBAC, Vault
Scaling	Handle more traffic	HPA, VPA, Cluster Autoscaler

Wisdom Gained

Lesson	Key Insight	Impact
1⃣ Approachability	Kubernetes isn’t scary with the right guidance	Confidence boost
2⃣ Security First	Talos makes security simple and automatic	Peace of mind
3⃣ Performance	eBPF networking is truly game-changing	Speed & efficiency
4⃣ Efficiency	Single-node clusters are surprisingly powerful	Resource optimization
5⃣ Accessibility	Modern infrastructure is accessible to everyone	Democratized tech

Join the Community

You’re now part of the cloud-native community! Here are some great resources:

Community Resources

Platform	Resource	What You’ll Find
Talos Linux	talos.dev	Official docs, guides, API reference
Cilium	cilium.io	eBPF tutorials, networking guides
Kubernetes	kubernetes.io	Complete K8s documentation
CNCF	cncf.io	Cloud-native landscape & projects
Discord/Slack	Community channels	Real-time help & discussions
Documentation	Official docs	Step-by-step tutorials
YouTube	Video content	Conferences, demos, deep-dives

Final Thoughts

Building your first Kubernetes cluster is like learning to drive—it seems overwhelming at first, but once you understand the basics, a whole world of possibilities opens up. You’ve just built something that many enterprises pay thousands of dollars for, using open-source tools and a single VPS.

“The future of infrastructure is declarative, automated, and secure. You’re now equipped with the knowledge to be part of that future.”

Happy clustering!

Did this guide help you build your first Kubernetes cluster? Share your experience in the comments below, and don’t forget to follow for more cloud-native tutorials!

Tags: #Kubernetes #TalosLinux #Cilium #CloudNative #DevOps #Containers #eBPF #Infrastructure #Tutorial #Beginner

This content originally appeared on DEV Community and was authored by Chiqo Rifky Saputra