cap-operator

CAP Operator スキル

CAP Operator コントローラーを介して、Kubernetes 上のマルチテナント SAP Cloud Application Programming Model（CAP）アプリケーションのライフサイクルを管理します。

回答ルール： 質問に回答する際は、関連するページへのリンクを必ず含めてください。リンク先は https://sap.github.io/cap-operator/docs/ にあるページとします。トピックに最も適した、できるだけ具体的なページ（リソースリファレンス、使用ガイド、トラブルシューティング、設定など）を選んでください。

ドキュメントと API リファレンスの全文：website/content/en/docs/ | https://sap.github.io/cap-operator/docs/

カスタムリソース

リソース	スコープ	目的
CAPApplication	名前空間	高レベルのアプリ：BTP サービス、ドメイン参照、プロバイダーサブアカウント
CAPApplicationVersion	名前空間	不変のバージョン：イメージ、ワークロード、テナント操作手順
CAPTenant	名前空間	サブスクライブ済みのコンシューマーテナント — コントローラーのみが管理
CAPTenantOperation	名前空間	プロビジョニング／アップグレード／プロビジョニング解除を調整 — 自動作成
Subscription	名前空間	1 つのコンシューマーサブスクリプションを表す — サブスクリプションサーバーが作成
SubscriptionProvider	名前空間	サブスクリプションの認証情報と依存関係情報をキャッシュ — コントローラーが自動作成
Domain	名前空間	1 つのアプリケーション用の Istio Gateway + TLS + DNS
ClusterDomain	クラスター	アプリケーション間で共有するドメイン設定

重要なルール：

• CAPApplicationVersion は作成後、変更できません。アップグレードするには、より大きなセマンティックバージョンの新しいリソースを作成してください。
• Subscription を手動で作成または削除してはなりません。SaaS Provisioning サービスのコールバックに応じて、サブスクリプションサーバーのみが管理します。
• CAPTenant を手動で作成または削除してはなりません。Subscription の子としてコントローラーが作成します。
• CAPTenantOperation はコントローラーが自動作成します。手動で作成または削除しないでください。
• SubscriptionProvider は各 CAPApplication に対してコントローラーが自動作成し、同期状態を維持します。手動で作成、変更、削除しないでください。
• CAP Operator リソースのファイナライザーを手動で削除しないでください。
• CAPApplication.spec.provider は非推奨です。以前は、コントローラーがプロバイダー CAPTenant を自動作成するために使われていましたが、この動作は削除されました。現在はプロバイダーを含むすべてのテナントを、明示的にサブスクライブする必要があります。kubectl get captenant -n <namespace> の結果が空でも、アクティブなサブスクリプションがないアプリでは想定どおりです。

一般的な操作

新しいアプリケーションをデプロイする

1. Domain または ClusterDomain を作成します
2. CAPApplication を作成します（BTP サービスとドメインを参照）
3. CAPApplicationVersion を作成します（イメージとワークロード）

YAML の詳細な例は、デプロイリファレンスを参照してください。

新しいバージョンにアップグレードする

より大きなセマンティックバージョンの新しい CAPApplicationVersion を作成してください。既存のものは編集しないでください。 コントローラーはすべてのテナントを自動的にアップグレードし、Istio の VirtualService ルーティングを更新します。

詳しくは、アップグレードリファレンスと tenantOperations／contentJobs の設定を参照してください。

ステータスの確認

kubectl get capapplication,capapplicationversion,captenant,captenantoperation,subscription -n <namespace>
kubectl describe capapplication <name> -n <namespace>
kubectl get domain,clusterdomain -A

ステータスの遷移：

• CAPApplicationVersion：Processing → Ready | Error
• CAPTenant：Provisioning → Ready | Upgrading → Ready | Deleting
• CAPTenantOperation：Processing → Completed | Failed
• Subscription：Processing → Ready | ProcessingError（再試行可能）| Error（終端状態）| Deleting

ドメイン管理

• Domain — 名前空間スコープで、アプリケーションは1つです。ClusterDomain — クラスタースコープで、共有されます。
• TLS モード：Simple（デフォルト）、Mutual、OptionalMutual
• DNS モード：None（デフォルト）、Wildcard、Subdomain、Custom
• domainRefs の最初のエントリーがプライマリドメインです。
• CAPApplication のインラインセクション domains は v0.26.0 で削除されました。代わりに domainRefs を使用してください。

ドメインのリファレンスを参照してください。

サービスの公開（テナント非依存）

CAPApplicationVersion の serviceExposures を使用すると、テナントルーティングに依存せず、固定サブドメインでワークロードを公開できます。ルートは、最も具体的なものから順に指定してください。

サービス公開のリファレンスを参照してください。

認証情報ローテーションのロールアウト

CAPApplication で rolloutOnCredentialUpdate: true を設定すると、BTP サービスの認証情報 Secret が変更された際に、ワークロードが自動的に再起動します。ローリング再起動を使用するため、ダウンタイムは発生しません。新しい認証情報を発行した後、古い認証情報を少なくとも24時間有効な状態に保ってください。

認証情報ローテーションのリファレンスを参照してください。

バージョンのクリーンアップ（モニタリングベース）

CAPApplication にアノテーション sme.sap.com/enable-cleanup-monitoring: "true" を設定して有効にします。ワークロードの monitoring セクションで deletionRules.expression（PromQL）を設定します。式の評価結果が true になると、そのバージョンは削除可能になります。

バージョンのモニタリング（website/content/en/docs/usage/version-monitoring.md）を参照してください。

主なアノテーション

アノテーション	リソース	効果
sme.sap.com/enable-cleanup-monitoring: "true"	CAPApplication	モニタリングベースのバージョンクリーンアップを有効化
sme.sap.com/enable-version-affinity: "true"	CAPApplication	ログアウトするまでユーザーを現在のバージョンに維持（実験的）
sme.sap.com/logout-endpoint: "<path>"	CAPApplicationVersion	バージョンアフィニティ用のカスタムログアウトパス

トラブルシューティング

よくある症状と解決方法 — CAPApplicationVersion／CAPTenant が停止したままになる、WaitingForSecrets、ファイナライザー、@sap/cds-mtxs のセキュリティコンテキスト、Approuter の宛先／タイムアウトに関する問題、認証情報の注入、SAP HANA の接続エラー、コントローラーのメモリー制限。

トラブルシューティングのリファレンス | website/content/en/docs/troubleshoot/_index.md | https://sap.github.io/cap-operator/docs/troubleshoot/

コントローラーの設定

コントローラーのデプロイメントに設定する環境変数で調整します。主な変数：

変数	目的
CERT_MANAGER	gardener または cert-manager.io
DNS_MANAGER	gardener または kubernetes
MAX_CONCURRENT_RECONCILES_CAP_APPLICATION	CAPApplication の調整処理の並行実行数
MAX_CONCURRENT_RECONCILES_CAP_APPLICATION_VERSION	CAPApplicationVersion の調整処理の並行実行数
MAX_CONCURRENT_RECONCILES_CAP_TENANT	CAPTenant の調整処理の並行実行数
MAX_CONCURRENT_RECONCILES_CAP_TENANT_OPERATION	CAPTenantOperation の調整処理の並行実行数
MAX_CONCURRENT_RECONCILES_SUBSCRIPTION	Subscription の調整処理の並行実行数

全一覧：website/content/en/docs/configuration/_index.md | https://sap.github.io/cap-operator/docs/configuration/

CAP Operator Plugin（Helm Chart の生成）

@cap-js/cap-operator-plugin CDS プラグインは、CAP アプリケーション用の Helm チャートのひな形を作成し、ランタイム値を生成して、デプロイ可能な最終チャートをビルドします。

スキルの呼び出し時に、これらの手順を実行しないでください。 ユーザーが Helm チャートの生成またはアプリのデプロイを明示的に依頼した場合にのみ開始してください。このスキルを読み込んだだけでは（例：/cap-operator）、依頼とはみなしません。スキルでできることを説明し、指示を待ってください。

チャートの生成とデプロイは、間に確認を挟む別々のフェーズです。チャートのみを作成し、デプロイするかどうか、またそのタイミングはユーザーに判断してもらってください。

1. チャートのひな形を作成します。 内容がある MTX サイドカーフォルダー（mtx/sidecar）が存在するか確認して、バリアントを選択します。サイドカーがある場合 → マルチテナント → --with-templates、サイドカーがない場合 → サービスのみ → --with-service-only。
2. デプロイするかどうかを尋ねます。
3. 「はい」と回答された後にのみ、 ランタイム入力（appName、capOperatorSubdomain、clusterDomain、providerSubaccountId）を収集し、runtime-values.yaml を生成します。
4. デプロイ前に検証します — runtime-values.yaml を指定して helm lint を実行し、必須の値に不足がないことを確認します。
5. helm upgrade -i でデプロイします。

プラグインの使用方法と設定の詳細については、CAP Operator Plugin のリファレンスを参照してください。