Vantage リソースのステータス、および問題が発生している ArgoCD アプリケーションのステータスを取得してください。
オペレーター および CRD
リソース不足の問題を解消した後で再試行を強制する
Vantage リソース自体のイベントに応答します。そのため、リソース外での状態変更 (Key Vault の権限、ネットワークポリシー、外部サービス) はリコンシルのトリガーになりません。Vantage リソースは変更可能ですが、Vantage のインストールを再試行するには、リソースに vantage.abbyy.com/reprocess (任意の値) というアノテーションを付与する必要があります。
対処法。 Vantage リソースに vantage.abbyy.com/reprocess (任意の値) というアノテーションを付与し、プレフライト フェーズからリコンシルを強制的にやり直します。
Vantage リソースが Progressing のまま止まる
kubectl describe vantages.vantage.abbyy.com $release_name -n $install_namespace を実行すると、Progressing=True が長時間表示されたままで、Ready が True になりません。
診断。 リソースの status.degradationReasons[] を確認してください。問題が発生している component はそこに オペレーター によって表示されます。次に、対応する ArgoCD アプリケーションを確認します:
Vantage リソースに vantage.abbyy.com/reprocess のアノテーションを追加してください (再試行を強制する) 。
オペレーター が新しい Vantage リソースを検知しない
Vantage リソースを適用し、kubectl get vantages では表示されるものの、オペレーター がステータスをまったく報告しません。
診断。 オペレーター が実行中で、リコンサイルを行っていることを確認してください。
Vantage リソースを監視します。チャートには、監視対象の名前空間を制限するための値は用意されていません。オペレーターが実行中なのに、ログに対象リソースに対するリコンシルの試行がまったく表示されない場合は、CRD がオペレーターの想定するバージョン (vantage.abbyy.com/v1alpha1) になっていること、およびクラスター内にオペレーターのインスタンスが 1 つだけインストールされていることを確認してください。チャートが実際に受け付ける値を確認するには、helm show values $charts_uri/vantage-operator --version $operator_version を実行してください (Helm チャートの値) 。
CRD の適用がバリデーションエラーで失敗する
kubectl apply により、Vantage リソースが CEL のバリデーションメッセージ付きで拒否されます。
Diagnosis. このエラーメッセージは、CRD の CEL ルールによるものです。よくある原因として、enabled: true なのに destination がない ociMigration ブロックや、keepPreviousVersion: true なのに previousVersion がない techcore ブロックがあります。
Fix. バリデーションメッセージで指定されている field を設定してください。完全なバリデーションルールについては、API リファレンスを参照してください。
OCI 移行
OCI 移行ジョブが開始されない
Vantage リソースが Progressing のままで、インストール先の名前空間に $release_name-oci-migration という名前のジョブが存在しません。
診断。 operator のログで operator のプレフライトチェックを確認し、あわせてリソースが劣化状態になっている理由を確認してください。ジョブが作成されるのは、プレフライトチェックに合格した後だけです。
対処法。 失敗しているプレフライトチェックを解消してください。プレフライトチェックでは、シークレットの設定を含む構成が検証されるため、まずはシークレットプロバイダーにすべての必須エイリアスが存在することを確認してください (Secrets and Key Vault) 。
OCI 移行ジョブは実行されるものの失敗する
kubectl -n $install_namespace get jobs を実行すると移行ジョブは表示されますが、Complete 状態になりません。
診断。 ジョブのログを確認します。
vantage.ociMigration.sources[] エントリの credentialsRef.name シークレットまたは Username/password を確認してください) か、宛先に push できなかった (vantage.ociMigration.destination の認証情報と、Azure Workload Identity を使用している場合は workload identity の RBAC を確認してください) かのいずれかです。ジョブの pod 自体がそのイメージをまったく pull できない場合は、ImagePullBackOff で停止した podを参照してください。
イメージの取得
pod が ImagePullBackOff のままになる
ImagePullBackOff または ErrImagePull が報告され、kubectl describe pod に registry からの unauthorized: authentication required が表示されます。
診断。 問題のある pod と registry エラーを確認します。
- オペレーター pod:
--set "manager.imagePullSecrets[0].name=my-pull-secret"を指定して、vantage-operatorリリースをアップグレードします。 - OCI 移行ジョブ: プルシークレットを持つ ServiceAccount でジョブを実行するか (
vantage.ociMigration.serviceAccountName=my-service-account) 、ソースエントリでシークレットを参照します (vantage.ociMigration.sources[0].credentialsRef.name=my-pull-secret) 。 - Vantage ワークロード:
vantage.serviceAccountNameで指定された ServiceAccount のimagePullSecretsにプルシークレットを追加します。問題が発生している pod がdefaultを含む別の ServiceAccount を使用していると報告している場合は、その ServiceAccount にプルアクセスを付与するか、意図した Vantage ServiceAccount を使用するようコンポーネントを設定します。 - AKS の場合: プルシークレットの代わりに、クラスターの kubelet ID にそのレジストリの
AcrPullを付与します。
Secrets
pod が MountVolume.SetUp failed for volume "secrets-store" エラーで起動しない
vantage.secrets.azure.identityModeで選択された ID に、指定されたシークレットまたは証明書への読み取りアクセス権がありません。- Key Vault オブジェクト名が Vantage で想定されるエイリアスと一致しておらず、
objectsマッピングも指定されていません。 - CSI ドライバー用の Azure プロバイダーがインストールされていません。
get 権限があることを確認してください。Key Vault オブジェクト名がエイリアスと異なる場合は、vantage.secrets.azure の下で objects マッピングを指定してください。各モードでどの ID が使用されるかについては、Identity modes を参照してください。
対となる TLS シークレットが不足しています
authSigningTlsCrt、authSigningTlsKey、authDeactivatedTlsCrt、authDeactivatedTlsKey がすべて存在することを確認してください。シークレットと Key Vault → 証明書エイリアスを参照してください。
Kubernetes Secret provider の プレフライト が失敗する
forbidden エラーで失敗します。
診断。 オペレーターは プレフライト 中に $install_namespace 内のネイティブ Secret を読み取ります。指定された Secret が存在しない、objects のマッピングが誤った名前を指している、Secret に想定されるデータキーが含まれていない、またはチャートによって作成された RoleBinding で、インストールされたオペレーターの ServiceAccount が正しく指定されていない可能性があります。
影響を受ける Secret のいずれかに対するオペレーターの権限を確認してください:
vantage.secrets.kubernetes.objects を シークレットエイリアス一覧 と照合します。認可に失敗する場合は、Vantage チャートの operator.namespace と operator.controllerManagerServiceAccount の値が、インストールされているオペレーターを指していることを確認してください。外部シークレットコントローラーが Secrets を作成している場合は、新たにオペレーターのリコンシルを強制する前に、同期が正常に完了したと報告されるまで待機してください。
データベース
PostgreSQL ワークロードで DataProvider が見つからないと表示される
DataProvider '<value>' not found エラーが発生して失敗します。
診断。 vantage.databaseProvider では大文字と小文字が区別されます。PostgreSQL ランタイム プロバイダーの名前は、正確に PostgreSQL です。
修正。 次のように設定します。
Postgresql や PostgreSql のような値は、ランタイムでは無効です。修正した値を適用し、強制的に再試行してください。
PostgreSQL スキーマが最新の状態ではありません
postgres database schema is not up to date またはマイグレーションのバージョン競合により起動に失敗します。
診断。 複数のサービスが同じ論理 PostgreSQL データベースを使用しています。各サービスはそれぞれ独自のマイグレーション履歴を保持するため、個別のデータベースを使用する必要があります。
対処方法。 データベースエイリアスごとに個別のデータベースを作成してください。汎用の Database__ConnectionString キーを使用するワークロードでは、個別の Kubernetes Secrets を作成し、vantage.secrets.kubernetes.objects を使用して各エイリアスをマッピングしてください。詳細は PostgreSQL とサービスごとの Secrets を参照してください。
ArgoCD
インストール後、ArgoCD application が OutOfSync と表示される
kubectl get application -A を実行すると、オペレーター はそれ以外では Ready を報告しているにもかかわらず、オペレーター が管理する application の 1 つが OutOfSync と表示されます。
診断。 application の status.conditions[] を確認します。
Vantage リソース (または vantage-selfhosted Helm リリース) を通じて更新してください。基盤となる ArgoCD Application オブジェクトを直接編集しないでください。
ArgoCD ApplicationSet の同期が止まる
KEDA と Prometheus
ScaledObject リソースでは HPA を作成できません
Ready=False または ScaledObjectCheckFailed を報告し、ArgoCD では影響を受けるワークロードアプリケーションが Degraded と表示されます。
診断。 インストールされている KEDA のバージョンと、ScaledObject のイベントを確認します。
HPAのメトリクスに <unknown> が表示される
kubectl get hpa で Vantage のメトリクスが <unknown> と表示され、ワークロードが想定どおりにスケールしません。
診断。 ScaledObject リソースは http://prometheus-operated.observability.svc.cluster.local:9090 にクエリを実行します。Service が存在しない、Vantage の ServiceMonitor が選択されていない、またはサービスメッシュによってスクレイプがブロックされている可能性があります。
修正。 Prometheus Service が存在すること、Vantage のターゲットが UP であること、および observability チャートの値がトップレベルにあることを確認してください。
Skillのインストール
インストール後に Ready と表示されても Skill が表示されない
Vantage リソースは Ready と表示され、Vantage にアクセスできるにもかかわらず、想定していた Skill が表示されず、ArgoCD にも Skill 関連の項目が何も表示されません。
診断。 Skill は、ArgoCD では表示されない別個の Kubernetes job によってインストールされるため、argocd app list には表示されません (このページ上部の診断用抽出結果にも含まれません) 。その job は Ready になった後も引き続き実行中の場合がありますが、その間も Vantage は使用できます。job を確認してください:
Complete に達するまで待機してください。ジョブが失敗した場合は、根本的なエラーを特定して解決するために、そのログを確認してください。失敗が続く場合は、ジョブのログをオペレーターのログとあわせて ABBYYアカウントチームに提供してください。
サービスメッシュと Ingress
ingress から 503 が返され、アプリケーションのトラフィックがブロックされる
Ready を報告しているにもかかわらず、https://$your_vantage_hostname から 503 が返されます。
診断。 AKS で組み込みの Istio ingress を使用している場合、外部ゲートウェイが正常でない可能性や、TLS シークレットが ingress.tls.secretName と一致していない可能性があります。顧客管理の ingress を使用している場合、コントローラーに一致するルートがない、バックエンドのサービス名またはポートが誤っている、または TLS 証明書の準備が完了していない可能性があります。
対処法。 Istio の場合は、ゲートウェイと TLS シークレットを確認します。
kubernetes.io/tls 型のシークレットが外部ゲートウェイの名前空間に存在し、その証明書が dnsRecord に対して有効であることを確認します。
顧客側で管理する ingress の場合は、コントローラーのログとルートのステータスを確認します。ルートのホスト名が vantage.dnsRecord と一致し、TLS が使用可能な状態であり、各バックエンド Service が $install_namespace に存在することを確認します。ingress と TLS を Configure するを参照してください。
サインインのリダイレクトまたは OIDC メタデータで http:// が使用される
/auth2/.well-known/openid-configuration で http:// の issuer やエンドポイントが通知されます。
診断。 TLS は ingress コントローラーで終端されていますが、認証ワークロードが転送された HTTPS スキームを正しく認識していません。
修正。 ingress が X-Forwarded-Proto: https を送信していること、および auth-identity、auth-adminapi2、api-gateway、api-registry のアプリケーション コンテナーに次が設定されていることを確認してください。
/metrics-text の Prometheus スクレイプターゲットが DOWN と表示される
DOWN と表示されます。
診断。 Istio では、Prometheus pod にサイドカーがないか、Istio の出力証明書が /etc/prom-certs/ に書き込まれていない可能性があります。Linkerd では、厳格な認可ポリシーによって、メッシュに参加していない Prometheus からの平文のスクレイプがブロックされる場合があります。
prometheus、config-reloader、istio-proxy) が含まれており、OUTPUT_CERTS: /etc/istio-output-certs を含む proxy.istio.io/config アノテーションが存在することを確認してください。Linkerd では、observability 名前空間へのインジェクションを有効にするか、お使いのポリシーで必要なクライアント証明書を使用するように ServiceMonitor と Prometheus を設定してください。Prometheus を使用した Monitoring。
Day-2 の運用
アップグレード後、オペレーター では新しいバージョンが報告されるのに、Vantage はまだ古いバージョンのままです
status.installedVantageVersion が変わりません。
Diagnosis. vantage-operator と vantage-selfhosted の releases が同じ新しいバージョンになっていないか、ArgoCD がまだコンポーネントごとの変更を適用中である可能性があります。両方の Helm releases と、ArgoCD application の同期ステータスを確認してください。
Fix. 両方の charts を同じバージョンにアップグレードしてから、ArgoCD applications の同期が完了するまで待ちます。オペレーター に Degraded condition が表示されている場合は、その reason をたどって障害が発生している component を特定し、問題を解決してから、再試行するために Vantage resource に vantage.abbyy.com/reprocess の annotation を追加します (再試行を強制する) 。Upgrading を参照してください。
次のステップ
アーキテクチャ
診断時に役立つ、リコンシルのたびにオペレーターが行う処理の説明。
既知の制限事項
実際にバグかどうかの判断材料となる、現在の制約事項。