このページでは、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 リポジトリの認証タイプを none
、gcenode
、または 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 origin
や warning: Could
not find remote branch BRANCH_NAME to clone.
などのエラーがある git-sync
コンテナを確認します。指定しない場合、デフォルトのブランチは master
に設定されます。
無効な Git、Helm、または OCI の認証情報
Config Sync ログで、git-sync
、helm-sync
、oci-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-sync
、oci-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
次のステップ
- まだ問題が解決しない場合は、既知の問題かどうかを確認してください。