Platform Engineering на ноутбуке: vind, Sveltos и ArgoCD

13 октября 2026 г.

#argocd#gitops#kind#multicluster#platform-engineering#sveltos

Full article source:

Local Platform Engineering on Your Laptop | vind, Sveltos and ArgoCD

A few weeks ago I finally sat down and built it. This article is about what I built, what broke, and why I think Sveltos is one of the most underrated tools in the Kubernetes ecosystem right now.

Photo by Kari Shea on Unsplash

The Setup

The goal: simulate a real platform engineering setup on a laptop.

  • One management cluster

  • Multiple workload clusters

  • GitOps-driven deployments

  • A way to manage cluster add-ons without losing your mind

Tools Used

  • vind — a tool for creating virtual Kubernetes clusters inside a Kind cluster. Think of it as "Kind inside Kind." It’s lightweight and extremely useful for simulating multi-cluster setups.

  • Sveltos — a Kubernetes add-on controller. More on this below.

  • ArgoCD — for GitOps. Watches a Git repo and applies manifests.

Why vind?

Kind is already great for local Kubernetes, but you’re limited to one cluster per Kind setup (without extra configuration). vind lets you spin up multiple isolated Kubernetes clusters inside a single Kind cluster using virtual nodes.

It’s surprisingly stable and easy to use.

Why Sveltos?

This is where it gets interesting.

Sveltos is an add-on controller for Kubernetes. It lets you define what should be deployed across your clusters using ClusterProfile and ClusterSet resources.

Here’s what makes it powerful:

  • Label-based targeting — you label your clusters, and Sveltos deploys the right add-ons to the right clusters automatically

  • Helm chart support — deploy Helm charts across clusters with a single resource

  • Templating — you can pull values from cluster-specific config maps or secrets and inject them into your Helm values

  • Drift detection — if someone manually changes something in a cluster, Sveltos notices and reverts it

  • Works with ArgoCD — doesn’t fight it. They complement each other.

Let me show you an example ClusterProfile:

apiVersion: config.projectsveltos.io/v1beta1
kind: ClusterProfile
metadata:
  name: nginx-ingress
spec:
  clusterSelector:
    matchLabels:
      env: staging
  helmCharts:
  - repositoryURL: https://kubernetes.github.io/ingress-nginx
    repositoryName: ingress-nginx
    chartName: ingress-nginx/ingress-nginx
    chartVersion: 4.7.1
    releaseName: ingress-nginx
    releaseNamespace: ingress-nginx
    helmChartAction: Install

This deploys nginx ingress to every cluster labeled env: staging. That’s it. No per-cluster Helm commands. No Argo Application per cluster.

The ArgoCD Side

ArgoCD watches a Git repo and syncs manifests. I used it to manage the Sveltos ClusterProfile resources themselves.

So the flow looks like this:

Git repo → ArgoCD → applies ClusterProfiles → Sveltos → deploys add-ons to clusters

This is a clean separation of concerns:

  • ArgoCD handles what should exist

  • Sveltos handles where and how it gets deployed

What Broke

vind networking

Getting pods in virtual clusters to communicate with each other (and with the management cluster) required some manual configuration. The vind documentation is minimal, so I had to dig through GitHub issues.

Sveltos RBAC

When Sveltos tries to deploy to a new cluster, it needs proper RBAC setup. I got burned by this a few times — the controller would silently fail to deploy until I checked the Sveltos logs.

Lesson: always check kubectl logs on the Sveltos controller pod when something doesn’t show up.

ArgoCD sync waves

I had some ordering issues — ArgoCD was trying to apply ClusterProfile resources before the Sveltos CRDs were installed. Sync waves fixed this:

annotations:
  argocd.argoproj.io/sync-wave: "1"

CRDs in wave 0, everything else in wave 1+.

Is This Production-Ready?

No — this is a local simulation. But it’s useful for:

  • Learning and experimentation

  • Testing new tools before adopting them

  • Demoing platform engineering concepts

If you’re evaluating Sveltos for real workloads, their documentation has improved a lot recently and there’s an active Slack community.

Final Thoughts

Sveltos solves a real problem: managing add-ons across many clusters without writing a custom controller or maintaining per-cluster Argo Applications.

It’s not perfect, but it’s genuinely useful and I think it deserves more attention.

The full setup (manifests + README) is on my GitHub — I’ll link it once I’ve cleaned it up a bit.

If you found this useful, consider following me here on Medium. I write about platform engineering, Kubernetes, and the occasional rant about YAML.

Конфигурация стенда

Цель: воспроизвести реальную среду платформенной инженерии (platform engineering) на ноутбуке.

  • Один управляющий кластер (management cluster)

  • Несколько рабочих кластеров (workload clusters)

  • Развёртывание по принципам GitOps

  • Удобное управление дополнениями кластера (cluster add-ons), не сводящее с ума

Используемые инструменты

  • vind — инструмент для создания виртуальных Kubernetes-кластеров внутри Kind-кластера. Можно описать как «Kind внутри Kind»: лёгкий и очень удобный для имитации мультикластерных сред.

  • Sveltos — контроллер дополнений для Kubernetes. Подробнее — ниже.

  • ArgoCD — для GitOps: следит за Git-репозиторием и применяет манифесты.

Зачем vind?

Kind и сам по себе отлично подходит для локального Kubernetes, однако по умолчанию ограничивает вас одним кластером на один экземпляр Kind (без дополнительной настройки). vind позволяет запускать несколько изолированных Kubernetes-кластеров внутри одного Kind-кластера, используя виртуальные узлы (virtual nodes).

Инструмент оказался на удивление стабильным и простым в использовании.

Зачем Sveltos?

Вот здесь начинается самое интересное.

Sveltos — это контроллер дополнений для Kubernetes. С его помощью вы описываете, что должно быть развёрнуто на ваших кластерах, с помощью ресурсов ClusterProfile и ClusterSet.

Чем он силён:

  • Выбор кластеров по меткам — вы расставляете метки на кластерах, и Sveltos автоматически доставляет нужные дополнения в нужные кластеры.

  • Поддержка Helm-чартов — разворачивайте Helm-чарты сразу на нескольких кластерах с помощью одного ресурса.

  • Шаблонизация — значения можно брать из ConfigMap или Secret конкретного кластера и подставлять в параметры Helm.

  • Обнаружение дрейфа (drift detection) — если кто-то вручную изменит что-то в кластере, Sveltos это заметит и вернёт состояние к желаемому.

  • Совместимость с ArgoCD — они не конфликтуют, а дополняют друг друга.

Вот пример ClusterProfile:

apiVersion: config.projectsveltos.io/v1beta1
kind: ClusterProfile
metadata:
  name: nginx-ingress
spec:
  clusterSelector:
    matchLabels:
      env: staging
  helmCharts:
  - repositoryURL: https://kubernetes.github.io/ingress-nginx
    repositoryName: ingress-nginx
    chartName: ingress-nginx/ingress-nginx
    chartVersion: 4.7.1
    releaseName: ingress-nginx
    releaseNamespace: ingress-nginx
    helmChartAction: Install

Этот манифест устанавливает nginx ingress на каждый кластер с меткой env: staging. Всё. Никаких отдельных вызовов Helm для каждого кластера. Никаких Argo Application на кластер.

Роль ArgoCD

ArgoCD следит за Git-репозиторием и синхронизирует манифесты. Я использовал его для управления самими ресурсами ClusterProfile в Sveltos.

Поток выглядит так:

Git-репозиторий → ArgoCD → применяет ClusterProfile → Sveltos → разворачивает дополнения на кластерах

Получается чёткое разделение ответственности:

  • ArgoCD отвечает за то, что должно существовать

  • Sveltos — за то, где и как это разворачивается

Что сломалось

Сеть vind

Чтобы поды в виртуальных кластерах могли общаться друг с другом и с управляющим кластером, потребовалась ручная настройка. Документация по vind крайне скудная, поэтому пришлось рыться в issues на GitHub.

RBAC в Sveltos

Когда Sveltos пытается выполнить развёртывание в новый кластер, ему нужны корректно настроенные права RBAC. Я несколько раз на этом обжёгся: контроллер молча не применял ресурсы, пока я не догадался заглянуть в его логи.

Вывод: если что-то не появляется — сразу проверяйте kubectl logs на поде контроллера Sveltos.

Волны синхронизации ArgoCD (sync waves)

Возникли проблемы с порядком применения ресурсов: ArgoCD пытался создать ресурсы ClusterProfile раньше, чем устанавливались CRD-ресурсы Sveltos. Проблему решили волны синхронизации:

annotations:
  argocd.argoproj.io/sync-wave: "1"

CRD-ресурсы — в волне 0, всё остальное — в волне 1 и выше.

Готово ли это к продакшену?

Нет — это локальная симуляция. Но она полезна для:

  • Обучения и экспериментов

  • Проверки новых инструментов перед их внедрением

  • Демонстрации концепций платформенной инженерии

Если вы оцениваете Sveltos для реальных рабочих нагрузок, документация в последнее время значительно улучшилась, и есть активное сообщество в Slack.

Заключение

Sveltos решает реальную задачу: управление дополнениями на множестве кластеров без написания собственного контроллера и без поддержки отдельных Argo Application на каждый кластер.

Инструмент не идеален, но по-настоящему полезен — и, на мой взгляд, заслуживает куда большего внимания.

Полная конфигурация (манифесты и README) выложена у меня на GitHub — дам ссылку, как только немного приберусь в репозитории.

Если материал оказался полезным — подписывайтесь на меня здесь, на Medium. Я пишу о платформенной инженерии, Kubernetes и время от времени даю волю мыслям о YAML.

Похожее

© 2026 meganuke