背景と理由 — 私のアプローチを変えた深夜2時のデプロイ悪夢
3ヶ月前の深夜2時、Slackが突然鳴り響いた。本番環境の決済サービスがクラッシュしていたが、ステージング環境はまったく正常だった。環境間のKubernetesマニフェストをdiffしたところ、原因が判明した。ステージングはresources.limits.memory: 256Mi、本番は512Miだったのだ。2週間前に誰かが本番の設定を手動でパッチしており、トラフィックスパイクが来るまで誰も気づかなかった。
このインシデントが、私にKubeVelaの必要性を痛感させた出来事だった。環境ドリフト——ステージング、本番、オンプレクラスターが時間の経過とともに少しずつズレていく現象——は、Kubernetesの障害モードの中でも最も多くの本番インシデントを静かに引き起こしている。地味な問題だが、解決すれば状況が一変する。
KubeVelaはKubernetes上にOpen Application Model（OAM）仕様を実装したCNCFプロジェクトだ。このアーキテクチャは明確な分離線を引く。何をデプロイするかはアプリ開発者の関心事であり、どのようにデプロイするかはプラットフォームチームの領域だ。OAMはこの分離を4つのプリミティブとして定義している：
- Component — アプリの正体（Webサービス、ワーカー、データベースなど）
- Trait — アプリが必要とするもの（オートスケーリング、Ingress、サイドカーインジェクション）
- Policy — デプロイ先と方法（環境固有のオーバーライド、マルチクラスター配置）
- Workflow — デプロイ手順（カナリア、承認ゲート、プログレッシブロールアウト）
結果として、1つのApplication定義で開発、ステージング、本番、クラウド、オンプレミスへ一貫したデプロイが実現する——環境ごとに別々のYAMLファイルを管理する必要はない。
インストール
前提条件
稼働中のKubernetesクラスター（1.22以降）、設定済みのkubectl、そしてHelm 3.xが必要だ。EKS、GKE、AKS、k3s、ベアメタルなど、どの構成でも動作する。
KubeVela CLIのインストール
curl -fsSl https://kubevela.io/script/install.sh | bash
vela version再現性のために特定バージョンを固定する場合：
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.9.0クラスターへのKubeVela Coreインストール
helm repo add kubevela https://kubevela.github.io/charts
helm repo update
helm install --create-namespace -n vela-system kubevela kubevela/vela-coreしばらく待ってから、すべてが起動していることを確認する：
kubectl wait --for=condition=Ready pods --all -n vela-system --timeout=300s
kubectl get pods -n vela-systemkubevela-vela-coreコントローラーとcluster-gatewayポッドが両方Runningになっていれば成功だ。Web UIも使いたい場合は、VelaUXアドオンを有効化する：
vela addon enable velaux設定 — 1つのApp仕様、すべての環境に対応
最初のOAMアプリケーションの定義
あの夜、これがあれば助かっていたというものがこれだ。ステージングと本番用に別々のYAMLファイルを管理する代わりに、環境固有のパッチを含む1つのApplicationを定義する：
# payment-service.yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: payment-service
namespace: production
spec:
components:
- name: payment-api
type: webservice
properties:
image: myregistry/payment-api:v1.2.3
port: 8080
cpu: "0.5"
memory: "512Mi"
traits:
- type: scaler
properties:
replicas: 3
- type: gateway
properties:
domain: payment.myapp.com
http:
"/": 8080
policies:
- name: staging-override
type: override
properties:
selector:
- payment-api
components:
- name: payment-api
type: webservice
properties:
cpu: "0.2"
memory: "256Mi"
traits:
- type: scaler
properties:
replicas: 1本番の設定値（memory: 512Mi、3レプリカ）が唯一の信頼できる情報源だ。ステージングは差分だけをパッチする名前付きポリシーを持つ。ドリフトなし、想定外なし。
デプロイする：
kubectl apply -f payment-service.yamlマルチクラスターデプロイ
クラウドとオンプレのクラスターを両方運用している場合は、まずKubeVelaのクラスターマネージャーに登録する：
vela cluster join /path/to/prod-kubeconfig --name prod-cluster
vela cluster join /path/to/dr-kubeconfig --name dr-cluster
vela cluster list次に、Applicationにtopologyポリシーを追加する：
policies:
- name: multi-cluster
type: topology
properties:
clusters:
- prod-cluster
- dr-cluster
namespace: productionWorkflowによる承認ゲートの追加
このWorkflow機能のおかげで、何度か失敗のプッシュを防げた。ステージングと本番の間に必須の承認ステップを挿入する：
workflow:
steps:
- name: deploy-staging
type: deploy
properties:
policies:
- staging-override
- name: human-approval
type: suspend
- name: deploy-production
type: deploy
properties:
policies:
- multi-cluster実行はtype: suspendで停止する。ステージングが正常であることを確認したら、再開する：
vela workflow resume payment-service -n production深夜2時に本番前の必須チェックポイントを設けることは過剰な心配ではない——軽微なインシデントと重大な障害の差がそこにある。
検証とモニタリング
アプリケーションの健全性確認
1つのコマンドで全体像が把握できる：
vela status payment-service -n productionコンポーネントごと、すべてのクラスターにわたって健全性が表示される：
概要:
名前: payment-service
名前空間: production
サービス:
- 名前: payment-api
クラスター: prod-cluster 名前空間: production
タイプ: webservice
正常 準備完了:3/3
Traits:
✅ scaler
✅ gatewayログとポートフォワーディング
Pod名を探し回ることなく、特定コンポーネントのログをストリーミングする：
vela logs payment-service --component payment-api -n productionインターネットに公開せずにAPIにローカルアクセスしたい場合：
vela port-forward payment-service -n productionWebダッシュボード
VelaUXを有効化済みなら、ダッシュボードを表示する：
vela port-forward -n vela-system addon-velaux 8080:80http://localhost:8080を開くと、すべてのアプリケーション、ワークフロー状態、クラスター、コンポーネント履歴をビジュアルマップで確認できる。深夜3時にマルチクラスターのインシデントが発生したとき、ダッシュボードはkubectlの出力をスクロールするより断然便利だ。
Prometheusメトリクス
本番環境のオブザーバビリティのために、KubeVelaはコントローラーのメトリクスを公開している。コントローラーにポートフォワードして確認する：
kubectl port-forward -n vela-system deployment/kubevela-vela-core 8080:8080
curl http://localhost:8080/metrics | grep vela_アラートを設定すべき3つのメトリクス：
vela_application_phase— 各アプリの現在フェーズ（running、failed、stopped）vela_reconcile_duration_seconds— 調整レイテンシ（スパイクはクラスターの負荷を示す）vela_reconcile_errors_total— 累積エラー数（増加し続けるカウンターは調査が必要）
これらをGrafanaに連携すれば、手探り状態から脱却できる。Podの健全性だけでなく、コミットからクラスターまでのデリバリーパイプライン全体の完全な可視性が手に入る。
3ヶ月前にこれが整っていれば、メモリの不一致が本番環境に到達することはなかった。トラフィックスパイクが来るずっと前に、設定ドリフトのアラートが発火していたはずだ。それがKubeVelaの真の価値だ——単なるツールではなく、設計によって組み込まれた運用の規律である。
