3行まとめ
このテーマをもう少し広げて見るなら、VCF 9.1のVKSマルチネットワーク対応を導入前に確認する：二つ目のNIC、NSX VPC/VDS、未対応範囲の実務ポイント と VCF Automation 9.1のNamespace Blueprintを導入前に確認する：App Stack Formation、VM Group、Content Libraryの実務ポイント も合わせて確認してください。Argo CDでVKSを宣言管理する前に、クラスターネットワークの前提と未対応範囲を確認できる。
アプリ配布だけでなく、Supervisorを通じてNamespace、VKSクラスター、add-on、ワークロードまで宣言管理の対象に広がります。
Argo CD Supervisor Service、VKS API、App of Apps参考構成、experimental community serviceを同じ重さで扱わないことが重要です。
version指定、OIDC/RBAC、LoadBalancer公開、互換性、CLI、Git到達性、add-on所有者を先に確認します。
GitOpsの対象を広げるほど、権限と責任分界を先に決める必要があります。
- Broadcom/VMware Cloud Foundation Blogは2026年6月5日、VMware vSphere Kubernetes Service（VKS）でArgo CDを使うGitOps設計を紹介しました。ポイントは、アプリ配布だけでなく、Supervisorを通じてNamespace、VKSクラスター、add-on、ワークロードまで宣言管理の対象に広げられるかを見極めることです。
- ただし、Argo CD Supervisor Service、VKS API、App of Appsの参考構成、experimental community serviceとされるauto-attachは根拠レベルが違います。公式APIで確認できる範囲とサンプル実装、未成熟な自動化補助を混ぜて読むと、導入判断を誤ります。
- PoC前には、
ArgoCDリソースのversion指定、OIDC/RBAC、LoadBalancer公開、Supervisorとの互換性、Broadcom customized Argo CD CLI、Gitリポジトリ到達性、add-onの所有者を先に棚卸ししてください。
VMware Cloud Foundation（VCF）やVKSでKubernetes運用を進めているチームにとって、Argo CDは珍しいツールではありません。すでに別のKubernetes環境でArgo CDを使い、Helm、Kustomize、Application manifestsをGitから配布している組織も多いはずです。
今回の論点は、Argo CDそのものの入門ではありません。2026年6月5日に公開されたVCF Blog「Driving GitOps workflows with ArgoCD on VMware vSphere Kubernetes Service」が示しているのは、VCF/VKS環境ではGitOpsの対象をアプリだけに閉じず、Supervisorを境界にしてVKSクラスター、add-on、場合によってはVM Serviceまで宣言管理へ広げる設計です。
これは便利な一方で、かなり強い運用設計を要求します。Gitに入れる対象が増えれば、変更履歴や監査は追いやすくなります。しかし、誰がNamespaceを作るのか、誰がVKSクラスターのバージョンを上げるのか、誰がadd-onの障害を戻すのか、どこまでをArgo CDに任せるのかを決めないまま始めると、GitOpsの形をした権限スプロールになります。
この記事では、VKSでArgo CD GitOpsを始める前に見るべき実務ポイントを、公式一次情報と参考実装に分けて整理します。株価材料や決算の話ではなく、導入企業、プラットフォームチーム、Kubernetes運用担当者がPoC前に確認すべき内容に絞ります。
VKSでArgo CDを使うと何が変わるのか
VKSでのArgo CDは置き換えではなく、管理面をどこまで拡張するかの設計として読むのが安全です。
VKSでArgo CDを使う話は、「既存のArgo CDを捨てて、Broadcom独自の別ツールへ移る」という話ではありません。むしろ、読者が最初に分けるべきなのは、既存のArgo CD運用をアプリ配布に使い続けるのか、それともSupervisor側のリソースまで管理対象に広げるのかです。
VCF Blogは、Argo CDがVCF上で動くと、vSphere Supervisorを通じてインフラ境界のリソースを宣言管理できる、と説明しています。記事内で挙げられている対象は、vSphere Namespaces、VKS cluster definitions、VM Service instancesです。さらに設計モデルでは、platform、cluster、add-ons、workloadsという4層に分けて管理対象を整理しています。
ここを「Argo CDで何でもできる」と読むと危険です。正しくは、Kubernetes resourceとして表現できるものをGitに置き、SupervisorやVKSのコントローラーが扱える範囲で状態を収束させる、という読み方になります。
需要シグナルは2026年6月5日のVCF Blog
根拠
今回の直接の需要シグナルは、2026年6月5日のVCF Blogです。同じ週にはVCF 9.1関連のブログやVKS関連更新が続いており、当サイトでもVKS multi-network、VCF Automation、VCF Operations、PowerCLI OAuthなどを追ってきました。
注意点
その中で今回の記事が扱う検索意図は、VKS 9.1の個別機能ではありません。読者が知りたいのは、VKSでArgo CDを使う場合に、アプリケーション配布、クラスター作成、add-on管理、Day-2運用までをどう分けて考えるかです。
VCF 9.1全体の導入前チェックは、既存記事のVCF 9.1を導入前に確認する：API-first、アップグレード計画、管理サービスIPの実務ポイントで扱っています。この記事では、そこから一段狭く、VKS GitOpsに絞ります。
置き換えではなく管理面の拡張として読む
評価基準
既存のKubernetes環境でArgo CDを使っている組織なら、まず「何を移すのか」を分けてください。
ひとつ目は、アプリ配布だけをVKSへ向け直すパターンです。アプリチームがすでにHelmやKustomizeで配布しているなら、VKSを新しいKubernetes endpointとして扱い、既存のCI/CDやGitOps運用を大きく変えない選択があります。
ふたつ目は、VKSクラスターやadd-onまでGit管理へ寄せるパターンです。こちらはプラットフォームチームの責任が重くなります。Namespace、ClusterClass、VKr references、AddonInstall、Application manifestsの変更がすべてGit上で見えるようになる反面、誤ったmanifestの影響範囲も大きくなります。
三つ目は、Argo CDインスタンス自体もSupervisor Serviceとして宣言管理するパターンです。この場合、Argo CDを運用するためのArgo CD、という再帰的な設計になりやすいため、初期ブートストラップ、切り戻し、管理者権限、認証連携を先に決める必要があります。
最初に決める責任分界
確認項目
PoC前に、少なくとも次の責任分界を決めてください。
| 確認項目 | 決めること | 決めない場合のリスク |
|---|---|---|
| Argo CDインスタンス | Supervisor Serviceとして誰が作成・更新するか | アプリチームが基盤設定を触る、または基盤チームがアプリ配布まで抱える |
| Gitリポジトリ | platform、cluster、add-on、workloadを同一repoに置くか分けるか | 承認フローが混ざり、変更影響のレビューが難しくなる |
| Namespace | vSphere Namespaceを誰が登録し、誰が削除できるか | テナント境界がGitの都合で曖昧になる |
| add-on | cert-manager、Contour、Veleroなどを誰が所有するか | アプリ障害と基盤add-on障害の切り分けが遅れる |
| クラスター更新 | VKS versionやVKr referenceを誰が上げるか | Git上の一行変更が大きな運用変更になる |
Argo CDは状態を収束させる道具です。責任分界をあいまいにしたまま導入しても、運用はきれいになりません。むしろ、誰かのローカル作業がGit commitに変わるだけで、判断の所在は見えないまま残ります。
Argo CD Supervisor Serviceで宣言管理できること
上流Argo CDの番号だけでなく、VMware/VKS向けService versionとして利用できる組み合わせを確認します。
外部公開の有無、到達範囲、OIDC redirect URLをネットワークと認証の設計に合わせます。
アプリチーム、基盤チーム、監査担当者の権限差をArgo CD側の設定に反映します。
差分確認や一時停止をどの場面で使うかを決め、保守時の操作手順に組み込みます。
本番想定では、コンポーネント設定やリソース配分を後回しにせず、採用有無を表にしておきます。
API Referenceのlatest表示だけで判断せず、実際に利用するSupervisor環境でkubectl explainなどを確認します。
Broadcom DeveloperのArgoCD Service API Referenceは、argocd-service.vsphere.vmware.com/v1alpha1というAPI groupを示し、ArgoCDをNamespace-scoped resourceとして説明しています。つまり、ここでまず確認する対象は、Argo CDインスタンスそのものです。
VKSクラスターやadd-onの宣言管理は、その次の層です。最初から「Argo CDでクラスターもアプリも全部管理する」と考えるのではなく、ArgoCDリソースで何を指定できるのかを先に押さえると、PoCの粒度が見えます。
ArgoCDリソースはインスタンス管理の土台
根拠
ArgoCD Service APIでは、ArgoCDSpecにversion、authentication、RBAC、component settingsなどが含まれると説明されています。導入前チェックとして重要なのは、フィールド名を丸暗記することではなく、その設定を誰が決めるべきかです。
たとえば、enableLoadBalancerはArgo CD Serverを外部LoadBalancer経由で到達可能にする設定です。これを有効にするなら、ネットワークチームやセキュリティチームと公開範囲を確認する必要があります。urlはOIDC認証を有効にする場合に必要になるため、SSO設計と切り離せません。rbacはアプリチーム、基盤チーム、監査担当者の権限差を反映する場所です。
API Referenceでは、serverSideDiff、paused、local accounts、OIDC、resourceConfigなども確認できます。PoCでは、これらを一度に全部使う必要はありません。ただし、本番を想定するなら「あとで決める」ではなく、少なくとも採用するかどうかを表にしておくべきです。
バージョン指定は導入前の最重要チェック
条件
spec.versionは、上流Argo CDのバージョン番号だけで判断しないでください。ArgoCD Service APIは、versionがX.Y.Z+vmware.W-vks.V形式に従う例を示しています。例として3.0.19+vmware.1-vks.1が挙げられています。
ここで重要なのは、「Argo CD 3.0.19だから動く」という判断をしないことです。Supervisor Serviceとして提供されるArgo CDは、VCF/VKS側のService version、Supervisor version、Operatorがサポートする組み合わせに依存します。
確認方法
導入前の確認として、API Referenceが示すように、少なくとも次の確認を入れてください。
kubectl explain argocd.spec.versionこの確認は、実際に利用するSupervisor環境で行う必要があります。ドキュメントのlatest表示と、自社環境で利用可能なService versionは一致しないことがあります。
認証とRBACは後回しにしない
注意点
Argo CDをPoCで動かすだけなら、最初は最小限の認証で動いてしまうことがあります。しかし、VKSでGitOpsを本格利用する場合、Argo CDの権限はそのままプラットフォーム操作権限につながります。
ArgoCDSpecではOIDC authenticationやRBAC policiesの例が示されています。アプリだけを配布するArgo CDと、VKSクラスターやadd-onまで扱うArgo CDでは、必要な権限の重みが違います。
特に注意したいのは、resource inclusion/exclusionです。ArgoCD Service APIには、Argo CDがどのKubernetes resourcesをdiscoverし、syncできるかを調整するresourceConfigが説明されています。inclusionsを指定しない場合は全resource groups and kindsが対象になる、という読み方になるため、本番では「見えてよいもの」「同期してよいもの」「同期対象から外すもの」を明示的に検討する価値があります。
App of AppsはどこまでをGit管理に入れる設計か
- 1Root Application
管理対象全体の入口をGit repositoryに置き、child Applicationをたどれるようにします。
- 2Namespace registration
platform側の前提を先に収束させ、後続のクラスターやworkloadが失敗しにくい順序を作ります。
- 3VKS clusters
クラスター定義や登録を段階的に同期し、変更履歴とレビュー範囲をGitで追えるようにします。
- 4add-ons
cert-managerやContourなどの基盤パッケージを依存順に置き、影響範囲を見える化します。
- 5workloads
アプリ配布を後段に置くことで、失敗時にNamespace、cluster、add-on、applicationのどこで止まったかを切り分けやすくします。
sync waveは見た目の整理ではなく、依存関係を壊さずに状態を収束させるための設計要素です。
VCF Blogは、App of AppsをVKS GitOps設計の中心に置いています。App of Appsは、単一のroot applicationから複数のchild Applicationをたどり、platform、cluster、add-ons、workloadsを段階的に収束させる設計です。
ここでの焦点は、「便利そうなディレクトリ構成を真似すること」ではありません。自社のVKS運用で、どこまでをGitの単一変更として扱うのかを決めることです。
Root Appから管理対象を段階的に広げる
根拠
VMwareのvks-consumption-models GitHubリポジトリには、argocd-app-of-appsという参考構成があります。READMEでは、Git repositoryからroot app、bootstrap、vSphere namespace registration、cluster provisioning、add-on、workload deploymentへ広がる構成が説明されています。
サンプルでは、clusters/cl01/にクラスター定義、Argo CD登録、cert-manager、ContourのAddonInstallが置かれ、clusters/cl02/にはautoscaler-enabled clusterの例が置かれています。workloads/cl01/にはnginxとOnline Boutiqueのようなアプリケーション例があります。
この構成は、VKS GitOpsの考え方を理解するには有用です。一方で、そのまま本番標準にするものではありません。自社では、platform repo、cluster repo、add-on repo、application repoを分けるかもしれません。セキュリティレビューや変更承認が必要な組織では、単一repoにまとめるよりも、責任分界ごとにrepositoryやbranch protectionを分けた方が自然な場合もあります。
sync waveは依存関係を壊さないために使う
評価基準
App of Appsで大事なのは、管理対象を束ねることだけではありません。順序を制御することです。
VCF Blogと参考リポジトリでは、sync waveの考え方が示されています。例として、wave 0でArgoNamespace CRを扱い、wave 10でcl01-app、wave 12でcl02-app、wave 20でnginx、wave 25でOnline Boutiqueを配布する流れが出ています。
これは見た目の整理ではありません。Namespaceがない状態でクラスターやworkloadを同期しても失敗します。クラスターがない状態でadd-onやアプリを同期しても、再試行の理由が見えにくくなります。GitOpsで「最終的に収束するから大丈夫」と考えるより、最初から依存関係をwaveで表現した方が、失敗時の切り分けがしやすくなります。
自社PoCでは、サンプルのwave番号をそのままコピーする前に、次のように置き換えて考えてください。
| waveで考える対象 | 自社で決めること |
|---|---|
| Namespace登録 | テナント境界、権限、Quota、StorageClass、VM Classを誰が承認するか |
| VKSクラスター | ClusterClass、Kubernetes version、worker node、CNI、storageを誰がレビューするか |
| add-on | cert-manager、Contour、Velero、monitoringなどの標準パッケージをどこまで共通化するか |
| workloads | アプリチームが自由に変更できる範囲と、基盤チームが守る範囲をどう分けるか |
VKSのネットワーク設計も同時に見たい場合は、VCF 9.1のVKSマルチネットワーク対応を導入前に確認するも先に読んでおくと、クラスター定義とネットワーク前提を分けやすくなります。
Day-2運用を「一行変更」で済ませない
確認項目
VCF Blogでは、Day-2 operationsとして、VKS cluster versionをVKr referenceの一行変更で更新し、Cluster APIがrolling upgradeを行う、という説明があります。worker nodeのscaleやbackup packageの追加も、Git commitを通じて同じ形で扱えるとされています。
これはGitOpsの魅力です。しかし、実務では「一行変更で済む」ことと「一行変更で進めてよい」ことは別です。
クラスターのversion変更は、アプリ互換性、CSI/CNI、Ingress、監視、バックアップ、セキュリティポリシー、maintenance windowに影響します。Git上の差分が小さいほど、レビューでは逆に意識して影響範囲を広く見る必要があります。
PoCでは、最初からクラスターアップグレードを自動化するより、まずはadd-on追加、worker nodeのscale、非重要workloadの配布など、影響範囲が小さい変更からGitOps化するのが安全です。
add-on管理とクラスターオンボーディングの境界
便利な自動化ほど、公式API、公式ブログ、参考実装、community serviceの境界を分けて導入判断する必要があります。
VKS GitOpsで読み違えやすいのが、add-on管理とクラスターオンボーディングの境界です。どちらもGit commitで表現できるように見えますが、根拠レベルとサポート前提が違います。
AddonInstallはSupervisorへ適用する前提で見る
条件
参考リポジトリでは、standard packagesをAddonInstall resourcesとしてSupervisorへ適用し、VKSが互換バージョンの選択やクラスターアップグレード時のライフサイクル管理を担う形が説明されています。例としてcert-managerやContourが挙げられています。
この発想は、複数VKSクラスターを持つ組織にはかなり実務的です。Ingress、証明書、backup、monitoringなどの基本パッケージをクラスターごとに手で入れていると、バージョン差分や設定差分が積み上がります。GitOpsでadd-onを管理できれば、どのクラスターに何が入っているかを追いやすくなります。
ただし、add-onはアプリよりも基盤寄りです。cert-managerやContourの不具合は、多くのアプリに横断的に影響します。Git管理へ入れる場合は、次の3点を必ず決めてください。
- add-onの変更はアプリチームのPull Requestで触ってよいのか、基盤チームだけが触るのか。
- add-on upgradeはクラスターupgradeと連動させるのか、別のメンテナンス単位にするのか。
- add-onが同期失敗した時、Argo CDで自動修復させるのか、手動承認を挟むのか。
auto-attachは公式機能として断定しない
注意点
VCF BlogのAutomating Cluster Onboarding部分には、重要な注記があります。クラスター登録を自動化するためのauto-attach serviceは、experimental community serviceとして扱われています。
評価基準
これは記事内で最も慎重に読むべき箇所です。便利なアイデアであることと、Broadcomの公式サポート前提で本番採用できることは違います。自動登録ができれば、クラスター作成からArgo CD配布対象への登録までをGit commitでつなげられます。しかし、その自動化が失敗した時に誰が調査し、どのログを見て、どう手動で戻すのかが決まっていないなら、本番導入は早いです。
PoCで試す場合も、auto-attachは別枠にしてください。まずは手動登録または公式に確認できる方法でArgo CDとVKSクラスターの関係を作り、その後でauto-attachを使う場合の差分、権限、監査ログ、削除時の挙動を確認するのが現実的です。
根拠レベルを表で分ける
確認項目
導入判断では、次のように根拠レベルを分けて読むと混乱しにくくなります。
| 対象 | 根拠 | 本文での扱い |
|---|---|---|
Argo CD Supervisor ServiceのArgoCDリソース | Broadcom Developer API Reference | 公式APIとして確認する |
| VKS Cluster、ClusterClass、MachineDeploymentなど | Broadcom Developer VKS API Reference | VKS APIの確認対象として扱う |
| App of Apps構成 | VCF BlogとVMware GitHubサンプル | 参考アーキテクチャ、PoC出発点として扱う |
| add-on管理サンプル | VMware GitHubサンプルとVCF Blog | GitOps設計例として扱い、実環境の対応バージョンを確認する |
| auto-attach service | VCF Blog上でexperimental community serviceと注記 | 公式機能のように断定せず、PoCの追加検証対象にする |
この表を作る理由は、責任逃れではありません。公式API、公式ブログ、参考実装、community serviceの境界を分けるほど、本番採用時のリスク説明がしやすくなるからです。
互換性で止まらないためのPoC前チェック
latest docsと自社環境の利用可能バージョンは一致しない場合があるため、ドキュメント確認と実環境確認を分けます。
Argo CD GitOpsの設計が良くても、Supervisor Serviceが入らなければ始まりません。Broadcom KB 412344は、Argo CD Supervisor Serviceのインストール時に互換性で失敗する例を示しています。
エラーメッセージ例としては、running platform componentsと互換でないためデプロイできない、argocd-service.vsphere.vmware.comがこのSupervisor versionでサポートされない、という内容が示されています。解決方針として、ArgoCD release notesを確認し、必要に応じてSupervisor Clusterをアップグレードするよう案内されています。
KB 412344の失敗例を先に読む
根拠
KB 412344には、例としてArgoCD version 1.0.0、Supervisor Cluster 9.0.0.0100、Supervisor version 1.30.10の互換関係が出ています。ただし、これは記事公開時点の一例として読むべきで、すべての環境に当てはまる固定条件ではありません。
確認項目
PoC前に確認すべきなのは、次の組み合わせです。
| 項目 | 確認する理由 |
|---|---|
| VCF version | VKSやSupervisor Serviceの利用可能範囲に影響する |
| Supervisor Cluster version | Argo CD Supervisor Serviceの互換性に直結する |
| Supervisor version | Service install可否や対応Kubernetes versionに影響する |
| ArgoCD Service version | spec.versionの指定、Operator対応、CLI互換に影響する |
| VKS API/latest docs | ドキュメントのlatest表示と自社環境の差を確認する |
| Broadcom customized Argo CD CLI | サンプル前提ではversionにvcf suffixが必要とされる |
| Git repository到達性 | Supervisor networkからGitに到達できないとGitOpsが成立しない |
このチェックは、VKSを使うチームだけでは完結しません。VCF基盤、ネットワーク、認証基盤、Gitサービス、セキュリティレビューが関係します。
CLIとGitリポジトリ到達性も忘れない
条件
参考リポジトリのprerequisitesには、VCF 9.0+ with Supervisor enabled、VKS 3.5.0+、Argo CD Supervisor Service、Broadcom customized Argo CD CLI、vSphere Namespace、Supervisor networkから到達できるGit repositoryなどが挙げられています。
ここで見落としやすいのが、CLIとネットワークです。Argo CDが動いているように見えても、Git repositoryへ到達できない、証明書を検証できない、OIDC redirect URLが合わない、RBACでcluster resourceを見られない、といった問題で詰まることがあります。
PowerCLIやOAuth認証まわりを同時に確認するなら、VCF PowerCLI 9.1のOAuth 2.0認証も合わせて読むと、自動化時の認証境界を整理しやすくなります。
API Referenceのlatest表示と自社環境を分ける
注意点
Broadcom DeveloperのVKS API Referenceは、確認時点でlatestとして3.6.0を示していました。API ReferenceにはCluster、ClusterClass、MachineDeploymentなどのCluster API系リソースや、VKS関連のAPI groupが並んでいます。
ただし、latest docsは「自社環境で今すぐ使える」という意味ではありません。VCF/VKSのversion、Supervisorの状態、Service version、インストール済みのパッケージによって、使えるAPIやresourceの挙動は変わります。
ドキュメントではlatestを見つつ、実環境ではkubectl api-resources、kubectl explain、Service release notes、Broadcom KBを組み合わせて確認する。この二段構えが、導入前チェックの基本です。
PoCは小さく分けて進める
- 第一段階: Argo CDインスタンス
Argo CD Supervisor Serviceのインストール、ArgoCD resource、version、LoadBalancer、URL、OIDC/RBAC、監査ログを確認します。
- 第二段階: アプリ配布だけ
VKSをdeployment targetとして扱い、HelmやKustomizeの同期、差分検知、rollbackを小さいworkloadで試します。
- 第三段階: add-onとクラスター定義
AddonInstall、cluster definition、sync wave、レビュー責任を確認し、基盤変更の影響範囲を見ます。
- 第四段階: auto-attachとDay-2操作
experimental service、version更新、worker node scale、削除、復旧、一時停止を失敗パス中心に検証します。
GitOpsは手作業を消すだけでなく、緊急時に何を止め、どこから再開するかまで含めて設計します。
VKS GitOpsは、うまく設計できればプラットフォーム運用をかなり整理できます。とはいえ、初回PoCでArgo CDインスタンス、Namespace、VKSクラスター、add-on、アプリ、auto-attach、upgradeまで一気に試すと、失敗した時に原因が見えません。
PoCは段階に分けた方がよいです。
第一段階：Argo CDインスタンスをSupervisor Serviceとして確認する
確認項目
最初は、Argo CD Supervisor ServiceのインストールとArgoCD resourceの作成だけに絞ります。ここで確認するのは、version、namespace、LoadBalancer、URL、OIDC、RBAC、server-side diff、resourceConfigです。
この段階で、Git repositoryへの到達性や証明書、SSOのredirect、管理者アカウント、監査ログを確認します。アプリ配布まで進める前に、Argo CDそのものが企業運用に耐えられる設定になっているかを見るべきです。
第二段階：アプリ配布だけをVKSへ向ける
条件
次に、既存のArgo CD運用に近い形で、VKS上のworkloadへ配布します。nginxのような小さいアプリ、または社内の非重要サービスを使い、HelmやKustomizeの同期、差分検知、rollbackを確認します。
この段階では、クラスター作成やadd-on管理まで広げない方がよいです。まずは「VKSをArgo CDのdeployment targetとして扱えるか」を確認します。
第三段階：add-onとクラスター定義をGit管理へ広げる
評価基準
アプリ配布が安定したら、add-on管理やクラスター定義をGitに入れる検証へ進みます。cert-manager、Contour、Veleroのような標準パッケージをどこまで共通化するか、VKS cluster definitionを誰がレビューするか、sync waveをどう置くかを確認します。
NamespaceやBlueprintの考え方を整理したい場合は、VCF Automation 9.1のNamespace Blueprintを導入前に確認するも参考になります。Argo CDのApp of AppsとVCF AutomationのNamespace再利用は同じものではありませんが、どこをテンプレート化し、どこを環境別に変えるかという判断には共通点があります。
第四段階：auto-attachとDay-2操作を追加検証する
注意点
最後に、experimental community serviceとされるauto-attach、VKS cluster version更新、worker node scale、add-on追加などを別枠で検証します。
ここでは、成功パスより失敗パスが重要です。Git commitを戻した時に何が削除されるのか。root applicationを消した時にchild resourcesはどう扱われるのか。cluster registrationが失敗した時に手動復旧できるのか。Argo CDが同期し続けることで、緊急対応の手作業が上書きされないか。
GitOpsは「手作業を禁止する」ためだけの仕組みではありません。緊急時に何を一時停止し、どこから再開するかまで含めて、運用手順として設計する必要があります。
導入判断のまとめ
VCF/VKS version、Supervisor Service、GitOps運用、責任分界、OIDC/RBAC、Git到達性を確認できる状態です。
アプリ配布だけなら試せるが、add-on所有者、クラスター定義、承認フロー、公開範囲がまだ整理途中の状態です。
SupervisorやVKSのversion、Argo CD管理者、Git repository管理者、VKS管理者、承認フローが未定の状態です。
Argo CD導入だけで未整理な運用は解決しないため、PoCの前に責任分界と変更レビューを見える化します。
VKSでArgo CD GitOpsを始める価値が大きいのは、すでにKubernetes運用があり、Gitを変更の正本として扱う文化があり、プラットフォームチームとアプリチームの責任分界を整理できる組織です。
逆に、Kubernetes clusterの所有者、Namespace設計、add-on所有者、SSO/RBAC、Git承認フローが未整理なら、Argo CD導入だけで問題は解決しません。むしろ、未整理な運用がGitOpsの中に移動するだけです。
すぐPoCに進めやすいケース
条件
次の条件がそろっているなら、PoCに進みやすいです。
- VCF/VKSのversionとSupervisor Serviceの利用可否を確認できる。
- 既存のArgo CDまたはGitOps運用があり、変更レビューの文化がある。
- platform、cluster、add-on、workloadの責任分界を分けられる。
- OIDC/RBAC、LoadBalancer公開、Git repository到達性を検証できる。
- experimental community serviceを本番前提にせず、追加検証として扱える。
この場合、まずはArgo CDインスタンス、次にアプリ配布、次にadd-on、最後にクラスター定義やauto-attachという順番で進めるのがよいです。
先に棚卸しすべきケース
下振れ
次の状態なら、PoCより先に棚卸しをおすすめします。
- SupervisorやVKSのversionがチーム内で把握されていない。
- Argo CDの管理者、Git repository管理者、VKS管理者が別で、承認フローが未定。
- Gitからclusterやadd-onを変更することに、監査・セキュリティ側の合意がない。
- auto-attachのようなcommunity serviceを、公式サポート機能と同じ前提で扱おうとしている。
- CLI、証明書、SSO、Git network到達性をPoC時にまとめて解決しようとしている。
この状態でApp of Appsを急ぐと、うまく動いた時ほど危険です。小さいデモが成功しても、本番の権限、監査、障害復旧、変更承認が追いつかないからです。
この記事で確認した結論
判断軸
VKSでArgo CD GitOpsを使う時の実務ポイントは、次の一文にまとまります。
Argo CDを「アプリ配布ツール」として使うのか、「Supervisorを通じてVKSプラットフォームの状態をGitで管理する道具」として使うのかを、最初に分けてください。
後者に進むなら、Argo CD Supervisor Serviceの公式API、VKS API、Broadcom KBの互換性情報、VMwareの参考リポジトリ、experimental community serviceの注記を別々に読み、PoCの段階も分けるべきです。そうすれば、GitOpsを「自動化の勢い」ではなく、VCF/VKS運用の監査性、再現性、責任分界を整えるための設計として扱えます。
次に読むなら
Broadcomの公式発表、製品/サービス更新、噂確認、月次まとめの更新をまとめて追いたい場合は、ニュースレターで新着通知を確認できます。一次情報の確認手順を見直したい場合は、資料・確認ログも参照してください。
更新履歴
- 2026年6月6日: 初版作成
VMware Cloud Foundation Blog、Broadcom Developer API Reference、Broadcom KB、VMware GitHub参考構成、BroadcomのVCF 9.1発表を確認しました。
- 製品仕様の再確認
サポート条件、互換性、提供範囲は、導入前に公式ドキュメントと契約条件で確認します。
- 投資判断との切り分け
この記事はAVGOの株式売買、目標株価、短期値動きではなく、製品・サービス・導入判断の確認を目的にしています。
Service versionやKB更新で前提が変わるため、PoC前に最新の一次情報へ戻って確認してください。
- 2026年6月6日: VMware Cloud Foundation Blog、Broadcom Developer API Reference、Broadcom KB、VMware GitHub参考構成、BroadcomのVCF 9.1公式発表を確認し、初版を作成。
- 本記事はBroadcom Inc.およびVMware/Broadcom関係会社とは非提携の情報整理です。製品仕様、サポート条件、互換性、提供範囲は導入前に公式ドキュメントと契約条件で確認してください。
- 本記事は投資助言ではありません。AVGOの株式売買、目標株価、短期値動きを推奨するものではなく、製品・サービス・導入判断の確認を目的としています。
次に読むなら
参照した主な情報源
- VMware Cloud Foundation Blog「Driving GitOps workflows with ArgoCD on VMware vSphere Kubernetes Service」（2026年6月5日公開、2026年6月6日参照）
https://blogs.vmware.com/cloud-foundation/2026/06/05/gitops-argo-on-vks/
- Broadcom Developer「ArgoCD Service API Reference」（2026年6月6日参照）
https://developer.broadcom.com/xapis/argocd-service-api/latest/api-docs.html
- Broadcom Developer「VMware vSphere Kubernetes Service API Reference」（2026年6月6日参照）
https://developer.broadcom.com/xapis/vmware-vsphere-kubernetes-service/latest/api-docs.html
- Broadcom Knowledge Base「Unable to install argoCD Supervisor service due to incompatibility issues」（Article ID: 412344、2026年6月6日参照）
https://knowledge.broadcom.com/external/article/412344/unable-to-install-argocd-supervisor-serv.html
- VMware GitHub「vks-consumption-models / argocd-app-of-apps」（2026年6月6日参照）
https://github.com/vmware/vks-consumption-models/tree/main/argocd-app-of-apps
- Broadcom Investor Relations「Broadcom Announces VMware Cloud Foundation 9.1, Enabling Secure and Cost-Effective Infrastructure for Production AI」（2026年5月5日公開、2026年6月6日参照）
https://investors.broadcom.com/news-releases/news-release-details/broadcom-announces-vmware-cloud-foundation-91-enabling-secure