信頼できる情報源への接続のトラブルシューティング

このページでは、Config Sync が信頼できる情報源との接続を確立できない場合に発生する問題を解決する方法について説明します。

認証の問題

認証が失敗すると、Config Sync は信頼できる情報源に接続できません。以下の各セクションでは、認証に関する問題を解決する方法について説明します。

Git サーバーのサーバー証明書の検証に失敗した

プライベート Git サーバーへの接続では、TLS を使用してサーバーの信頼性を検証します。この検証を行うには、ルート認証局と、Git サーバーの ID を証明する中間認証局を識別する証明書が必要です。Git サーバー証明書の検証に失敗した場合は、信頼チェーンを確立できません。

サーバー証明書の検証に失敗したことを示すエラーが表示された場合は、次のいずれかの原因が考えられます。

  • 認証局証明書(CACert)が指定されていない。この問題を解決するには、CACert を Secret として追加し、RootSync オブジェクトまたは RepoSync オブジェクトの spec.git.caCertSecretRef フィールドで Secret を参照します。
  • CACert が不完全。この問題を解決するには、CACert Secret を修正して、ルート証明書と中間証明書を含む完全な信頼チェーンを含めるようにします。
  • CACert が無効。この問題を解決するには、サーバーによって提示された証明書で指定されたリンクから証明書チェーンをダウンロードし、CACert Secret を更新します。

Git Secret をマウントできない

git-sync コンテナがリポジトリを Secret と同期しようとしたときに次のエラーが発生した場合、Git Secret が git-sync コンテナに正常にマウントされません。

KNV2004: unable to sync repo Error in the git-sync container: ERROR: can't configure SSH: can't access SSH key: stat /etc/git-secret/ssh: no such file or directory: lstat /repo/root/rev: no such file or directory

これは、Git リポジトリの認証タイプを nonegcenode、または gcpserviceaccount から Secret を必要とするタイプに切り替えると発生する可能性があります。

この問題を解決するには、次のコマンドを実行して Reconciler Manager と Reconciler を再起動します。

# Stop the reconciler-manager Pod. The reconciler-manager Deployment spins
# up a new Pod which can pick up the latest `spec.git.auth`.
kubectl delete po -l app=reconciler-manager -n config-management-system

# Delete the reconciler Deployments. The reconciler-manager recreates the
# reconciler Deployments with correct volume mount.
kubectl delete deployment -l app=reconciler -n config-management-system

構成に関する問題

構成に問題があると、Config Sync が信頼できる情報源に接続できなくなることが頻繁に発生します。以下の各セクションでは、構成に関する一般的な問題を特定して解決する方法について説明します。

無効なグラフ名

Helm リポジトリから同期する場合は、spec.helm.chart に正しい値が設定されていることを確認してください。チャート名に、リポジトリ名、チャートのバージョン、または .tgz が含まれていません。チャート名は helm template コマンドを使用して確認できます。

無効な構成ディレクトリ

構成ファイルに誤りがないか確認します(ConfigManagement オブジェクトの policyDir の値や、RootSync オブジェクトまたは RepoSync オブジェクトの spec.git.dir または spec.oci.dir の値の誤りなど)。ディレクトリの値は、表示された KNV2004 エラー メッセージに含まれます。Git リポジトリまたは OCI イメージと照合して、値を確認します。

無効な Git ブランチ

ログで、Remote branch BRANCH_NAME not found in upstream originwarning: Could not find remote branch BRANCH_NAME to clone. などのエラーがある git-sync コンテナを確認します。指定しない場合、デフォルトのブランチは master に設定されます。

無効な Git、Helm、または OCI の認証情報

Config Sync ログで、git-synchelm-syncoci-sync の各コンテナに次のいずれかのエラーがないか確認します。

  • Could not read from remote repository. Ensure you have the correct access rights and the repository exists.
  • Invalid username or password. Authentication failed for ...
  • 401 Unauthorized

Git リポジトリの場合は、Git 認証情報と git-creds Secret が正しく構成されていることを確認します。

Helm リポジトリの場合、Helm 認証情報が正しく構成されていることを確認します。

OCI イメージの場合、OCI 認証情報が正しく構成されていることを確認します。

無効な Git リポジトリ URL

ログで、Repository not found などのエラーがある git-sync プロセスを確認します。

正しい URL 形式を使用していることを確認してください。たとえば、SSH 鍵ペアを使用して Git リポジトリへの認証を行っている場合は、Config Sync を構成するときに Git リポジトリに入力する URL が SSH プロトコルを使用していることを確認してください。

無効な Helm リポジトリ URL

ログで、...not a valid chart repository などのエラーがある helm-sync プロセスを確認します。Helm リポジトリの URL を確認するには、helm template コマンドを使用します。

無効な OCI レジストリ URL

RootSync または RepoSync オブジェクトの spec.oci.image フィールドまたは spec.oci.dir フィールドに無効な値が設定されていると、接続の問題が発生することがあります。これらの値が正しいことを確認します。たとえば、OCI レジストリから同期する場合、oci:// で始まる URL を使用する必要があります。

詳細については、oci-sync コンテナのログを確認することもできます。

ネットワークに関する問題

問題がクラスタのネットワークに関連していると思われる場合は、次のトラブルシューティング手順を実施してください。

ホストを解決できませんでした: github.com

Config Sync が Git リポジトリに接続するときに、DNS を使用して指定されたホスト名の IP を解決します。ホストを解決できない場合は、通常、DNS またはクラスタ ネットワーキングに問題があることを示します。

問題を診断するには、GKE での DNS のトラブルシューティングをご覧ください。

クラスタ内から Git リポジトリにアクセスできない

git-sync コンテナのログから、リポジトリに到達できないことを示すエラーがスローされることがあります(例: ssh: connect to host source.developers.google.com port 2022: Network is unreachable。問題を解決するには、クラスタのファイアウォールまたはネットワーク構成を調整します。

ソース API リクエストの数が多い

Config Sync は、マルチ インスタンス化戦略を使用して、テナント ドメインと障害ドメインをスケーリングして分離します。このため、各 RootSync オブジェクトと RepoSync オブジェクトはそれぞれ独自の Reconciler インスタンスを取得します。各 Reconciler インスタンスには、ソース固有のサイドカー git-syncoci-sync、または helm-sync があります。これらのサイドカーは信頼できる情報源をポーリングします。RootSync オブジェクトまたは RepoSync オブジェクトを追加すると、整合性ソースをポーリングする Reconciler により API リクエストの数が増加します。そのため、同じ信頼できる情報源をポーリングする RootSync オブジェクトと RepoSync オブジェクトが多数あると、ソースサーバーに多大なトラフィック負荷が発生する可能性があります。

この問題を軽減するには、次のいずれかの戦略を検討してください。

  • 複数の RootSyncs オブジェクトまたは RepoSync オブジェクトを組み合わせて、ソース API リクエストを行う Reconciler の数を削減する。
  • ソースタイプを Git から OCI に変更する。Artifact Registry などの OCI リポジトリは、サーバー レプリカ間の同期を必要とせずに水平方向にスケーリングできるため、ほとんどの Git サーバーよりもスケーリングしやすい傾向があります。

その他の問題

このセクションでは、前のセクションに該当しないその他の問題について説明します。

Git ロックファイルが残っている

git-sync から次のエラーが表示された場合は、前の git 呼び出しが失敗し、コンテナにロックファイルが残っている可能性があります。

KNV2004: error in the git-sync container: ... fatal: Unable to create '/repo/source/.git/shallow.lock': File exists. ...

この問題を解決するには、影響を受ける Reconciler Pod を再起動して、新しいエフェメラル ボリュームを Pod に割り当てます。

kubectl delete pod -n config-management-system RECONCILER_NAME

次のステップ

  • まだ問題が解決しない場合は、既知の問題かどうかを確認してください。