Kubernetes has become the de facto platform for running modern cloud-native applications, but operating Kubernetes at scale introduces challenges that extend far beyond deploying a handful of workloads. As organizations grow, the number of applications, teams, environments, and clusters typically grows alongside them. What may begin as a single cluster hosting a few services often evolves into a complex platform spanning multiple environments, regions, and operational boundaries.

Managing deployments consistently across this growing Kubernetes estate can quickly become difficult. Platform teams need a reliable way to deploy applications, maintain configuration consistency, reduce operational risk, and provide visibility across all environments. Traditional deployment approaches that rely on manual processes or tightly coupled CI/CD pipelines often become increasingly difficult to maintain as scale increases.

In a previous article, we explored deploying a highly available Kubernetes cluster using Talos OS, running on Proxmox and automated with Terraform. That setup provided a clean, immutable base for Kubernetes. However, its default networking stack—based on Flannel and kube-proxy—offers limited capabilities when it comes to modern network observability, performance tuning, or multi-interface pods.

In this guide, we’ll walk through installing Cilium as the primary CNI and Multus as a secondary CNI meta-plugin on Talos OS. This combination introduces support for advanced features such as eBPF-powered networking, per-pod visibility, and attaching pods to multiple physical or logical networks.

A highly available Kubernetes cluster in a homelab setup creates opportunities to test distributed systems, automation, and failure recovery under real-world conditions. This guide walks through one approach to building such a cluster using Proxmox for virtualization, Terraform for provisioning, and Talos OS for running the Kubernetes nodes.

This setup provides declarative infrastructure and immutable operating systems, eliminating the need for traditional Linux administration—no SSH, no shell, and no drifting configuration. The result is a consistent, secure, and maintainable cluster architecture suitable for long-term experimentation or light production use.

In our previous post, we introduced the fundamentals of telemetry—covering logs, metrics, traces, and security monitoring. In this follow-up, we’re shifting from theory to practice: what do telemetry stacks actually look like in real-world environments?

The answer depends heavily on infrastructure. In reality, infrastructure decisions come first, and the telemetry stack adapts to support what’s already in place—not the other way around. Observability evolves as a response to growing scale, complexity, and operational maturity.

Running a dedicated virtualization server at home is a practical way to centralize always-on workloads like self-hosted services, infrastructure tooling, or test environments. In this post, we’ll walk through one possible setup using Proxmox VE as the hypervisor, Ansible for configuration management, and Packer to create reusable virtual machine templates.

The configuration is tailored for a single-node homelab using a compact mini-PC, but the principles can be adapted to larger or different environments. All playbooks, templates, and configuration files used in this guide are available in this GitHub repository for reference and reuse.

In modern DevOps workflows, observability plays an important role. Operating distributed systems often depends on telemetry data, including metrics, traces, and logs. Logs are frequently a detailed source of information during troubleshooting. Traditional unstructured log messages, written as free-form text, can make it difficult to extract useful information automatically.

Structured logging organizes log data into a consistent, machine-readable format. For a primer on telemetry systems and observability fundamentals, see the blog post Introduction to Telemetry Systems.