Summary:

While in the vCluster and Cilium Gateway API post, we explored how to share Gateway API resources between the Control Plane and the tenant cluster using a simplistic NGINX application; today, we take a step further, and we combine all the parts of the series to demonstrate how Grafana performs OpenID Connect (OIDC) authentication using Keycloak.

Summary: In previous parts of the series, we laid the foundation for creating and using multitenant environments with vCluster and Cilium for networking, observability, and security. In today's post, we introduce a way of sharing Kubernetes resources and custom resource defintions between the Control Plane cluster and the underlying virtual clusters.

Summary:

When I started the vCluster series, I did not expect to keep writing and have already releases a few parts. Having said that, I strongly believe that combining an RKE2 Kubernetes cluster with vCluster and Cilium Multi-Pool IPAM allows us to create powerful multitenant setups for teams building development environments following a GitOps approach. In today's part, we extend the setup to include individual PodCIDRs and LoadBalancer IP ranges for each tenant. This is made possible by Cilium's Multi-Pool IPAM mode, which assigns pod IPs from different pools on a per-namespace basis. We also cover the RKE2 1.35.x cluster bootstrap, touching the cgroup v2 migration required by newer Kubelet versions.

Summary:

In part 2, we introduced the concept of using the Sveltos Event Framework and templating capabilities to dynamically instantiate a Flux HelmRelease based on cluster labels. This blog brings to life the concept of automated Flux HelmReleases using a hub-and-spoke case scenario. We will run a local Kubernetes fleet using KinD, bootstrap Flux, and watch Sveltos automatically generate and deploy Flux HelmReleases based on labels.

Summary:

In part 1 of the series, we explored how Sveltos acts as the main brain for our deployments to a fleet of clusters. However, this is the case when we start with Continuous Deployments (CD) or when we are willing to perform a full migration to a new architecture. The next two posts are dedicated to the collaboration between Flux and Sveltos. Flux remains the core way of deploying applications using the Flux Customer Resource Definitions (CRDs), while Sveltos enters the play when we talk about scalability, automation, and dynamic instantiation of deployments.

Summary:

In parts 1 and 2 of the series, we explored the different node assignment strategies, Cilium L2 Announcements, and the vCluster Platform. Today, we take a step further. We will look at how Cilium CNI running on the underlying Control Plane cluster directly enhances networking for virtual clusters. We will cover traffic isolation, policy enforcement, DNS resolution, and traffic observability.

Summary:

After many discussions at the KubeCon Europe in Amsterdam, I decided to start a new series covering the most commonly seen scenarios and approaches on how Sveltos and different GitOps Controllers can work together. Sveltos is not a replacement for your GitOps Controller. It is a tool to enhance and extend existing capabilities. When we talk about GitOps Controllers, we primarily refer to either ArgoCD or Flux. In the first part of the series, we will demonstrate how Sveltos fits into the Platform engineering space and, more specifically, in the Continuous Deployment (CD) part. We will provide a commonly seen scenario and explore how Sveltos can control all the deployments.

Summary:

In part 1 of the series, we explored some of the recent vCluster Helm chart changes and how we can create the simplest vCluster possible. We also explored how we can assign specific Kubernetes worker nodes to vClusters based on taints, tolerations, and labels. Today, we will walk through the process of setting up Cilium L2 Announcements to make the vCluster available via a LoadBalancer service and then deploy and use the vCluster Platform.

Summary:

It has been a while since my last post on vCluster. After working more closely with the tool, I decided to update the series and show you what changes when it comes to a local setup.

Summary:

To make our lives easier when it comes to manual Sveltos progressive rollout approvals, we will use Botkube and Slack.

Summary:

In a previous post, we looked at using MkDocs and MkDocs Material with the Mike plugin for versioning. This helps in creating a static site on GitHub with GitHub workflows. As MkDocs Material entered maintenance mode on the 6th of November 2025, I decided to migrate to Zensical.

Summary:

KubeCon Amsterdam 2026 highlights.

Summary:

Cloud Native Rejekts Amsterdam 2026 highlights.

Summary:

From one lake to another. From Lake Plastira to Kastoria and Prespes. If you are a nature lover and have a few more days in Greece, I would recommend visiting them.

Summary:

No work travel this time. Only a few days to recharge my batteries in a quiet, yet magnificent place in Greece, Lake Plastira. If you happen to be there at the end of February or the beginning of March, check out the blog for quick and easy hikes and walks.

Summary:

Taking a step further from where we left off in part 1 of the series. We will look at an example that mixes Sveltos rollouts with progressive rollouts, validation, and checks after validation. This gives us tailored control over deployments and updates.

Summary:

Rollouts and progressive rollouts are essential for operation teams and developers. They help deploy new features and updates safely and with less risk. Today, we will explore how Sveltos' Rollout and Progressive Rollout features enable platform teams and engineers to update confidently, without fear! 💪

Summary:

Learn how to use Sveltos to automate the creation of Cluster API (CAPI) clusters on Proxmox using the CAPMOX provider.

Summary:

We continue where we left off with the CAPMOX deployment. In this post, we will go through common issues during deployment and the tools used to troubleshoot and resolve them.

Summary:

Learn how to use the image-builder to craft a base Ubuntu 24.04 image for Kubernetes and how Cluster API (CAPI) helps teams provision, manage, and automate the lifecycle of Kubernetes clusters on a Proxmox server. The guide is suitable for Platform engineers or homelab setups.