38 posts tagged with "Kubernetes"

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:

KubeCon Amsterdam 2026 highlights.

Summary:

Cloud Native Rejekts Amsterdam 2026 highlights.

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.

Summary:

My KCD Geneva 2025 highlights.

Summary:

An easy way to migrate ArgoCD running on an RKE2 cluster from Ingress NGINX to Cilium Ingress.

Summary:

This is part 3 of the step-by-step guide to creating Kubernetes managed clusters on Azure Cloud using Cluster API (CAPI) and Sveltos! We will give platform teams and seasonal engineers a simple, secure, and flexible way to build Kubernetes clusters.

Summary:

This is part 2 of our series. Here, we show how to use Cluster API (CAPI) to create Azure Kubernetes managed clusters. We’ll use Cilium as our Container Network Interface (CNI) and explore additional features. Follow along to experiment with CAPI and explore the Azure cloud.

Summary:

In this post, we show how to use Cluster API (CAPI) to create Azure Kubernetes managed clusters. We will use Cilium as our Container Network Interface (CNI) and explore additional features. Follow along to experiment with CAPI and explore the Azure cloud.

Introduction​

Welcome to part 4 of the dual-stack series! In parts 1, 2, and 3, we walked through how to set up dual-stack networking on a Proxmox server using our Internet provider. We also showed you how to deploy RKE2 Kubernetes clusters and share both IPv4 and IPv6 services across them. Now, in the final part of the series, we are diving into some of the most commonly used features of Cilium for a home lab setup! Let’s get started!