Sveltosの概要

Sveltosは、複数のKubernetesクラスタ（マルチクラスタ）にまたがるアドオンやアプリケーションのデプロイと管理を簡素化するオープンソースのコントローラです (Sveltosによるシンプルで柔軟なKubernetesクラスタ運用 #kubernetes - Qiita)。典型的には一つの管理クラスタ（マネジメントクラスタ）上で動作し、そこから他の管理対象クラスタに対して設定やアドオンを集中管理します (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。ユーザはYAMLによって各クラスタ群の望ましい状態（desired state）を宣言し、Sveltosがそれを各クラスタに反映・維持することで、一貫性のある構成管理と自動化を実現します (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community) (Sveltosによるシンプルで柔軟なKubernetesクラスタ運用 #kubernetes - Qiita)。

Sveltosはさまざまな形式のマニフェストに対応しており、Helmチャート・生のYAML/JSON・Kustomize・Carvel ytt・Jsonnetなど、多様な方法で定義されたリソースを取り扱うことができます (Sveltosによるシンプルで柔軟なKubernetesクラスタ運用 #kubernetes - Qiita)。これにより既存の様々なツールやリポジトリ形式を活かして、マルチクラスタ環境全体に対してアドオンの配布・更新を行えます。また、マルチクラスタ運用で課題となる各クラスタごとの設定差異（バージョン違いやネットワーク設定など）にも柔軟に対応できるよう、テンプレート機能によりリソース定義内で変数を用いてクラスタ固有情報を埋め込むことが可能です (projectsveltos · GitHub)。Sveltosは「適切なラベルを付けて新しいクラスタを追加すれば、自動的に望ましい状態に持っていく」というモットーのもと設計されており (projectsveltos · GitHub)、複雑なマルチクラスタの運用負荷を大幅に軽減します。

Sveltosのアーキテクチャと内部構造

管理クラスタ上で動作するSveltosは、複数のKubernetesコントローラ（Custom Controller）から構成されます (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。管理対象となる各クラスタは、管理クラスタ内に専用のカスタムリソース（CR）として登録され、例えばSveltosClusterというCRにクラスタ名や接続情報、ラベルなどが紐づけられます (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。Sveltosはこのクラスタリソースに付与されたラベルを基に、対象クラスタを選択（セレクション）して設定を適用します (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。具体的には、後述するClusterProfileというCRで「env: production」などのラベル選択を指定すると、そのラベルを持つ全クラスタ群に対し定義されたアドオンを適用する、といった動作です (Sveltosによるシンプルで柔軟なKubernetesクラスタ運用 #kubernetes - Qiita)。このようにラベル駆動で構成適用範囲を動的に管理できるため、新しいクラスタが追加された場合でも適切なラベル付けさえ行えば自動で必要なリソースが展開されます (projectsveltos · GitHub)。

管理クラスタと各クラスタ間の通信には、Sveltos独自のエージェント（sveltos-agent）が用いられます。クラスタ登録時、Sveltosは管理対象クラスタ内にServiceAccountや必要なRBACを作成し、その認証情報を管理クラスタにSecretとして保存します (Sveltos: Argo CD and Flux CD are not the only GitOps Tools for Kubernetes | by Artem Lajko | ITNEXT)。さらに対象クラスタ上にSveltosエージェントPodを自動デプロイします (Sveltos: Argo CD and Flux CD are not the only GitOps Tools for Kubernetes | by Artem Lajko | ITNEXT)。このエージェントは管理クラスタのコントローラと連携し、指示されたリソース（マニフェストやHelmリリース）をクラスタ内に適用する役割を担います。またエージェントは継続的にクラスタの状態を監視し、ドリフト検知（実際の状態が期待する状態から逸れていないか）を行います (Sveltosによるシンプルで柔軟なKubernetesクラスタ運用 #kubernetes - Qiita)。もし手動変更や予期せぬ事態で構成にずれが生じた場合、エージェントが管理クラスタ側にイベントを報告し、必要に応じてSveltosがそのクラスタに再同期（再適用）を行って望ましい状態に戻します (Sveltos: Argo CD and Flux CD are not the only GitOps Tools for Kubernetes | by Artem Lajko | ITNEXT)。このようなエージェントベースの同期モデルにより、従来のツールが全クラスタをポーリングして状態チェックするのに比べ、Sveltosは必要時にのみ同期を行うため大規模環境でも効率的でリソース消費が抑えられるという利点があります (Sveltos: Argo CD and Flux CD are not the only GitOps Tools for Kubernetes | by Artem Lajko | ITNEXT)。なお、Sveltosにはエージェントを各クラスタに配置しない動作モード（全エージェントを管理クラスタ内で動かし、リモートの各クラスタAPIを操作する方式）も用意されています (Sveltos: Argo CD and Flux CD are not the only GitOps Tools for Kubernetes | by Artem Lajko | ITNEXT)。これはKamajiという分散コントロールプレーンの手法に着想を得たもので、ネットワーク制約上エージェントPodを動かせない場合や管理クラスタへの集約運用をしたい場合に選択できます。

Sveltosが利用する主な**カスタムリソース（CRD）**は以下の通りです：

ClusterProfile（クラスタプロファイル）: どのクラスタ群にどのリソース（アドオンや設定）を適用するかを定義する中核のCRDです (Sveltosによるシンプルで柔軟なKubernetesクラスタ運用 #kubernetes - Qiita)。ClusterProfileにはクラスタ選択子（clusterSelector）としてラベル条件を指定し、その条件に合致するクラスタすべてに対して適用すべき内容（Helmチャートやマニフェスト群）を記述します。ClusterProfileは管理クラスタ内の任意のネームスペースに作成可能で、プラットフォーム管理者が全クラスタ共通のポリシーや標準アドオンを配布する用途に向きます (Sveltosによるシンプルで柔軟なKubernetesクラスタ運用 #kubernetes - Qiita)。
Profile: ClusterProfileに似ていますが、Profileは特定のネームスペース内に限定され、そのネームスペースに対応付けられたクラスタ（例：マルチテナント環境で各チーム固有のクラスタ）にのみ設定を適用するためのCRDです (Sveltosによるシンプルで柔軟なKubernetesクラスタ運用 #kubernetes - Qiita)。これによりテナントごとの独立した管理が可能となり、他のチームやテナントに影響を与えずにアドオン適用を制御できます (Sveltosによるシンプルで柔軟なKubernetesクラスタ運用 #kubernetes - Qiita)。簡潔に言えば、ClusterProfileがグローバルな設定適用用であるのに対し、Profileは局所的（テナント単位）の設定適用用です (Sveltosによるシンプルで柔軟なKubernetesクラスタ運用 #kubernetes - Qiita)。
Classifier（クラスタ分類）: 各クラスタの実行時の状態に基づいて、自動的にクラスタへラベル付与するためのCRDです。たとえばClassifierに「Kubernetesのメジャーバージョンがv1.24系ならラベルversion: v1.24を付ける」と定義しておけば、クラスタがバージョンアップした際にSveltosが自動で対応するラベルを書き換えます (Conf42: Manage Kubernetes addons for multiple cluster using runtime state)。この仕組みにより、クラスタがアップグレードされた場合でも管理者が手動でラベル付与変更することなく、ラベルに基づくClusterProfile適用対象が自動更新されます (Conf42: Manage Kubernetes addons for multiple cluster using runtime state)。結果として、クラスタの状態変化（例：K8sバージョンアップや特定のアプリケーション有無）に応じて適用するアドオンセットを自動で切り替える、といった動的管理が可能です (Conf42: Manage Kubernetes addons for multiple cluster using runtime state)。
EventSource / EventTrigger（イベントソース・イベントトリガー）: Sveltosのイベント駆動フレームワークを構成するCRDです。EventSourceは監視すべきイベントの種類を定義し（例：特定のKubernetesリソースの生成/削除、または外部メッセージングシステム上のトピック）を指定します。一方EventTriggerは、どのクラスタ群で（clusterSelector使用）、どのEventSourceに対して、どのアクションを実行するかを定義します (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community) (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。アクション部分では、イベント種別に応じて「リソースを作成 or 削除」などのロジックを記述でき、場合によってはLua言語で柔軟なスクリプトを書くことも可能です (projectsveltos · GitHub)。この仕組みにより、後述するように「外部システムでユーザがログインしたイベントを受け取ったら、自動で該当クラスタに名前空間を作成する」等のイベントドリブンな制御が実現できます (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community) (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。
その他のCRD: 上記の他、SveltosにはHealthCheck（各クラスタ内のカスタムヘルスチェック定義とモニタリング）や、クラスタのスナップショット/ロールバック用のCRD（後述）などがあります。必要に応じてこうしたCRDを用いることで、クラスタの状態監視や設定の巻き戻し等、高度な運用管理機能を利用できます。

Sveltos自体はKubernetesネイティブに実装されており、これらCRDとコントローラによって拡張されたコントロールプレーンとして振る舞います。したがってkubectlやKubernetes API経由でSveltosの各種リソースを操作でき、他のKubernetesツール（FluxやArgo CDなど）と連携させることも可能です (Sveltos: Argo CD and Flux CD are not the only GitOps Tools for Kubernetes | by Artem Lajko | ITNEXT)。実際、SveltosはGitOpsスタイルの運用を補完すべくFlux CDとの統合もサポートしており、FluxがGitリポジトリからClusterProfile/Profileを自動同期し、Sveltosがそれを解釈してクラスタ群へ展開するという構成も取れます (Sveltos: Argo CD and Flux CD are not the only GitOps Tools for Kubernetes | by Artem Lajko | ITNEXT)。このようにSveltosは既存エコシステムと協調しながら、マルチクラスタ管理に必要な要素を包括的に提供するよう設計されています。

Sveltosの主要機能

Sveltosの特徴的な機能を以下に整理します。

以上のように、Sveltosはマルチクラスタ環境で必要となる「展開の自動化」「変更への即応」「一貫性の維持」を包括的にサポートするプラットフォームと言えます。

Kubernetes環境でのSveltosの具体的な活用方法

SveltosをKubernetes環境で活用する基本的な手順を説明します。

管理クラスタへのインストール: まずSveltos本体を管理クラスタ上にインストールします。Helmチャートまたはマニフェストが提供されており、例えばHelm利用の場合は次のようにチャートをインストールします (How to Deploy and Manage Kubernetes Add-Ons across multiple Clusters - DEV Community)。
```
helm repo add projectsveltos https://projectsveltos.github.io/sveltos-charts
helm repo update
helm install projectsveltos projectsveltos/projectsveltos -n projectsveltos --create-namespace
```
これにより、管理クラスタ上にSveltosのCRD群とコントローラ（およびダッシュボード用コンポーネントなど）がデプロイされます。インストール後、kubectl get pods -n projectsveltos等でSveltosコントローラが起動していることを確認します。
クラスタの登録（管理対象クラスタの追加）: 次に、配下に管理したいKubernetesクラスタをSveltosに登録します。Cluster APIを使っている場合は管理クラスタ上で自動検出されることもありますが、手動でもkubectlまたはSveltos CLI（sveltosctl）で登録可能です (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。例えば手動で2つのクラスタcluster1とcluster2を登録する場合:
```
# 事前に各クラスタのkubeconfigを取得済みとする
kubectl create ns civo  # クラスタ登録用のNamespace作成（任意）
sveltosctl register cluster --namespace=civo --cluster=cluster1 \
    --kubeconfig=./civo-cluster1-kubeconfig --labels=env=production
sveltosctl register cluster --namespace=civo --cluster=cluster2 \
    --kubeconfig=./civo-cluster2-kubeconfig --labels=env=production
```
上記では2つの既存クラスタをenv=productionというラベル付きで登録しています (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。実行後、管理クラスタ上でkubectl get sveltoscluster -Aとすると登録されたクラスタの一覧が確認でき、READYがtrueなら接続が正常なことを示します (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。登録時に指定したラベル（例: env=production）はSveltosClusterリソースに反映され、以後のアドオン適用ターゲット選択に使用されます。
エージェントと接続のセットアップ: クラスタ登録により、Sveltosは自動的に各管理対象クラスタにエージェントをデプロイします (Sveltos: Argo CD and Flux CD are not the only GitOps Tools for Kubernetes | by Artem Lajko | ITNEXT)。また、各クラスタ用に管理クラスタ側にNamespace（例: 上記ではcivo）と認証情報のSecretが作成され、管理クラスタからクラスタへのアクセスが可能な状態になります (Sveltos: Argo CD and Flux CD are not the only GitOps Tools for Kubernetes | by Artem Lajko | ITNEXT)。この接続設定は内部で行われるためユーザが個別にServiceAccountやKubeconfigを配布する必要はありません（裏では先述のようにServiceAccountとRBAC、Secret化が行われています）。準備が整うと、Sveltosは各クラスタの情報（K8sバージョンなど）を取得し、デフォルトのClassifierが有効であれば例えばクラスタのK8sバージョンに応じたラベル（projectsveltos.io/k8s-version=v1.xx.y）が付与されます (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。
アドオン適用の定義（ClusterProfileの作成）: 管理対象クラスタ群に適用したいアドオンや設定をClusterProfileリソースとして作成します。ClusterProfileにはspec.clusterSelectorで対象とするクラスタのラベル条件を指定し、spec内に適用する内容を記述します (Sveltosによるシンプルで柔軟なKubernetesクラスタ運用 #kubernetes - Qiita)。例として、すべてのenv=productionラベルを持つクラスタにNATSサーバをデプロイしたい場合、以下のようなClusterProfileを管理クラスタ上で作成します (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community) (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。
```
apiVersion: config.projectsveltos.io/v1beta1
kind: ClusterProfile
metadata:
  name: nats-deployment
spec:
  clusterSelector:
    matchLabels:
      env: production
  helmCharts:
  - chartName: nats/nats
    chartVersion: 1.2.9
    releaseName: nats
    releaseNamespace: nats
    repositoryName: nats
    repositoryURL: https://nats-io.github.io/k8s/helm/charts/
    values: |-
      config:
        # NATSの設定（例として全権限のシンプル認証を有効化）
        merge:
          authorization:
            default_permissions:
              publish: [">"]
              subscribe: [">"]
          users:
          - user: "admin"
            password: "my-password"
  syncMode: Continuous
```
上記のClusterProfileをkubectl applyすると、Sveltosは自動的に登録済みクラスタのうちenv=productionラベルを持つもの全てに対してNATS（Helm chart version 1.2.9）をインストールします (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community) (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。Helmチャート適用なので各クラスタ上にnatsというNamespaceが作成され、Helmリリース（Deployment/Serviceなど含む）がデプロイされます。syncMode: Continuousの指定により、NATSが動作し続けるよう常に監視され、もしPodが落ちれば自動再作成されるなど、Helmリリースの整合性も維持されます (Sveltosによるシンプルで柔軟なKubernetesクラスタ運用 #kubernetes - Qiita)。

ClusterProfileではHelmチャートのほかポリシー参照（policyRefs）によって任意のKubernetesリソースを適用できます (Sveltosによるシンプルで柔軟なKubernetesクラスタ運用 #kubernetes - Qiita)。たとえばConfigMapに生のYAMLマニフェストを記述しておき、そのConfigMapをpolicyRefとしてClusterProfileに列挙すると、その中身のリソースが対象クラスタに作成されます (Sveltosによるシンプルで柔軟なKubernetesクラスタ運用 #kubernetes - Qiita)。Secretを用いて機微な設定（例えばデータベースの認証情報など）を配布することも可能です (Sveltosによるシンプルで柔軟なKubernetesクラスタ運用 #kubernetes - Qiita)。このように、一つのClusterProfileでHelmチャートとYAMLマニフェストの両方を組み合わせてデプロイ定義ができ、柔軟な構成管理が行えます。

（必要に応じて、複数のClusterProfileを組み合わせ、dependsOnで適用順序を制御できます。NATSの例では、NATSチャート適用ClusterProfileに続いて、SveltosにNATS接続情報を渡すためのSecretを各クラスタに配置するClusterProfileがあり、後者は前者にdependsOn指定しています (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。これにより、NATS本体の展開が完了してから接続設定が行われるよう保証されています。）
適用状況の確認と管理: Sveltosは適用したアドオンやリソースの状況を可視化するためのCLIコマンドやダッシュボードを提供します。CLIツールのsveltosctlを使えば、各クラスタに現在適用されているアドオン一覧を表示できます（例：sveltosctl show addonsコマンドでクラスタごとのデプロイ済みHelmリリースやリソースの一覧を表形式で取得） (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community) (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。また、前述のWebダッシュボードを有効化すればブラウザ上で管理対象クラスタやClusterProfile、適用結果を確認できます (How to Deploy and Manage Kubernetes Add-Ons across multiple Clusters - DEV Community)。問題が発生した場合は、管理クラスタのイベントログ（kubectl get events）や通知（Slack等）を通じて異常を検知でき、必要ならClusterProfileの定義を更新して再適用することで対処します。Sveltosはこうした変更検出から再適用まで自動化しているため、管理者はポリシーや設定内容の更新に集中でき、展開作業そのものはSveltosに任せる形となります。
（オプション）クラスタ分類の活用: 環境が安定してきたら、Classifierを設定して更なる自動化を図ることもできます。例えばClusterProfileを「K8sバージョンごと」に用意し、Classifierでクラスタにk8s-versionラベルを自動付与するようにしておけば、クラスタをアップグレードした際に自動で適用アドオンセットが切り替わります (Conf42: Manage Kubernetes addons for multiple cluster using runtime state)。また特定のアプリケーション（例：Istioが入っているクラスタか否か）で区別したい場合、そのリソースの存在有無をClassifierで検出してラベルを付け、それに応じたClusterProfileを適用することもできます (Conf42: Manage Kubernetes addons for multiple cluster using runtime state)。このようにClassifier機能を組み合わせると、クラスタのライフサイクル全体にわたり人手を介さない自動適応が実現します。
（オプション）イベントハンドリングの設定: Sveltosを使えば外部イベントに連動したリソース操作も可能です。必要に応じて、EventSourceとEventTriggerを作成することで、指定したイベント受信時に自動アクションを定義できます (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community) (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。たとえば「ClusterRoleが削除されたら自動で再作成する」「外部のメッセージブローカーから特定メッセージを受け取ったらPodをスケールアウトする」などのシナリオを実装できます。これらは高度なユースケースとなるため、詳細は次項の具体例で紹介します。

以上が基本的なSveltosの利用フローです。Sveltosは導入後も容易にスケールできます。クラスタの追加時は単に登録コマンドを実行し、適切なラベルを付けるだけで、そのクラスタにも既存のClusterProfile群が即座に適用されます (projectsveltos · GitHub)。逆にクラスタ削除時も、対応するSveltosClusterリソースを削除すれば自動的に管理対象から外れます。運用者は各種ClusterProfile/Classifier/イベント設定をGit管理しておくことで、GitOps的な運用も可能です（Flux CDを使えばそれらCR変更の自動適用もできます (Sveltosによるシンプルで柔軟なKubernetesクラスタ運用 #kubernetes - Qiita)）。このようにSveltosは日常のマルチクラスタ管理の手間を減らし、変化に強い自律的なシステムを構築する下支えとなります。

ブログ記事に基づいたユースケースの詳細: Kubernetesを「自動運転」するイベント駆動オートメーション

公式ブログ記事「Kubernetes on Autopilot: Event-Driven Automation Across Clusters」では、Sveltosを用いたイベント駆動の自動化シナリオが紹介されています (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。ここではその内容に沿って、マルチクラスタ環境での具体的な活用例を解説します。

ユースケース概要:
外部システムからのイベント（ユーザのログイン/ログアウト）をトリガーに、複数のKubernetesクラスタ上で自動的にリソースを作成・削除する仕組みを構築します。例えば開発者がシステムにログインしたら各クラスタにそのユーザ専用のNamespaceを自動生成し、ログアウトしたら不要になったNamespaceを削除する、といった動きをKubernetes側で自律的に行います (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community) (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。これにより、管理者が逐一手作業でNamespaceを準備したりクリーンアップしたりすることなく、ユーザの操作に合わせてクラスタリソースがオンデマンドに調整されます。まさに“Kubernetesの自動運転（Autopilot）”とも言える仕組みです (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。

シナリオ環境:

管理クラスタ: Kind（ローカルのKubernetes）クラスタ1つを管理クラスタとして使用。ここにSveltosをインストールして全体をコントロールします (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。
管理対象クラスタ: クラウドKubernetesサービスであるCivo上に構築した2つのクラスタ（cluster1とcluster2）を用意。それぞれ3ノードからなるK3sクラスタで、ラベルenv=productionを付与済みとします (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community) (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。これら2クラスタが「本番環境クラスタ」という想定です。
外部イベントソース: 軽量なメッセージングシステムNATSを使用します (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community) (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。NATSはPub/Sub型のメッセージブローカーで、JetStreamという拡張によりメッセージ永続化も可能なため、外部イベントの伝達に適しています (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。ここではユーザログイン/ログアウトイベントをNATS経由で配信し、Sveltosがそれを受け取る形にします。

手順と実装:

NATSのデプロイ: まず、管理対象クラスタ（production環境クラスタ）すべてにNATSサーバをデプロイします。これは前節の手順4と同様、ClusterProfileを使って行います。記事では以下のようなClusterProfile (name: nats) を作成しています (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community) (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。
```
apiVersion: config.projectsveltos.io/v1beta1
kind: ClusterProfile
metadata:
  name: nats
spec:
  clusterSelector:
    matchLabels:
      env: production    # productionラベルのクラスタ全対象
  helmCharts:
  - chartName: nats/nats
    chartVersion: 1.2.9
    releaseName: nats
    releaseNamespace: nats
    repositoryName: nats
    repositoryURL: https://nats-io.github.io/k8s/helm/charts/
    values: |-
      config:
        # 認証ユーザ設定（簡易な全権限ユーザadmin）
        merge:
          authorization:
            default_permissions:
              publish: [">"]
              subscribe: [">"]
          users:
          - user: "admin"
            password: "my-password"
  syncMode: Continuous
```
これにより、2つのproductionクラスタ（cluster1, cluster2）それぞれにNATS（バージョン1.2.9）がインストールされます (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community) (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。全クラスタで同一のユーザ名/パスワード（admin / my-password）による認証が有効化され、どのクラスターのNATSでも共通の資格情報でPub/Subが可能になります。
SveltosからNATSへの接続設定: 次に、Sveltos（管理クラスタ上のコントローラ）がNATSからのイベントを受け取れるように接続情報を設定します。記事では別のClusterProfile (name: deploy-deploy-sveltos-nats-secret)を用い、各クラスタに対してNATS接続用のSecretを配置しています (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community) (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。このSecretにはSveltosがNATSに接続するための設定（サーバURLや認証情報）がエンコードされて含まれています (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。重要なのは、このClusterProfileが先ほどのNATSデプロイClusterProfileにdependsOn: natsで依存している点です (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community) (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。これにより、NATS本体がデプロイされて各クラスタで稼働するまで、このSecret適用が遅延され順序が保証されます。結果として、各productionクラスタにはprojectsveltosというNamespaceにsveltos-natsというSecretが作成され（Base64エンコードされた内容）、Sveltosコントローラはそれを参照してNATSサーバ（クラスタ内のNATS）への接続を初期化します (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community) (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。Sveltosは以後この接続を通じてNATS上の特定トピックを購読し、メッセージ（CloudEvent）を受信できるようになります (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community) (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。
イベントソースとトリガーの定義: 続いて、Sveltosのイベントフレームワークを使い「どのイベントを待ち受けて、何を実行するか」を定義します。記事では以下の3つのリソースを作成しています (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community) (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community) (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。
- EventSource (name: user-operation): これはNATSの**「user-operation」というサブジェクト（トピック）**に流れてくるCloudEventsをソースとして定義しています (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。さらにcloudEventSource: "auth.example.com"という条件も含まれており、イベント内のsourceフィールドがこの値に一致する場合に有効となります (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。要するに、「認証システム(auth.example.com)から発行されたuser-operation系イベント」がこのEventSourceにマッチするトリガー対象となります。
- EventTrigger (name: manage-namespace): こちらが実際のアクション定義です (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。sourceClusterSelectorでenv: productionラベルのクラスタを対象とし、上記EventSource「user-operation」を紐づけています (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。さらにcloudEventActionとしてテンプレート式が記述されており、受信したイベントのタイプがauth.example.com.logout（ログアウト）ならDelete、それ以外（すなわちログインの場合）はCreateをアクションとする条件分岐になっています (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。policyRefsにはnamespaceという名前のConfigMap（後述）を指定しており、このConfigMapに定義されたリソースを上述のCreate/Deleteアクション対象として扱います (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。
- ConfigMap (name: namespace): 上記で参照されたConfigMapで、projectsveltos.io/instantiate: okというアノテーションが付与されています (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。このアノテーションは「テンプレートをインスタンス化せよ」というSveltos向けの指示で、ConfigMap内のデータがリソース定義テンプレートであることを示します (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。実際data.namespace.yamlキーに格納されたYAMLを見ると、KindがNamespaceで名前が{{ .CloudEvent.subject }}となっています (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。つまりこのテンプレートは、「CloudEventのsubjectフィールドの値を名前とするNamespace」リソースを表しています。
以上の設定により、「auth.example.com（認証サービス）からのユーザ操作イベント」を受け取った際に、イベントsubject（ユーザ名）に対応するNamespaceリソースをCreateまたはDeleteする、というSveltos上のルールが出来上がりました (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community) (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。対象クラスタはenv=productionの2クラスタで、Create/Deleteの具体的リソース内容はConfigMapテンプレートで定義されています。
イベントの発行と検証（ログイン時）: 準備が整ったところで、実際にイベントを発生させてみます。ユーザ「mgianluc」がログインしたケースをシミュレートするため、以下のようなCloudEvent JSONを組み立てます (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。
```
{
  "specversion": "1.0",
  "type": "auth.example.com.login",
  "source": "auth.example.com",
  "id": "10001",
  "subject": "mgianluc",
  "datacontenttype": "application/json",
  "data": {
    "message": "User mgianluc login"
  }
}
```
重要なのはtypeがauth.example.com.login、sourceがauth.example.com、subjectがmgianlucとなっている点です。これが先ほど定義したEventSource/Triggerの条件にマッチします（loginなのでTrigger側のcloudEventActionではCreateが選択される）。このJSONを、クラスタ内で稼働中のNATSに対してpublishします。記事では各クラスタにデプロイされたnats-boxというNATSクライアントPodを利用し、以下のようにpublishしています (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。
```
# cluster1に対して発行する場合（cluster2も同様）
KUBECONFIG=civo-cluster1-kubeconfig 
kubectl exec -it deployment/nats-box -n nats -- \
    nats pub user-operation "$CLOUDEVENT_JSON" --user=admin --password=my-password
```
user-operationというサブジェクトに先ほどのJSONを送り、NATS経由でSveltos（管理クラスタ）がそれを受信します (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。するとEventTriggerのロジックが走り、各productionクラスタでNamespace作成が行われます。結果として、cluster1およびcluster2のそれぞれにmgianlucという名前のNamespaceが新規作成されます (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community) (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。実際に記事では、sveltosctl show addonsコマンドでNamespaceが作成されたことを確認しています (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community) (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)（該当出力に:Namespace ... mgianluc ... ClusterProfile/...と記録されている）。このように、ユーザログインイベントにより自動で複数クラスタにNamespaceがプロビジョニングされたことが確認できます。
イベントの発行と検証（ログアウト時）: 次に、同じユーザがログアウトしたイベントを発行します。JSONのtypeをauth.example.com.logoutに変え、subjectは同じくmgianlucとしたCloudEventを再度NATSへpublishします (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。Sveltosはこれを受信すると、EventTrigger設定に基づきNamespace削除アクションを実行します (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。その結果、先ほど作成されたmgianluc Namespaceがcluster1およびcluster2から削除されます (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。記事では再度sveltosctl show addonsを実行し、Namespaceが一覧から消えていること（削除されたこと）を確認しています (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community) (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。

以上のシナリオにより、外部認証システムのイベント -> Kubernetesリソース操作という自動化パイプラインが構築できました。Sveltosのイベントフレームワークとマルチクラスタ適用機能を組み合わせることで、このケースではユーザごとの作業環境（Namespace）のオンデマンドな作成・破棄が可能となっています (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community) (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。ブログ記事の結論でも触れられているように、これはマルチクラスタ管理における非常に強力なアプローチであり、人手を介さずリアルタイムに環境を変化させることで運用の効率と俊敏性を大幅に向上させます (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。

このユースケースは一例ですが、Sveltosのイベント機能は他にも応用可能です。例えばCI/CDパイプラインからの通知で自動デプロイをトリガーしたり、監視システムのアラートに応じてコンテナを再スケジュールしたりといった、イベント駆動インフラを実現できます (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。SveltosはKubernetesの枠を超えて外部システムと連携できるため、クラウド全体の自動化ハブとして機能しうるのです。

他の類似ツールとの比較

Sveltosと役割が一部重なるツールやフレームワークについて、その特徴を比較します。必要に応じて使い分けや統合の検討材料としてください。

Argo CD / Flux CD（GitOps系ツール）:
Argo CDやFluxはGitOpsに基づく継続的デプロイ（CD）ツールで、Git上の設定をKubernetesクラスタに同期する用途で広く利用されています。Sveltosも宣言的管理という点では共通しますが、大きな違いはマルチクラスタ対応とイベントドリブンの部分です。Argo CDは基本的に1つのArgoインスタンスで1クラスタ（またはリモートクラスタにアクセス可）を管理し、複数クラスタの扱いにはApplicationSetなどを用いて間接的に対応します。一方Sveltosは初めから複数クラスタ管理を目的に設計されており、単一のSveltosでフリート（複数クラスタ群）全体を統合的に制御できます (Sveltos: Argo CD and Flux CD are not the only GitOps Tools for Kubernetes | by Artem Lajko | ITNEXT)。またArgo CD/FluxはいずれもGitリポジトリを唯一の情報源とし、定期的（例: 3分毎）にリポジトリとクラスタの差分をチェックして同期します。一方Sveltosは、エージェントからの通知に基づくプル型同期を採用しており、差分が発生した時点で都度必要な処理を行うため遅延が少なく効率的です (Sveltos: Argo CD and Flux CD are not the only GitOps Tools for Kubernetes | by Artem Lajko | ITNEXT)。特に大規模環境では、Argoのような頻繁な全体チェックはAPI負荷が高くなる傾向がありますが、Sveltosはドリフトが起きた所だけ再調整するためスケーラビリティに優れます (Sveltos: Argo CD and Flux CD are not the only GitOps Tools for Kubernetes | by Artem Lajko | ITNEXT)。さらに、SveltosはArgo/Fluxにはないイベントハンドリングやクラスタ分類といった機能も持ち、純粋なGitOpsに留まらない柔軟な自動化を実現できます (projectsveltos · GitHub)。もっとも、SveltosはGitリポジトリから直接マニフェストを同期する仕組み（いわゆるGitウォッチャー）は内蔵していないため、Flux CDとの統合によりそこを補完できます (Sveltos: Argo CD and Flux CD are not the only GitOps Tools for Kubernetes | by Artem Lajko | ITNEXT)。実際にFluxを用いてClusterProfile/Policy定義をGit管理しつつ、Sveltosでマルチクラスタ展開するという構成が公式にも推奨されています。このように、Argo CD/FluxはシングルクラスタのGitOpsデプロイに強みがあり、Sveltosはマルチクラスタの包括管理やイベント対応に強みがあるため、競合というより補完関係にあります。特に既存のGitOpsフローをマルチクラスタに拡張したい場合、Flux＋Sveltosの組み合わせが有効です (Sveltosによるシンプルで柔軟なKubernetesクラスタ運用 #kubernetes - Qiita)。
Karmada:
KarmadaはCNCFサンドボックスプロジェクトの一つで、複数のKubernetesクラスタをまるで一つのクラスタであるかのように扱うことを目指したマルチクラスタ管理基盤です。Karmadaは統一コントロールプレーンを提供し、ユーザはそのVirtual Clusterに対してDeployment等のリソースを適用すると、裏でKarmadaがMember Clusterと呼ばれる各クラスタにPodをスケジューリングします (Karmada and Open Cluster Management: two new approaches to ...)。いわばKubernetesの上にもう一層のスケジューラを載せたイメージです。対してSveltosは、各クラスタを独立した対象として扱いながら、それらに共通の追加コンポーネントを配布・管理するアプローチです。アプリケーションワークロードそのもののスケジューリングは行わず（そこは各クラスタのスケジューラに任せる）、アドオン（コントローラやポリシー）や設定にフォーカスしている点が異なります (projectsveltos · GitHub) (projectsveltos · GitHub)。Karmadaはマルチクラスタでの負荷分散やフェイルオーバー、クロスクラスタのDeploymentなどに強みがありますが、導入が比較的ヘビーでクラスタ間の強いつながりを要求します。一方Sveltosは既存クラスタ群にエージェントを追加してゆるやかに統制する形で、よりシンプルかつ段階的に導入できる利点があります。両者は目的が異なる部分もありますが、マルチクラスタ環境の管理という広義では類似領域です。Karmadaはワークロードのスケジューリング、Sveltosはアドオンのライフサイクル管理と捉えると分かりやすいでしょう。
Rancher Fleet:
Rancherが開発したFleetは、多数のクラスタに対するGitOps型のリソース配布を行うツールです。Fleetもまたエージェント（Fleet Agent）を各クラスタに配置し、Gitリポジトリ内のマニフェストを適用するという仕組みを取ります。アーキテクチャ的にはFluxやArgoよりSveltosに近く、集中管理＋各クラスタにデーモンという構造です。FleetはGitOps（Gitドリブン）専用ですが、Sveltosは前述のようにイベントドリブンや動的分類など、Gitに限らないトリガーで動作できる点で差別化されています。また、SveltosはネイティブにHelmやKustomizeに対応しつつ、Fleetと同様に大規模クラスタ向けの設計がなされており、どちらも「大規模分散環境における構成管理」を目指しています。既にRancher環境を使っている場合はFleetが統合されていますが、そうでなければSveltos単体で同等以上のことが可能です。さらにSveltosはマルチテナントの分離や**きめ細かな条件制御（Luaによるイベント処理など）**が可能で、柔軟性の面で優れています。
Cluster API + ClusterResourceSet:
Cluster API (CAPI)はKubernetesクラスタそのもののライフサイクル管理を宣言的に行うフレームワークですが、付随機能としてClusterResourceSetという仕組みでクラスタ作成時にマニフェストを自動適用できます。これは限定的にはマルチクラスタのアドオン初期化に使えますが、あくまでクラスタ作成直後の静的適用であり、Sveltosのような継続的な管理やイベント駆動には対応していません。むしろSveltosはCAPIと補完関係にあり、CAPIでクラスタを作ったらSveltosが自動でアドオンを投入する、といった連携が可能です (Sveltosによるシンプルで柔軟なKubernetesクラスタ運用 #kubernetes - Qiita) (Sveltosによるシンプルで柔軟なKubernetesクラスタ運用 #kubernetes - Qiita)。CAPIでインフラ～クラスタレベルを管理し、Sveltosでアプリケーション～ポリシーレベルを管理することで、フルスタックなIaCを実現できます (Sveltosによるシンプルで柔軟なKubernetesクラスタ運用 #kubernetes - Qiita) (Sveltosによるシンプルで柔軟なKubernetesクラスタ運用 #kubernetes - Qiita)。

以上のように、Sveltosは既存のGitOps/マルチクラスタツールとは一部重複しつつも独自のポジションと強みを持っています。特にイベント対応やクラスタ状態に応じた自動適用などは現状Sveltosならではの機能です。既存ツールとの組み合わせも視野に入れ、自社の要件に合わせた最適なアーキテクチャを選定すると良いでしょう。

実装の際のベストプラクティスと考慮点

最後に、Sveltosを実環境に導入・運用する際のベストプラクティスや留意事項をまとめます。

クラスタラベル設計: 適切なラベリングはSveltos運用の鍵です。クラスタに付与するラベルは、環境種別（例: env=prod, env=dev）、用途（team=alpha、region=us-eastなど）を明確に表すよう計画しましょう (How to Deploy and Manage Kubernetes Add-Ons across multiple Clusters - DEV Community)。ラベル命名を組織で統一し、ターゲット選択が一意かつ分かりやすくなるよう工夫します。ラベルを戦略的に設計することで、ClusterProfileの記述が簡潔になり、意図しないクラスタへ設定が適用されるリスクも減ります。
ClusterProfileの分割と命名: 一つのClusterProfileに盛り込みすぎず、役割や機能ごとに分割することを検討してください (How to Deploy and Manage Kubernetes Add-Ons across multiple Clusters - DEV Community)。例えば「監視基盤デプロイ用」「セキュリティポリシー適用用」など用途別にClusterProfileを作成し、それぞれに明確な名前を付けます (How to Deploy and Manage Kubernetes Add-Ons across multiple Clusters - DEV Community)。こうすることで変更管理やトラブルシューティングが容易になり、他の管理者とも認識を共有しやすくなります。
依存関係の明示: 複数のClusterProfile間に順序や依存関係がある場合は、dependsOnフィールドを活用して明示的に制御しましょう (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。例えばCRDを提供するアドオンとそれを使う別のコンポーネントは別Profileに分け、後者に前者をdependsOn指定する、といった形です。この指定によりSveltosが適用順序を保証し、初回適用時の不整合エラーを防ぎます。依存関係が複雑になる場合は、ドキュメント化やDiagramで視覚化しておくと管理しやすくなります。
マルチテナント運用: 複数チーム・プロジェクトでSveltosを共有する場合は、基本的にClusterProfileはプラットフォームチーム専用とし、各テナントには自分のNamespaceでProfileを作らせるルールにすると良いでしょう (Sveltosによるシンプルで柔軟なKubernetesクラスタ運用 #kubernetes - Qiita)。RBAC設定で一般ユーザには自分のNamespace下でのProfile作成権限のみ与え、ClusterProfile（全体影響を及ぼす操作）は限定された管理者だけが触れるようにします。これによりチーム間の干渉を防ぎ、意図しない設定変更から環境を保護できます。また、各テナントが使えるラベルもホワイトリスト制にするなど、ポリシーを明文化しておくことを推奨します。
監視と可視性の確保: Sveltos導入後は、その動作自体も監視の目を届かせましょう。幸いSveltosはSlackやTeams通知、Kubernetesイベント連携が容易にできるため、重要なイベント（例: アドオン適用失敗、ヘルスチェック異常）を確実に拾えるよう設定します (projectsveltos · GitHub)。またGrafanaダッシュボードやPrometheusメトリクスと組み合わせ、各クラスタの状態や適用履歴を可視化するとトラブルシュートに役立ちます。Sveltos専用のダッシュボードUIも活用して、クラスタ一覧や適用中のProfileなどを定期的にレビューしてください (How to Deploy and Manage Kubernetes Add-Ons across multiple Clusters - DEV Community)。
段階的な導入と検証: いきなり本番全クラスタに適用せず、まずは検証環境でSveltosの挙動を確認しましょう (How to Deploy and Manage Kubernetes Add-Ons across multiple Clusters - DEV Community)。KindやK3sを使ったテストクラスタで、主要なClusterProfileを適用し想定通り動くか検証します (How to Deploy and Manage Kubernetes Add-Ons across multiple Clusters - DEV Community)。ドリフト検知の動作やイベントトリガーのシナリオも事前に試し、Sveltosの挙動に慣れておくことが重要です。本番導入時も、まずは限定的なクラスタ群から徐々に適用範囲を広げることで、万一の問題発生時の影響を抑えられます。
Sveltos管理クラスタの堅牢性: 管理クラスタはSveltosの中枢となるため、可用性と健全性に注意を払います。可能であれば管理クラスタ自体を冗長化（HA構成）し、定期的なバックアップを取得します。SveltosのSnapshot機能も活用し、重要な変更前後でスナップショットを取っておくと安心です (Conf42: Manage Kubernetes addons for multiple cluster using runtime state)。また管理クラスタのKubernetesバージョンはSveltosがサポートする最新安定版を保ち、互換性問題を避けます (How to Deploy and Manage Kubernetes Add-Ons across multiple Clusters - DEV Community)。Sveltosアップグレード時はリリースノートを確認し、必要に応じてCRDのアップデートやエージェント更新も忘れずに行います。
変更のプレビューと慎重な適用: 大きな変更を行う際は、すぐに適用モードにせずDryRunモードで影響を確認することを推奨します (Conf42: Manage Kubernetes addons for multiple cluster using runtime state)。DryRunに設定すると実際のクラスタには触れず、Sveltosが内部的に「この変更でどのクラスタに何を変更するか」をシミュレートし結果をまとめてくれます (Conf42: Manage Kubernetes addons for multiple cluster using runtime state)。それをレビューし、期待通りであることを確認してから通常モード（Continuous）に戻して反映することで、安全性を高められます。特に多数のクラスタにまたがる変更や、デリケートなリソース（ネットワークや権限系）の変更時には有効な手段です。
外部イベント活用時の注意: Sveltosのイベント機能を使う場合、イベントソース側（例えばNATSなどメッセージング基盤）の信頼性とセキュリティにも留意してください。イベントが届かなかった場合のリトライ戦略や、悪意あるイベントをフィルタリングする仕組みが必要か検討します。SveltosのEventTriggerにはoneForEventというオプションがあり、同一イベントIDに対して一度だけ処理を行う設定ができます (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。冪等性を保つためにもこれを有効にしておくと、重複イベントによる二重処理を防げます。また、イベントドリブンで作成したリソースの命名規則や競合対策も考慮しましょう。例えば本例では「ユーザ名」をNamespace名にしましたが、万一同名ユーザが複数存在すると衝突します。その場合はsubjectにユニークなIDを使う、プレフィックスを付ける等の運用ルールを決めておくと良いでしょう。

以上のベストプラクティスを念頭に置くことで、Sveltosをより安全かつ効果的に活用できます。Sveltosは強力なツールですが、運用次第でその効果は大きく変わります。中央集権的な管理を実現しつつも柔軟性を保つバランスを取り、組織のポリシーやカルチャーに沿った使い方を模索してください。適切に導入すれば、SveltosはまさにKubernetesを自動操縦するパイロットとして、日々のマルチクラスタ運用を支えてくれるでしょう (Kubernetes on Autopilot: Event-Driven Automation Across Clusters - DEV Community)。