Config Controller のトラブルシューティング

このページでは、Config Controller に関する問題の解決方法について説明します。

インストールのトラブルシューティング

default という名前のネットワークがない

Config Controller インスタンスを作成する際に、デフォルトネットワークを使用できないというエラーが表示される場合があります。

Error 400: Project \"PROJECT_ID\" has no network named \"default\"., badRequest\n\n  on main.tf line 35, in resource \"google_container_cluster\" \"acp_cluster\"

このエラーは、--network フラグを使用して既存のネットワークを指定しなかった場合や、Google Cloud でデフォルトネットワークが削除または無効にされている場合に発生します。デフォルトでは、Config Controller は、デフォルトネットワークで Config Controller インスタンスをサポートする Google Kubernetes Engine（GKE）Enterprise エディションクラスタを作成します。

既存のネットワーク内にインスタンスを作成する場合は、Config Controller インスタンスの作成時に --network=NETWORK フラグを追加してください。NETWORK は既存のネットワークの名前に置き換えます。

Config Controller インスタンスをデフォルトネットワーク内に作成する場合は、次のコマンドを使用してデフォルトネットワークを再作成します。

gcloud compute networks create default --subnet-mode=auto

このコマンドを使用するには、--subnet-mode=auto フラグを使用して自動サブネットを有効にする必要があります。

デフォルトネットワークを再作成した後は、Config Controller インスタンスの作成時に --network フラグを省略できます。

MasterIpv4CidrBlock の値が無効

Config Controller の作成では、コントロールプレーンの IPv4 CIDR に 172.16.0.128/28 のデフォルトサブネットを使用します。IPv4 CIDR ブロックに競合があると、Config Controller の作成は失敗し、次のエラーが返されます。

Cloud SSA\n\nError: Error waiting for creating GKE cluster: Invalid value for field PrivateClusterConfig.MasterIpv4CidrBlock: 172.16.0.128/28 conflicts with an existing subnet in one of the peered VPCs.

このエラーが表示された場合は、別のプライベート IPv4 CIDR を選択し、gcloud anthos config controller create コマンドで --master-ipv4-cidr-block フラグを指定して使用します。

すでに使用されている IPv4 CIDR ブロックを見つける手順は次のとおりです。

ピアリングの名前を見つけます。

gcloud compute networks peerings list --network=NETWORK

NETWORK は、検索するネットワークの名前に置き換えます。

出力は次のようになります。

NAME                                    NETWORK   PEER_PROJECT               PEER_NETWORK                            PEER_MTU  IMPORT_CUSTOM_ROUTES  EXPORT_CUSTOM_ROUTES  STATE   STATE_DETAILS
gke-n210ce17a4dd120e16b6-7ebf-959a-peer  default  gke-prod-us-central1-59d2  gke-n210ce17a4dd120e16b6-7ebf-0c27-net            False                 False                 ACTIVE  [2021-06-08T13:22:07.596-07:00]: Connected.

ピアリングで使用されている IPv4 CIDR を表示します。
```
gcloud compute networks peerings list-routes PEERING_NAME \
    --direction=INCOMING \
    --network=NETWORK \
    --region=REGION
```
次のように置き換えます。
- PEERING_NAME: 検索するピアリングの名前
- NETWORK: 検索するネットワークの名前
- REGION: Config Controller インスタンスが存在するリージョンの名前

Config Controller の実行中に発生する問題のトラブルシューティング

ノードプールの IP を使い果たした

次のエラーメッセージが表示された場合は、ノードプールに十分な数の IP アドレスが存在しない可能性があります。

Can't scale up because instances in managed instance groups hosting node pools ran out of IPs

この問題は、--cluster-ipv4-cidr-block フラグを省略した場合に発生することがあります。このフラグを省略すると、Config Controller はデフォルトで /20 Pod CIDR 範囲に設定されます。これにより、ノードの最大数は 16 になります。

CIDR ブロックは作成後に変更できません。追加のノードが必要な場合は、Config Controller インスタンスを削除します。Config Controller インスタンスを再作成する場合は、オプションパラメータ --cluster-ipv4-cidr-block を使用して、CIDR range or netmask size を指定します。

ダッシュボード情報がない

Google Cloud コンソールのダッシュボードに Config Controller の詳細が表示されない場合、Config Controller が使用するデフォルトのサービスアカウントに、必要な Google Cloud Observability の権限がない可能性があります。

これらの権限を付与するには、次のコマンドを使用します。

# Cloud Monitoring metrics permissions
gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/monitoring.metricWriter \
    --condition=None \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/stackdriver.resourceMetadata.writer \
    --condition=None \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/opsconfigmonitoring.resourceMetadata.writer \
    --condition=None \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"

# Cloud Logging permissions
gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/logging.logWriter \
    --condition=None \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"

# Cloud Trace permissions\
gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/cloudtrace.agent \
    --condition=None \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"

次のように置き換えます。

PROJECT_ID: Config Controller インスタンスを作成したプロジェクトの ID
PROJECT_NUMBER: Google Cloud プロジェクト番号

コンポーネントのトラブルシューティング

Config Controller インスタンスには、Policy Controller、Config Sync、Config Connector がプリインストールされているため、これらのコンポーネントで問題が発生することがあります。これらのコンポーネントのトラブルシューティングについては、次のページをご覧ください。

以降のセクションでは、これらのコンポーネントと Config Controller を組み合わせて使用する際に発生する可能性がある、よくある問題について説明します。

同期エラー

信頼できる情報源（Git リポジトリや OCI イメージなど）の構成は、Config Sync を使用して Config Controller インスタンスと同期されます。この同期プロセスのエラーは、nomos status コマンドで確認できます。

nomos status  --contexts $(kubectl config current-context)

Config Connector リソースのトラブルシューティング

変更不可のフィールドとリソース

プロジェクト ID や VPC ネットワークの名前など、基盤となる Google Cloud リソースのフィールドには、変更できないものがあります。このようなフィールドの編集は、Config Connector によりブロックされ、変更を反映できません。こうした変更不可フィールドの 1 つを編集する必要がある場合は、（Git で）元のリソースを削除し、続いて優先する値で追加し直す必要があります。

停止しているリソース

場合によっては、リソースが正しく削除できないことがあります（nomos status で報告されます）。この問題は、リソースのファイナライザを削除した後、手動でリソースを削除することにより解決できます。

たとえば、動かなくなった IAMPolicyMember を削除するには、次のコマンドを実行します。

kubectl patch IAMPolicyMember logging-sa-iam-permissions \
    -p '{"metadata":{"finalizers":[]}}' --type=merge -n config-control
kubectl delete IAMPolicyMember logging-sa-iam-permissions -n config-control

次のステップ

さらにサポートが必要な場合は、Cloud カスタマーケアにお問い合わせください。