このページは Cloud Translation API によって翻訳されました。

Google Distributed Cloud エアギャップ 1.13.x の既知の問題

Artifact Registry

サブコンポーネント `sar-failoverregistry` の調整エラー

バージョン: 1.13.1、1.13.3、1.13.4

現象: gdcloud system admin-cluster install コマンドを使用してルート管理者クラスタを作成するときに、ブートストラップ時にサーバーのリストが長いと、オペレーションが失敗することがあります。エラー出力メッセージは次のとおりです。

Secret "sar-failoveregistry-backend-parameter" is invalid: data: Too long: must have at most 1048576 bytes

回避策: この問題を軽減するには、次の手順を行います。

サブコンポーネントと同じ Kubernetes クラスタで、サーバーを一覧表示し、各サーバーカスタムリソースにキーが cluster.private.gdc.goog/inventory-machine のラベルがあることを確認します。
```
kubectl get servers -n gpc-system
```

次のコンポーネントカスタムリソースを見つけます。

  apiVersion: lcm.private.gdc.goog/v1
  kind: Component
  metadata:
    creationTimestamp: "2025-01-06T12:00:41Z"
    generation: 1
    name: sar-v1.14.2-sar-acbf97caf6
    resourceVersion: "3199"
    uid: 681ec5cb-9eb3-423b-ac1d-f6aa27abfd75
  spec:
    name: sar

システムアーティファクトレジストリ（SAR）コンポーネントのカスタムリソースで、sar-failover-registry の runtimeParameterSources サーバーにラベルセレクタを追加します。

既存の server リソースを表示します。

servers:
  targetCluster: Local
  object:
    apiVersion: system.private.gdc.goog/v1alpha1
    kind: ServerList
    namespace: gpc-system

コンポーネントカスタムリソースの servers フィールドを更新します。

servers:
  targetCluster: Local
  object:
    apiVersion: system.private.gdc.goog/v1alpha1
    kind: ServerList
    namespace: gpc-system
    labelSelector:
      - key: cluster.private.gdc.goog/inventory-machine
        operator: "in"
        strValues:
          - "bm-1"
          - "bm-2"
          - "bm-3"

前の手順で SAR コンポーネントの変更がサブコンポーネント sar-failverregistry に伝播されていることを確認します。
1. SAR コンポーネントの詳細を取得します。
```
kubectl get component | grep sar
```
2. sar-failoverregistry コンポーネントの詳細を取得します。
```
kubectl get subcomponent sar-failoverregistry -n root
```
  -n フラグを使用して、Namespace を指定します。

バックアップと復元

ボリューム容量の不足によりスナップショットが失敗する

バージョン: 1.13.x のすべてのバージョン

症状: 永続ボリュームのバックアップで断続的な問題が発生し、定期的なバックアップジョブのワークフローに影響する可能性があります。変更率の高い一部のボリュームでは、継続的なバックアップ用に取得されたボリュームスナップショットにより、ボリュームの容量が不足し、ボリュームが読み取り専用モードになることがあります。

回避策: 本番環境のワークロードに影響が及ばないようにするには、BACK-R0104 ランブックの手順に沿って操作します。必要に応じて、BACK-R0106 ランブックに沿って、蓄積されたスナップショットを削除することもできます。

メモリ不足のため、エージェント Pod とコントロールプレーン Pod が再起動する

バージョン: 1.13.x のすべてのバージョン

症状: メモリ不足になると、エージェントとコントロールプレーンの Pod が再起動する可能性があります。

回避策: BACK-R0005 ランブックの手順に沿って、コントロールプレーンとエージェント Pod のメモリを増やします。Pod のメモリを 2 GiB に増やします。

PVC スナップショットのバックアップが失敗する

バージョン: 1.13.x のすべてのバージョン

事象: PersistentVolumeClaim（PVC）リソースあたりの ONTAP スナップショットの上限（1,023）を超えたため、バックアップエラーが発生しました。

回避策: この問題を緩和するには、次の操作を行います。

上限に達しないようにバックアッププランを更新します。1 時間ごとにバックアップを取得するようにバックアッププランを構成するか、deleteLockDays を 3 に減らして、スナップショットの数が 1,023 を超えないようにします。
```
apiVersion: backup.gdc.goog/v1
kind: BackupPlan
metadata:
  name: test-backup-plan
spec:
  clusterName: system-cluster
  backupSchedule:
    cronSchedule: "*/10 * * * *"
    paused: false
  backupConfig:
    backupScope:
      selectedApplications:
        namespacedNames:
        - name: test-protected-application
          namespace: release-namespace
    backupRepository: gdchservices-backup-repository
    includeVolumeData: true
    volumeStrategy: LocalSnapshotOnly
  retentionPolicy:
    backupDeleteLockDays: LOCK_DAYS
    backupRetainDays: RETENTION_DAYS
```
次のように置き換えます。
- LOCK_DAYS: バックアップの作成後に指定された日数の間、バックアップの削除をロックします。次の値を使用します。
  - volumeStrategy フィールドが LocalSnapshotOnly の値に設定されている場合は、2 の値を使用します。
  - volumeStrategy フィールドが ProvisionerSpecific の値に設定されている場合は、7 の値を使用します。
- RETENTION_DAYS: バックアップ作成後に指定された日数が経過すると、バックアップを削除します。volumeStrategy フィールドが LocalSnapshotOnly の値に設定されている場合は、3 より小さい値を使用します。
ボリュームスナップショット削除コマンドを使用して環境から過剰なスナップショットを手動で削除する手順は次のとおりです。
1. 変数を初期化します。
```
export RKCNF=/root/release/root-admin/root-admin-kubeconfig
export KCNF=/root/release/org-admin/gdchservices-admin-kubeconfig

export ORG_NAME=ORG_NAME
export PVC=PVC_NAME
```
  次のように置き換えます。
  - ORG_NAME: 組織の名前。
  - PVC_NAME: バックアッププランに関連する PVC リソースの名前。
2. NetApp ONTAP は、GDC のストレージを管理するために使用されるオペレーティングシステムです。ONTAP へのアクセス権を取得します。
```
export USERNAME="$(kubectl --kubeconfig ${RKCNF?} -n gpc-system get
secret storage-root-level1 -o jsonpath='{.data.username}' | base64 -d)"

export MGMT_IP="$(kubectl --kubeconfig ${RKCNF?} get storagecluster -A
-o jsonpath='{.items[0].spec.network.clusterManagement.ip}')"

export PASSWORD="$(kubectl --kubeconfig ${RKCNF?} -n gpc-system get
secret storage-root-level1 -o jsonpath='{.data.password}' | base64 -d)"

echo $PASSWORD
```
3. 選択した PVC リソースのすべてのスナップショットを一覧表示します。
```
ssh ${USERNAME?}@${MGMT_IP?} "volume snapshot show -vserver ${ORG_NAME?}
-fields volume,snapshot,size,create-time" | grep "snapshot-" >
/tmp/snapshot_unsort.list
```
  前の手順のパスワードを使用して、MGMT_IP 変数で定義された IP アドレスのマシンにログインします。
4. スナップショット数が最も多い PVC を見つけます。
```
grep ${ORG_NAME?} /tmp/snapshot_unsort.list | grep snapshot | awk
'{print $2}' | sort | uniq -c
```
5. PVC リソース名を、スナップショット数の多いものに設定します。
```
export PV_NAME=
```
6. スナップショット数が多い PVC リソースのスナップショットを削除します。PVC リソースのスナップショット数の上限は 1,023 です。
```
for snap_name in `grep ${ORG_NAME?} /tmp/snapshot_unsort.list | grep
snapshot | grep ${PV_NAME?} | awk '{print $3}'` do
    echo "volume snapshot delete -vserver ${ORG_NAME} -volume ${PV_NAME} -snapshot $snap_name"
    echo "Y"
done
```
7. ONTAP にログインし、次のコマンドを実行してスナップショットを削除します。
```
echo $PASSWORD

#Use this password to login to ontap
ssh ${username?}@${mgmt_ip?}
```
8. 前の手順で説明したコマンドを実行して、スナップショットを削除します。完了したら、SSH セッションを終了します。
問題のある PVC スナップショットがすべてクリーンアップされるまで、削除手順を繰り返します。

SVM 割り当てと互換性のないバックアップからの復元

バージョン: 1.13.1

症状: この問題は、NetApp 機能間の非互換性です。この非互換性により、テナント割り当ての配信と復元の実装が失敗します。この問題は、割り当てが制限されたユーザークラスタにバックアップを復元する場合にのみ発生します。

回避策: この問題が発生すると、復元がエラーメッセージ DP volumes are not supported on storage-limit enabled Vserver で失敗します。インフラストラクチャオペレーター（IO）は、そのユーザークラスタの割り当てを無効にして、復元プロセスを再開する必要があります。復元が完了したら、IO はテナントの割り当てを再度有効にする必要があります。システムは引き続き意図したとおりに動作します。詳細については、ランブック FILE A0030 を参照してください。

課金

請求先ダッシュボードに請求先指標が正しく表示されない

バージョン: 1.13.1

症状: MetricsProxySidecar がないため、課金指標が cortex に正しく出力されません。

回避策: billing-monetizer MetricsProxySidecar リソースを作成します。次に、スクリプトを実行して metricExpression を更新します。

次の kubeconfig 変数をエクスポートします。
```
export KUBECONFIG=KUBECONFIG_PATH
```
KUBECONFIG_PATH 変数を、組織管理クラスタの kubeconfig ファイルのパスに置き換えます。サービスマニュアル IAM-R0101 の手順に沿って、この回避策に必要な kubeconfig ファイルを生成します。

billing-system Namespace と partner-billing-system Namespace の billing-monetizer MetricsProxySidecar リソースを作成します。

billing-system:

cat <<EOF | kubectl --kubeconfig=$KUBECONFIG apply -n billing-system -f -
apiVersion: monitoring.private.gdc.goog/v1alpha1
kind: MetricsProxySidecar
metadata:
  name: billing-monetizer
  namespace: billing-system
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep
spec:
  restartUninjectedPods: true
  restartUnsyncedPods: false
  sources:
  - port: 8080
    scrapeInterval: 60s
  destinations:
  - certificate:
      secretName: billing-monetizer-monitoring-target-infra-obs-cert
    port: 9090
  - certificate:
      secretName: billing-monetizer-monitoring-target-platform-obs-cert
    port: 9091
---
apiVersion: monitoring.private.gdc.goog/v1alpha1
kind: MetricsProxySidecar
metadata:
  name: usagemetering
  namespace: billing-system
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep
spec:
  restartUninjectedPods: true
  restartUnsyncedPods: false
  sources:
  - port: 8099
    scrapeInterval: 60s
  destinations:
  - port: 9090
    certificate:
      secretName: bil-usagemetering-monitoring-target-cert
EOF

partner-billing-system:

cat <<EOF | kubectl --kubeconfig=$KUBECONFIG apply -n partner-billing-system -f -
apiVersion: monitoring.private.gdc.goog/v1alpha1
kind: MetricsProxySidecar
metadata:
  name: billing-monetizer
  namespace: partner-billing-system
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep
spec:
  restartUninjectedPods: true
  restartUnsyncedPods: false
  sources:
  - port: 8080
    scrapeInterval: 60s
  destinations:
  - certificate:
      secretName: billing-monetizer-monitoring-target-infra-obs-cert
    port: 9090
EOF

次のスクリプトを実行して metricExpression を更新します。これにより、skuconfig（billing_total_cost{container_name="monetizer" を含む）から container_name="monetizer" が削除されます。

cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig bc73-b150-e0ea --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"BC4D-B784-EA3C|BC73-B150-E0EA|BD0C-C8CF-658B|BD1A-9464-9DF9|BD5A-044C-4860|BDB4-6C62-00BE|BDB4-BBA6-3EEE|3034-EE51-7404|3160-1596-5D9B|54AD-8EBC-8BB1\"}\n              [{{.Range}}:1m]          )        ) * max(metering_premium_support_base_fee)"
     }
   }
 ]
}'
EOF
cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig bd1a-9464-9df9 --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"BC4D-B784-EA3C|BC73-B150-E0EA|BD0C-C8CF-658B|BD1A-9464-9DF9|BD5A-044C-4860|BDB4-6C62-00BE|BDB4-BBA6-3EEE|3034-EE51-7404|3160-1596-5D9B|54AD-8EBC-8BB1\"}\n              [{{.Range}}:1m]          )        ) * max(metering_enhanced_support_base_fee)"
     }
   }
 ]
}'
EOF
cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig b93c-effb-6d6b --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"B853-4EA7-4587|B871-C5E5-BAC1|B874-4D01-5058|B8D9-1200-1016|B93C-EFFB-6D6B|B995-6E8E-BF8D|B9B4-1B11-A9F1|B9B5-DFDA-8526|BA38-E4BE-BA5D|BB08-6B46-E1B3|BB51-EA7D-1728|BBE8-7B7A-03DE|BBF1-CE8E-CD24|BC4C-AC45-6448|34A1-F9B1-DC13|53F3-F2F8-54A9|3674-F9D1-120A|5463-A50F-B07D\"}\n              [{{.Range}}:1m]          )        ) * max(metering_premium_support_base_fee)"
     }
   }
 ]
}'
EOF
cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig b871-c5e5-bac1 --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"B853-4EA7-4587|B871-C5E5-BAC1|B874-4D01-5058|B8D9-1200-1016|B93C-EFFB-6D6B|B995-6E8E-BF8D|B9B4-1B11-A9F1|B9B5-DFDA-8526|BA38-E4BE-BA5D|BB08-6B46-E1B3|BB51-EA7D-1728|BBE8-7B7A-03DE|BBF1-CE8E-CD24|BC4C-AC45-6448|34A1-F9B1-DC13|53F3-F2F8-54A9|3674-F9D1-120A|5463-A50F-B07D\"}\n              [{{.Range}}:1m]          )        ) * max(metering_enhanced_support_base_fee)"
     }
   }
 ]
}'
EOF

cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig ba38-e4be-ba5d --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"B853-4EA7-4587|B871-C5E5-BAC1|B874-4D01-5058|B8D9-1200-1016|B93C-EFFB-6D6B|B995-6E8E-BF8D|B9B4-1B11-A9F1|B9B5-DFDA-8526|BA38-E4BE-BA5D|BB08-6B46-E1B3|BB51-EA7D-1728|BBE8-7B7A-03DE|BBF1-CE8E-CD24|BC4C-AC45-6448|34A1-F9B1-DC13|53F3-F2F8-54A9|3674-F9D1-120A|5463-A50F-B07D\"}\n              [{{.Range}}:1m]          )        ) * max(metering_enhanced_support_base_fee)"
     }
   }
 ]
}'
EOF
cat <<EOF | kubectl --kubeconfig=$KUBECONFIG -n billing-system patch skuconfig bbe8-7b7a-03de --type=merge -p '
{
 "metricMappingTimeline": [
   {
     "billingModel": "Generic",
     "usageAggregationLevel": "Organization",
     "revision": 1,
     "generic": {
       "metricExpression": "sum(          increase(              billing_total_cost{sku !~ \"B853-4EA7-4587|B871-C5E5-BAC1|B874-4D01-5058|B8D9-1200-1016|B93C-EFFB-6D6B|B995-6E8E-BF8D|B9B4-1B11-A9F1|B9B5-DFDA-8526|BA38-E4BE-BA5D|BB08-6B46-E1B3|BB51-EA7D-1728|BBE8-7B7A-03DE|BBF1-CE8E-CD24|BC4C-AC45-6448|34A1-F9B1-DC13|53F3-F2F8-54A9|3674-F9D1-120A|5463-A50F-B07D\"}\n              [{{.Range}}:1m]          )        ) * max(metering_premium_support_base_fee)"
     }
   }
 ]
}'
EOF

検証 Webhook のバグのため、ユーザーが `BillingAccountBinding` を作成できない

バージョン: 1.13.0、1.13.1、1.13.3

症状: このバグは、BillingAccountBinding 検証 Webhook ロジックにあります。ユーザーが BillingAccountBinding リソースを作成しようとすると、Webhook はエラー permission denied を返します。

回避策: BillingAccountBinding リソースを作成するには、インフラストラクチャオペレーターに通知し、IAC を介して対応するリソースを作成します。

ブロックストレージ

ボリュームマウントエラーのため、Grafana Pod が `Init` 状態のままになる。

バージョン: 1.13.3

症状:

ボリュームのマウントエラーのため、anthos-identity-service-obs-system Namespace と platform-obs-obs-system Namespace の Grafana Pod が Init 状態のままになります。kubelet ログのエラーメッセージは、マルチアタッチの問題を示しています。この問題は、Trident のバグが原因で発生します。Trident は、LUKS マッピングの基盤となるデバイスを正しく識別して検証できないため、マルチアタッチエラーが発生します。

回避策:

PVC で deletionTimestamp を確認します。deletionTimestamp がない場合（Pod の移行）は、次の手順を行います。

PVC の VolumeAttachment を確認して、ボリュームが現在アタッチされている場所を特定します。
この値と一致しないクラスタ内の Nodes を分離します。
失敗した Pod を削除します。これにより、元の Node に移行されます。

確認後、deletionTimestamp（Volume の削除）がある場合は、次の手順を行います。

PVC の VolumeAttachment を確認して、ボリュームが現在アタッチされている場所を特定します。
Node で、トラッキングファイルの内容を出力します。
```
cat /var/lib/trident/tracking/PVC_NAME.json
```
トラッキングファイルの出力の devicePath フィールドで見つかった LUKS デバイスが実際に閉じていることを確認します。この時点で、このパスは存在しません。
```
stat DEVICE_PATH
```
シリアル番号が現在マルチパスデバイスにマッピングされているかどうかを確認します。
1. トラッキングファイルの iscsiLunSerial フィールドの値をコピーします。
2. この値を想定される 16 進数値に変換します。
```
echo 'iISCSILUNSERIAL' | xxd -l 12 -ps
```
3. この新しい値を使用して、マルチパスエントリがまだ存在するかどうかを確認します。
```
multipath -ll | grep SERIAL_HEX
```
4. 存在しない場合は、トラッキングファイルを削除します。
5. 存在する場合は、検索した値よりも少し長いシリアル 16 進数値（multipathSerial）が表示されます。次のコマンドを実行して、ブロックデバイスを見つけます。
```
multipath -ll MULTIPATH_SERIAL
```
6. 次に、次のコマンドを実行します。最後のコマンドは、ブロックデバイスごとに一意に実行します。
```
systemctl restart iscsid
systemctl restart multipathd
multipath -f MULTIPATH_SERIAL
echo 1 > /sys/block/BLOCK_DEVICE_NAME/device/delete
```

仮想マシンランチャー Pod がボリュームをマッピングできない

バージョン: 1.13.1

症状:

次のような警告が表示されることがあります。

 Warning  FailedMapVolume  2m50s (x206 over 13h)  kubelet  MapVolume.SetUpDevice failed for volume "pvc-2a68356a-47da-422b-8781-15e3a6fe7ec9" : rpc error: code = DeadlineExceeded desc = context deadline exceeded

問題を診断するには、次の手順を行います。

ボリュームと Pod が同じノードにあることを確認します。
Pod が存在するノードを見つけて、その健全性を確認します。
ノードの接続を確認します。
IPSEC を確認します。
マルチパスをチェックして、ゾンビが存在するかどうかを確認します。
Trident ログを調べて、CSI フローのどのステップでこのゾンビが導入されたかを確認します。
```
kubectl --kubeconfig /root/release/system/org-1-system-cluster logs -n netapp-trident -c trident-main
```

回避策: この問題を回避するには、次のランブックの手順に沿って操作します。

ノードに関する問題については、FILE-R0010 ランブックをご覧ください。
IPSEC に関する問題については、FILE-R0007 ランブックをご覧ください。
ゾンビ LUN に関する問題については、FILE-R0020 ランブックをご覧ください。
スーパーゾンビ LUN に関する問題については、FILE-R0021 ランブックをご覧ください。

ストレージ関連の障害

バージョン: 1.13.1

症状: ストレージ関連の障害は、file_block_zombie_luns_present アラートがトリガーされるか、MountVolume 呼び出しの問題が複数の調整ループにわたって継続し、Pod が起動に失敗することで特定できます。タイムアウトは 2 分ほどになることがあります。同じ障害が繰り返される場合は、NodeStage または NodePublish CSI パスで障害が発生していることを示しており、回避策が必要です。唯一の例外は、タイムアウトエラーの表示です。次のようなエラーが表示されることがあります。

NMountVolume.SetUp failed for volume "pvc-a63313b2-3e30-4c92-b074-f9fffe0500a4" : rpc error: code = Internal desc = unable to mount device; exit status 32

MapVolume.SetUpDevice failed for volume "pvc-f594b0c7-a5b5-4a5b-8a53-bf13e95c4bb0" : rpc error: code = Internal desc = rpc error: code = Internal desc = failed to stage volume: multipath device not found when it is expected

MapVolume.SetUpDevice failed for volume "pvc-f594b0c7-a5b5-4a5b-8a53-bf13e95c4bb0" : rpc error: code = Internal desc = rpc error: code = Internal desc = failed to stage volume: failure when reconfiguring multipath

回避策:

Pod を含む Node が失敗した PVC に対して修正できるかどうかを確認するには、Pod がスケジュールされている現在のノードを分離し、Pod を削除します。
```
KUBECONFIG=CLUSTER_KUBECONFIG kubectl cordon node TARGET_NODE
```
Pod は完全に異なる Node にスケジュールする必要があります。これにより、Trident は NodeStage、NodePublish、NodeUnpublish、NodeUnstage を完全に実行する必要があります。元の Node でこのボリュームのセッションがまだ開いている可能性があるため、ボリュームがすぐに修正されないことがあります。
前の手順が完了したら、問題のノードのコードンを解除します。
```
KUBECONFIG=CLUSTER_KUBECONFIG kubectl uncordon node TARGET_NODE
```
障害がまだ存在する場合は、Pod が最初にスケジュールされた Nodes 以外のすべての Nodes を分離し、Pod を削除します。これにより、既存のデバイスがまだ残っている可能性がある元の Node で Pod が開始されます。
前の手順が完了したら、問題のノードのコードンを解除します。
PV とそのデータを保存する最後の手段として、Node を再起動して、Node のマルチパス、udev、devmapper の障害をクリアできます。この手順はかなり面倒ですが、成功する可能性が最も高い方法です。
前の軽減策でボリュームの問題を解決できない場合は、データが破損して使用できなくなっていることを示します。目的のコンテナの動作を続行する唯一の方法は、PV、PVC、Pod の失敗を削除し、PV がホストされていたノードを再起動することです。このアクションにより、ボリュームにすでに書き込まれているデータが完全に失われます。

サイズが正しくない永続ボリュームが作成される

バージョン: 1.13.1

症状: 永続ボリュームを含むワークロードが約 16 MiB 小さく作成されます。ワークロードが永続ボリュームでアドバタイズされたサイズに正確に依存している場合、わずかな差異によって、拡張またはプロビジョニング時にワークロードが失敗します。この問題は、standard-rwo ストレージクラスでプロビジョニングされた永続ボリュームよりも、standard-block ストレージクラスでプロビジョニングされた永続ボリュームで発生する可能性が高くなります。この問題は、volumemode:block モードを使用する standard-rwo ストレージクラスの永続ボリュームで発生する可能性があります。

回避策: 実際に必要なサイズよりも 16 MiB 以上大きい永続ボリュームを割り当てます。

ストレージ仮想マシンを削除できない

バージョン: 1.13.1

現象: StorageVirtualMachine に次のようなエラーが表示されることがあります。

 Warning  SVMDeletion  27m (x32 over 4h9m)   StorageVirtualMachine  Reconcile error for svm deletion: failed to delete svm: failed to delete svm volumes: failed to call VolumeCollectionGet: error message: "SVM \"org-2-user\" does not exist. "; error target: "svm.name"

回避策: org Namespace の StorageVirtualMachines からファイナライザを削除します。

組織を無効にしてもリソースはクリーンアップされない

バージョン: 1.13.1

現象: 組織を無効にすると、一部の StorageVirtualMachines リソースが残ります。例:

gpc-system シークレット/org-2-admin-backup-agent-cert-secret
gpc-system シークレット/org-2-admin-client-cert-secret
gpc-system シークレット/org-2-admin-server-cert-secret
gpc-system シークレット/org-2-admin-svm-credential
gpc-system シークレット/org-2-admin-backup-agent-cert-secret
gpc-system シークレット/org-2-admin-client-cert-secret
gpc-system シークレット/org-2-admin-server-cert-secret
gpc-system シークレット/org-2-admin-svm-credential

回避策: これらのリソースを削除します。

削除の調整の失敗

バージョン: 1.13.1

現象: StorageVirtualMachine に依存するクラスタのクリーンアップの前に StorageVirtualMachine が削除されると、一部のクラスタの永続ボリューム（PV）のクリーンアップで問題が発生する可能性があります。具体的には、LUKS で暗号化された PV がクリーンアップされない場合、そのシークレットによって、PV が存在する Namespace の削除が阻止されます。ログに次のような警告が表示されることがあります。

Warning  ReconcileBackoff  5m35s (x6 over 88m)  ClusterLifecycleReconciler  cluster namespace deletion is not completed: deletion is still ongoing for namespace: /g-org-2-shared-service-cluster

回避策: サービスクラスタの Namespace の g-luks-gdc-vm-disk-* シークレットからファイナライザーを削除します。

ベアメタルのアップグレードが停止する

バージョン: 1.13.1、1.13.5、1.13.6

症状: Zombie LUN がある場合、Ansible ジョブが事実の収集で停止します。multipath -ll コマンドを実行すると、次の問題が表示されることがあります。

3600a098038314955593f574669785635 dm-11 NETAPP,LUN C-Mode
size=1.0G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=0 status=enabled
| |- 5:0:0:10 sdaf 65:240 failed faulty running
| `- 6:0:0:10 sdau 66:224 failed faulty running
`-+- policy='service-time 0' prio=0 status=enabled
  |- 7:0:0:10 sdad 65:208 failed faulty running
  `- 8:0:0:10 sdar 66:176 failed faulty running

次のエラーメッセージが表示されることもあります。

 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv PLAY [Check inventory] *********************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv TASK [set_fact] ****************************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv Wednesday 03 July 2024  01:39:04 +0000 (0:00:00.018)       0:00:00.018 ********
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv ok: [10.252.151.3]
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv PLAY [Verify inventory]********************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv TASK [assert]******************************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv Wednesday 03 July 2024  01:39:04 +0000 (0:00:00.031)       0:00:00.050 ********
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv ok: [localhost]
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv PLAY [all] *********************************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv TASK [Gathering Facts] *********************************************************
 bm-system-upgrade-node-10.252.151.3-8cee3ed5ff67fdeb1716d964ztv Wednesday 03 July 2024  01:39:04 +0000 (0:00:00.064)       0:00:00.114 ********

回避策: ターゲットノードとの SSH 接続を確認し、次のランブック FILE-R0020 を使用します。

Trident のマルチアタッチエラー

バージョン: 1.13.3

症状: Pod と PVC が異なるノードに分散し、Pod が PVC を待機して初期化を停止している可能性があります。

回避策:

PVC で deletionTimestamp を確認します。

kubectl --kubeconfig KUBECONFIGget pvc -n <namespace> | grep deletionTimestamp

deletionTimestamp（Pod の移行）がない場合:
1. PVC の VolumeAttachment を確認して、ボリュームが接続されている場所を特定します。
2. この値と一致しないクラスタ内のノードを分離します。
3. 障害が発生した Pod を削除します。このアクションにより、POD が元のノードに移行されます。
注: Trident がマルチパスエントリに使用するシリアル 16 進数値は ONTAP の実際の LUN リソースから取得されるため、このアクションではゾンビは作成されません。デバイスがすでに存在する場合は、元の値が返されます。デバイスが存在しない場合は、値が正しく作成されます。
deletionTimestamp（ボリュームの削除）がある場合:
1. PVC の VolumeAttachment を確認して、ボリュームが接続されている場所を特定します。
2. ノードで、トラッキングファイル /var/lib/trident/tracking/PVC_NAME.json の内容を出力します。
3. トラッキングファイルの出力の devicePath フィールドで見つかった LUKS デバイスが実際に閉じられていることを検証します。この時点でこのパスは存在しません: stat DEVICE_PATH。パスがまだ存在する場合は、別の問題が発生しています。
4. シリアル番号がマルチパスデバイスにマッピングされているかどうかを確認します。
5. トラッキングファイルの iscsiLunSerial フィールドの値をコピーします。
6. この値を想定される 16 進数値 echo ISCSI_LUN_SERIAL | xxd -l 12 -ps に変換します。
7. この新しい値を使用して、マルチパスエントリがまだ存在するかどうかを確認します。multipath -ll | grep SERIAL_HEX
8. 存在しない場合は、トラッキングファイルを削除します。
9. 存在する場合は、検索した値よりも少し長いシリアル 16 進数値が表示されます。この値を MULTIPATH_SERIAL として記録します。multipath -ll MULTIPATH_SERIAL を実行すると、次のようなメッセージが表示されます。
```
3600a09803831486f2d24575445314678 dm-32 NETAPP,LUN C-Mode
size=8.0G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| |- 1:0:0:12 sde  8:64   active ready running
| `- 2:0:0:12 sdt  65:48  active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  |- 3:0:0:12 sdbc 67:96  active ready running
  `- 4:0:0:12 sdbe 67:128 active ready running
```
10. 次のコマンドを実行します。
  1. systemctl restart iscsid
  2. systemctl restart multipathd
  3. multipath -f MULTIPATH_SERIAL
  4. echo 1 > /sys/block/BLOCK_DEVICE_NAME/device/delete
11. 最後のコマンドは、ブロックデバイスごとに一意に実行します。

IPsec 構成のエラー

バージョン: 1.13.4

現象: 0X を含む無効な事前共有鍵（PSK）が原因で、ONTAP IPsec 構成でエラーが発生します。0X は 16 進文字列として解釈されます。

次のような警告が表示されることがあります。

Warning  ONTAPIPSecConfiguration  3m47s (x22 over 75m)  StorageEncryptionConnection  Reconcile error on ONTAP IPSec configuration: failed to call IpsecPolicyCreateDefault: error message: "The specified pre-shared key \"0XxBDkG8iHoAlOc
nCUfHl0AKYzClgGCH\" is not valid because it is not a valid hexadecimal string."; error target: ""

回避策:

ストレージ暗号化接続を取得します。

kubectl get  Storageencryptionconnections --kubeconfig ROOT_ADMIN_KUBECONFIG

Ready=False のエントリを探し、PRESHAREKEY の名前をメモします。出力は次のようになります。

NAME          INVENTORYMACHINE   STORAGEVIRTUALMACHINE   STORAGECIDR        PRESHAREDKEY                 READY   AGE
vm-5a77b2a2   vm-5a77b2a2        gpu-org-user            192.0.2.0/27   vm-5a77b2a2-pre-shared-key   False   26h

このマシンは gpu 組織を実行しているため、gpu-org-admin の secrets gpc-system/vm-5a77b2a2-pre-shared-key を削除します。
システムが secret/vm-5a77b2a2-pre-shared-key を再作成するまで待ちます。
gpc-system/os-policy-config-host-ipsec-vm-5a77b2a2 のようなパターンを持つジョブを探します。最後の 8 文字はランダムに生成されます。キーが再び使用可能になったら、gpu-org-admin の jobs gpc-system/os-policy-config-host-ipsec-vm-5a77b2a2m8xdl などのジョブを削除します。

ストレージ仮想マシンが作成されない

バージョン: 1.13.5

現象: gpu-org の Harbor サービスが、ボリュームのプロビジョニングに関する問題により起動に失敗します。この問題は、file-storage-backend-controller Pod が存在しないインベントリマシンを参照していることが原因で発生します。

次のようなストレージコントローラエラーが表示され、InventoryMachine が見つからないことを示している場合があります。

{"ts":1730135301218.1772,"caller":"controller/controller.go:329","msg":"Reconciler error","controller":"StorageEncryptionConnectionGenerator","controllerGroup":"baremetal.cluster.gke.io","controllerKind":"InventoryMachine","InventoryMachine":{"n
ame":"vm-26c89d33","namespace":"@org-1/org-1-admin"},"namespace":"@org-1/org-1-admin","name":"vm-26c89d33","reconcileID":"48ab38a8-385d-4fdb-bd7e-1212f287379c","err":"InventoryMachine.baremetal.cluster.gke.io \"vm-26c89d33\" not found"}

回避策:

file-storage-backend-controller Pod を削除します。
ストレージコントローラに、存在するインベントリマシンを再取得させます。

ストレージクラスタ間ネットワークの調整に失敗する

バージョン: 1.13.5、1.13.6

現象: アップグレード後、ルート管理クラスタの StorageCluster カスタムリソースが、仕様のクラスタ間サブネットの構成ミスにより、準備完了になりません。ストレージクラスタは Not Ready を報告し、このエラーを含むイベントを生成します。

Reconciler error: failed to configure additional networks: failed to configure intercluster LIF: the \"\" Kind is not currently supported

このエラーが発生した場合、ストレージクラスタで使用されるクラスタ間サブネットクレームの参照に kind フィールドが含まれていません。StorageCluster カスタムリソースを調べると、次のように名前と Namespace のみのクラスタ間サブネットクレーム参照が見つかります。

spec:
  additionalNetworks:
  - destinationSubnets:
    - 10.252.112.0/20
    name: backup-agent-storage-network
    port: a0a
    subnetConfig:
      subnetClaimRef:
        name: file-block-storage-intercluster-lif-subnet
        namespace: root
    types:
    - BackupAgent

回避策:: サブネットクレーム参照に kind: SubnetClaim フィールドを含めるように StorageCluster 仕様を更新します。

spec:
  additionalNetworks:
  - destinationSubnets:
    - 10.252.112.0/20
    name: backup-agent-storage-network
    port: a0a
    subnetConfig:
      subnetClaimRef:
        kind: SubnetClaim
        name: file-block-storage-intercluster-lif-subnet
        namespace: root
    types:
    - BackupAgent

StorageCluster 仕様を更新したら、file-storage-backend-controller Deployment を再起動し、ストレージクラスタの準備ができていることを確認します。

クラスタ管理

クラスタのプロビジョニング中に `machine-init` ジョブが失敗する

バージョン: 1.13.1

症状:

クラスタのプロビジョニング中に、2 番目のコントロールプレーンノードの machine-init ジョブが次のメッセージで失敗します。
```
FAILED! => {"changed": true, "cmd": "/usr/bin/kubeadm join phase control-plane-prepare certs --config /dev/stdin --v 5".
```

ログを表示します。

kubectl --kubeconfig=ADMIN_KUBECONFIG logs -p kube-apiserver-{first_node_name} -n kube-system | grep "etcdmain: open /etc/kubernetes/pki/etcd/ca.crt: permission denied"

出力には空でない結果が表示されます。

回避策:

/etc/kubernetes/pki/etcd/ca.crt の権限を切り替えます。これは非常に時間依存性の高いオペレーションです。machine-init は権限をルートに上書きするため、権限の切り替えは machine-init ジョブの前回の実行後、かつ machine-init ジョブの次回の実行前に行う必要があります。
2 番目のノードで etcd を再起動して、最初のノードの etcd をクラッシュループから復元します。

この 2 つの手順を完了すると、最初のノードの kube-apiserver が実行を開始し、次の machine-init ジョブが成功します。

サービスクラスタからオブジェクトストレージバケットへの接続がない

バージョン: 1.13.1

症状: サービスクラスタで実行されているデータベース Pod から組織の管理クラスタ内のオブジェクトストレージバケットへの接続が失敗します。

回避策: KUB-R0305 ランブックの手順に沿って操作します。

プリフライトチェックが失敗する

バージョン: 1.13.1

症状: クラスタオブジェクトのステータスに次のメッセージが表示されることがあります。

conditions:
    message: Preflight check <cluster> failed
    reason: PreflightCheckFailed
    status: "False"
    type: PreflightCheckSuccessful

また、PreflightCheck オブジェクトに示されているエラーまたは障害が問題ではなくなったことがわかっているにもかかわらず、数時間以上存在しているクラスタオブジェクトと同じ名前と Namespace の対応する PreflightCheck オブジェクトも表示されます。

回避策: PreflightCheck オブジェクトを削除します。

ユーザークラスタのワーカーノードプールの作成が失敗する

バージョン: 1.13.5

症状: 次のいずれかのマシンタイプで、ユーザークラスタワーカーノードプールの作成が応答しなくなることがあります。

n2-standard-16-gdc
n2-standard-32-gdc
n2-highmem-16-gdc
n2-highmem-32-gdc

回避策: そのノードプールを削除し、ユーザークラスタ作成 UI のプルダウンから使用可能な他のマシンタイプを選択して再作成します。

再作成されたユーザークラスタが、不適切なクリーンアップにより調整で停止することがある

バージョン: 1.13.x

症状: 以前に削除されたクラスタと同じ名前でユーザークラスタを作成すると、Reconciling で無限にスタックし、アドオンインストールステージ ONE がステータスに表示されることがあります。

回避策: helm アドオン CLUSTER_NAME-abm-overrides をアンインストールし、managed-adm-controller デプロイを再起動します。詳しい手順については、MKS-R0004 をご覧ください。

データベースサービス

このセクションでは、Database サービスの既知の問題について説明します。

AlloyDB Omni データベースのクローン作成が停止する

バージョン: 1.13.x のすべてのバージョン

現象: ユーザーが特定の時点から AlloyDB Omni クラスタのクローンを作成すると、クローンされたデータベースクラスタが DBSE0005 エラーで停止し、準備完了状態になりません。対応する restore.alloydb リソースが「ProvisionInProgress」フェーズで停止しています。

回避策: この問題を回避するには、成功したバックアップの COMPLETETIME から特定の時点を慎重に選択します。

管理 API サーバーで、クローンを作成できる AlloyDB Omni バックアップを一覧表示します。

kubectl get backups.alloydb -n source-dbcluster-namespace

出力例:

NAMESPACE   NAME                         PHASE       COMPLETETIME
db1         backupplan1-20240908215001   Succeeded   2024-09-08T21:37:38Z
db1         backupplan1-20240909215001   Succeeded   2024-09-09T21:16:18Z
db1         backupplan1-20240910215001   Succeeded   2024-09-10T21:09:38Z
db1         backupplan1-20240911215001   Succeeded   2024-09-11T21:50:47Z

クローンの特定の時点として COMPLETETIME 値を選択します。時間は UTC で表示されます。

IOPS の適用がストレージパフォーマンスに影響する

バージョン: 1.13.1

回避策: この問題を回避するには、次のいずれかの方法をお試しください。

ストレージサイズを増やします。
IOPS 割り当てをオーバーライドします。

`dbs-fleet` サブコンポーネントのアップグレード時の調整エラー

バージョン: 1.13.3

症状: ルート組織を 1.13.1 から 1.13.3 にアップグレードすると、調整エラーが発生することがあります。調整エラーを確認します。

kubectl get subcomponent -n ${CLUSTER} -o json | jq -r '.items[] |  select(.status.conditions[]?.reason == "ReconciliationError") |  "Sub-Component: \(.metadata.name) - \(.status.conditions[]?.message)"'

次のようなエラーメッセージが表示されます。

Sub-Component: dbs-fleet - Reconciliation error: E0121 - rollback chart: no ControlPlaneAgentsVersion with the name "alloydbomni-v0.12.46" found

回避策: OCLCM-R0122 ランブックの手順に沿って対応します。

DBCluster の作成に失敗する

バージョン: 1.13.3

現象: 1.13.3 にアップグレードした後、新しい DBCluster の調整に失敗し、ステータスに次のエラーが表示されます。

status:
  criticalIncidents:
  - code: DBSE0001
    createTime: ""
    message: Internal. General Controller Error.
    resource:
      component: controller-default
      location: {}
    stackTrace:
    - component: controller-default
      message: 'DBSE0001: Internal. General Controller Error. Failed to reconcile
        Postgres DBCluster [<name>] DBSE0001: Internal.
        General Controller Error. target release is empty in ModuleInstance <name>'

回避策

組織管理クラスタに cpa-v0.12.46 と cpa-v0.12.51 の両方で終わる localrollout CR があることを確認します。次に例を示します。

kubectl get localrollouts -A

dbs-fleet-system   dp-alloydbomni-15-5.2--cpa-v0.12.46         true
dbs-fleet-system   dp-oracle-19-10.0.0.0--cpa-v0.12.46         true
dbs-fleet-system   dp-postgresql-13-8-v0.12.46--cpa-v0.12.46   true
dbs-fleet-system   dp-postgresql-14-5-v0.12.46--cpa-v0.12.46   true
dbs-fleet-system   dp-postgresql-15-2-v0.12.46--cpa-v0.12.46   true
dbs-fleet-system   dp-alloydbomni-15-5.2--cpa-v0.12.51         true
dbs-fleet-system   dp-oracle-19-10.0.0.0--cpa-v0.12.51         true
dbs-fleet-system   dp-postgresql-13-8-v0.12.51--cpa-v0.12.51   true
dbs-fleet-system   dp-postgresql-14-5-v0.12.51--cpa-v0.12.51   true
dbs-fleet-system   dp-postgresql-15-2-v0.12.51--cpa-v0.12.51   true

cpa-v0.12.46 で終わる localrollout CR を見つけて削除し、他の localrollout CR に影響がないことを確認します。

kubectl get localrollouts -A | grep cpa-v0.12.46

次のようなリストが返されます。

dbs-fleet-system   dp-alloydbomni-15-5.2--cpa-v0.12.46         true
dbs-fleet-system   dp-oracle-19-10.0.0.0--cpa-v0.12.46         true
dbs-fleet-system   dp-postgresql-13-8-v0.12.46--cpa-v0.12.46   true
dbs-fleet-system   dp-postgresql-14-5-v0.12.46--cpa-v0.12.46   true
dbs-fleet-system   dp-postgresql-15-2-v0.12.46--cpa-v0.12.46   true

それぞれを削除します。

kubectl delete -n dbs-fleet-system localrollout/dp-alloydbomni-15-5.2--cpa-v0.12.46
...
...

cpa-v0.12.51 で終わる localrollout CR がまだ存在することを確認します。

NAMESPACE          NAME                                        PAUSED   IN PROGRESS   FINISHED
dbs-fleet-system   dp-alloydbomni-15-5.2--cpa-v0.12.51         true
dbs-fleet-system   dp-oracle-19-10.0.0.0--cpa-v0.12.51         true
dbs-fleet-system   dp-postgresql-13-8-v0.12.51--cpa-v0.12.51   true
dbs-fleet-system   dp-postgresql-14-5-v0.12.51--cpa-v0.12.51   true
dbs-fleet-system   dp-postgresql-15-2-v0.12.51--cpa-v0.12.51   true

DNS

DNSSEC は resolved.conf で明示的にオフにする必要があります

バージョン: 1.13.1、1.13.3、1.13.4

現象: ベアメタルノードまたは VM ノードで DNS 解決が失敗します。DNS 解決が失敗していることを確認するには、影響を受けるノードへの SSH 接続を確立し、systemctl status systemd-resolved を実行します。出力には、DNSSEC validation failed for question . IN SOA: no-signature のような行が含まれます。

回避策:

影響を受けるノードの /etc/systemd/resolved.conf に次の行を追加します。
```
DNSSEC=false
```
systemd-resolved サービスを再起動します。
```
systemctl restart systemd-resolved.service
```

港湾サービス

Harbor サービスの作成に失敗しました

バージョン: 1.13.6

症状: ServiceIsolationEnvironment 名の長さ制限が原因で Namespace の不一致が発生し、Harbor インスタンスの作成が失敗します。次のようなメッセージが表示されることがあります。

Failed to reconcile ODSDatabase: failed to create or update ODS ProjectNetworkPolicy: namespaces "g-dbs-PROJECT_NAME-HARBOR_INSTANCE_NAME" not found

回避策: 現在の問題を解決するには、Harbor インスタンス名を短くします。PROJECT_NAME と HARBOR_INSTANCE_NAME の合計の長さが 27 文字未満であることを確認します。

Harbor インスタンスを削除しても、関連付けられたレジストリミラーは削除されない

バージョン: 1.13.1、1.13.3、1.13.4、1.13.5、1.13.6、1.13.7、1.13.8

現象: Harbor インスタンスを削除しても、関連付けられたレジストリミラーが削除されない。ノードプールが Provisioning 状態のままになっている可能性があります。これは、Harbor インスタンスが削除されたときに、MHS コントローラによって作成されたレジストリミラーが削除されないことが原因です。

回避策: レジストリミラーを手動で削除する必要があります。この問題を緩和するには、次の操作を行います。

組織の管理クラスタに接続します。詳細については、GDC クラスタアーキテクチャをご覧ください。

このスクリプトを実行して、ラベル lcm.private.gdc.goog/cluster-type=user を持つすべての Kubernetes クラスタから、HARBOR_INSTANCE_URL 環境変数の値に一致するレジストリミラーを削除します。

LABEL="lcm.private.gdc.goog/cluster-type=user"
ENDPOINT=HARBOR_INSTANCE_URL

while read -r out; do
    info=${out% *}
    ns_name=${info%:*}
    name=${ns_name##*/}
    ns=${ns_name%%/*}
    INDEX=$(kubectl get cluster user-vm-1 -n user-vm-1-cluster -ojson | jq '.spec.nodeConfig.registryMirrors | map(.endpoint=='\"$ENDPOINT\"') | index(true)')
    kubectl patch clusters "${name}" -n "${ns}" --type=json -p="[{'op': 'remove', 'path': '/spec/nodeConfig/registryMirrors/$INDEX'}]"
done <<< $(kubectl get clusters -l "$LABEL" -o jsonpath="$JSONPATH" -A)

HARBOR_INSTANCE_URL は、Harbor インスタンスの URL に置き換えます。

ハードウェアセキュリティモジュール

HSM の無効化されたトライアルライセンスは検出可能

バージョン: 1.13.1、1.13.3 ～ 1.13.11

現象: CipherTrust Manager の既知の問題により、無効にしたトライアルライセンスが検出され、誤った有効期限切れの警告が表示されることがあります。

回避策: HSM-R0003 を参照して、有効な通常ライセンスを確認し、無効化されたトライアルライセンスを削除します。

HSM ホストデーモンファイル記述子のリーク

バージョン: 1.13.x

症状: HSM が 30 日以上実行されると、ファイル記述子のリークによりホストデーモンサービスが応答を停止し、ServicesNotStarted エラーが発生する可能性があります。

回避策: host-daemon サービスを再起動します。これを行うには、インフラストラクチャオペレーター（IO）に、ksadmin ユーザーとして SSH 経由で HSM に接続し、次のコマンドを実行するように依頼します。

sudo systemctl restart host-daemon

それでも問題が解決しない場合は、IO が異常な HSM を再起動できます。

HSM 証明書の有効期限が切れている

バージョン: 1.13.11

症状: 組織をアップグレードするときに、次のような警告が表示されることがあります。

Warning  Unsuccessful  50m   OrganizationUpgrade  1 error occurred:
          * UPG1300: ABM upgrade expected to finish within 2h0m0s but hasn't after 13h45m23.442682119s, last message was: Cluster upgrade for system cluster: in-progress

HSM（ハードウェアセキュリティモジュール）証明書の有効期限が切れているため、org-1-system-cluster が ABM バージョンのアップグレードで停止しています。

HPE サーバー iLO、StorageGRID、ONTAP に次のようなエラーが表示されることもあります。

Not able to connect SSL to Key Manager server at IP_ADDRESS

回避策:

ksctl を使用してルート CA とウェブインターフェース証明書を手動でローテーションします。

HSM、HSMCluster、HSMTenant のすべての CR を一時停止します。

古いルート CA からコピーした属性を使用して、新しいルート CA を作成します。ksctl ca locals list を使用して古い CA ID を見つけます。次に例を示します。

ksctl ca locals create --cn example.com --copy-from-ca 6d7f7fa7-df81-44b7-b181-0d3e6f525d46
{
    "id": "b0516120-6b4c-40ed-93f4-35e9fdc690e7",
    "uri": "kylo:kylo:naboo:localca:b0516120-6b4c-40ed-93f4-35e9fdc690e7",
    "account": "kylo:kylo:admin:accounts:kylo",
    "createdAt": "2025-06-04T18:46:25.728332Z",
    "updatedAt": "2025-06-04T18:46:25.728332Z",
    "state": "pending",
    "csr": "-----BEGIN CERTIFICATE REQUEST-----\nMIHQMHgCAQAwFjEUMBIGA1UEAxMLZXhhbXBsZS5jb20wWTATBgcqhkjOPQIBBggq\nhkjOPQMBBwNCAAR5pwW1UC1JNg79gkjK2rvnmgaZpGNwb4VxYN3dQCieHtHlYJUu\nQWk56RB9oPw4SKkf/Y1ZwEI4m2mx3d9XFHU7oAAwCgYIKoZIzj0EAwIDSAAwRQIh\nANWTPjkJNcY56lSARN714EBa1gLuvxJlMENVHKEbanooAiA1BQ3sz7mxykL/1t7v\nqRlIpxKGrhw56XC67vz4NvZ4Kg==\n-----END CERTIFICATE REQUEST-----\n",
    "subject": "/CN=example.com",
    "notBefore": "0001-01-01T00:00:00Z",
    "notAfter": "0001-01-01T00:00:00Z",
    "sha1Fingerprint": "21F033940A65657CC6C2C1EA0BB775F14FD5D193",
    "sha256Fingerprint": "31EF6E1316DF039F77DDDB051890CDEBBF67BBE8A14AEE04E01716D30DC90937",
    "sha512Fingerprint": "F200817829A23F30239C33DC2CED8C889954A252EBA2CC12A3977FD5F91239ED7A2A4CCF0EA3D90D50CEF7A779E5C487798AAC75617DB2F29AF7F4794AD66F17",
    "purpose": {}
}

有効期間が 1 年の新しい CA に自己署名します。たとえば、次のようになります。

ksctl ca locals self-sign --id b0516120-6b4c-40ed-93f4-35e9fdc690e7 -x 365
{
    "id": "b0516120-6b4c-40ed-93f4-35e9fdc690e7",
    "uri": "kylo:kylo:naboo:localca:b0516120-6b4c-40ed-93f4-35e9fdc690e7",
    "account": "kylo:kylo:admin:accounts:kylo",
    "createdAt": "2025-06-04T18:46:25.728332Z",
    "updatedAt": "2025-06-04T18:52:51.976847092Z",
    "state": "active",
    "csr": "",
    "cert": "-----BEGIN CERTIFICATE-----\nMIIBbTCCAROgAwIBAgIRAMyQJHhs4i2uwj4ghilVFJQwCgYIKoZIzj0EAwIwFjEU\nMBIGA1UEAxMLZXhhbXBsZS5jb20wHhcNMjUwNjAzMTg1MjUxWhcNMjYwNjA0MTg1\nMjUxWjAWMRQwEgYDVQQDEwtleGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49\nAwEHA0IABHmnBbVQLUk2Dv2CSMrau+eaBpmkY3BvhXFg3d1AKJ4e0eVglS5BaTnp\nEH2g/DhIqR/9jVnAQjibabHd31cUdTujQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNV\nHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQ9uCnTZ+lHhiLx3f1xEn0+JC5J+TAKBggq\nhkjOPQQDAgNIADBFAiBsSiB5BRBJ8TZQ6O5TzMBgDoWzTZVMVXNLdZUiqHtcDwIh\nAOnqKNq5ytWLvMsBQKhulGgqqw1dccpkJJz01n3Smzyp\n-----END CERTIFICATE-----\n",
    "serialNumber": "271910941595574900448900837122680099988",
    "subject": "/CN=example.com",
    "issuer": "/CN=example.com",
    "notBefore": "2025-06-03T18:52:51Z",
    "notAfter": "2026-06-04T18:52:51Z",
    "sha1Fingerprint": "1114AF5ED6DF7D4A9F83A0F8DF5DFEF041A81622",
    "sha256Fingerprint": "93BAD9D44B320EFB446F65FE2A4F3A341147D15AF5315C000ADF644A3C1347A7",
    "sha512Fingerprint": "07386D7461B4013304CF0E0830517EA433E09EAB146A9F106F1B0DED4BBEC78BB4C89EAFAEC37178FE98AC4ACA234B98290D240607D5EA896F03DABF3DB56D5C",
    "purpose": {
            "client_authentication": "Enabled",
            "user_authentication": "Enabled"
    }
}

証明書の自動生成にこの新しい CA を使用するようにウェブインターフェースを更新します。例は次のようになります。

ksctl interfaces modify --name web --auto-gen-ca-id kylo:kylo:naboo:localca:b0516120-6b4c-40ed-93f4-35e9fdc690e7                 
{                                                                                                                                                                      
    "id": "61aab814-2821-43ac-b652-41784b7b06bf",                                                                                                                  
    "name": "web",                                                                                                                                                 
    "mode": "tls-cert-opt-pw-opt",                                                                                                                                 
    "cert_user_field": "CN",                                                                                                                                       
    "auto_gen_ca_id": "kylo:kylo:naboo:localca:b0516120-6b4c-40ed-93f4-35e9fdc690e7",                                                                              
    "trusted_cas": {                                                                                                                                               
            "local": [                                                                                                                                             
                    "kylo:kylo:naboo:localca:6d7f7fa7-df81-44b7-b181-0d3e6f525d46"                                                                                 
            ]                                                                                                                                                      
    },                                                                                                                                                             
    "createdAt": "2023-11-13T22:46:56.251881Z",                                                                                                                    
    "updatedAt": "2025-06-04T19:02:12.710563Z",                                                                                                                    
    "port": 443,                                                                                                                                                   
    "network_interface": "all",                                                                                                                                    
    "interface_type": "web",                                                                                                                                       
    "minimum_tls_version": "tls_1_2",                                                                                                                              
    "maximum_tls_version": "tls_1_3",                                                                                                                              
    "local_auto_gen_attributes": {                                                                                                                                 
            "cn": "web.ciphertrustmanager.local",                                                                                                                  
            "dns_names": [                                                                                                                                         
                    "web.ciphertrustmanager.local"                                                                                                                 
            ],      
...

新しい CA によって署名された新しいウェブインターフェース証明書を生成します。--url フラグは、HSM の管理 IP（kubectl get hsm -n gpc-system から）です。例は次のようになります。

ksctl interfaces auto-gen-server-cert --name "web" --url=https://10.128.52.18
{
    "certificates": "-----BEGIN CERTIFICATE-----\nMIICljCCAjygAwIBAgIRANPuw/42oHZAb9nzAYnrf9MwCgYIKoZIzj0EAwIwFjEU\nMBIGA1UEAxMLZXhhbXBsZS5jb20wHhcNMjUwNjAzMTkwOTU5WhcNMjYwNjA0MTg1\nMjUxWjBjMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVFgxDzANBgNVBAcTBkF1c3Rp\nbjEPMA0GA1UEChMGVGhhbGVzMSUwIwYDVQQDExx3ZWIuY2lwaGVydHJ1c3RtYW5h\nZ2VyLmxvY2FsMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEy9T8uGa/N9ruRJMy\nxy4an+G/OyZjB/8nth1BPxpw5orljbTuOh9toS9c9FiOuMQQ13mGJSImadLP33PR\ngdXcHaOCARwwggEYMA4GA1UdDwEB/wQEAwIDiDATBgNVHSUEDDAKBggrBgEFBQcD\nATAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaAFD24KdNn6UeGIvHd/XESfT4kLkn5\nMGIGA1UdEQRbMFmCHHdlYi5jaXBoZXJ0cnVzdG1hbmFnZXIubG9jYWyBIXRlY2hu\naWNhbC5zdXBwb3J0QHRoYWxlc2dyb3VwLmNvbYcECoA0EocECgADAocErBMjAocE\nrBMLAjBeBgNVHR8EVzBVMFOgUaBPhk1odHRwOi8vY2lwaGVydHJ1c3RtYW5hZ2Vy\nLmxvY2FsL2NybHMvYjA1MTYxMjAtNmI0Yy00MGVkLTkzZjQtMzVlOWZkYzY5MGU3\nLmNybDAKBggqhkjOPQQDAgNIADBFAiEAusSKWMoFeTsK+OrbURch7XtMR31XD45E\n+w+wjf2VAk4CIAsHytphizTFQks4qqOMaHm6Ap58uU0HMNGSm0WW6mQY\n-----END CERTIFICATE-----\n-----BEGIN CERTIFICATE-----\nMIIBbTCCAROgAwIBAgIRAMyQJHhs4i2uwj4ghilVFJQwCgYIKoZIzj0EAwIwFjEU\nMBIGA1UEAxMLZXhhbXBsZS5jb20wHhcNMjUwNjAzMTg1MjUxWhcNMjYwNjA0MTg1\nMjUxWjAWMRQwEgYDVQQDEwtleGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49\nAwEHA0IABHmnBbVQLUk2Dv2CSMrau+eaBpmkY3BvhXFg3d1AKJ4e0eVglS5BaTnp\nEH2g/DhIqR/9jVnAQjibabHd31cUdTujQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNV\nHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQ9uCnTZ+lHhiLx3f1xEn0+JC5J+TAKBggq\nhkjOPQQDAgNIADBFAiBsSiB5BRBJ8TZQ6O5TzMBgDoWzTZVMVXNLdZUiqHtcDwIh\nAOnqKNq5ytWLvMsBQKhulGgqqw1dccpkJJz01n3Smzyp\n-----END CERTIFICATE-----\n"
}

この時点では、openssl s_client -showcerts -connect 10.128.52.18:443 2>/dev/null | openssl x509 -text には古い証明書が表示されています。新しい証明書を取得するには、HSM を再起動する必要があります。
```
ssh -i ~/.ksctl/ssh-privatekey ksadmin@10.128.52.18

sudo reboot
```
openssl s_client -showcerts -connect 10.128.52.18:443 2>/dev/null | openssl x509 -text に新しい証明書が表示されます。

HSM CR から古い CA を削除します。

kubectl edit hsm zv-aa-hsm01 -n gpc-system and delete hsm.Spec.RootCACertificates

HSM の一時停止を解除します。

kubectl annotate hsm zv-aa-hsm01 -n gpc-system hsm.security.private.gdc.goog/paused-

HSM が正常になることを確認します。

他の 2 つの HSM についても、上記の手順を繰り返します。CA はクラスタ内の HSM 間で共有されるため、新しい自己署名ルート CA はすでに存在します。ステップ 2 と 3 をスキップし、ステップ 4 ～ 8 を繰り返します。
HSM T0008 CA ローテーションのトイルタスクに沿って、すべての証明書のローテーションを自動化しますが、ca-rotation-finalizing annotation が追加される hsmcluster に新しいローテーションアノテーションを追加してローテーションを完了するステップはスキップします。

新しい CA 名を iLO にアップロードします。

iLO インターフェースで、[Administration - Key Manager] ページを開き、[Key Manager] タブをクリックします。
証明書名をローテーションします。
コールド再起動を実行します。
SSL ハンドシェイクが再び機能し始めることを確認します。

ID とアクセスの管理

`opa-system` Namespace の `gatekeeper-audit` Pod が頻繁に再起動する

バージョン: 1.13.3

症状: opa-system Namespace の gatekeeper-audit-*** Pod のステータスを確認します。

kubectl get pods/gatekeeper-audit-POD_ID -n opa-system-NAMESPACE_ID -n opa-system

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

NAME                                READY   STATUS    RESTARTS        AGE
gatekeeper-audit-58d8c4c777-7hzvm   2/2     Running   987 (12h ago)   12d

この問題は、リソースの上限が低いことが原因で発生します。

Infrastructure as Code（IAC）

GitLab トークンの過剰な作成により、GitLab データベースが満杯になるリスクがある

バージョン: 1.13.1

現象: iac-manager サブコンポーネントが、必要がない場合でも configsync-ro ユーザーの新しいトークンを繰り返し作成します。これにより、Gitlab データベースが満杯になり、IAC にアクセスできなくなる可能性があります。gitlab-system 名前空間の pg-gitlab-database-0 Pod が起動できず、次のようなイベントが表示されることがあります。

  Warning  Unhealthy  84s (x18 over 4m14s)   kubelet  Startup probe failed: /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
psql: error: connection to server at "localhost" (127.0.0.1), port 5432 failed: FATAL:  could not write init file

回避策:

Google の担当者と協力して、1.13.1 リリース用の hotfix_3 を取得して適用します。

鍵管理システム（KMS）

ルートキーのタイプを変更すると、既存のキーがすべて無効になります

バージョン: 1.13.x

症状: 組織が作成されると、KMS にソフトウェアルートキーが自動的にプロビジョニングされます。ソフトウェアルート鍵から CTM 鍵に移行するには、サブコンポーネントのオーバーライドを行います。これにより、ルート鍵のタイプが変更され、KMS の既存のソフトウェア鍵がすべて無効になります。

回避策: 可能であれば、ルートキーのタイプを更新しないでください。ルートキータイプを更新すると、既存のキーはすべて無効になります。

`kms-rootkey-controller` `CrashLoopBackOff`（`OOMKILL`）

バージョン: 1.13.1

事象: kms-rootkey-controller メモリ使用量が 600Mi 上限を超えると、コントローラは OOMKilled ステータスにより CrashLoopBackOff に入ります。

回避策: SubcomponentOverride を作成して、メモリ上限を 1500Mi に更新します。手順については、KMS ランブック 0007 をご覧ください。ランブックの前提条件の手順を完了したら、次のコマンドを実行します。

SubcomponentOverride カスタムリソースを作成します。

cat << EOF > ~/kms-rootkey-subcomponentoverride.yaml

次の例は、完全な SubcomponentOverride カスタムリソースを示しています。

apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: kms-rootkey-subcomponentoverride
  namespace: root
spec:
  subComponentRef: kms-rootkey-cm
  backend:
    operableParameters:
      resourcesLimit:
        memory: 1500Mi
EOF

SubcomponentOverride リソースを適用します。

kubectl --kubeconfig ${KUBECONFIG:?} apply -f ~/kms-rootkey-subcomponentoverride.yaml

kubectl --kubeconfig ${KUBECONFIG:?} describe subcomponentoverride kms-rootkey-subcomponentoverride -n root

ロギング

オブジェクトストレージ監査ロガーが DNS ホストを解決できない

バージョン: 1.13.x

症状:

ルート管理クラスタで、obs-system/log-remote-logger デプロイに次のような複数のエラーが含まれています。

E1220 17:00:25.247258       1 manager.go:183] Failed to fetch obj audit logs for gce-gpcstgesite01: failed to get authorization token for Grid Management  API: Post "https://objectstorage-grid-mgmt.gpc-system.svc.cluster.local/api/v3/authorize": dial tcp: lookup objectstorage-grid-mgmt.gpc-system.svc.cluster.local: no such host

回避策: 次のコマンドを使用して obs-system/log-remote-logger デプロイにパッチを適用します。

kubectl --kubeconfig ${KUBECONFIG:?} patch deployment log-remote-logger -n obs-system -p '{"spec":{"template":{"spec":{"dnsPolicy":"ClusterFirstWithHostNet"}}}}'

HaaS Logger がルート管理クラスタでエラーを表示する

バージョン: 1.13.x

症状:

ルート管理クラスタで、obs-system/log-remote-logger デプロイに次のような複数のエラーが含まれています。

E0109 17:33:08.917876       1 manager.go:156] Failed to run logger haas: Failed to get log targets: failed to list harborinstances in the cluster: failed to get API group resources: unable to retrieve the complete list of server APIs: artifactregistry.gdc.goog/v1: the server could not find the requested resource

回避策: 1.13.8 にアップグレードしてエラーを修正します。または、次のように obs-system/log-remote-logger Deployment を変更します。

remote-logger コンテナ引数で、--disabled-loggers フラグを更新して、santricity と HaaS を含めます。

YAML

args:
  - --disabled-loggers=santricity,haas

Santricity Logger が失敗する

バージョン: 1.13.x

症状:

ルート管理クラスタで、obs-system/log-remote-logger デプロイに次のような複数のエラーが含まれています。

E0109 17:33:10.931737       1 manager.go:183] Failed to fetch santricity audit logs for lb-aa-objs01: failed to get CA cert: failed to get ClusterIssuer internal-root-ca-issuer: no kind is registered for the type v1.ClusterIssuer in scheme "pkg/logging/manager.go:32"

回避策: 1.13.8 にアップグレードしてエラーを修正します。

ロギングターゲットのログが間違ったプロジェクトに送信される

バージョン: 1.13.x

症状: obs-system/oplogs-forwarder DaemonSet が次のような警告をログに記録します。

oplogs-forwarder-2xrfw [2025/01/16 21:02:09] [ warn] [output:loki:log_output_loki_dbs_fleet_system_dbs_fleet] Tenant ID is overwritten platform-obs -> infra-obs
oplogs-forwarder-kxf8p [2025/01/16 21:05:23] [ warn] [output:loki:log_output_loki_workbench_system_nws_lt] Tenant ID is overwritten infra-obs -> platform-obs

これらの警告により、ログが間違ったプロジェクト（テナント ID）に転送されます。この問題は、Fluent Bit の既知のバグが原因です。詳細については、Fluent Bit GitHub の問題をご覧ください。

回避策: 1.13.8 にアップグレードしてエラーを修正します。

プラットフォーム Namespace の監査ログは PA に表示されない

バージョン: 1.13.x

現象: プラットフォーム Namespace の監査ログが、プラットフォーム管理者（PA）ではなくインフラストラクチャオペレーター（IO）に表示されます。

回避策: すべての組織クラスタの platform Namespace に observability.gdc.goog/auditlog-destination=pa ラベルを手動で追加します。この手動の回避策を実装する手順は次のとおりです。

KUBECONFIG をターゲットクラスタに設定します。

必要なラベルを Namespace に追加します。

KUBECONFIG=${KUBECONFIG:?} kubectl label namespace platform observability.gdc.goog/auditlog-destination=pa --overwrite

ラベルが正常に追加されたことを確認します。

KUBECONFIG=${KUBECONFIG:?} kubectl label namespace platform --list

Pod がコンテナの初期化に失敗する

バージョン: 1.13.x

現象: Pod の作成が失敗し、次のようなエラーが発生します。

Events:
│   Type     Reason                  Age                     From     Message                                                                                                                                                 │
│   ----     ------                  ----                    ----     -------                                                                                                                                                 │
│   Warning  FailedCreatePodSandBox  10m (x2080 over 7h40m)  kubelet  Failed to create pod sandbox: mkdir /var/log/pods/org-1_managed-asm-local-readiness-xq75d_9a3275d7-5f16-4d67-8f4a-38fe0993be4a: no space left on device │

これらのエラーにより、特定のノードで Pod が起動されなくなります。この動作は、logrotate-daemon ステータスファイルがロックされ、デーモンが想定どおりのファイルローテーションを実行できなくなる既知のエッジケースで発生します。このエラーを確認する手順は次のとおりです。

KUBECONFIG をターゲットクラスタに設定します。
ノードでスケジュールされている anthos-audit-logs-forwarder-xxxx インスタンスを特定します。
```
KUBECONFIG=${KUBECONFIG:?} kubectl get po -n obs-system -o wide | grep anthos-audit-logs-forwarder
```

ノードでスケジュールされた anthos-audit-logs-forwarder-xxxx インスタンスからログを取得して確認します。

KUBECONFIG=${KUBECONFIG:?} kubectl logs -n obs-system anthos-audit-logs-forwarder-xxxx -c logrotate-daemon | grep "state file /var/lib/logrotate/status is already locked"

回避策:

この問題を解決するには、次の手順を行います。

ノードの /var/log ディレクトリでディスク容量の手動再利用を実行します。
KUBECONFIG をターゲットクラスタに設定します。
クラスタ内のターゲットノードを特定します。
```
KUBECONFIG=${KUBECONFIG:?} kubectl get no -o wide
```

SSH を使用してノードに接続し、ノードの /var/log ディレクトリのスペースを手動で解放します。logrotate は、これらのディレクトリにあるファイルを管理します。

/var/log/audit/*/*/*/audit.log
/var/log/audit*/*/*.log
/var/log/auditproxy-*/*.log
/var/log/global-api-*/audit.log
/var/log/ceph/ceph.audit.log
/var/log/fanout/audit/*.log
/var/log/fanout/audit/*/*.log
/var/log/netflow/*.log
/var/log/fanout/operational/*.log
/var/log/fanout/operational/*/*.log

異常に大きなログファイル（サイズが 100 MB を超える）や、数日以上前のファイルがないか確認します。ターゲットファイルがある場合は、次のようにログを切り捨てることができます。
```
truncate -s 1G <target_file>
```
ノードでスケジュールされている anthos-audit-logs-forwarder-xxxx インスタンスを特定します。
```
KUBECONFIG=${KUBECONFIG:?} kubectl get po -n obs-system -o wide | grep anthos-audit-logs-forwarder
```
ノードでスケジュールされている anthos-audit-logs-forwarder-xxxx インスタンスを再起動します。
```
KUBECONFIG=${KUBECONFIG:?} kubectl delete po -n obs-system anthos-audit-logs-forwarder-xxxx
```

Marketplace

Prisma Cloud イメージの pull が失敗する

バージョン: 1.13.7

現象: Marketplace から Prisma Cloud サービスインスタンスを作成できません。この問題は、画像タグが正しくないことが原因で発生します。

回避策:

twistlock-console デプロイを編集してイメージタグを変更します。

KUBECONFIG=${KUBECONFIG:?} kubectl edit deployment twistlock-console -n ${PROJECT:?}

次の行を探します。

image: HARBOR_IP/library/twistlock/console:console_33_01_137

console_33_01_137 を console_33.01.137 に置き換えます。

image: HARBOR_IP/library/twistlock/console:console_33.01.137

Pod が正しく実行されていることを確認します。

KUBECONFIG=${KUBECONFIG:?} kubectl get pods -n ${PROJECT:?}

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

NAME                                 READY   STATUS    RESTARTS   AGE
twistlock-console-58b578cbf4-5nvbk   1/1     Running   0          2m45s

モニタリング

ServiceNow で大量のアラートが作成される

バージョン: 1.13.x

症状:

MON-T0016 と MON-T1016 の toil タスクを使用して、Monitoring が ServiceNow にアラートを送信するように構成すると、ServiceNow で大量のインシデントが自動的に作成されます。

この問題には次の特徴があります。

インシデントがすべて空です。
ServiceNow にアラートを送信できるのは、ルート管理クラスタと gdchservices 組織のみです。

回避策: MON-T0016 と MON-T1016 のトイルタスクを実行した直後に、MON-T0018 のトイルタスクを実行します。

ServiceNow で重複するアラートが複数作成される

バージョン: 1.13.x

症状:

MON-T0016、MON-T1016、MON-T0018 のトイルタスクを使用して、ServiceNow にアラートを送信するようにモニタリングを構成すると、ServiceNow に複数の重複するアラートが作成されます。

この問題には次の特徴があります。

MON-T0018 の toil タスクを適用しても、一部のアラートで重複するインシデントが複数作成される。

回避策: MON-T0016、MON-T1016、MON-T0018 の Toil タスクを実行した直後に、MON-T0019 の Toil タスクを実行します。

Vertex AI 指標を表示できない

バージョン: 1.13.1

症状: 指標が dvs-frontend-server Pod から出力されない。

回避策: バージョン 1.13.1 は、Vertex AI サービスの暗号化された指標をサポートしていません。Vertex AI サービスが 1 時間以上有効にならない場合は、mon-admin コントローラ Pod を再起動します。

`mon-cortex` の調整エラー

バージョン: 1.13.1、1.13.9

症状: mon-cortex Pod に調整エラーが発生します。mon-cortex Pod のステータスを取得します。

kubectl get subcomponent mon-cortex -n gpu-org-1-system-cluster

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

NAME         AGE   STATUS
mon-cortex   15h   ReconciliationError

次のようなメッセージがログに記録されることがあります。

message: 'E0100 - deploy: failed to install chart: release mon-cortex-backend
        failed, and has been uninstalled due to atomic being set: context deadline
        exceeded'

回避策:

次のようなメッセージを送信している Cortex Pod を確認します。

Warning  FailedMount             11s   kubelet                  MountVolume.MountDevice failed for volume "pvc-0ad24fdc-52ec-4080-8ac0-5784989d1da3" : rpc error: code = Internal desc = rpc error: code = Internal desc = failed to stage volume: could not open LUKS device; could not open LUKS device; could not open LUKS device; exit status 1

その Pod に関連付けられている PVC を削除して、再起動します。

システムクラスタの `metrics-server-exporter` Pod がクラッシュループしている

バージョン: 1.13.1

症状: システムクラスタの metrics-server-exporter Pod が OOMKilled でクラッシュループしていますが、上限に達していないようです。エラーを診断します。

kubectl --kubeconfig $KUBECONFIG describe pod -n mon-system metrics-server-exporter-<id>

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

[...]
Containers:
  [...]
  otel-collector:
    Container ID:  containerd://3a1373de4880cde9e09aa9cacc109a8059ec29d9355aef1f03735fdcdcd45596
    Image:         gcr.io/private-cloud-staging/opentelemetry-collector:v0.93.0-gke.2
    Image ID:      gcr.io/private-cloud-staging/opentelemetry-collector@sha256:2b14f8fe936e725efca24dace1abcc26449d996b1480eab1b25d469a16aac221
    Port:          3113/TCP
    Host Port:     0/TCP
    Command:
      /otelcol
      --config=/conf/otel-collector-config.yaml
      --feature-gates=pkg.translator.prometheus.PermissiveLabelSanitization
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    137
      Started:      Thu, 20 Jun 2024 15:55:35 +0000
      Finished:     Thu, 20 Jun 2024 15:56:57 +0000
    Ready:          False
    Restart Count:  570
    Limits:
      cpu:     200m
      memory:  200Mi
    Requests:
      cpu:        100m
      memory:     100Mi
    Environment:  <none>

回避策: Pod を削除して再起動することで、指標エンドポイントで提供されるデータ量を減らします。この処理を行うと、メモリに保持されている古い time-series がクリアされ、必要なメモリが削減されます。

`ObservabilityPipeline` の調整エラーメッセージを無視する

バージョン: 1.13

症状:

ObservabilityPipeline オブジェクトは、root-admin-controller Pod に次のような Reconciler error ログを表示します。

{"msg":"Reconciler error","controller":"observabilitypipeline","ObservabilityPipeline":{"name":"default","namespace":"infra-obs"},"namespace":"infra-obs","name":"default","err":"unable to reconcile project level ObservabilityPipeline: 1 error occurred:\n\t* failed to get system cluster client to install per project overrides: root admin cluster has no system cluster\n\n"}

回避策:

次の条件をすべて満たすログを無視します。

"controller":"observabilitypipeline"
"namespace":"infra-obs"
"name":"default"
"err" に failed to get system cluster client to install per project overrides: root admin cluster has no system cluster が含まれる

調整エラーが多いことが原因でアラートをデバッグしている場合は、これらのログは誤検出であるため無視してください。

`mon-prober-backend-prometheus-config` ConfigMap がリセットされる

バージョン: 1.13.0 と 1.13.1

症状:

アラート MON-A0001 がトリガーされます。

mon-prober-backend-prometheus-config ConfigMap がリセットされ、プローブジョブが含まれなくなります。次に例を示します。

apiVersion: v1
data:
  prometheus.yaml: |
    remote_write:
    - url: http://cortex-tenant.mon-system.svc:9009/push
      name: cortex-tenant
kind: ConfigMap
metadata:
  creationTimestamp: "2024-06-26T14:55:07Z"
  name: mon-prober-backend-prometheus-config
  namespace: mon-system
  resourceVersion: "6606787"
  uid: 1a495af0-1fdc-40b8-845b-4976e3b0f899

回避策:

問題を解決するには、以下の手順を行ってください。

次の環境変数を設定します。
- KUBECONFIG: クラスタ内の kubeconfig ファイルのパス。
- TARGET_CLUSTER: 問題を解決するクラスタの名前。

すべてのクラスタで mon-prober サブコンポーネントを一時停止します。

kubectl --kubeconfig $KUBECONFIG annotate subcomponent mon-prober -n $TARGET_CLUSTER lcm.private.gdc.goog/paused=true

次に例を示します。

kubectl --kubeconfig ~/root-admin-kubeconfig annotate subcomponent mon-prober -n my-org lcm.private.gdc.goog/paused=true

各管理クラスタで MON 管理コントローラを再起動します。
```
kubectl --kubeconfig $KUBECONFIG rollout restart deploy -n obs-system mon-admin-backend-controller
```
Prober ConfigMap は、各プローブが登録されるたびに設定されます。
このアラートは継続的に発生するため、ランブック MON-R2009 に沿って MON-A0001 アラート Blackbox monitoring metrics pipeline down をミュートします。

Cortex ストアゲートウェイコンポーネントの OOMKilled crashloop

バージョン: 1.13.3

症状: 指標の読み込み時に Grafana でエラーが表示される場合や、指標がまったく読み込まれない場合は、cortex-store-gateway Pod がクラッシュループしている可能性があります。

cortex-store-gateway Pod を診断し、クラッシュループが発生しているかどうかを確認するには、ステータスを確認します。

kubectl --kubeconfig SYSTEM_CLUSTER_KUBECONFIG describe pod \
  -l app=cortex-store-gateway -n mon-system

SYSTEM_CLUSTER_KUBECONFIG は、システムクラスタの kubeconfig ファイルのパスに置き換えます。

Pod がクラッシュループしている場合、出力は次の例のようになります。

State:          Waiting
Reason:       CrashLoopBackOff
Last State:     Terminated
Reason:       OOMKilled
Exit Code:    137

回避策: SubcomponentOverride を使用して、cortex-store-gateway メモリの上限を一時的に増やします。SubComponentOverride の実装の詳細については、MON-R2008 ランブックをご覧ください。

メモリ上限が指定された SubcomponentOverride の例を次に示します。

apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: mon-cortex-memory-bump
  namespace: org-1-system-cluster
spec:
  subComponentRef: 'mon-cortex'
  backend:
    operableParameters:
      storeGateway:
          resourcesLimit:
              memory: 16Gi

すべての cortex-store-gateway Pod のステータスが Ready になるまでオーバーライドをそのままにして、mon-cortex サブコンポーネントが一時停止されていないことを確認します。

cortex-store-gateway Pod のステータスが Ready であることを確認します。
```
kubectl --kubeconfig SYSTEM_CLUSTER_KUBECONFIG get statefulset \
  -n mon-system cortex-store-gateway
```
すべての Pod のステータスが Ready の場合、出力は次の例のようになります。
```
NAME                   READY   AGE
cortex-store-gateway   3/3     70d
```
すべての Pod が準備完了になるには、READY 列に N/N 値が表示されている必要があります。それ以外の場合は、1/3 や 2/3 などの値が表示されます。
特定の組織で mon-cortex サブコンポーネントが一時停止されていないことを確認します。
```
kubectl --kubeconfig ORG_ADMIN_KUBECONFIG describe subcomponent \
  -n SYSTEM_CLUSTER mon-cortex | grep paused
```
次のように置き換えます。
- ORG_ADMIN_KUBECONFIG: 組織の管理クラスタの kubeconfig ファイルのパス。
- SYSTEM_CLUSTER: システムクラスタの名前。
サブコンポーネントが一時停止されている場合、出力には次の行が表示されます。
```
lcm.private.gdc.goog/paused: true
```
それ以外の場合、出力は空になります。

ユーザークラスタで Kube コントロールプレーン指標プロキシイメージのプルバックオフが発生する

バージョン: 1.13.3

現象: kube-scheduler または kube-controller-manager に関連する指標（scheduler_pending_pods 指標や workqueue_depth 指標など）が Grafana に表示されない場合、kube-control-plane-metrics-proxy Pod でイメージプルバックオフの問題が発生している可能性があります。

kube-control-plane-metrics-proxy Pod を診断し、イメージプルバックオフの問題があるかどうかを確認するには、ステータスを確認します。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe pod \
  -l k8s-app=kube-control-plane-metrics-proxy -n obs-system

USER_CLUSTER_KUBECONFIG は、ユーザークラスタの kubeconfig ファイルのパスに置き換えます。

Pod にイメージプルバックオフの問題がある場合、出力は次のようになります。

State:          Waiting
Reason:       ImagePullBackOff
Ready:          False
Restart Count:  0

回避策: この問題を解決するには、次の手順を行います。

gpc-system-container-images Harbor プロジェクトから gcr.io/gke-release/asm/proxyv2:1.20.4-asm.0 イメージを pull します。イメージの pull に必要な手順と権限については、Docker を使用してイメージを pull するをご覧ください。
gcr.io/gke-release/asm/proxyv2:1.20.4-asm.0 イメージを library Harbor プロジェクトに push します。イメージの push に必要な手順と権限については、イメージを push するをご覧ください。

library プロジェクトは、ユーザークラスタにデプロイされるアーティファクトに使用されます。

WAL の増加により、Prometheus が大量のメモリを使用する

バージョン: 1.13.3

現象: システムコントロールプレーン VM ノードが NodeHasInsufficientMemory イベントと EvictionThresholdMet イベントを報告します。

kubectl describe node NODE_NAME | grep Events -A100

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

Events:
  Type     Reason                     Age                   From                   Message
  ----     ------                     ----                  ----                   -------
  Normal   NodeNotReady               12m (x8 over 10d)     node-controller        Node vm-e792c63a status is now: NodeNotReady
  Normal   NodeHasNoDiskPressure      12m (x9 over 24d)     kubelet                Node vm-e792c63a status is now: NodeHasNoDiskPressure
  Normal   NodeHasSufficientPID       12m (x9 over 24d)     kubelet                Node vm-e792c63a status is now: NodeHasSufficientPID
  Normal   NodeReady                  12m (x9 over 24d)     kubelet                Node vm-e792c63a status is now: NodeReady
  Normal   NodeHasInsufficientMemory  12m (x34 over 13h)    kubelet                Node vm-e792c63a status is now: NodeHasInsufficientMemory
  Warning  EvictionThresholdMet       12m (x64 over 13h)    kubelet                Attempting to reclaim memory
  Normal   TridentServiceDiscovery    11m (x21 over 13h)    csi.trident.netapp.io  [iSCSI] detected on host.
  Normal   NodeHasSufficientMemory    6m52s (x31 over 24d)  kubelet                Node vm-e792c63a status is now: NodeHasSufficientMemory

Prometheus は WAL（write-ahead log）の増加により多くのメモリを使用し、ノードのメモリに影響します。WAL の増加は Cortex がデプロイされていないことが原因で発生する可能性があります。この問題は Cortex のダウンが原因で発生する可能性があります。Prometheus インスタンスが Cortex への接続を長時間失い、その間、メモリと永続ボリューム（PV）にデータをバッファリングします。Prometheus が終了すると、起動時に WAL 内のすべてのデータがメモリに読み込まれます。

別の根本原因として、ネットワーク接続の問題（サービスメッシュ、物理ネットワーク、上位ネットワーク）が考えられます。

回避策: この状態から回復するには、根本原因を解決して Cortex を正常な状態にするか、ネットワーク接続の問題を解決することをおすすめします。次に、Prometheus からの WAL がドレインされるまで待ちます。データは失われませんが、Cortex がダウンしていた場合、Cortex が復旧するまでの間、ノードは使用できません。

または、Prometheus STS をゼロにスケールダウンして PV を削除することもできます。このアクションにより、ノードが使用できない合計時間は短縮されますが、データが失われます。また、Cortex がダウンしている間、またはネットワーク接続の問題が発生している間は、この操作を定期的に繰り返す必要があります。Prometheus と Cortex の間に接続の問題がある限り、PV は再びいっぱいになります。

Prometheus STS をゼロにスケールダウンして PV を削除する手順は次のとおりです。

logmon-operator コンポーネントをスケールダウンします。
```
kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG scale deployment -n obs-system logmon-operator --replicas 0
```
ORG_SYSTEM_KUBECONFIG は、組織システムクラスタ内の kubeconfig ファイルのパスに置き換えます。

anthos-prometheus-k8s コンポーネントをスケールダウンします。

kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG scale statefulset -n obs-system anthos-prometheus-k8s --replicas 0

Persistent Volume Claim を削除します。

kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG delete pvc -n obs-system anthos-prometheus-k8s-data-anthos-prometheus-k8s-0

logmon-operator をスケールアップします。

kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG scale deployment -n obs-system logmon-operator --replicas 1

anthos-prometheus-k8s の準備ができるまで待ちます。

マルチゾーンブートストラップ

クラスタロールがない

バージョン: 1.13.1

症状: 必要なロールを追加するで使用するマルチゾーンをブートストラップするための特定のロールがありません。

回避策: リンクされた手順で指定されている cluster-admin クラスタロールを使用します。これにより、ユーザーは後続のタスクを実行するために必要な最小限のアクセス権よりも多くのアクセス権を取得します。

互換性のない `Bootstrap` リソース

バージョン: 1.13.1

症状: ブートストラップファイルを作成するの手順 3 で作成された Bootstrap リソースが、それを処理するロジックと互換性がありません。

回避策: 手順 4 で指定したとおりに、生成された YAML ファイルを編集します。

`GlobalAPIZone` リソースがグローバル API に作成されない

バージョン: 1.13.1

症状: コントロールプレーンがグローバル API のゾーンの GlobalAPIZone リソースを作成しないため、このリソースに依存するコンポーネントが正しく機能しません。

回避策: GlobalAPIZone リソースを作成するに記載されているようにリソースを作成します。

ネットワーキング

Object Storage Nodes Grid Network down

バージョン: 1.13.1、1.13.3、1.13.4

症状:

オブジェクトストレージのブートストラップフェーズでは、OBJ 管理ノードインストーラ UI でグリッドネットワークがダウンしていると表示されます。
cables.csv と Cell CR は、オブジェクトストレージ objsadmin ノードと TOR スイッチ間の接続の cables.csv の MPN 値が QSFP-100G-CU2.5M であることを示しています。

説明 1.13 では、cables.csv の MPN フィールドを使用して、Tor スイッチに設定されている速度を特定します。これらのポートに速度が設定されていない場合、tor スイッチから objsadmin ノードへの接続は失敗します。MPN を速度にマッピングするために使用されるリストで、システムインテグレータが提供した値が考慮されていなかったため、オブジェクトストレージのブートストラップが失敗していました。1.13 のほとんどのセットアップでは、ベンダーは QSFP-100G-CU2.5M を使用していました。

回避策:

ルート管理者クラスタで kubectl get -A cell -oyaml を使用して、オブジェクトストレージアプライアンスと TOR スイッチに関連する接続を見つけます。
objsadm -> torsw connect の mpn のすべての出現箇所を「QSFP-100G-CU3M」に変更します。

次に例を示します。

    - endA: "ap-aa-torsw01:Eth1/10"
      endB: "ap-aa-objsadm01:e3a"
      cableType: "DAC"
      mpn: "QSFP-100G-CU3M"
      length: "2m"
      color: "Black"

ノードに到達できない

バージョン: 1.13.1、1.13.3、1.13.4

症状:

ネットワークブートストラップフェーズでは、一部のスイッチに到達できません。
DHCP インストールフェーズで、一部のサーバーに iLO IP アドレス経由でアクセスできない。

回避策:

影響を受ける管理スイッチを再読み込みします。詳細については、PNET-R0018 ランブックを参照してください。

`ClusterCIDRConfig` が作成されても `PodCIDR` がノードに割り当てられない

バージョン: 1.13.1

症状: PodCIDRs を割り当てるには、ClusterCIDRConfig が必須のオブジェクトです。ClusterCIDRConfig が作成されたにもかかわらず、PodCIDRs が割り当てられませんでした。この問題は、ipam-controller Pod のブートストラップと同時に ClusterCIDRConfig が作成された場合に発生します。クラスタの作成が調整状態で停止しています。

クラスタに ClusterCIDRConfig オブジェクトが作成されているかどうかを確認します。

kubectl --kubeconfig=CLUSTER_KUBECONFIG get clustercidrconfigs -oyaml

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

apiVersion: v1
items:
- apiVersion: networking.gke.io/v1alpha1
  kind: ClusterCIDRConfig
  metadata:
    annotations:
      baremetal.cluster.gke.io/managed: "true"
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"networking.gke.io/v1alpha1","kind":"ClusterCIDRConfig","metadata":{"annotations":{"baremetal.cluster.gke.io/managed":"true"},"creationTimestamp":null,"name":"root-admin-control-plane"},"spec":{"ipv4":{"cidr":"172.24.0.0/21","perNodeMaskSize":23},"ipv6":{"cidr":"fd00:1::2:0/112","perNodeMaskSize":119}},"status":{}}
    creationTimestamp: "2024-06-17T05:27:55Z"
    finalizers:
    - networking.kubernetes.io/cluster-cidr-config-finalizer
    generation: 1
    name: root-admin-control-plane
    resourceVersion: "2172"
    uid: d1216fe3-04ed-4356-a105-170d72d56c90
  spec:
    ipv4:
      cidr: 172.24.0.0/21
      perNodeMaskSize: 23
    ipv6:
      cidr: fd00:1::2:0/112
      perNodeMaskSize: 119
kind: List
metadata:
  resourceVersion: ""

調整が停止しているクラスタのノードオブジェクトのいずれかで describe を実行し、ノードオブジェクトに CIDRNotAvailable イベントが存在するかどうかを確認します。

kubectl --kubeconfig=CLUSTER_KUBECONFIG describe node NODE_NAME

出力イベントは次のようになります。

  Type     Reason            Age                   From             Message
  ----     ------            ----                  ----             -------
  Normal   CIDRNotAvailable  3m22s (x96 over 21h)  cidrAllocator    Node gpc-adhoc-4f533d50vm-worker-node2-zone1 status is now: CIDRNotAvailable
  Warning  ReconcileError    3m22s (x96 over 21h)  ipam-controller  CIDRAssignmentFailed, retrying: failed to get cidrs for node gpc-adhoc-4f533d50vm-worker-node2-zone1, unable to get clusterCIDRs for node gpc-adhoc-4f533d50vm-worker-node2-zone1, no available CIDRs

回避策:

ipam-controller-manager Pod を再起動します。

kubectl --kubeconfig=CLUSTER_KUBECONFIG -n kube-system rollout restart ds ipam-controller-manager

ipam-controller-manager Pod が実行状態になったら、podCIDR がノードに割り当てられているかどうかを確認します。
```
kubectl --kubeconfig=CLUSTER_KUBECONFIG get nodes -oyaml | grep podCIDR
```
出力は次のようになります。
```
podCIDR: 172.24.4.0/23
podCIDRs:
podCIDR: 172.24.2.0/23
podCIDRs:
podCIDR: 172.24.0.0/23
podCIDRs:
```

NTP のドリフト

バージョン: 1.13.1

症状: VM ノードがスリープ状態になった後、またはしばらく実行された後に、時間がずれたり不正確になったりします。

回避策:

VM ノードへの SSH 接続を確立し、/etc/chrony.conf ファイルを編集します。
行 makestep 1.0 3 を makestep 1.0 -1 に置き換えます。
chronyd サービスを再起動します。
```
systemctl restart chronyd
```

この変更は、各 VM に対して 1 回だけ行う必要があります。変更は上書きされません。

時間をスキップする迅速な応急処置として、VM ノードからノードへの SSH 接続を確立し、chronyc -a makestep を実行します。

SyncServer の監査ログが解析されない

バージョン: 1.13.1、1.13.3、1.13.4、1.13.5、1.13.6、1.13.7

現象: SyncServer の監査ログが log-remote-logger によって正しく解析されない。一部の監査ログは Grafana で使用できません。root-admin log-remote-logger Pod に次のようなエラーメッセージが表示されることがあります。

Failed to fetch syncserver audit logs for syncserver-...

回避策: 監査ログは SyncServer で引き続き利用できます。NTP-P0002 に沿って SyncServer UI にアクセスし、Logs > Events の下のログを表示します。

Switch イメージでイメージの抽出に失敗しました

バージョン: 1.13.3

現象: スイッチ RMA を実行する場合や、ルート管理者クラスタをブートストラップする場合に、SwitchImageHostRequest オブジェクトに次のようなメッセージが表示されることがあります。

failed to pull or extract image "192.0.2.0:10443/gdch-switch/os:v1.13.0-pnet-aa505d9004

kubectl アクセス権がある場合は、それを使用してこの問題が発生しているかどうかを確認します。

kubectl --kubeconfig=<path/to/root-admin-kubeconfig> -n gpc-system get switchimagehostrequest -o yaml

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

kind: SwitchImageHostRequest
metadata:
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    meta.helm.sh/release-name: pnet-core-assets
    meta.helm.sh/release-namespace: pnet-system
  creationTimestamp: "2024-08-20T04:16:36Z"
  generation: 1
  labels:
    app.kubernetes.io/managed-by: Helm
  name: v1.13.0-pnet-aa505d9004
  namespace: gpc-system
  resourceVersion: "149295"
  uid: f6c5b880-3fdb-4679-acd4-840b52998946
spec:
  fromVersion: v1.13.0-pnet-aa505d9004
  toVersion: v1.13.0-pnet-aa505d9004
status:
  conditions:
  - lastTransitionTime: "2024-08-20T05:10:17Z"
    message: ""
    observedGeneration: 1
    reason: TFTPRunning
    status: "True"
    type: TFTPReady
  - lastTransitionTime: "2024-08-20T04:16:36Z"
    message: 'exception: failed to pull images with config images: [{10.249.48.5:10443/gdch-switch/os:v1.13.0-pnet-aa505d9004
      /shared/tftpboot/switch/images}]: failed to pull or extract image "10.249.48.5:10443/gdch-switch/os:v1.13.0-pnet-aa505d9004":
      failed to pull image from source "10.249.48.5:10443/gdch-switch/os:v1.13.0-pnet-aa505d9004":
      GET https://10.249.48.5:10443/v2/gdch-switch/os/manifests/v1.13.0-pnet-aa505d9004:
      NOT_FOUND: artifact gdch-switch/os:v1.13.0-pnet-aa505d9004 not found'
    observedGeneration: 1
    reason: ReconcileBackoff
    status: Unknown
    type: Ready

回避策:

正しいイメージタグを使用して SwitchImageHostRequest を手動で作成します。

ブートストラップサーバーにログインします。
gdcloud を使用して、正しいスイッチイメージバージョンを特定します。
```
release/gdcloud artifacts tree release/oci/ | grep -i gdch-switch
```
出力は次のようになります。
```
│   │   │   │   └── gdch-switch/os:1.13.3-gdch.5385
```
この出力から、正しいスイッチイメージのバージョンは 1.13.3-gdch.5385 です。

エラーを報告する SwitchImageHostRequest オブジェクトを編集します。

kubectl --kubeconfig=<path/to/root-admin-kubeconfig> -n gpc-system edit switchimagehostrequest <SWITCH_IMAGE_HOST_REQUEST_NAME>

name、fromVersion、toVersion の各フィールドを編集または置き換えて、想定されるスイッチイメージバージョンと一致させます。この場合は 1.13.3-gdch.5385 です。次の diff 出力は、SwitchImageHostRequest オブジェクトに対して行う変更を示しています。
```
kind: SwitchImageHostRequest
metadata:
- name: v1.13.0-pnet-aa505d9004
+ name: 1.13.3-gdch.5385
  namespace: gpc-system
spec:
- fromVersion: v1.13.0-pnet-aa505d9004
+ fromVersion: 1.13.3-gdch.5385
- toVersion: v1.13.0-pnet-aa505d9004
+ toVersion: 1.13.3-gdch.5385
```

StatefulSet Pod の通信が失敗する

バージョン: 1.13.1、1.13.3、1.13.4、1.13.5、1.13.6、1.13.7、1.13.8、1.13.9、1.13.10

症状: StatefulSet Pod の再起動後に Cilium Endpoint（CEP）オブジェクトの削除が正しく処理されないため、接続に関する問題や中断が発生します。これにより、管理対象外のエンドポイント ID が原因で、ネットワークポリシーが正当なトラフィックを誤ってドロップする可能性があります。影響を受ける Pod は、対応する CEP オブジェクトがないことを確認することで検証できます。

kubectl get cep -A | grep [*POD_IP*]

回避策: 影響を受ける StatefulSet Pod を再起動して UID を更新し、関連するメタデータを更新します。

kubectl rollout restart statefulset [*STATEFULSET_NAME*] -n [*NAMESPACE*]

DBS インスタンスへの接続に関する問題

バージョン: 1.13.0、1.13.1

現象: データベースクライアントで接続タイムアウトが表示され、Database Services（DBS）インスタンスにアクセスできない。

この問題は、DBS に依存する別のシステムコンポーネントを通じて表面化する可能性があります。たとえば、課金で次のようなエラーメッセージが報告されることがあります。

DBSE0301: Healthcheck: DB cluster is not healthy. Cannot connect to DBdaemon
DBSE0005: DBDaemon Client Error. secure dbdaemon connection failed: context
deadline exceeded

回避策: このエラーは、組織のサービスクラスタでスケジュールを設定できないネットワークシステムコンポーネントが原因で発生します。

次の環境変数を設定します。
```
export KUBECONFIG=KUBECONFIG_PATH
export ORG_NAME=ORG_NAME
```
次のように置き換えます。
- KUBECONFIG_PATH: 組織の管理クラスタの kubeconfig ファイルへのパス。
- ORG_NAME: 組織の名前（org-1 など）。

ネットワーキングコンポーネントの構成を更新して、スケジュールできるようにします。

kubectl --kubeconfig=KUBECONFIG_PATH kubectl -n g-ORG_NAME-shared-service-cluster   patch addonconfiguration ang-overrides   --type='json'   -p='[{"op": "replace", "path": "/spec/configs/1/patchContent", "value": "apiVersion: apps/v1\nkind: DaemonSet\nmetadata:\n  name: ang-node\n  namespace: kube-system\nspec:\n  template:\n    spec:\n      containers:\n      - name: angd\n      - name: bgpd\n        env:\n        - name: DISABLE_RECEIVED_ROUTES\n          value: \"true\"\n      tolerations:\n      - operator: \"Exists\"\n        effect: \"NoSchedule\""}]'

ネットワーク接続は数分後に復元されます。

クラスタメッシュがゾーン情報で構成されていない

バージョン: 1.13.5

症状: VM が同じプロジェクト内のデータベースクラスタに接続できません。内部ロードバランサへの接続が影響を受けます。この問題は、クラスタ名構成にゾーン情報がないため、Clustermesh がクラスタ間でサービスオブジェクトを交換できないことが原因で発生します。

回避策: マルチゾーンとしてブートストラップされた環境で、次の手動の回避策の手順を実行して、内部ロードバランサを動作させます。

組織の管理クラスタで、ゾーン名を取得します。

ZONENAME="$(kubectl get controlplanes -A -o jsonpath="{.items[0].spec.zone}")"
echo $ZONENAME

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

zone1

組織の管理クラスタで、ゾーンサイト ID を取得します。
```
SITEID="$(kubectl -n mz-system get zones $ZONENAME -o jsonpath="{.spec.siteID}")"
echo $SITEID
```
出力は次のようになります。
```
1
```

すべてのクラスタを一覧表示します。

kubectl get clusters -A

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

NAMESPACE                        NAME                     ABM VERSION        DESIRED ABM VERSION   CLUSTER STATE
g-org-1-shared-service-cluster   g-org-1-shared-service   1.30.0-gke.1592    1.30.0-gke.1592       Running
org-1-system-cluster             org-1-system             1.30.0-gke.1592    1.30.0-gke.1592       Running
user-vm-1-cluster                user-vm-1                1.16.11            1.16.11               Running
user-vm-2-cluster                user-vm-2                1.28.700-gke.150   1.28.700-gke.150      Running

クラスタごとに CILIUM_CLUSTERNAME を構築します。

CLUSTER_NAME=CLUSTER_NAME
CILIUM_CLUSTERNAME=$CLUSTERNAME-zone$SITEID
echo $CILIUM_CLUSTERNAME

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

org-1-system-zone1

クラスタごとに、他のパラメータを次のように設定します。org-1-system の次の例:
```
CLUSTER_NAMESPACE=org-1-system-cluster
CLUSTER_VERSION=1.30.0-gke.1592
```

クラスタごとに AddOnConfiguration オブジェクトを作成し、addonconfig.yaml ファイルに保存します。既存のクラスタと、今後作成する新しいクラスタすべてに対して、このファイルを作成します。

このページで次の変数を設定して、次のコードサンプルを更新します。

CLUSTER_NAMESPACE=CLUSTER_NAMESPACE
CLUSTER_VERSION=CLUSTER_VERSION
CILIUM_CLUSTERNAME=CILIUM_CLUSTERNAME

apiVersion: baremetal.cluster.gke.io/v1alpha1
kind: AddOnConfiguration
metadata:
  name: cilium-addon
  namespace: CLUSTER_NAMESPACE
spec:
  anthosBareMetalVersions:
  - CLUSTER_VERSION
  configs:
  - name: cilium-config
    namespace: kube-system
    apiVersion: v1
    kind: ConfigMap
    patchContent: |
      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: cilium-config
        namespace: kube-system
      data:
        cluster-name: CILIUM_CLUSTERNAME

組織の管理クラスタに addonconfig.yaml を適用します。
```
kubectl apply -f addonconfig.yaml
```
システムクラスタ、サービスクラスタ、ユーザークラスタで、クラスタの cilium-config で cluster-name が更新されていることを確認します。更新には時間がかかる場合がありますが、clustermesh-apiserver デプロイを再起動する前にこの手順を行う必要があります。
```
kubectl get configmap -n kube-system cilium-config -o jsonpath="{.data.cluster-name}" && echo
```
システムクラスタ、サービスクラスタ、ユーザークラスタで、clustermesh-apiserver Deployment を再起動します。
```
kubectl rollout restart deployment -n kube-system clustermesh-apiserver
```

正しくない EVPN IP アドレスが生成される

バージョン: 1.13.1、1.13.3、1.13.4、1.13.5、1.13.6、1.13.7

現象: ハードウェアアセット管理システム（HAMS）によって生成されたマルチゾーン（MZ）EVPN 相互接続セッションピアリング IP アドレスが .65 または .66 で終わらない。これは正しくなく、MZ EVPN BGP セッションの確立が停止する。

回避策:

この問題を解決するには、次の手順に沿って操作します。

すべての InterconnectSession リソースを一覧表示します。

kubectl get interconnectsession -n gpc-system --kubeconfig=/root/release/root-admin/root-admin-kubeconfig | grep zoneevpnpeering

interconnectType 値が ZonePeering で、addressFamily が EVPN の生成された EVPN マルチゾーン InterconnectSession リソースを確認します。

apiVersion: system.private.gdc.goog/v1alpha1
kind: InterconnectSession
metadata:
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep
  creationTimestamp: null
  name: interconnect-session-am-aa-blsw01-zoneevpnpeering-3
  namespace: gpc-system
  labels:
    system.private.gdc.goog/ipv4-session-name-1: interconnect-session-am-aa-blsw01-zoneipv4peering-3
spec:
  interconnectLinkRef:
    name: interconnect-am-aa-blsw01-zoneevpnpeering-3
    namespace: gpc-system
  interconnectType: ZonePeering
  peerIP: 192.168.203.67
  md5HashKey: ""
  peerASN: 65402
  addressFamily: EVPN
status: {}

これらのパラメータに一致する InterconnectSession リソースごとに、次の修正を適用します。
1. インターコネクトセッションのカスタムリソース名を確認します。
2. 名前が奇数で終わる場合は、次のステップのコマンドを使用して、ピア IP アドレスの最後の部分を 65 に更新します。
3. 名前が偶数で終わる場合は、次のステップのコマンドを使用して、ピア IP アドレスの最後の部分を 66 に更新します。

誤ったピア IP アドレスで InterconnectSession リソースを変更します。

kubectl edit interconnectsession
interconnect-session-zy-aa-blsw01-zoneevpnpeering-1 -n gpc-system
--kubeconfig=/root/release/root-admin/root-admin-kubeconfig

この修正を、エラーの原因となっているすべての InterconnectSession リソースに適用します。

上部のネットワーキングコントロールプレーンダッシュボードにデータが表示されない

バージョン: 1.13.7

現象: org-1-system クラスタに指標がないため、TestUpperNetworkingMetrics の Prometheus クエリが失敗します。IO 組織管理者の Upper Networking コントロールプレーンダッシュボードのクラスタメッシュパネルにデータが表示されない。この問題は、Cilium とモニタリングシステムの source_cluster ラベルの不一致が原因で発生します。

回避策: UNET コントロールプレーンダッシュボードから source_cluster フィルタを削除して、データを表示します。

ネットワークインストールで表示されるミスリードエラー

バージョン: 1.13.1

事象: ネットワークのインストール中に、ケーブル接続に関する警告メッセージが表示される。次に例を示します。

  W0725 18:01:19.127111   39319 switch_port.go:59] Got error on getting port speed for la-ac-mgmtsw01:Eth1/46<>la-ac-base03:ilo: no speed associated with cable model: 31342 (CAT6 5ft Black)
  W0725 18:01:19.127127   39319 switch_port.go:59] Got error on getting port speed for la-ac-mgmtsw01:Eth1/33<>la-ac-bm21:LOM1: no speed associated with cable model: 03982 (CAT6 4ft Black)

これらのエラーメッセージは無視してかまいません。

allow-all-egress PNP を作成すると、予期しないトラフィックが拒否される

バージョン:

Google Distributed Cloud（GDC）エアギャップのすべてのバージョンが影響を受ける可能性があります。

現象: allow-all-egress プロジェクトネットワークポリシー（PNP）では、プロジェクト内のエンドポイントとクラスタ外の外部エンドポイントへのトラフィックは許可されますが、システムエンドポイントへのトラフィックは許可されません。この問題により、DNS 解決やオブジェクトストレージなど、システムとファーストパーティサービスへのアクセスがブロックされる可能性があります。

allow-all-egress PNP は次のようになります。

apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-all-egress
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
  egress:
  - {}

回避策: allow-all-egress PNP を削除します。デフォルトでは、データ引き出し保護が無効になると、クラスタエンドポイントとシステムエンドポイントの外部にあるプロジェクトエンドポイントと外部エンドポイントへのトラフィックが許可されます。

kubectl delete pnp  [*ALLOW_ALL_EGRESS_PNP_NAME*] -n [*NAMESPACE*]

オブジェクトストレージ

ストレージ組織を削除できない

バージョン: 1.13.1

現象: SVM の削除が完了しない問題により、組織の削除が正常に完了しないことがあります。次のような警告が表示されることがあります。

Warning StorageOrganizationDeletion 49m (x97
over 23h) StorageOrganization Reconcile error for storage org
deletion: cannot delete storage organization resources, pre-checks failed:
subnet claim "poc2/poc2-admin-svm-mgmt-network-subnet" exists,
cannot continue before it is deleted

一部のオブジェクトストレージのアップグレード警告は無視できます

バージョン: 1.13.3

症状: オブジェクトストレージをアップグレードすると、次のような警告が表示されることがあります。

Type     Reason          Age                From                              Message
  ----     ------          ----               ----                              -------
  Warning  ReconcileError  55m (x2 over 55m)  ObjectStorageAdminNodeReconciler  Reconcile error, retrying: error storing the ssh creds: 500 Internal Server Error:ErrorMessage: {"text":"The GDU service is currently busy. Try again later. Contact technical support if the issue persists.","key":"maintenance.gdu.gdu_server_locked

回避策:

各ノードに対応する SSH 認証情報がシークレットに保存されていることを確認します。

管理ノードを確認します。

kubectl get objectstorageadminnodes -o json | jq -r '.items[].metadata.name' | while read -r nodeName; do kubectl get secret -n gpc-system $nodeName-ssh-creds; done

ストレージノードを確認します。

kubectl get objectstoragestoragenodes -o json | jq -r '.items[].metadata.name' | while read -r nodeName; do kubectl get secret -n gpc-system $nodeName-ssh-creds; done

正常な出力は、ストレージノードの場合、次の例のようになります。

NAME                                      TYPE     DATA   AGE
gpcstgecn01-gce-gpcstgesite01-ssh-creds   Opaque   2      3d23h
NAME                                      TYPE     DATA   AGE
gpcstgecn02-gce-gpcstgesite01-ssh-creds   Opaque   2      3d23h
NAME                                      TYPE     DATA   AGE
gpcstgecn03-gce-gpcstgesite01-ssh-creds   Opaque   2      3d23h

シークレットが見つからない場合、エラーは次のようになります。

Error from server (NotFound): secrets "gpcstgeadm02-gce-gpcstgesite01-ssh-creds" not found

コマンドがエラーを返さない場合は、Reconciler によって報告されたエラーを無視しても問題ありません。

`ObjectStorageStorageNodeReconciler` レポート `maintenance.gdu.gdu_server_locked`

バージョン: 1.13.3

症状: objectstoragestoragenode の詳細を表示します。

kubectl describe objectstoragestoragenode zv-aa-objs02

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

Events:
  Type     Reason          Age                    From                                Message
  ----     ------          ----                   ----                                -------
  Warning  ReconcileError  54m (x2 over 54m)      ObjectStorageStorageNodeReconciler  Reconcile error, retrying: error storing the ssh creds: 500 Internal Server Error:ErrorMessage: {"text":"The GDU service is currently busy. Try again later. Contact technical support if the issue persists.","key":"maintenance.gdu.gdu_server_locked"}

回避策: この問題は無視できます。GDU サービスは、リクエストが多すぎると一時的にロックされることがありますが、数分後にロックが解除されます。

Postflight 1.12.x -> 1.13.x アップグレードのオブジェクトストレージチェックが失敗する

バージョン: 1.13.x

現象: ObjectStorageUpgrade CR がエラーで失敗する

Message:               check "ObjectStorageUpgrade" of operable component "OBJ" failed with reason "BackoffLimitExceeded", please check logs in pods: [gpc-system/upgrade-managed-check-objectstorageupgrade] 
Observed Generation:   2
Reason:                PostflightCheckFailed

Pod gpc-system/upgrade-managed-check-objectstorageupgrade がエラーで失敗する

Error: check "ObjectStorageUpgrade" preflight check failed: ObjectStorageSite gce-gpcstgesite01 not ready                                                                      │
  Usage:                                                                                                                                                                         │
    managed [flags]                                                                                                                                                              │
  Flags:                                                                                                                                                                         │
        --component_name string              preflight check name                                                                                                                │
        --current_version string             current version of the Organization                                                                                                 │
    -h, --help                               help for managed                                                                                                                    │
        --organization-upgrade-name string   the name of current OrganizationUpgrade                                                                                             │
        --target_version string              target version of the Organization                                                                                                  │
  F1023 06:18:01.122723       1 main.go:80] check "ObjectStorageUpgrade" preflight check failed: ObjectStorageSite gce-gpcstgesite01 not ready                                   │
  goroutine 1 [running]:

根本原因: ブートストラップ KIND クラスタが非アクティブ化または削除されていない場合、Object Storage オペレーショナルコンポーネントを 1.12.x から 1.13.x にアップグレードできません。アップグレードが成功しても、TLS 証明書の検証エラーにより、Kubernetes RBAC を介した新しいバケットや S3 認証情報の作成などの一般的なオブジェクトストレージサービスが失敗することがあります。これは、KIND クラスタ内の特定のオブジェクトストレージ Pod が、StorageGRID 管理エンドポイントの TLS サーバー証明書を継続的にインストールしようとするためです。この証明書は 1.12.x では有効でしたが、1.13.x では認識されない可能性があります。アップグレード中に、StorageGRID は検証可能な新しい TLS サーバー証明書をインストールしますが、KIND クラスタ Pod はそれを古い無効な証明書に置き換えるため、TLS 証明書エラーが発生します。

回避策: 次の要件を満たしている必要があります。

1.12.x から 1.13.x への Object Storage のアップグレード
ブートストラップクラスタ（KIND クラスタ）がまだ存在する

次の手順を行います。

ブートストラップクラスタ（KIND クラスタ）の ObjectStorageSite リソースに対する表示権限と変更権限を持つ kubeconfig を取得します。
ブートストラップクラスタ（KIND クラスタ）に接続する kubectl にエイリアスを設定します。
```
alias kubectlkind="kubectl --kubeconfig <Full path to the kubeconfig of the bootstrapping cluster>
```
ブートストラップクラスタから ObjectStorageSite カスタムリソースインスタンスを取得します。ObjectStorageSite リソースインスタンスは 1 つにする必要があります。
```
SITENAME=$(kubectlkind get ObjectStorageSite -A -o jsonpath='{.items[0].metadata.name}')
```
オブジェクトストレージの一時停止アノテーションを ObjectStorageSite リソースインスタンスに追加します。
```
kubectlkind annotate ObjectStorageSite "${SITENAME:?}" storagegrid.netapp.storage.private.gdc.goog/paused=true
```
オブジェクトストレージの一時停止アノテーションが ObjectStorageSite インスタンスに追加されていることを確認します。
```
kubectlkind get ObjectStorageSite "${SITENAME:?}" -o jsonpath='{.metadata.annotations}' | jq
```
ルート管理クラスタの ObjectStorageCluster リソースに対する閲覧権限とステータスパッチ権限を持つ kubeconfig を取得します。

ルート管理クラスタに接続する kubectl のエイリアスを設定します。

alias kubectlrootadmin="kubectl --kubeconfig <Full path to the kubeconfig of the root admin >"

ルート管理クラスタに ObjectStorageCluster リソースインスタンスが存在するかどうかを確認します。
```
kubectlrootadmin get ObjectStorageCluster
```
ObjectStorageCluster リソースインスタンスがない場合、回避策は完了です。Object Storage のアップグレード手順を再度実行する必要がある場合があります。
ブートストラップクラスタの ObjectStorageSite リソースのステータスから管理エンドポイント URL を取得します。
```
MGMT_ENDPOINT=$(kubectlkind get ObjectStorageSite -o jsonpath='{.items[0].status.managementAPIEndpointURL}')
```
環境変数 $MGMT_ENDPOINT が設定されているかどうかを検証します。エンドポイントは https:// で始まる必要があります。
```
echo ${MGMT_ENDPOINT:?}
```
残りの手順は、ルート管理クラスタに ObjectStorageCluster リソースインスタンスが 1 つだけ存在する場合にのみ実行します。それ以外の場合は、Object Storage のアップグレード手順をもう一度実行します。
```
kubectlrootadmin patch ObjectStorageCluster <the name of ObjectStorageCluster> --type=merge --subresource status --patch "status: {managementAPIEndpointURL: '${MGMT_ENDPOINT:?}'}"
```

gpc-system/obj-infra-cluster-cm Pod を再起動します。

kubectlrootadmin rollout restart deployment -n gpc-system obj-infra-cluster-cm-backend-controller

管理エンドポイントが ObjectStorageCluster リソースのステータスに追加されているかどうかを確認します。
```
kubectlrootadmin get ObjectStorageCluster -o jsonpath='{.items[0].status}' | jq
```
ポストフライトチェック Kubernetes Job gpc-system/upgrade-managed-check-objectstorageupgrade-<random suffix> を削除して、ポストフライトチェックを再起動します。ジョブはまもなく再作成されます。

データネットワークでノードにアクセスできない

これは、anetd Pod がクラッシュループに陥った場合に発生するまれな問題です。

ノードの接続に不可欠なカーネルリソースが破損した状態になることがあります。

このガイドでは、この問題の症状と、問題を解決するために実行できる手順について説明します。

バージョン:

Google Distributed Cloud（GDC）エアギャップのすべてのバージョンが影響を受ける可能性があります。

症状:

この問題が発生すると、次のような症状が現れることがあります。

ノードが NotReady 状態のままになる
ノードの説明に kubelet:kubelet was found unhealthy; repair flag : true というメッセージが表示される
データネットワークではノードへの SSH アクセスはできません

回避策:

次の手順に沿って、異常なノードを修復します。

影響を受けるノードの管理 IP アドレスを取得します。

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get -n gpc-system servers/NODE_NAME -ojsonpath='{.spec.managementNetwork.ips[0]}'

影響を受けるノードへの SSH アクセスを取得します。
ノードの管理 IP アドレスを使用して、SSH を使用してノードに接続します。
ノードで次のコマンドを実行し、SSH 接続を閉じます。
```
tc filter del dev bond0 egress
```

影響を受けるノードを含むクラスタの anetd DaemonSet を再起動します。

kubectl --kubeconfig AFFECTED_CLUSTER_KUBECONFIG rollout restart ds/anetd -n kube-system

オペレーティングシステム

Pod が `init` 状態で停止する

バージョン: 1.13.1

症状: ノードは準備完了を報告しますが、ノードへの SSH アクセスが遅く、top -n 1 に 100 を超えるゾンビプロセスが表示されます。

回避策:

OS-P0001 に沿ってサーバーをドレインします。ドレインには 20 分以上かかることがあります。1 時間経過しても放電が完了しない場合は、次のステップに進みます。
サーバーへの SSH 接続を確立し、次のコマンドを発行してサーバーを再起動します。
```
systemctl reboot
```
サーバーを完全に復元するには、2 回目の再起動が必要になる場合があります。
SSH アクセスの速度が低下しておらず、ゾンビプロセスの数が大幅に減少していること（できれば 30 未満）を確認します。
サーバーで maintenance を false に設定して、サーバーのドレインを解除します。

`bm-system-machine-preflight-check` ベアメタルまたは VM ノードの Ansible ジョブが失敗する

バージョン: 1.13.1

症状: 再起動後にカーネルモジュール nf_tables が読み込まれず、クラスタ Ansible ジョブが Either ip_tables or nf_tables kernel module must be loaded エラーで失敗します。この問題は、ベアメタルノードまたは VM ノードが完全にプロビジョニングされる前に再起動された場合に発生します。Ansible ジョブで次のようなエラーが発生する場合があります。

fatal: [172.20.128.23]: FAILED! => {"changed": false, "msg": "following are the error messages for each failed preflight check {'check_netw
orking_kernel_module_pass': 'Either ip_tables or nf_tables kernel module must be loaded. Use the command \"modprobe <ip_tables OR nf_tables
>\" to load the module.'}"}

回避策:

ノードへの SSH 接続を確立し、次のコマンドを実行します。

modprobe nf_tables

デバイスに空き容量がない VM

バージョン: 1.13.1、1.13.3、1.13.4、1.13.5

症状: ログディレクトリ /var/log がいっぱいになると、Node が NotReady ステータスで停止し、エラー no space left on device により Pod の起動に失敗することがあります。これを確認するには、ノードで次のコマンドを実行し、使用率が 100% 前後かどうかを確認します。

df -h /var/log
Filesystem                     Size  Used Avail Use% Mounted on
/dev/mapper/rocky-rl--var_log   15G   15G   20K 100% /var/log

回避策:

問題が発生したノードにログインし、/var/log/messages の古いログアーカイブをクリーンアップします。
```
find /var/log -name "messages*" -mtime +4 -delete
```
また、この問題の発生を防ぐために、以下の回避策を継続して適用することをおすすめします。回避策は、AnsiblePlaybook を作成し、ターゲット OS（BM+VM マシン）を安全に構成するカスタム OSPolicy CR を介して変更を適用することです。詳しくは、プロセス OS-P0005 を参照してください。

次の環境変数を設定します。

export KUBECONFIG=<the path to the kubeconfig file>

回避策の Ansible プレイブックを作成します。

kubectl --kubeconfig=${KUBECONFIG:?must be set} apply -f - <<EOF
apiVersion: system.private.gdc.goog/v1alpha1
kind: AnsiblePlaybook
metadata:
  name: update-logrotate
  namespace: gpc-system
spec:
  playbook: |
    - name: Set the default context for the /etc/kubernetes path to etc_t
      hosts: all
      gather_facts: no
      tasks:
        - name: Change log rotation for /var/log/messages
          block:
            - name: Check if /etc/logrotate.d/syslog exists
              check_mode: false
              ansible.builtin.stat:
                path: '/etc/logrotate.d/syslog'
              register: syslog_exists
            - name: Comment out /var/log/messages lines in syslog
              ansible.builtin.replace:
                path: '/etc/logrotate.d/syslog'
                regexp: '^/var/log/messages'
                replace: '# /var/log/messages'
              when: syslog_exists.stat.exists
            - name: Change logrotate config for /var/log/messages
              ansible.builtin.blockinfile:
                path: '/etc/logrotate.d/syslog'
                block: |
                  /var/log/messages
                  {
                      daily
                      rotate 4
                      missingok
                      notifempty
                      sharedscripts
                      postrotate
                          /usr/bin/systemctl kill -s HUP rsyslog.service >/dev/null 2>&1 || true
                      endscript
                  }
              when: syslog_exists.stat.exists
EOF

変更を適用する必要があるターゲットインベントリを特定します。ターゲットは個々の InventoryMachine または NodePool になります。プロセス OS-P0005（2. 詳細については、ランタイム構成のターゲットインベントリを特定する）をご覧ください。

次の OSPolicy の例では、spec.inventory に 2 つのターゲット広告枠が含まれていますが、必要に応じて広告枠を追加できます。

kubectl --kubeconfig=${KUBECONFIG:?must be set} apply -f - <<EOF
apiVersion: system.private.gdc.goog/v1alpha1
kind: OSPolicy
metadata:
  name: manual-update-logrotate
  namespace: gpc-system
spec:
  inventory:
  - apiVersion: baremetal.cluster.gke.io/v1
    kind: NodePool
    name: control-plane-node-pool
    namespace: org-1-system-cluster
  - apiVersion: baremetal.cluster.gke.io/v1
    kind: NodePool
    name: control-plane-node-pool
    namespace: user-vm-1-cluster
  policy:
    installPlaybook:
      name: update-logrotate
EOF

検証

ポリシーの実行ステータスを追跡するには、プロセス OS-P0005（検証）を参照してください。

Pod が `ContainerCreating` 状態で停止する

バージョン: 1.13.3、1.13.5、1.13.6

症状: ノードは正常と表示されるが、ContainerCreating 状態の Pod が多数あり、サーバーへの SSH 接続を確立できない。

回避策: サーバーの電源を入れ直し、再起動後にノードへの SSH 接続を確立できることを確認します。

プロビジョニングされたノードに SSH で接続できない

バージョン: 1.13.5

症状: ノードはプロビジョニングされますが、管理 IP とデータ IP の両方で SSH がタイムアウトします。

回避策: iLO を使用してノードを再起動します。起動したら、ssh で接続し、systemctl stop clamonacc; systemctl disable clamonacc で clamonacc を無効にします。

Operations Suite Infrastructure（OI）

Hardware 3.0 では SSA は不要

Hardware 3.0 では、RAID アダプタの構成が異なります。ハードウェア 3.0 OIC サーバーは自己暗号化ドライブを使用するため、Smart Storage Administration（SSA）を起動する必要がなくなりました。サーバーごとにディスク識別子を特定するには、追加の手順が必要です。OI サーバーのブートストラップをご覧ください。

境界セキュリティ

組織のブートストラップ中に組織システムクラスタが停止する

バージョン: 1.13.1

症状: 組織のブートストラップ中に、組織のシステムクラスタがスタックする可能性があります。edr-sidecar-injector Pod が保留状態になっています。これらの Pod を削除しようとすると、次のようなエラーメッセージが表示されることがあります。

Delete failed with `Internal error occurred: failed calling webhook "validation.gatekeeper.sh": failed to call webhook: Post "https://gatekeeper-webhook-service.opa-system.svc:443/v1/"

同時に、他の保留中の Pod に次のようなエラーメッセージが表示されることがあります。

Error creating: Internal error occurred: failed calling webhook "edr-sidecar-injector.gpc-system.internal": failed to call webhook: Post "https://edr-sidecar-injector.gpc-system.svc:443/mutate?timeout=10s": dial tcp 172.20.3.222:443: connect: connection refused

システムがロックを解除するには、手動での介入が必要です。

回避策:

システムクラスタで MutatingWebhookConfiguration CR edr-sidecar-injector-webhook-cfg を複製します。
システムクラスタで ValidatingWebhookConfiguration CR gatekeeper-validating-webhook-configuration を複製します。
システムクラスタから edr-sidecar-injector-webhook-cfg CR と gatekeeper-validating-webhook-configuration CR の両方を削除します。
edr-sidecar-injector Pod が復元し、gatekeeper-controller-manager が復元するまで待ちます。
kubectl apply コマンドを使用して、Webhook CR を復元します。

PANW ファイアウォールのアドレスグループが CIDR クレームの変更で更新されない

バージョン: 1.13.1

症状: ブートストラップ中に、OCIT cidr-claim は正しい値で更新されますが、ファイアウォール AddressGroups は更新されません。AddressGroups のペア（具体的には vsys1-root-ocit-network-cidr-group と ocvsys1-root-ocit-network-cidr-group）は、OIR で実際に使用されているものと重複しないネットワークブロックを使用します。OIR が GDC ゾーンレコードを解決できず、クエリが応答なしでタイムアウトします。

回避策: cidr-claim の変更後、ルート管理者クラスタの fw-system Namespace で fw-core-backend-controller Deployment を再起動して、AddressGroup が最新の cidr-claim で更新されていることを確認します。

物理サーバー

HPE サーバーの POST の問題によりサーバーのブートストラップが失敗する

バージョン: 1.13.1

現象: サーバーが POST 起動プロセスを完了できない場合、サーバーのブートストラップが失敗します。ILO にログインしてサーバーのコンソールを確認すると、次のエラーが表示されます。

Symptom: An Invalid Opcode Exception has occurred indicating
that the processor tried to execute an invalid, undefined opcode,
or an instruction with invalid prefixes.

Causes: This issue is typically a software or firmware issue and
not indicative of a hardware problem

Causes: This issue is typically a software or firmware issue and
not indicative of a hardware problem.

ACTION : Reboot the server.

回避策:

iLO で [電源ボタン] をクリックし、Cold Boot を選択します。

サーバーがプロビジョニング状態のままになる

バージョン: 1.13.1、1.13.3、1.13.5

症状: サーバーのブートストラップ中に、サーバーがプロビジョニング状態のままになる。サーバーの状態を確認します。

k get servers -A | grep -v availabl

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

NAMESPACE    NAME         AGE   RACK    MACHINE-CLASS               MANAGEMENT-IP   DATA-IP    DATA-IP   BMC-IP           CLUSTER   NODEPOOL   STATE          PROVISION-READY
gpc-system   ag-aa-bm01   21h   ag-aa   o1-highmem1-40-gdc-metal    192.0.2.0       198.51.100.0         203.0.113.0                         provisioning
gpc-system   ag-ab-bm01   21h   ag-ab   o1-highmem1-40-gdc-metal    192.0.2.0       198.51.100.1         203.0.113.0                         provisioned    true
gpc-system   ag-ac-bm01   21h   ag-ac   o1-highmem1-40-gdc-metal    192.0.2.0       198.51.100.2         203.0.113.0                         provisioning

回避策:

KIND クラスタからダウンロードした構成を使用して、dhcp を手動で開始します。この例では、/tmp/dhcp.conf は KIND クラスタの DHCP 構成です。
```
docker run  -d -it --network host --name dnsmasq -v /tmp/dhcp.conf:/etc/dnsmasq.conf --cap-add=NET_ADMIN --restart always 198.51.100.255/gpc-system-container-images/private-cloud-staging/dnsmasq:VERSION
```
VERSION は、ルートクラスタと組織管理クラスタのファイルコンポーネントの手動アップグレードのアップグレード手順の説明に沿って、リリースバージョン（例: 1.13.1-gdch.525）に置き換えます。
サーバーの BIOS 構成を確認し、データプレーン NIC（Slot{i}Nic{i} というパターンで命名）で NetworkBoot が有効になっていないことを確認します。
API 呼び出しで BIOS を確認します。
```
curl -kv https://{bmcIP}/redfish/v1/Systems/1/bios -u $bmcUser:$bmcPassword
```
ここで、$bmcUser と $bmcPassword は ILO のパスワードです。これは、bmc-credentials-<server-name> という名前のシークレットの cellcfg ファイルまたはディレクトリにあります（例: bmc-credentials-ai-aa-bm01）。このコマンドの出力に Slot1Nic1: Disabled が表示されていることを確認します。
これらの Slot{i}Nic{i} のいずれかに NetworkBoot が含まれている場合は、BIOS 設定 API を使用して無効にします。
```
curl -kv https://{bmcIP}/redfish/v1/Systems/1/bios/settings -u $bmcUser:$bmcPassword -X PATCH -d '{"Attributes": {"Slot{i}Nic{i}":"Disabled"}}' -H 'content-type: application/json'
```
Slot{i}Nic{i} は、ペイロードで問題が発生しているスロットの名前に置き換えます。
サーバーを再起動します。

DL380a サーバーのプロビジョニングに失敗する

バージョン: 1.13.3、1.13.4、1.13.5

現象: HPE DL380a モデルの暗号化ジョブでサーバーのプロビジョニングが失敗します。サーバーブートストラップ中にサーバー CR の状態が available のままになる:

# server name
export SERVER_NAME=

kubectl --kubeconfig "${KUBECONFIG:?must be set}" get servers ${SERVER_NAME} -n gpc-system

回避策:

IAM-R0004 に沿って、root-admin-cluster の KUBECONFIG を生成します。
PLATAUTH-G0001 に沿って、CLUSTER_NS=root の SSH 認証鍵 root-id_rsa を生成します。

サーバーカスタムリソースにアノテーション server.system.private.gdc.goog/paused を追加して、サーバーを一時停止します。

kubectl --kubeconfig "${KUBECONFIG:?must be set}" annotate server ${SERVER_NAME:?} -n gpc-system --overwrite server.system.private.gdc.goog/paused=''

管理 IP からサーバーにログインします。

export MGMT_IP=$(kubectl --kubeconfig "${KUBECONFIG:?must be set}" get server ${SERVER_NAME:?} -n gpc-system -o=jsonpath='{.spec.managementNetwork.ips[0]}')

ssh $MGMT_IP -i ~/.ssh/root-id_rsa

暗号化を手動で有効にする:

/opt/MegaRAID/storcli/storcli64 /call/eall/sall secureerase force

/opt/MegaRAID/storcli/storcli64 /c0 delete securitykey

/opt/MegaRAID/storcli/storcli64 /c0 set securitykey useekms j

コマンドの出力は次のようになります。

root@ubuntu:~# /opt/MegaRAID/storcli/storcli64 /call/eall/sall secureerase force
CLI Version = 007.2417.0000.0000 Apr 21, 2023
Operating system = Linux 5.4.0-1072-fips
Controller = 0
Status = Success
Description = Drive Secure Erase Succeeded.

root@ubuntu:~# /opt/MegaRAID/storcli/storcli64 /c0 delete securitykey
CLI Version = 007.2417.0000.0000 Apr 21, 2023
Operating system = Linux 5.4.0-1072-fips
Controller = 0
Status = Success
Description = None

Controller Properties :
=====================

------------------------
Ctrl Method     Result
------------------------
  0 delete Key Success
------------------------

root@ubuntu:~# /opt/MegaRAID/storcli/storcli64 /c0 set securitykey useekms j
{
"Controllers":[
{
        "Command Status" : {
                "CLI Version" : "007.2417.0000.0000 Apr 21, 2023",
                "Operating system" : "Linux 5.4.0-1072-fips",
                "Controller" : 0,
                "Status" : "Success",
                "Description" : "None"
        },
        "Response Data" : {
                "Controller Properties" : [
                        {
                                "Ctrl" : 0,
                                "Method" : "Set Security using EKMS",
                                "Result" : "Please reboot the system for the changes to take effect"
                        }
                ]
        }
}
]
}

最後のコマンドが成功しなかった場合や、「Invalid BIOS EKM status」などのエラーが表示された場合は、サーバーと iLO を再起動してから、この手順を再度実行してください。

root@ubuntu:~# /opt/MegaRAID/storcli/storcli64 /c0 set securitykey useekms j
{
"Controllers":[
{
        "Command Status" : {
                "CLI Version" : "007.2417.0000.0000 Apr 21, 2023",
                "Operating system" : "Linux 5.4.0-1072-fips",
                "Controller" : 0,
                "Status" : "Failure",
                "Description" : "None",
                "Detailed Status" : [
                        {
                                "Ctrl" : 0,
                                "Method" : "Set Security using EKMS",
                                "Result" : "-",
                                "ErrMsg" : "Invalid BIOS EKM status",
                                "ErrCd" : 255
                        }
                ]
        }
}
]
}

最後のコマンドが成功した場合は、指示に従ってサーバーを再起動します。

論理ドライブを手動で作成します。

サーバーの再起動が完了したら、管理 IP からサーバーに再度ログインし、使用可能なすべてのドライブを一覧表示します。

ssh $MGMT_IP -i ~/.ssh/root-id_rsa

/opt/MegaRAID/storcli/storcli64 /c0 show j

最後のコマンドの出力は次のようになります。

{
  "Controllers":[
  {
    "Command Status" : {
      "CLI Version" : "007.2417.0000.0000 Apr 21, 2023",
      "Operating system" : "Linux 5.4.0-1072-fips",
      "Controller" : 0,
      "Status" : "Success",
      "Description" : "None"
    },
    "Response Data" : {
      "Product Name" : "HPE MR416i-o Gen11",
      "Serial Number" : "******",
      "PCI Slot Number" : 17,
      "SAS Address" : "******",
      "PCI Address" : "00:12:00:00",
      "System Time" : "09/12/2024 23:32:48",
      "Mfg. Date" : "09/15/23",
      "Controller Time" : "09/12/2024 23:32:47",
      "FW Package Build" : "52.26.3-5379",
      "BIOS Version" : "7.26.00.0_0x071A0000",
      "FW Version" : "5.260.03-3985",
      "Driver Name" : "megaraid_sas",
      "Driver Version" : "07.713.01.00-rc1",
      "Current Personality" : "RAID-Mode ",
      "Vendor Id" : 4096,
      "Device Id" : 4322,
      "SubVendor Id" : 5520,
      "SubDevice Id" : 808,
      "Host Interface" : "PCI-E",
      "Device Interface" : "SAS-12G",
      "Bus Number" : 18,
      "Device Number" : 0,
      "Function Number" : 0,
      "Domain ID" : 0,
      "Security Protocol" : "SPDM-1.0.0",
      "Physical Drives" : 8,
      "Drive LIST" : [
        {
          "EID:Slt" : "252:1",
          "DID" : 0,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "1.60 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "MO001600PXVRU   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:2",
          "DID" : 1,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "1.60 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "MO001600PXVRU   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:3",
          "DID" : 2,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:4",
          "DID" : 3,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:5",
          "DID" : 4,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:6",
          "DID" : 5,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:7",
          "DID" : 6,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        },
        {
          "EID:Slt" : "252:8",
          "DID" : 7,
          "State" : "UGood",
          "DG" : "-",
          "Size" : "7.68 TB",
          "Intf" : "SAS",
          "Med" : "SSD",
          "SED" : "Y",
          "PI" : "N",
          "SeSz" : "512B",
          "Model" : "VO007680PXVRT   ",
          "Sp" : "U",
          "Type" : "-"
        }
      ],
      "Enclosures" : 1,
      "Enclosure LIST" : [
        {
          "EID" : 252,
          "State" : "OK",
          "Slots" : 8,
          "PD" : 8,
          "PS" : 0,
          "Fans" : 0,
          "TSs" : 0,
          "Alms" : 0,
          "SIM" : 0,
          "Port#" : "2I"
        }
      ]
    }
  }
  ]
}

この場合、Size が 1.60 TB に等しい 2 つの EID:Slt ID を保存する必要があります。

252:1,252:2

次に、EID:Slt ID を使用して論理ドライブを作成します。

/opt/MegaRAID/storcli/storcli64 /c0 add vd type=raid1 drives=252:1,252:2 SED

最後のコマンドの出力は次のようになります。

/opt/MegaRAID/storcli/storcli64 /c0 add vd type=raid1 drives=252:1,252:2 SED

CLI Version = 007.2417.0000.0000 Apr 21, 2023
Operating system = Linux 5.4.0-1072-fips
Controller = 0
Status = Success
Description = Add LD Succeeded.

Server CR でディスクの暗号化ステータスをモックします。

Server CR のステータスを編集します。

kubectl edit-status --kubeconfig "${KUBECONFIG:?must be set}" server ${SERVER_NAME:?} -n gpc-system

DiskEncryptionEnabled ステータスを true に追加または変更します。

  - lastTransitionTime: "<time>"
    message: ""
    observedGeneration: 1
    reason: DiskEncryptionJobSucceeded
    status: "True"
    type: DiskEncryptionEnabled

サーバーの暗号化ジョブがある場合は削除します。

kubectl --kubeconfig "${KUBECONFIG:?must be set}" delete job server-encrypt-and-create-logical-drive-${SERVER_NAME:?} -n gpc-system

プロビジョニングが再開されるように、サーバーの一時停止を解除します。

kubectl --kubeconfig "${KUBECONFIG:?must be set}" annotate server ${SERVER_NAME:?} -n gpc-system --overwrite server.system.private.gdc.goog/paused-

ライセンスがないと安全な消去が失敗する

バージョン: 1.13.5

現象: サーバーのインストール中にサーバーが停止すると、サーバー CR のステータスが次のようになります。

- lastTransitionTime: "2024-09-10T20:28:33Z"
   message: 'unable to trigger secure erase: unable to complete secure erase
     for server "zx-ad-bm07": failed to post payload to /redfish/v1/Systems/1/Actions/Oem/Hpe/HpeComputerSystemExt.SecureSystemErase:
     400: {"error":{"code":"iLO.0.10.ExtendedInfo","message":"See @Message.ExtendedInfo
     for more information.","@Message.ExtendedInfo":[{"MessageId":"iLO.2.27.LicenseKeyRequired"}]}}'
   reason: Succeeded
   status: "False"
   type: BMCConfigPreinstallSecureEraseTriggered

回避策: SERV-R0014 ランブックの手順に沿って操作します。

プラットフォームのセキュリティ

BYO SubCA Reconciler が証明書に一致する公開鍵があるかどうかを検証しない

バージョン: 1.13.1

症状: PKI BYO SubCA モードで、以前に署名された証明書が SubCA にアップロードされている間に新しい証明書署名リクエスト（CSR）が生成されると、Reconciler は新しい CSR が古い署名済み証明書と一致するかどうかを確認せず、cert-manager CertificateRequest カスタムリソース（CR）を Ready としてマークします。これは、SubCA 証明書の更新または手動ローテーション中に発生します。cert-manager コントローラが Certificate CR ステータスの更新を試行し、次のエラーメッセージがトリガーされます。

The certificate request has failed to complete and will be retried: Error signing certificate: error creating x509 │
│  certificate: x509: provided PrivateKey doesn't match parent's PublicKey

回避策:

手順に沿って、新しい CSR の新しい署名済み BYO SubCA 証明書をアップロードします。

cert-manager の問題により、ACME を使用した PKI BYO の発行が失敗する

バージョン: 1.13.1

症状: 自動証明書管理環境（ACME）で BYO 証明書を初めて発行または更新するときに障害が発生します。証明書のステータスを確認するコマンドを実行すると、証明書が not ready であることがわかります。

kubectl -n istio-system get certificate.pki.security.gdc.goog/default-wildcard-cert

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

status:
  conditions:
  - lastTransitionTime: "2024-07-23T17:27:02Z"
    message: 'reconciling Certificate status failed: cert-manager Certificate CR "default-wildcard-cert-pki-ct"/"pki-system" is not ready'
    observedGeneration: 1
    reason: ReconcileBackoff
    status: "False"
    type: Ready

回避策:

組織の管理クラスタで cert-manager Deployment を再起動します。

export KUBECONFIG=ORG_ADMIN_KUBECONFIG

kubectl rollout restart deployment/cert-manager -n cert-manager

リソース管理者

GDC コンソールでプロジェクトのステータスを確認できない

バージョン: 1.13.1 以降

現象: GDC コンソールにプロジェクトのステータスが表示されない。Ready 状態でないプロジェクトでは、新しいリソースをサポートしたり、既存のリソースに対する新しい変更を処理したりすることはできません。プロジェクトのステータスを確認できないため、プロジェクトのリソースを管理できるタイミングが不明になり、新しいプロジェクトアクションを試行するとエラーが発生します。

回避策: RM-R0100 ランブックを参照して、kubectl CLI を使用してプロジェクトのステータスを出力します。

アップグレード

`bm-system` と他のジョブが停止している

バージョン: 1.13.1

症状: bm-system と、ansible playbook を実行している他のジョブが gathering facts で停止します。

回避策: 停止しているノードの名前を入力し、multipath -ll | grep failed と multipath -ll | grep # を実行します。結果が空でない場合は、ランブック FILE R0020 と FILE R0021 に沿って対応します。

到達不能な管理 IP

バージョン: 1.13.1、1.13.3、1.13.4、1.13.5

症状: アップグレード中に、サーバーの管理 IP にアクセスできません。特に、スイッチの後に発生します。

Rocky Linux では、静的ルートを追加する前に、静的ルートに到達するために使用される宛先 IP に到達できる必要があります。OS のアップグレード後にスイッチが再起動している場合、その管理 IP に一時的にアクセスできなくなる可能性があります。

回避策: データ IP アドレスを使用してサーバーへの SSH 接続を確立し、ネットワーキングサービスを再起動して、欠落している静的ルートを再作成します。

systemctl restart NetworkManager.service

`storagecluster` のバージョン番号が表示されない

バージョン: 1.13.3

現象: アップグレード後、StorageCluster CR の StorageVersion ステータスフィールドに値が表示されません。

バージョンを確認します。

kubectl --kubeconfig <var>ROOT_ADMIN_KUBECONFIG</var> get StorageCluster -n gpc-system

バージョンフィールドが空の場合は、回避策の手順に沿って対応します。

回避策: file-storage-backend-controller デプロイを再起動します。

kubectl --kubeconfig  <var>ROOT_ADMIN_KUBECONFIG</var> rollout restart deployment -n file-system file-storage-backend-controller

ベアメタルサーバーがプロビジョニング状態で停止する

バージョン: 1.13.1

症状:

組織の作成時に、ベアメタルサーバーが「プロビジョニング」状態で長時間停止します。

回避策:

サーバーの BIOS 構成が変更され、サーバーが Pxebooting に誤ったネットワークカードを使用している可能性があります。

データプレーン NIC のネットワークブートを無効にする手順は次のとおりです。

必要なアクセス権:
- 停止しているサーバーの bmc 管理者の認証情報にアクセスする必要があります。
- IAM-R0005 に沿って、ルート管理クラスタで ClusterRole hardware-admin ロールを 1 時間取得します。
- IAM-R0004 に沿って、root-admin クラスタの KUBECONFIG を生成します。

停止したサーバーの名前を設定します。
```
export SERVER_NAME=
```

サーバーの BMC の IP と認証情報を設定します。

export ip=$(kubectl --kubeconfig "${KUBECONFIG:?must be set}" get server ${SERVER_NAME:?} -n gpc-system -ojsonpath='{.spec.bmc.ip}')
export BMC_CREDENTIALS_SECRET=$(kubectl --kubeconfig "${KUBECONFIG:?must be set}" get server ${SERVER_NAME:?} -n gpc-system -ojsonpath='{.spec.bmc.credentialsRef.name}')
export user=$(kubectl --kubeconfig "${KUBECONFIG:?must be set}" get secret ${BMC_CREDENTIALS_SECRET:?} -n gpc-system -ojsonpath='{.data.username}' | base64 -d)
export pass=$(kubectl --kubeconfig "${KUBECONFIG:?must be set}" get secret ${BMC_CREDENTIALS_SECRET:?} -n gpc-system -ojsonpath='{.data.password}' | base64 -d)

サーバー上のデータプレーンネットワークカードの PCIe スロットを特定します。
```
kubectl --kubeconfig "${KUBECONFIG:?must be set}" get server ${SERVER_NAME} -n gpc-system -o jsonpath={.spec.serverHardware.portBond.nicPortNames}
```
たとえば、次の出力は、ネットワークカードがスロット 3 にインストールされていることを示しています。
```
["s3p1","s3p2"]
```
PCIEslot 変数を設定します。
```
export DATA_NIC_SLOT=3
```
ネットワークブートが無効になっていないことを確認します。
```
curl -ks -u $user:$pass https://$ip/redfish/v1/systems/1/bios/settings  | jq .Attributes | grep "Slot${DATA_NIC_SLOT}NicBoot1"
```
結果が「NetworkBoot」の場合は、明示的に無効にする必要があります。
BMC を使用して、データプレーンネットワークカードのネットワークブート機能を無効にします。

次のコマンドの「Slot3」を実際のスロット番号に置き換えます。
```
curl -k -u "$user":"$pass" -H "Content-Type: application/json" https://$ip/redfish/v1/systems/1/bios/settings/ -X PUT --data '{"Attributes":{"Slot3NicBoot1":"Disabled"}}' | jq
```
マシンを再起動します。
```
curl -k -u "$user":"$pass" -H "Content-Type: application/json" https://$ip/redfish/v1/Systems/1/Actions/ComputerSystem.Reset/ -X POST -d '{"ResetType": "ForceRestart"}' | jq
```
サーバーが復旧するまでに 10 ～ 15 分かかり、プロビジョニングプロセスが自動的に再開されます。

オブジェクトストレージのアップグレードで、ポストフライトチェックまたはプリフライトチェック中にエラーが表示される

バージョン: 1.13.1

症状: プリフライトチェックまたはポストフライトチェックがエラーで失敗します。ログを調べる

kubectl logs -n gpc-system upgrade-managed-check-objectstorageupgrade-87698-rrjhrW0410

次のようなエラーメッセージが表示されます。

 03:42:05.701163       1 upgrade_check.go:276] 1 error occurred:
      * Group "/rbac.sysstd.role.vm-system.wtwf7txfmbhvujhpxrfampnrkdwqsvzro6i7rmo5tsfst4wbxldq" not ready for RBAC resource {Role vm-system g-vm-image-bucket-reader    }

   Error: check "ObjectStorageUpgrade" preflight check failed: 1 error occurred:
      * Bucket "gpc-system/range-read-internal" not ready

  F0410 03:42:05.701901       1 main.go:80] check "ObjectStorageUpgrade" preflight check failed: 1 error occurred:
      * Bucket "gpc-system/range-read-internal" not ready

回避策:

ポストフライトチェック中にエラーが発生し、他のすべてのチェックがエラーなしで完了した場合は、ポストフライトチェックをスキップします。アップグレードが再開されたら、ルート管理者 kubeconfig を使用してプリフライトチェックもスキップする必要があります。

kubectl delete organizationupgrade -n gpc-system ORG_NAME && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-postflight-check=ok && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-preflight-check=ok

たとえば、エラーが org-1 で発生した場合、コマンドは次のようになります。

kubectl delete organizationupgrade -n gpc-system org-1 && kubectl annotate -n gpc-system organization org-1 upgrade.private.gdc.goog/skip-postflight-check=ok && kubectl annotate -n gpc-system organization org-1 upgrade.private.gdc.goog/skip-preflight-check=ok

プリフライトチェック中にエラーが発生し、他のすべてのプリフライトチェックがエラーなく完了した場合は、プリフライトチェックをスキップします。

kubectl delete organizationupgrade -n gpc-system ORG_NAME && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-preflight-check=ok

たとえば、エラーが org-1 で発生した場合、コマンドは次のようになります。

kubectl delete organizationupgrade -n gpc-system org-1 && kubectl annotate -n gpc-system organization org-1 upgrade.private.gdc.goog/skip-preflight-check=ok

この回避策が適用されない場合は、複数回適用する必要がある場合があります。

Helm アップグレードのロールバック

バージョン: 1.13.3

症状: Helm のアップグレードの問題により、一連のロールバックが発生し、Certificate と ServiceEntry が見つかりません。次のようなメッセージが表示されることがあります。

REVISION        UPDATED                         STATUS          CHART                                   APP VERSION             DESCRIPTION
91              Thu Jul 18 13:26:42 2024        deployed        iam-ais-backend-1.12.4-gdch.54          1.12.4-gdch.54          Upgrade complete
9138            Fri Jul 19 22:21:56 2024        superseded      iam-ais-backend-v1.13.0-iam-9b810cbc70  v1.13.0-iam-9b810cbc70  Rollback "iam-ais-backend" failed: no Certificate with the name "ais-metrics" found
9139            Fri Jul 19 22:22:04 2024        superseded      iam-ais-backend-1.12.4-gdch.54          1.12.4-gdch.54          Rollback "iam-ais-backend" failed: no ServiceEntry with the name "ais-envoy-grpc" found
9140            Fri Jul 19 22:22:16 2024        superseded      iam-ais-backend-v1.13.0-iam-9b810cbc70  v1.13.0-iam-9b810cbc70  Rollback "iam-ais-backend" failed: no Certificate with the name "ais-metrics" found
9141            Fri Jul 19 22:22:30 2024        superseded      iam-ais-backend-1.12.4-gdch.54          1.12.4-gdch.54          Rollback "iam-ais-backend" failed: no ServiceEntry with the name "ais-envoy-grpc" found
9142            Fri Jul 19 22:22:35 2024        superseded      iam-ais-backend-v1.13.0-iam-9b810cbc70  v1.13.0-iam-9b810cbc70  Rollback "iam-ais-backend" failed: no Certificate with the name "ais-metrics" found
9143            Fri Jul 19 22:22:42 2024        superseded      iam-ais-backend-1.12.4-gdch.54          1.12.4-gdch.54          Rollback "iam-ais-backend" failed: no ServiceEntry with the name "ais-envoy-grpc" found
9144            Fri Jul 19 22:22:48 2024        superseded      iam-ais-backend-v1.13.0-iam-9b810cbc70  v1.13.0-iam-9b810cbc70  Rollback "iam-ais-backend" failed: no Certificate with the name "ais-metrics" found
9145            Fri Jul 19 22:22:56 2024        superseded      iam-ais-backend-1.12.4-gdch.54          1.12.4-gdch.54          Rollback "iam-ais-backend" failed: no ServiceEntry with the name "ais-envoy-grpc" found
9146            Fri Jul 19 22:23:04 2024        failed          iam-ais-backend-v1.13.0-iam-9b810cbc70  v1.13.0-iam-9b810cbc70  Rollback "iam-ais-backend" failed: no Certificate with the name "ais-metrics" found

回避策: OCLCM-R0122 ランブックの手順に沿って対応します。

dhcp-tftp-core-server Pod がドレインされないため、ノードのアップグレードまたは ABM が停止する

バージョン: 1.13.3、1.14.4、1.14.5

症状: ノードのアップグレードが停止する可能性があります。ベアメタルマシンのステータスで、dhcp-tftp-core-server Pod がドレインされていません。次のようなメッセージが表示されることがあります。

bareMetalMachineDrainingStatus:
    currentDrainingStage: SystemCriticalPriorityClass
    podsYetToDrain:
    - name: dhcp-tftp-core-server-7ffcfcbb97-6wlg7
      namespace: dhcp-system
      resourceVersion: "5005530"
      uid: f77826ea-1d57-46ff-a699-f42faa36c1d2

回避策: dhcp-tftp-core-server-* Pod を強制的に削除して続行します。コマンドは次のようになります。

kubectl delete pod dhcp-tftp-core-server-7ffcfcbb97-6wlg7 -n dhcp-system --force

`OrganizationUpgrade` がノードのアップグレード段階で停止している

バージョン: 1.13.3

症状: OrganizationUpgrade がノードのアップグレードステージで停止します。次のようなメッセージが表示されることがあります。

  Last Transition Time: 2024-08-27T12:37:40Z
    Message:             observed the following reason: [JobRunning]
    Observed Generation: 614
    Reason:              Unsuccessful
    Status:              Unknown
    Type:                service/Node

回避策:

ルートクラスタ ka get upgradetaskrequest -n gpc-system で upgradetaskrequest CR を確認します。ノードが実行中のステータスになっているかどうかを確認します。サービスタスクで停止していることを確認します。

spec:
    clusterType: service
Last Transition Time: 024-08-27T12:37:40Z
  Message:            job gpc-system/v1.13.0-os-aa505d9004-upg-task-org-1-os-node-upgra-czwwd is running
  Observed Generation: 1
  Reason:              JobRunning
  Status:              Unknown
  Type:                Succeeded

nodepool クレームごとに nodeupgrade CR を手動で作成します。

export KUBECONFIG=ORG_ADMIN_KUBECONFIG
kubectl get nodepoolclaims -n g-org-1-shared-service-cluster
NAME                                                     AGE
control-plane-node-pool                                  34d
dbs-billing-system-billing-dbcluster-n2-standard-4-gdc   34d
shared-service-default-worker                            34d

nodepool クレームごとに nodeupgrade CR を作成します。アノテーション upgrade.private.gdc.goog/target-release-version の詳細は、ターゲットの OS CRMD 名から取得する必要があります。
```
kubectl get crmd  --kubeconfig ${ROOT_ADMIN_KUBECONFIG} | grep "os"
os-1.13.1-gdch.525                     35d
os-v1.13.0-os-4175a6dce6               27d
os-v1.13.0-os-aa505d9004               5d18h
```

ここから取得したバージョンをアノテーション upgrade.private.gdc.goog/target-release-version で使用します。

kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} get crmd os-v1.13.0-os-aa505d9004 -o json | jq -r '.spec.config.vmNodeImage'
rocky-86-1.13-v20240731-1.13-r191

各 nodepoolclaim に次の yaml を適用します。

    apiVersion: upgrade.private.gdc.goog/v1alpha1
    kind: NodeUpgrade
    metadata:
      annotations:
        upgrade.private.gdc.goog/target-release-version: VERSION
      name: NAME
      labels:
        addon.private.gdc.goog/cluster-type: service
      namespace: NAMESPACE
    spec:
      inFlightConf:
        maxConcurrentNodes: 1
      nodePoolClaimRef:
        name: NAME
        namespace: NAMESPACE
      nodeType: Virtual
      software:
        osImage:
          name: NAME
          version: VERSION

サービスクラスタノードのノードアップグレードが完了したら、UpgradeTaskRequest CR ステータスを True に更新して、組織のアップグレードが次のステージに進むようにします。

    kubectl patch upgradetaskrequest  upg-task-org-1-os-node-upgrade-task-pckxn --type='json' -p='[{"op": "replace", "path": "/status/conditions/0/status", "value": "True"}]' --subresource=status -n gpc-system --kubeconfig /root/release/root-admin/root-admin-kubeconfig

組織のアップグレードが次のステージに進み、サービスまたはノードのステータスが完了になります。

Last Transition Time: 2024-08-27T22:44:09Z
  Message:             observed the following reason: [JobRunning]
  Observed Generation: 614
  Reason:              Complete
  Status:              True
  Type:                service/Node

カーネルがコンテナを作成できない

バージョン: 1.13.3

症状: カーネルがメモリ cgroup を割り当てることができず、新しいコンテナの作成に失敗します。

次のようなメッセージが表示されることがあります。

Conditions:
  Type                          Status    LastHeartbeatTime                 LastTransitionTime                Reason                          Message
  ----                          ------    -----------------                 ------------------                ------                          -------
  FrequentContainerdRestart     False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   NoFrequentContainerdRestart     containerd is functioning properly
  KernelDeadlock                False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   KernelHasNoDeadlock             kernel has no deadlock
  ReadonlyFilesystem            False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   FilesystemIsNotReadOnly         Filesystem is not read-only
  ContainerRuntimeUnhealthy     False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 10:52:30 +0000   ContainerRuntimeIsHealthy       Container runtime on the node is functioning properly
  FrequentUnregisterNetDevice   False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   NoFrequentUnregisterNetDevice   node is functioning properly
  KubeletUnhealthy              False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   KubeletIsHealthy                kubelet on the node is functioning properly
  FrequentKubeletRestart        False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   NoFrequentKubeletRestart        kubelet is functioning properly
  FrequentDockerRestart         False     Thu, 29 Aug 2024 13:28:33 +0000   Sun, 30 Jun 2024 07:41:50 +0000   NoFrequentDockerRestart         docker is functioning properly
  MemoryPressure                Unknown   Thu, 29 Aug 2024 13:31:31 +0000   Thu, 29 Aug 2024 13:32:30 +0000   NodeStatusUnknown               Kubelet stopped posting node status.
  DiskPressure                  Unknown   Thu, 29 Aug 2024 13:31:31 +0000   Thu, 29 Aug 2024 13:32:30 +0000   NodeStatusUnknown               Kubelet stopped posting node status.
  PIDPressure                   Unknown   Thu, 29 Aug 2024 13:31:31 +0000   Thu, 29 Aug 2024 13:32:30 +0000   NodeStatusUnknown               Kubelet stopped posting node status.
  Ready                         Unknown   Thu, 29 Aug 2024 13:31:31 +0000   Thu, 29 Aug 2024 13:32:30 +0000   NodeStatusUnknown               Kubelet stopped posting node status.

[root@zv-aa-bm01 ~]# journalctl -u kubelet -f | grep cilium-agent
Aug 29 17:29:47 zv-aa-bm01 kubelet[48625]: E0829 17:29:47.941493   48625 pod_workers.go:1298]
"Error syncing pod, skipping" err="failed to \"StartContainer\" for \"cilium-agent\" with CrashLoopBackOff: \"back-off 5m0s restarting failed container=cilium-agent pod=anetd-pvmz4_kube-system(db55cbd2-36e3-4d20-8c6b-edbb5191232d)\"" pod="kube-system/anetd-pvmz4" podUID="db55cbd2-36e3-4d20-8c6b-edbb5191232d"
Unknown   Thu, 29 Aug 2024 13:31:31 +0000   Thu, 29 Aug 2024 13:32:30 +0000   NodeStatusUnknown               Kubelet stopped posting node status.

ノードが非常に多くの cgroup を使用している場合:

# cat /proc/cgroups | grep memory
memory  12      380360  1

回避策:

次のいずれかの手順に沿って操作します。

ノードで echo 3 > /proc/sys/vm/drop_caches を実行し、kubelet を再起動します。
前の方法で解決しない場合は、ノードの再起動を試してください。

外部クラスタ VIP への接続が断続的に失敗する

バージョン: 1.13.3

現象: 外部クラスタの仮想 IP（VIP）（コントロールプレーン VIP、istio-gateway VIP、Harbor VIP など）への接続が断続的に失敗し、dial tcp :: connect: no route to host エラーが発生します。

この問題を診断する手順は次のとおりです。

ルート管理クラスタに接続します。この回避策は、ルート管理クラスタの IP アドレスをデバッグすることを前提としています。組織管理者クラスタや組織システムクラスタなどの他の Kubernetes クラスタで接続の問題をデバッグする場合は、KUBECONFIG の値を正しいクラスタ kubeconfig パスに変更します。
影響を受ける可能性のある IP のカテゴリは 2 つあります。Border Gateway Protocol（BGP）が IP アドレスをトップオブラック（ToR）スイッチにアドバタイズしているかどうかを確認します。
- IP が 192.0.2.100 などの Kubernetes コントロールプレーン IP アドレスの場合は、次のコマンドを使用して構成情報を取得します。
```
KUBECONFIG=KUBECONFIG
kubectl cluster-info
# Kubernetes control plane is running at https://192.0.2.100:443`
```
  KUBECONFIG は、ルート管理クラスタの kubeconfig ファイルのパスに置き換えます。
- 一部の構成では、BGPAdvertisedRoute カスタムリソースは、BGP を使用して他のネットワークまたはシステムにアドバタイズされる IP アドレス内のルートを定義します。IP アドレスが BGPAdvertisedRoute カスタムリソースによってアドバタイズされている場合は、次のコマンドを使用して構成情報を取得します。
```
TARGET_IP=TARGET_IP_ADDRESS
KUBECONFIG=KUBECONFIG
kubectl get BGPAdvertisedRoute -A --kubeconfig=$KUBECONFIG | grep $TARGET_IP
```
  TARGET_IP_ADDRESS は、接続が断続的に切断される IP アドレスに置き換えます。
BGPSession カスタムリソースのステータスを確認します。BGPSession は、Kubernetes クラスタと外部 BGP ピアの間に確立された個々の BGP ピアリングセッションを表します。BGPAdvertiser Pod のログを調べて、すべての BGPSession リソースが Established 状態であることを確認します。
```
KUBECONFIG=KUBECONFIG
kubectl get pods -l app=bgpadvertiser -n kube-system

# Based on the name of pods, check their logs
kubectl logs pod/bgpadvertiser-gpc-adhoc-6a265a03vm-worker-node0-zone1 -n
kube-system --kubeconfig=$KUBECONFIG`
```
正常な BGPAdvertiser Pod の出力には、次のスニペットが含まれます。
```
I0904 04:32:19.999906       1 main.go:217] BGP advertiser serving...\
time="2024-09-04T04:32:25Z" level=info msg="Peer Up" Key=10.200.0.1
State=BGP_FSM_OPENCONFIRM Topic=Peer\
```

接続の安定性を確認します。接続が断続的か不安定かを確認するスクリプトを作成して実行します。

スクリプトを作成します。

#!/bin/bash

TARGET=$1
CNT=0
for i in {1..100}; do
    output=$(curl --no-progress-meter -k https://$TARGET 2>&1)
    if echo "$output" | grep -q "No route to host"; then
            CNT=$((CNT+ 1))
            echo "Attempt $i: $output"
    fi
    sleep 0.1
done
echo "$CNT out of 100 runs hit No route to host error"

スクリプトを実行します。

./script.sh TARGET_IP_ADDRESS:PORT

PORT は、問題が発生しているポート番号に置き換えます。

接続に問題がある場合は、次のような出力が表示されます。

Attempt 2: curl: (7) Failed to connect to 192.0.2.201 port 10443: No route
to host
Attempt 4: curl: (7) Failed to connect to 192.0.2.201 port 10443: No route
to host
Attempt 7: curl: (7) Failed to connect to 192.0.2.201 port 10443: No route
to host`

上記の出力で問題を確認します。TOR スイッチのルートを調べて、TOR スイッチの構成が問題の原因かどうかを確認します。

たとえば、IP アドレス 192.0.2.201 のトラフィックがドロップされ、BGPAdvertisedRoute リソースによってアドバタイズされているとします。BGPAdvertisedRoute リソースのホップを調べて、障害が発生する可能性のあるポイントを特定します。

apiVersion: networking.gke.io/v1
kind: BGPAdvertisedRoute
metadata:
  annotations:
    bgploadbalancer.networking.gke.io/servicename: istio-ingressgateway
    bgploadbalancer.networking.gke.io/servicens: istio-system
  creationTimestamp: "2024-08-20T19:03:02Z"
  generation: 150
  name: default-istio-system-istio-ingressgateway-rj2fv
  namespace: kube-system
  ownerReferences:
  - apiVersion: networking.gke.io/v1
    blockOwnerDeletion: true
    controller: true
    kind: BGPLoadBalancer
    name: default
    uid: f681f3e5-c66a-45d6-a3ac-9d7ae26f555f
  resourceVersion: "27133500"
  uid: 8ede0c81-3aba-40ce-a441-4aec334b41bd
spec:
  bgpPeerNames:
  - 192.0.2.6-peer-10.0.1.1
  - 192.0.2.5-peer-10.0.1.0
  - 192.0.2.5-peer-10.0.1.1
  - 192.0.2.6-peer-10.0.1.0
  nextHops:
  - 192.0.2.2
  - 192.0.2.3
  - 192.0.2.4
  prefix: 192.0.2.201/32

nextHops フィールドの IP アドレスを確認します。各 IP アドレスのサーバー名を確認します。次に例を示します。
```
- 192.0.2.2 zt-aa-bm08
- 192.0.2.3 zt-aa-bm09
- 192.0.2.4 zt-ab-bm01
```
この出力は、ネクストホップがラック aa とラック ab のサーバーに向かっていることを示しています。ラック aa と ab の TOR スイッチにログインし、両方のラックのルートを比較します。
```
show ip route 192.0.2.201 vrf root-external-vrf
```

2 つのラックの TOR スイッチ間でルートが異なる場合は、この回避策で軽減される問題が発生しています。この問題の出力は次のようになります。

zt-aa-torsw01# show ip route 192.0.2.201 vrf root-external-vrf
IP Route Table for VRF "root-external-vrf"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.0.2.201/32, ubest/mbest: 3/0, all-best
*via 192.0.2.2, [20/0], 1w1d, bgp-65070, external, tag 64513
*via 192.0.2.3, [20/0], 1w1d, bgp-65070, external, tag 64513
*via 192.0.2.4, [20/0], 1w1d, bgp-65070, external, tag 64513

zt-aa-torsw02# sh ip route 192.0.2.201  vrf root-external-vrf
IP Route Table for VRF "root-external-vrf"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.0.2.201/32, ubest/mbest: 3/0, all-best
*via 192.0.2.2, [20/0], 1w3d, bgp-65070, external, tag 64513
*via 192.0.2.3, [20/0], 1w3d, bgp-65070, external, tag 64513
*via 192.0.2.4, [20/0], 1w3d, bgp-65070, external, tag 64513

zt-ab-torsw01# show ip route 192.0.2.201 vrf root-external-vrf
IP Route Table for VRF "root-external-vrf"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.0.2.201/32, ubest/mbest: 2/0, all-best
*via 10.249.88.2, [200/0], 1w1d, bgp-65070, internal, tag 64513
*via 192.0.2.3, [200/0], 1w1d, bgp-65070, internal, tag 64513

zt-ab-torsw02# sh ip route  192.0.2.201  vrf root-external-vrf
IP Route Table for VRF "root-external-vrf"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.0.2.201/32, ubest/mbest: 2/0, all-best
*via 192.0.2.2, [200/0], 1w3d, bgp-65070, internal, tag 64513
*via 192.0.2.3, [200/0], 1w3d, bgp-65070, internal, tag 64513

この出力では、ラック aa のルートは想定どおりの状態であり、プレフィックスに対して 3 つのネクストホップがリストされています。ただし、ラック ab では、プレフィックスのネクストホップは 2 つだけです。プレフィックス宛てのトラフィックがラック ab にハッシュされると、欠落したネクストホップに対応するノードはトラフィックを受信せず、ネットワークで接続の問題が発生します。

この問題を軽減するには、回避策を実施してください。

回避策:

この回避策は、Kubernetes クラスタ内の特定の IP アドレスへの断続的な接続の問題に役立ちます。

この問題を軽減するには、アグリゲーションスイッチ間の BGP セッションにいくつかの構成変更を適用する必要があります。アグリゲーション（AGG）スイッチは、複数の TOR スイッチからのトラフィックを集約します。必要なすべての構成を更新する手順は次のとおりです。

switchstaticconfig という構成ファイルは、単一のスイッチの静的構成を表します。両方の AGG スイッチの switchstaticconfig ファイルをダウンロードします。

export KUBECONFIG=KUBECONFIG
kubectl get switchstaticconfig za-ab-aggsw01-static-config -n gpc-system -oyaml > /tmp/za-ab-aggsw01-static-config.yaml
kubectl get switchstaticconfig za-ac-aggsw01-static-config -n gpc-system -oyaml > /tmp/za-ac-aggsw01-static-config.yaml

環境の自律システム番号（ASN）を取得します。
```
root@bootstrapper:/tmp# kubectl get ClusterBGPRouter --kubeconfig KUBECONFIG -A -o yaml | grep networkASN | head -1
    networkASN: 65030
```
この出力は、ASN 値が 65030 であることを示しています。次の手順では、ここで返された ASN 値を使用する必要があります。
AGG スイッチのループバック IP アドレスは、他のネットワーク接続がダウンしている場合でも、管理、ルーティング、トラブルシューティング用の安定した常時オンのアドレスとして機能します。各 AGG スイッチのループバック IP アドレスを取得します。
```
root@bootstrapper:~# kubectl get --kubeconfig KUBECONFIG
aggswitchinternal -n gpc-system -o
jsonpath='{range.items[*]}{.metadata.name}{":\t"}{.spec.loopbackIPs}{"\n"}{end}'
```
出力は次のようになります。
```
za-ab-aggsw01-internal: ["192.0.2.1"]
za-ac-aggsw01-internal: ["192.0.2.2"]
```
za-ab-aggsw01 AGG スイッチの staticswitchconfig を更新します。このスニペットを config セクションに追加します。
```
spec:
  config: |

route-map onlydefault permit 10
match ip address prefix default
router bgp ASN
      neighbor LOOPBACK_ADDRESS
  address-family l2vpn evpn
      route-map onlydefault in

...
    key chain OSPF_AUTH_KEYCHAIN_0
      key 1
```
次のように置き換えます。
- ASN: 前のステップの ASN 値。この例では、この値は 65030 です。
- LOOPBACK_ADDRESS: AGG スイッチ za-ac-aggsw01 のループバック IP アドレスです。この例での値は 192.0.2.2 です。
同じ更新を他の AGG スイッチ za-ac-aggsw01 に適用します。正しいループバックアドレスを指定する必要があります。ループバック IP アドレスはスイッチごとに異なります。
```
za-ab-aggsw01-internal: ["192.0.2.1"]
za-ac-aggsw01-internal: ["192.0.2.2"]
```
このステップで問題の診断に使用したスクリプトと同じスクリプトを作成して実行し、修正が成功したことを確認します。出力にはエラーメッセージが表示されません。

アップグレード中に `Incorrect version of Trident` エラーが表示される

バージョン: 1.13.3、1.13.4、1.13.5

現象: バージョン 1.13.3 より前のバージョンからアップグレードすると、ontap に Incorrect version of Trident エラーが表示されます。次のようなメッセージが表示されることがあります。

Status:
  Conditions:
  Last Transition Time: 2024-08-27T15:19:07Z
  Message:              Incorrect version of Trident. Wanted v23.10.0-gke.6, got v23.10.0-gke5
  Observed Generation:  1
  Reason:               QualificationFailed
  Status:               False
  Type:                 AllComplete
  Events:

回避策:

アップグレードするバージョンの releasemetadata を更新します。

export KUBECONFIG=<point to ROOT Admin Kubeconfig>
To get the list of all releasemetadata:
`kubectl get releasemetadata`

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

NAME AGE 1.12.2-gdch.785 24d 1.12.4-gdch.96 13d 1.13.3-gdch.5548 11h

次の例に示すように、アップグレード先のバージョンを選択します。
```
kubectl get releasemetadata 1.13.3-gdch.5548 -o yaml > releasemetadata.yaml
```
.yaml の fileBlockStorage セクションの tridentVersion を、エラーに記載されているバージョンに更新します。エラーメッセージが次のような場合:
```
Message: Incorrect version of Trident. Wanted v23.10.0-gke.6, got v23.10.0-gke.5
```
releasemetadata.yaml で tridentVersion を v23.10.0-gke.5 に変更します。

たとえば、元の値が infraComponents: fileBlockStorage: ONTAPVersion: 9.14.1P1 harvestVersion: v22.08.0-gke.7 tridentVersion: v23.10.0-gke.6 の場合、

次の値に変更します。

infraComponents: fileBlockStorage: ONTAPVersion: 9.14.1P1 harvestVersion: v22.08.0-gke.7 tridentVersion: v23.10.0-gke.5。
変更を適用します。
```
kubectl apply -f releasemetadata.yaml
```
ontap ストレージのアップグレードを再度適用します。

Pod のスケジュール設定に失敗する

バージョン: 1.13.3。1.13.4、1.13.5

症状: ユーザークラスタのプロビジョニング中に、一部の Pod のスケジュール設定が失敗します。次のようなメッセージが表示されることがあります。

0/6 nodes are available: 1 Insufficient cpu. preemption: 0/6 nodes are available: 6 No preemption victims found for incoming pod

回避策:

ユーザークラスタのコントロールプレーンノードプールをスケールアップします。

  kubectl --kubeconfig ORG_ADMIN_KUBECONFIG patch addresspoolclaim/control-plane-node-pool -n ${CLUSTER_NAME}-cluster --type=json -p="[{'op': 'replace', 'path': '/spec/size', 'value': 5}]"
  kubectl --kubeconfig ORG_ADMIN_KUBECONFIG patch nodepoolclaim/control-plane-node-pool -n ${CLUSTER_NAME}-cluster --type=json -p="[{'op': 'replace', 'path': '/spec/nodeCount', 'value': 5}]"

`iac-zoneselection-global` サブコンポーネントでアップグレードが失敗する

バージョン: 1.13.1

現象: 1.13.3 へのアップグレード中に、サブコンポーネント iac-zoneselection-global でエラーが発生します。次のようなメッセージが表示されることがあります。

== Subcomponents with failures in root org ===
Sub-Component: iac-zoneselection-global - Reconciliation error: E0100 - deploy: failed to install chart: release iac-zoneselection-global-backend failed, and has been uninstalled due to atomic being set: 1 error occurred:
        * ZoneSelection.location.mz.global.private.gdc.goog "iac" is invalid: spec.resultObjectName: Required value

Events: Type     Reason               Age                   From          Message
----     ------               ----                  ----          -------
Warning  ReconciliationError  119s (x521 over 20h)  Subcomponent  E0100 - deploy: failed to install chart: release iac-zoneselection-global-backend failed, and has been uninstalled due to atomic being set: 1 error occurred:
         * ZoneSelection.location.mz.global.private.gdc.goog "iac" is invalid: spec.resultObjectName: Required value

回避策:

1.13.3 にアップグレードすると、このエラーは修正されます。

アップグレードチェックジョブの期限が超過しました

バージョン: 1.12.x、1.13.x

症状: 組織のアップグレード中に、アップグレードチェックでステータス False と理由 DeadlineExceeded が表示されます。次のようなメッセージが表示されることがあります。

  Preflight Check:                                                                                                                                                                                                          
    Conditions:                                                                                                                                                                                                             
      Last Transition Time:  2024-10-29T18:57:47Z                                                                                                                                                                           
      Message:               the result has status: False, reason: PreflightCheckFailed, and err: [check "OPAUpgrade" of operable component "OPA" failed with reason "DeadlineExceeded", no existing pods found, check "Arti
actAvailability" of operable component "AR" failed with reason "DeadlineExceeded", no existing pods found, check "PackageValidation" of operable component "AR" failed with reason "DeadlineExceeded", no existing pods foun
d, check "IAMUpgrade" of operable component "IAM" failed with reason "DeadlineExceeded", no existing pods found, check "NodeHealth" of operable component "OS" failed with reason "DeadlineExceeded", no existing pods found
, check "DNSHealth" of operable component "DNS" failed with reason "DeadlineExceeded", no existing pods found, check "AdminClusterCheck" of operable component "UPORC" failed with reason "DeadlineExceeded", no existing po
ds found[]                                                                                                                                                                                                                  
      Observed Generation:   3                                                                                                                                                                                              
      Reason:                PreflightCheckFailed                                                                                                                                                                           
      Status:                False                                                                                                                                                                                          
      Type:                  Succeeded                                                                                                                                                                                      
    Start Time:              2024-10-29T17:57:47Z

回避策:

失敗したアップグレードチェックに対応する、失敗したアップグレードチェックジョブを削除します。
アップグレードチェックジョブが再作成されるまで待ちます。
再作成されたジョブのログを調べて、問題をトリアージします。

strongswan の場所が別のランタイムディレクトリにあるため、`meta-monitoring` アドオンが失敗する

バージョン: 1.12.x、1.13.x

症状: 1.13.4 または 1.13.5 へのアップグレード中に、meta-monitoring アドオンが失敗します。

kubectl --kubeconfig ORG_ADMIN_KUBECONFIGget addons -A | grep meta-monitoring
org-1-system-cluster                                      meta-monitoring                                      false                                        false                                      1.12.4-gdch.96

アドオンを確認します。

kubectl --kubeconfig ORG_ADMIN_KUBECONFIG get -n org-1-system-cluster addon meta-monitoring -o yaml

条件メッセージは次のようになります。

status:
  conditions:
  - lastTransitionTime: "2024-11-19T02:57:30Z"
    message: 'Error occurred during addon installation: failed to rollback chart:
      create: failed to create: Internal error occurred: failed calling webhook "validation.gatekeeper.sh":
      failed to call webhook: Post "https://gatekeeper-webhook-service.opa-system.svc:443/v1/admit?timeout=3s":
      context deadline exceeded'
    observedGeneration: 2
    reason: InstallationError
    status: "False"
    type: Deployed

回避策:

Org System Cluster の BGP セッションが失敗していることを確認します。例:

kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG get bgpsessions -A
NAME                                           LOCAL ASN   PEER ASN   LOCAL IP        PEER IP     STATE   LAST REPORT
10.252.122.10-peer-10.0.1.32-vm-7351eebe       64513       65030      10.252.122.10   10.0.1.32           
10.252.122.10-peer-10.0.1.33-vm-7351eebe       64513       65030      10.252.122.10   10.0.1.33           
10.252.122.11-peer-10.0.1.32-vm-7351eebe       64513       65030      10.252.122.11   10.0.1.32           
10.252.122.11-peer-10.0.1.33-vm-7351eebe       64513       65030      10.252.122.11   10.0.1.33           
172.20.128.3-peer-10.0.1.48-za-aa-bm02-hltg2   64513       65030      172.20.128.3    10.0.1.48           
172.20.128.3-peer-10.0.1.49-za-aa-bm02-hqblq   64513       65030      172.20.128.3    10.0.1.49

ang-node Pod が ContainerCreating で停止していることを確認します。次に例を示します。

kubectl --kubeconfig ORG_SYSTEM_KUBECONFIG get pods -n kube-system -l app=ang-node
NAME                                                 READY   STATUS              RESTARTS        AGE
ang-node-5c6c8                                       0/3     ContainerCreating   0               2d21h
ang-node-6skkl                                       0/3     ContainerCreating   0               2d14h
ang-node-7d7dj                                       0/3     ContainerCreating   0               2d20h
ang-node-9l4xc                                       0/3     ContainerCreating   0               2d17h

次のエラーが表示されます。

Warning  FailedMount  112s (x2056 over 2d21h)  kubelet  MountVolume.SetUp failed for volume "vici" : hostPath type check failed: /var/run/strongswan is not a directory

組織管理クラスタの ang-overrides AddonConfiguration に次の変更を適用します。

kubectl --kubeconfig ORG_ADMIN_KUBECONFIG edit addonconfiguration ang-overrides -n org-1-system-cluster

以下の変更を加えます。

            volumes:
            - hostPath:
                path: /var/run/strongswan
                type: Directory
              name: vici

次のように変更します。

            volumes:
            - hostPath:
                path: /var/run
                type: Directory
              name: vici

1 分ほど経過したら、ang-node Pod が Running 状態になっていることを確認します。

NAME             READY   STATUS    RESTARTS   AGE
ang-node-7hj5q   3/3     Running   0          15s
ang-node-xps2m   3/3     Running   0          34s
ang-node-krx8p   3/3     Running   0          34s
ang-node-cbm1a   3/3     Running   0          34s

組織システムクラスタの BGP セッションが実行されていることを確認します。
meta-monitoring アドオンが次のステージに進みます。

ルート組織のアップグレードが署名ジョブの失敗で停止する

バージョン: 1.13.3、1.13.4

症状: 1.13.3 から 1.13.4 にアップグレードすると、次のようなメッセージが表示されることがあります。

Message:       [the result has status: False, reason: PreflightCheckFailed, and err: check "PackageValidation" of operable component "AR" failed with reason "DeadlineExceeded", no existing pods found, the result has status: Unknown, reason: UpgradeCheckJobsInProgress

回避策:

プリフライトチェックを無効にします。

kubectl annotate -n gpc-system organization root upgrade.private.gdc.goog/skip-preflight-check=ok

失敗した artifact-signature-verification-*** ジョブを削除します。
ルートのアップグレードが完了するまで待ちます。
省略可: 環境が 1.13.4 以降にアップグレードされている場合は、プリフライトチェックを有効にします。

コントローラが 1.13.4 になると、アップグレードでこの問題が発生することはありません。

テナント組織のアップグレードがプリフライトチェックステージで `ErrImagePull` により失敗する

バージョン: 1.13.3

症状: テナント組織のアップグレードが、パッケージ検証 Pod の ErrImagePull でプリフライトチェックの段階で失敗します。次のようなメッセージが表示されることがあります。

export KUBECONFIG=ORG_ADMIN_KUBECONFIG
kubectl get po -n package-validation-system  | grep artifact-signature-verification

Pod に ImagePullBackOff エラーが表示されます。

kubectl describe po -n package-validation-system POD_NAME

次のようなイメージプルエラーが表示されます。

Name:             artifact-signature-verification-20240823224755-4ppkt
Namespace:        package-validation-system
Priority:         0
Service Account:  package-validation
Node:             ak-ab-base02/203.0.113.250
Start Time:       Fri, 23 Aug 2024 22:47:55 +0000
Labels:           batch.kubernetes.io/controller-uid=bf81d5eb-d597-464e-a907-67c1c8a11c11
                  batch.kubernetes.io/job-name=artifact-signature-verification-20240823224755
                  controller-uid=bf81d5eb-d597-464e-a907-67c1c8a11c11
                  job-name=artifact-signature-verification-20240823224755
Annotations:      <none>
Status:           Pending
IP:               203.0.113.255
IPs:
  IP:           203.0.113.255
Controlled By:  Job/artifact-signature-verification-20240823224755
Containers:
  artifact-signature-verification:
    Container ID:
    Image:          gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004
    Image ID:
    Port:           <none>
    Host Port:      <none>
    State:          Waiting
      Reason:       ImagePullBackOff
    Ready:          False
    Restart Count:  0
...
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason     Age                     From               Message
  ----     ------     ----                    ----               -------
  Normal   Scheduled  10m                     default-scheduler  Successfully assigned package-validation-system/artifact-signature-verification-20240823224755-4ppkt to ak-ab-base02
  Normal   Pulling    7m25s (x4 over 9m22s)   kubelet            Pulling image "gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004"
  Warning  Failed     7m14s (x4 over 9m12s)   kubelet            Failed to pull image "gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004": failed to pull and unpack image "gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004": failed to resolve reference "gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004": unexpected status from HEAD request to https://203.0.113.255/v2/private-cloud-staging/signature-verifier/manifests/v1.13.0-uporc-aa505d9004?ns=gcr.io: 401 Unauthorized
  Warning  Failed     7m14s (x4 over 9m12s)   kubelet            Error: ErrImagePull
  Warning  Failed     7m3s (x6 over 9m11s)    kubelet            Error: ImagePullBackOff
  Normal   BackOff    4m11s (x17 over 9m11s)  kubelet            Back-off pulling image "gcr.io/private-cloud-staging/signature-verifier:v1.13.0-uporc-aa505d9004"

回避策:

プリフライトチェックをスキップします。

kubectl annotate -n gpc-system organization ORG_NAME \
upgrade.private.gdc.goog/skip-preflight-check=ok

ルート組織のアップグレード中に `serviceaccount` が見つからない

バージョン: 1.13.8、1.13.9

現象: 1.13.8 へのアップグレード中に、以前のアップグレードが完了していてアドオンがすでに存在する場合、RBAC の addon Deployment が失敗します。症状は次のいずれかの段階にあります。

プリフライトチェックまたはポストフライトチェック
アップグレードタスクを含むステージで、タスクが停止しているにもかかわらず、ジョブが実行中であることを示すメッセージが表示される。status.conditions メッセージは、ジョブが長時間実行されていることを示し、問題があることを示しています。

アップグレードのプリフライトチェックが失敗したかどうかを確認するには、アップグレードする組織に対応する OrganizationUpgrade オブジェクトのステータスを確認します。

  kubectl get -n gpc-system organizationupgrade ORG_NAME -o yaml

ジョブが PreflightCheck で失敗した場合、次のような失敗または UpgradeCheckRBACDeploymentInProgress メッセージが表示されることがあります。

  - lastTransitionTime: "2024-09-27T00:28:21Z"
    message: ""
    observedGeneration: 2
    reason: Unknown
    status: "False"
    type: PreflightCheck

タスクジョブが実行されている AnthosBareMetal（ABM）ステージでジョブが失敗した場合、次の出力が表示されます。

- Last Transition Time:  2024-09-26T19:55:13Z
  message:               observed the following reason: [JobRunning]
  observedGeneration:    3
  reason:                Unsuccessful
  status:                Unknown
  type:                  root-admin/AnthosBareMetal

チェックで失敗した場合、upgradecheckrequest CR は失敗します。

kubectl get upgradecheckrequests -n gpc-system  --kubeconfig /root/release/root-admin/root-admin-kubeconfig

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

NAME                                   AGE
upgrade-check-root-postflight-xc7p8    6h32m

障害がタスクにある場合、upgradetaskrequests CR は失敗します。

kubectl get upgradetaskrequests -n gpc-system  --kubeconfig /root/release/root-admin/root-admin-kubeconfig

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

NAME                                          AGE
upg-task-org-1-mz-mz-location-upgrade-5n6wp   2d19h

サービスアカウントの検索で RBAC エラーが示されている場合は、以前のアドオンがデプロイされているかどうかを確認します。

Type     Reason        Age                   From            Message
----     ------        ----                  ----            -------
Warning  FailedCreate  38s (x11 over 5m41s)  job-controller  Error creating: pods "v1.13.0-mz-2837f80328-upg-task-root-mz-mz-location-jkv69-" is forbidden: error looking up service account gpc-system/upgrade-task-mz-sa-v1.13.0-mz-2837f80328: serviceaccount "upgrade-task-mz-sa-v1.13.0-mz-2837f80328" not found

回避策:

以前のアドオンがデプロイされているかどうかを確認します。

  Type     Reason        Age                    From            Message
  ----     ------        ----                   ----            -------
  Warning  FailedCreate  4m30s (x101 over 99m)  job-controller  Error creating: pods "v1.13.0-os-2837f80328-upg-task-root-os-node-upgrad-fdblm-" is forbidden: error looking up service account gpc-system/upgrade-task-os-sa-v1.13.0-os-2837f80328: serviceaccount "upgrade-task-os-sa-v1.13.0-os-2837f80328" not foundcount gpc-system/upgrade-task-mz-sa-v1.13.0-mz-2837f80328: serviceaccount "upgrade-task-mz-sa-v1.13.0-mz-2837f80328" not found

同じコンポーネントに存在する以前のアドオンを取得します。タスクの場合は upgrade-task-mz:

kubectl get addons -n gpc-system | grep upgrade-task
upgrade-task-mz-lsqzc            true       true    v1.13.0-mz-7cf810d7a5

このアドオンを削除します。

kubectl delete addon -n gpc-system upgrade-task-mz-lsqzc upgrade-task-os-px5wj
addon.addon.private.gdc.goog "upgrade-task-mz-lsqzc" deleted

アドオンを削除したら、対応する upgradetaskrequest または upgradecheckrequest も削除します。再作成されます。
```
kubectl delete upgradetaskrequest -n gpc-system upgrade-task-mz-lsqzc
```
新しく作成された upgradetaskrequest、upgradecheckrequest、または対応するジョブを直接モニタリングし続けます。

`shared-service-cluster upgrade` でアップグレードが失敗する

バージョン: 1.13.3

症状: Anthos Bare metal のアップグレードが 1 つ以上のベアメタルマシンで停止します。他のすべてのベアメタルマシンは正常にアップグレードされたか、まだアップグレードが開始されていません。1 台のベアメタルマシンがメンテナンスモードになっていますが、現在の ABM バージョンと目的の ABM バージョンの両方のフィールドに以前のバージョンが表示されています。

Anthos bare metal に沿って、クラスタの baremetalmachine ステータスと詳細情報を取得します。

kubectl get baremetalmachines -n "${CLUSTER_NAMESPACE}" --kubeconfig=${ADMIN_KUBECONFIG}

予想される出力:

NAME           CLUSTER                  READY   INSTANCEID                  MACHINE         ABM VERSION        DESIRED ABM VERSION
192.0.2.0      g-org-1-shared-service   true    baremetal://192.0.2.0       192.0.2.0       1.29.300-gke.185   1.29.300-gke.185
192.0.2.18     g-org-1-shared-service   true    baremetal://192.0.2.18      192.0.2.18      1.29.300-gke.185   1.29.300-gke.185
192.0.2.19     g-org-1-shared-service   true    baremetal://192.0.2.19      192.0.2.19      1.29.300-gke.185   1.29.300-gke.185
192.0.2.10     g-org-1-shared-service   true    baremetal://192.0.2.10      192.0.2.10      1.29.300-gke.185   1.29.300-gke.185
192.0.2.22     g-org-1-shared-service   true    baremetal://192.0.2.22      192.0.2.22      1.29.300-gke.185   1.29.300-gke.185
192.0.2.9      g-org-1-shared-service   true    baremetal://192.0.2.9       192.0.2.9       1.29.0-gke.1449    1.29.0-gke.1449

kubectl get baremetalmachines -n "${CLUSTER_NAMESPACE}" --kubeconfig=${ADMIN_KUBECONFIG} ${MACHINE_IP}  -o json | jq '.status.underMaintenance'

予想される出力:

true

回避策:

インベントリマシンをメンテナンスモードから移動します。

export InventoryMachineName=$(kubectl --kubeconfig=${ADMIN_KUBECONFIG} get inventorymachines -A  -o json | jq '.items[] | select(.spec.address=="${MACHINE_IP}") | .metadata.name')
kubectl --kubeconfig "${ADMIN_KUBECONFIG:?}" patch inventorymachine/${InventoryMachineName:?} --type=merge  -p '{"spec": {"maintenance": false}}'

インベントリマシンがメンテナンスモードを終了するまで待ちます。この処理には最大で 10 分ほどかかります。

kubectl --kubeconfig "${ADMIN_KUBECONFIG:?}" wait inventorymachine/${InventoryMachineName} --for=jsonpath=.status.maintenance=true --timeout=600s

baremetalmachines をモニタリングして、マシンが選択した ABM バージョンの更新を確認していることを確認します。
```
kubectl get baremetalmachines -n "${CLUSTER_NAMESPACE}" --kubeconfig=${ADMIN_KUBECONFIG}
```

`system-dashboards` アドオンのインストールに失敗しました

バージョン: 1.13.5

症状: 1.12.4 から 1.13.5 へのアップグレードが、system-dashboards アドオンのアドオンアップグレードで失敗します。

│ Status:                                                                                                                                                                        │
│   Conditions:                                                                                                                                                                  │
│     Last Transition Time:  2024-10-22T00:34:54Z                                                                                                                                │
│     Message:               Error occurred during addon installation: failed to rollback chart: no ConfigMap with the name "cluster-etcd-platform-obs" found                    │
│     Observed Generation:   2                                                                                                                                                   │
│     Reason:                InstallationError                                                                                                                                   │
│     Status:                False

回避策: OCLCM-R0122 ランブックの手順に沿って対応します。

`NodeUpgradeTask` CR が `NodeOSInPlaceUpgradePostProcessingCompleted` 条件で停止する

バージョン: 1.13.5

症状: 1.13.5 へのアップグレード中に、NodeUpgradeTask CR が NodeOSInPlaceUpgradePostProcessingCompleted 条件で停止します。

対応する os-artifact-collector ジョブが完了しているかどうかを確認します。ジョブが数時間停止すると、次のメッセージが表示されます。

  root@gpc-adhoc-7e017e71vm-bootstrapper-zone1:~# kag logs  os-artifact-collector-bm-45942837-p8hrk-z56gh 
  I1020 22:06:11.844634       1 main.go:30] BuildDate: 2024-10-19T16:54:08Z
  I1020 22:06:11.844695       1 main.go:31] Version: 0.0.0-gdch.1.v3f2043

回避策:

ジョブまたは Pod を削除して、再試行を強制します。

アップグレード中にイメージの配布が失敗する

バージョン: 1.13.5

現象: 1.12.4 から 1.13.x へのアップグレード中にイメージ配布が失敗します。

Error: error uploading the VM image to object storage: failed to upload to object storage: BadRequest: Bad Request
    status code: 400, request id: , host id: 
F1018 02:04:46.191627       1 main.go:88] VM Image Distributor quit: error uploading the VM image to object storage: failed to upload to object storage: BadRequest: Bad Request
    status code: 400, request id: , host id: 
goroutine 1 [running]:

組織の gpc-system で obj-proxy Pod を確認し、証明書の検証が失敗していることを確認します。

E1021 19:10:31.710076       1 token_source.go:185] Unable to rotate token: failed to initialize aisClient: failed to initialise AIS client: failed to obtain login config from the provided path "https://console.org-1.zone1.google.gdch.test/.well-known/login-config" with error: unable to parse centralized login config file: unsuccessful get request to config URL (https://console.org-1.zone1.google.gdch.test/.well-known/login-config) with error: Get "https://console.org-1.zone1.google.gdch.test/.well-known/login-config": tls: failed to verify certificate: x509: certificate signed by unknown authority

回避策:

失敗した組織の KUBECONFIG を使用して obj-proxy Pod を再起動します。

export KUBECONFIG=<ORG_KUBECONFIG>
kubectl delete pods -n gpc-system -l name=obj-proxy-manager

obj-proxy のログを確認します。

kubectl get pods -n gpc-system | grep obj-proxy

想定される出力は次のとおりです。

obj-proxy-gdgzp                                                1/1     Running     0              5d1h
obj-proxy-nhnsm                                                1/1     Running     0              5d1h
obj-proxy-wrxlq                                                1/1     Running     0              5d1h

使用可能な Pod のログを確認します。
```
kubectl logs obj-proxy-gdgzp -n gpc-system
```
回避策を適用すると、イメージ配布ジョブが完了します。

ユーザークラスタのアップグレード中にノードが失敗する

バージョン: 1.13.3

症状: ユーザークラスタのアップグレード中にノードで実行されているジョブが失敗し、次のようなエラーメッセージが表示されます。

 Reason: mkdir: cannot create directory '/root/.ansible/tmp/ansible-tmp-1727810181.4584012-29-114086005628321': No space left on device

ノードにログインして、パーティションが満杯かどうかを確認します。

df -h /

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

Filesystem                  Size  Used Avail Use% Mounted on
/dev/mapper/rocky-rl--root   31G   31G  120K 100% /

/etc/kubernetes/tmp が大量の容量を使用しているかどうかを確認します（du -s /etc/kubernetes/tmp）。この問題は、Kubernetes が通常よりも多くのバックアップを作成した場合に発生します。

回避策:

rm -f /etc/kubernetes/tmp/* のバックアップをすべてクリアします。
```
df -h /
```
出力は次のようになります。
```
Filesystem                  Size  Used Avail Use% Mounted on
/dev/m
```

ルート管理者のアップグレードが再作成され、プリフライトチェックで失敗する

バージョン: 1.13.3、1.13.4、1.13.5、1.13.6、1.13.7、1.13.8、1.13.9

症状: プリフライトチェックでルート組織のアップグレードが失敗します。例:

│   Preflight Check:                                                                                                                                                             │
│     Conditions:                                                                                                                                                                │
│       Last Transition Time:  2024-10-28T14:17:31Z                                                                                                                              │
│       Message:               [the result has status: False, reason: PreflightCheckFailed, and err: check "ASMStable" of operable component "ASM" failed with reason "BackoffLi │
│ mitExceeded", please check logs in pods: [gpc-system/upgrade-managed-check-asmstable-4dw66-cld74, gpc-system/upgrade-managed-check-asmstable-4dw66-k8xk5, gpc-system/upgrade-m │
│ anaged-check-asmstable-4dw66-wtc6q, gpc-system/upgrade-managed-check-asmstable-4dw66-l9b6v, gpc-system/upgrade-managed-check-asmstable-4dw66-nf62h, gpc-system/upgrade-managed │
│ -check-asmstable-4dw66-6m7p2, gpc-system/upgrade-managed-check-asmstable-4dw66-4mqmb], the result has status: Unknown, reason: UpgradeCheckJobsInProgress, and err: upgrade ch │
│ eck jobs in progress for Operable Components: haas,bil]                                                                                                                        │
│       Observed Generation:   2                                                                                                                                                 │
│       Reason:                PreflightCheckFailed                                                                                                                              │
│       Status:                False                                                                                                                                             │
│       Type:                  Succeeded                                                                                                                                         │
│     Start Time:              2024-10-28T14:46:42Z

ルート管理クラスタとルート管理の kubeapiserver が、選択した abm バージョンにアップグレードされました。

例:

export KUBECONFIG=<path to root admin kubeconfig>
kubectl describe kubeapiserver root-admin -n root
kubectl get cluster root-admin -n root

kubectl describe kubeapiserver root-admin -n root の出力例:

Name:         root-admin
Namespace:    root
Labels:       lcm.private.gdc.goog/cluster-type=root-admin
              lcm.private.gdc.goog/cluster-version=1.29.600-gke.108
              lcm.private.gdc.goog/component-version=v1.13.0-oclcm-f4c190e0f2

kubectl get cluster root-admin -n root の出力例:

NAME         ABM VERSION        DESIRED ABM VERSION   CLUSTER STATE
root-admin   1.29.600-gke.108   1.29.600-gke.108      Running

回避策

プリフライトチェックのスキップを適用してアップグレードを続行します。

export KUBECONFIG=<path to root admin kubeconfig>
kubectl delete organizationupgrade root -n gpc-system && kubectl annotate -n gpc-system organization root upgrade.private.gdc.goog/skip-preflight-check=ok 
kubectl delete organizationupgrade root -n gpc-system

Namespace `platform-obs-obs-system` または `platform-obs` が終了状態のままになる

バージョン: 1.13.5

症状: アップグレードまたはブートストラップ中にアドオンのデプロイが失敗し、次のようなエラーメッセージが表示されます。

 export KUBECONFIG=ROOT_ADMIN
 kubectl get addon -n org-1 system-alerts system-dashboards

次の出力が表示されます。

  NAME                DEPLOYED   READY   VERSION
  system-alerts
  system-dashboards   false      false   1.12.4-gdch.96

DEPLOYED または READY ステータスに false が表示されるか、空白の場合は、エラーについてそれぞれのアドオンを確認します。例:

  export KUBECONFIG=ROOT_ADMIN
  kubectl describe addon -n org-1 system-alerts

次の出力が表示されます。

  ...
  ... unable to create new content in namespace platform-obs-obs-system because it is being terminated                             
  ...

削除中の Namespace にコンテンツを作成しようとしたため、アドオンがブロックされました。このブロックは、Namespace の削除もブロックされているため、継続されます。

回避策:

アップグレードを開始する前に、プロジェクトにアノテーションを付けて削除を防ぎます。

export KUBECONFIG=ORG_ADMIN
kubectl annotate project -n gpc-system platform-obs helm.sh/resource-policy="keep"

次の出力が表示されます。

project.resourcemanager.gdc.goog/platform-obs annotated
kubectl annotate project -n gpc-system platform-obs-obs-system helm.sh/resource-policy="keep"
project.resourcemanager.gdc.goog/platform-obs-obs-system annotated

環境ですでに前述の症状が発生している場合は、次の回避策を実施してください。

ファイナライザを含むリソースがあるため、Namespace の削除がブロックされています。削除を続行するには、提供されたスクリプトを使用してファイナライザーを削除します。

  export KUBECONFIG=ORG_ADMIN
  function rm_finalizer() {
      export TYPE=$1
      export NS=$2
      RESOURCES=$(kubectl get $TYPE -n $NS --no-headers -o custom-columns=":metadata.name")
      for rc in $RESOURCES; do
          kubectl patch $TYPE $rc -n $NS \
                  --type json \
                  --patch '{"metadata":{"finalizers":[]}}' --type=merge
      done
    }
    rm_finalizer "monitoringrule" "platform-obs-obs-system"
    rm_finalizer "monitoringrule" "platform-obs"
    rm_finalizer "loggingrule" "platform-obs"
```
Note: Use a bash terminal (default on bootstrappers) to run the script.

リソースの削除を待ちます。スクリプトを実行したら、リソースと終了中の Namespace を削除します。Namespace が終了状態のままになっている場合は、スクリプトを再度実行する必要があります。終了すると、Namespace は自動的に再作成されます。Namespace が再作成され、ACTIVE 状態になっていることを確認します。
```
  export KUBECONFIG=ORG_ADMIN
  kubectl get namespace platform-obs platform-obs-obs-system
```
次の出力が表示されます。
```
  NAME                      STATUS   AGE
  platform-obs              Active   45s
  platform-obs-obs-system   Active   49s
```
アクティブな Namespace がある場合、停止していたアドオンは数分以内にデプロイされます。DEPLOYED ステータスと READY ステータスが true になっていることを確認します。
```
  export KUBECONFIG=ROOT_ADMIN
  kubectl get addon -n org-1 system-alerts system-dashboards
```
次の出力が表示されます。
```
  NAME                DEPLOYED   READY   VERSION
  system-alerts       true       true    1.14.0-gdch.143998
  system-dashboards   true       true    1.14.0-gdch.143998
```

ブートストラップ中に KIND クラスタで UPORC クラッシュループが発生する

バージョン: 1.13.x

症状: Namespace uporc-system の Deployment uporc-root-backend-controller が KIND クラスタでクラッシュループします。

回避策:

ComponentGroupReleaseMetadata オブジェクトと ReleaseMetadata オブジェクトが一致しているかどうかを確認します。
```
export KUBECONFIG=KIND
kubectl get componentgroupreleasemetadata
kubectl get releasemetadata
```
オブジェクトが一致する場合、回避策は必要ありません。
オブジェクトが一致しない場合は、UPORC チームにお問い合わせください。これは、他の根本的な問題を示している可能性があります。

ノードのアップグレードに失敗しました

バージョン: 1.13.6

症状: ノードのアップグレードが NodeOSInPlaceUpgradeCompleted で失敗しました。

os-upgrade ospolicy ジョブのログを確認します。
ログに構成ファイルが破損していることを示すエラーが含まれている場合は、ノードマシンにアクセスして、ファイルの内容を手動で確認し、破損しているかどうかを確認します。ログエラーには、configparser.DuplicateOptionError エラーコードと /etc/yum.repos.d/gdch.repo ファイルが記載されている場合があります。

回避策: ファイルが破損していることを確認した場合にのみ、破損したノードで破損した /etc/yum.repos.d/gdch.repo ファイルを手動で削除します。

アップグレードの ansible ジョブは、ansible プレイブックの一部としてファイルを自動的に再生成します。

### NodeUpgradeTask CR が NodeOSInPlaceUpgradePostProcessingCompleted 条件のままになる

バージョン: 1.13.5

症状: 1.13.5 へのアップグレード中に、NodeUpgradeTask CR が NodeOSInPlaceUpgradePostProcessingCompleted 条件で停止します。

対応する os-artifact-collector ジョブが完了しているかどうかを確認します。ジョブが数時間停止すると、次のメッセージが表示されます。

  root@gpc-adhoc-7e017e71vm-bootstrapper-zone1:~# kag logs  os-artifact-collector-bm-45942837-p8hrk-z56gh 
  I1020 22:06:11.844634       1 main.go:30] BuildDate: 2024-10-19T16:54:08Z
  I1020 22:06:11.844695       1 main.go:31] Version: 0.0.0-gdch.1.v3f2043

回避策:

ジョブまたは Pod を削除して、再試行を強制します。

`NodeUpgradeTask` CR が `NodeBIOSFirmwareUpgradeCompleted` 条件で停止する

バージョン: 1.13.5

症状: 1.13.5 へのアップグレード中に、NodeUpgradeTask CR が NodeBIOSFirmwareUpgradeCompleted 条件で停止します。

対応する NodeBIOSFirmwareUpgradeCompleted 条件が次の条件でスタックしているかどうかを確認します。

  {
  "lastTransitionTime": "2024-12-03T04:03:37Z",
  "message": "",
  "observedGeneration": 1,
  "reason": "InProgress",
  "status": "False",
  "type": "NodeBIOSFirmwareUpgradeCompleted"
  }

回避策:

NodeUpgrade CR で、"U30 v3.20 (05/29/2024)" を "U30 v3.20 (05/27/2024)" に手動で編集します。

ノードがメンテナンスモードに移行できないため、クラスタのアップグレードがブロックされる

バージョン: 1.13.5、1.13.6、1.13.7

症状: ノードがメンテナンスモードに移行できないため、クラスタ（組織管理者、システム、ユーザークラスタ）のアップグレードがブロックされます。

クラスタでは MaintenanceMode が true に設定されていますが、次のコマンドを実行すると Status が false で停止します。

kubectl get baremetalmachines -A -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,MaintenanceMode:.spec.maintenanceMode,Status:.status.underMaintenace

次の出力が表示されます。

NAMESPACE           NAME            MaintenanceMode   Status
user-vm-1-cluster   10.8.4.22       true              false
user-vm-1-cluster   10.8.4.23       false             false
user-vm-1-cluster   10.8.4.24       false             false
user-vm-1-cluster   172.20.128.13   false             false
user-vm-1-cluster   172.20.128.14   false             false
user-vm-1-cluster   172.20.128.15   false             false

回避策:

KUBECONFIG を、ドレイン解除するノードを含むクラスタの kubeconfig ファイルに設定します。クラスタは、ユーザークラスタまたは共有サービスクラスタのいずれかです。

for VM in $(kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints --no-headers | grep "baremetal.cluster.gke.io/maintenance" | awk '{print $1}'); do
  for i in {1..50}; do
    kubectl delete po -n kube-system $(kubectl get po -A -o wide  | grep ang | grep -e $VM| awk '{print $2}');
  done
done

初期ルート `organizationupgrade` 中の永続的なタイムアウト

バージョン: 1.13.3

症状: 組織のアップグレード中にメンテナンスの時間枠を無視するアノテーションが存在すると、organizationupgrade CR が繰り返しパッチ適用され、進行状況がリセットされます。

回避策:

サブコンポーネント rm-org を一時停止し、rm-org-backend-controller レプリカをスケールダウンします。

エイリアスが宣言されていない場合は、次のコマンドを実行します。
```
alias ka="kubectl --kubeconfig=/root/release/root-admin/root-admin-kubeconfig"
```

サブコンポーネントを一時停止し、rm-org のデプロイをスケールダウンします。

kubectl --kubeconfigROOT_ADMIN_KUBECONFIG annotate subcomponent -n root rm-org lcm.private.gdc.goog/paused=true
kubectl --kubeconfigROOT_ADMIN_KUBECONFIG scale deploy -n gpc-system rm-org-backend-controller --replicas=0

クラスタのアップグレードが完了したら、デプロイをスケールバックします。

kubectl --kubeconfigROOT_ADMIN_KUBECONFIG scale deploy -n gpc-system rm-org-backend-controller --replicas=1

サブコンポーネント `obj-syslog-server` がルート組織で調整に失敗する

バージョン: 1.13.3、1.13.4、1.13.5、1.13.6

現象: バージョン 1.13.x へのアップグレード中に、サブコンポーネント obj-syslog-server が ReconciliationError 状態であることが判明します。

root        obj-syslog-server     ReconciliationError

次のような条件を指定します。

Sub-Component: obj-syslog-server - Reconciliation error: E0100 - deploy: failed to install chart: release obj-syslog-server-backend failed, and has been uninstalled due to atomic being set: context deadline exceeded

Last Transition Time: 2024-09-17T21:49:25Z
     Message: E0100 - deploy: failed to install chart: release obj-syslog-server-backend failed, and has been uninstalled due to atomic being set: context deadline exceeded
     Observed Generation: 1
     ReconciliationError
     Status:True
     Type: Reconciling
     Last Transition Time: 2024-09-17T21:49:23Z
     Message: E0100 - deploy: failed to install chart: release obj-syslog-server-backend failed, and has been uninstalled due to atomic being set: context deadline exceeded
     Observed Generation: 1
     Reason: DeployError
     Status: False
     Type: Deployed

Pod syslog-server-abcdefg-wxyz が CrashLoopBackOff 状態になり、次のエラーが表示されることがあります。

       containerID: containerd://65d460176a1dcae412af698fa02fa5ffb0c5f0ef9bf0d0e2111ef88845630827
       exitCode: 128
       finishedAt: "2024-09-18T19:14:45Z"
       message: 'failed to create containerd task: failed to create shim task: OCI
         runtime create failed: runc create failed: unable to start container process:
         error during container init: error mounting "/var/lib/kubelet/pods/637cf395-e597-446d-9949-1371cca88970/volume-subpaths/observability-ca/syslog-server/2"
         to rootfs at "/etc/ssl/certs/obs-ca-cert.pem": mount /var/lib/kubelet/pods/637cf395-e597-446d-9949-1371cca88970/volume-subpaths/observability-ca/syslog-server/2:/etc/ssl/certs/obs-ca-cert.pem
         (via /proc/self/fd/6), flags: 0x5001: not a directory: unknown'
       reason: StartError
       startedAt: "1970-01-01T00:00:00Z"

回避策:

サブコンポーネントを正常な状態に戻すには、不要な volumeMounts を削除します。

現在のデプロイを編集します。

export KUBECONFIG=/root/release/root-admin/root-admin-kubeconfig

kubectl edit deployments syslog-server -n istio-system

spec.containers.volumeMounts で不要な volumeMounts を削除します。次のマウントパスを削除します。

    - mountPath: /etc/ssl/certs/obs-ca-cert.pem
      name: observability-ca
      readOnly: true1.
      subPath: ca.crt
    - mountPath: /etc/ssl/certs/obj-ca-cert.pem
      name: obj-ca
      readOnly: true
      subPath: ca.crt

変更を適用すると、変更の適用後にサブコンポーネントが ReconciliationCompleted に戻ります。

ABM またはノードのアップグレードが `maintenanceMode false` で停止する

バージョン: 1.13.4

症状: ノードが AnthosBaremetal クラスタのアップグレードで停止し、ノードがメンテナンスモードになりません。

サービスクラスタノードで baremetalmachine を確認します。

kubectl get baremetalmachine -n g-org-1-shared-service-cluster 192.0.2.0 -o json | jq .spec.maintenanceMode
false

回避策:

anthos-cluster-operator を再起動して BMM.MaintenanceMode を伝播します。

kubectl get baremetalmachine -n g-org-1-shared-service-cluster 192.0.2.0 -o json | jq .spec.maintenanceMode
true

テナント組織の atat-webhooks アドオンのアップグレードが失敗する

バージョン: 1.13.5

症状: atat-webhooks アドオンのアップグレードが回復に失敗します。

org-1                                         atat-webhooks                                    false                                        false                                     1.13.4-gdch.5582

次のようなメッセージが表示されることがあります。

Status:                                                                                                                                                                                                        │
│   Conditions:                                                                                                                                                                                                  │
│     Last Transition Time:  2024-10-30T17:57:06Z                                                                                                                                                                │
│     Message:               Error occurred during addon installation: failed to generate parameters for AddOn[atat-webhooks]: failed to generate runtime parameters: parameter job not ready yet                │
│     Observed Generation:   4                                                                                                                                                                                   │
│     Reason:                InstallationError                                                                                                                                                                   │
│     Status:                False                                                                                                                                                                               │
│     Type:                  Deployed                                                                                                                                                                            │
│     Last Transition Time:  2024-10-30T17:56:36Z                                                                                                                                                                │
│     Message:               Reconciliation error

atat-webhooks-parameters-***** の Pod を確認します。

kubectl logs -n org-1 atat-webhooks-parameters-***** --kubeconfig ROOT_ADMIN_KUBECONFIG

次のようなエラーが表示されることがあります。

E1030 22:04:33.242244       7 main.go:39] failed to generate parameter for AddOn [atat-webhooks], error: ATAT0003: Organization.resourcemanager.private.gdc.goog "org-1" is invalid: metadata.labels[atat.config.google.com/task-order-number]: Invalid value: "TO1234": The current date 2024-10-30 is not within the valid range of this TaskOrder: 2024-06-30 - 2024-10-30.

回避策:

現在のポートフォリオのコピーを作成します。

export KUBECONFIG=ROOT_ADMIN_KUBECONFIG

kubectl get portfolios -n atat-system portfolio-org-1 -oyaml > portfolio-org-1

portfolio-org-1 Pop End Date を将来の日付に更新します。
```
kubectl delete portfolios -n atat-system portfolio-org-1
```
このコマンドが応答しなくなった場合は、ポートフォリオを削除する前に、アクティブなポートフォリオから .Metadata.Finalizers 条件を削除します。条件は次のようになります。
```
│     portfolio.finalizers.atat.config.google.com 
```
コピーした YAML ファイルを再度適用します。
```
kubectl apply -f portfolio-org-1
```
日付を再確認して、ポートフォリオと configmap の両方が更新されていることを確認します。
ジョブが復元しない場合は、失敗した atat-webhooks-parameters ジョブを削除すると復元します。完了するまで待ちます。
```
kubectl delete jobs -n org-1 atat-webhooks-parameters
```

`DeadlineExceeded` エラーまたは `BackoffLimitExceeded` エラーが原因で、ポストフライトまたはアップグレードチェックが失敗します。

バージョン: 1.13.8

症状:

1.13.7 から 1.13.8 にアップグレードする際、フライト後のチェックが保留状態のままで、DeadlineExceeded エラーまたは BackoffLimitExceeded エラーが表示される。

Message:postflight check result: pending, [NodeHealth (OS) HarborClusterHealth (AR)] still running 
Observed Generation: 3
Reason: ReconcileBackoff
Status: Unknown 
Type: ManagedCheckSucceeded 
Last Transition Time: 2025-02-13T02:11:41Z
Message: observed the following failure reasons: [ReconcileBackoff UpgradeCheckJobsInProgress]

回避策:

ジョブが失敗している場所を特定します。

プリフライトチェックまたはポストフライトチェック中にジョブが失敗しているかどうかを確認します。

kubectl get jobs -A -l "upgrade.private.gdc.goog/use" -o json | jq '.items[] | select(.status.conditions | any(.reason == "BackoffLimitExceeded" or .reason == "DeadlineExceeded")) | {name: .metadata.name, namespace: .metadata.namespace, status: .status.conditions[].type, reason: .status.conditions[].reason}'

アップグレード中にジョブが失敗しているかどうかを確認します。

kubectl get jobs -A -l "upgrade.private.gdc.goog/upgrade-check-owner" -o json | jq '.items[] | select(.status.conditions | any(.reason == "BackoffLimitExceeded" or .reason == "DeadlineExceeded")) | {name: .metadata.name, namespace: .metadata.namespace, status: .status.conditions[].type, reason: .status.conditions[].reason}'

ジョブを削除します。

kubectl delete jobs -n gpc-system CHECK_NAME

アップグレードチェックにチェックレベルと無関係な結果が含まれる

バージョン: 1.13.x

症状:

他のレベルの結果が誤って含まれているため、組織のアップグレードチェックが失敗することがあります。たとえば、ルート組織のチェックでテナント組織の結果が表示されたり、テナント組織のチェックでユーザークラスタの結果が表示されたりすることがあります。

ルート組織のチェックの失敗ログの例:

kubectl logs -n gpc-system upgrade-check-postflight-haas-n2rk2-zv9rr --kubeconfig /root/release/root-admin/root-admin-kubeconfig
... {org-1 admin } failure ...

回避策:

次のコマンドを使用すると、プリフライトチェックまたはポストフライトチェックを完全にスキップできます。

プリフライト:

kubectl delete organizationupgrade -n gpc-system ORG_NAME && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-preflight-check=ok

Postflight:

kubectl delete organizationupgrade -n gpc-system ORG_NAME && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-postflight-check=ok

Vertex AI

事前トレーニング済みの API は、ユーザーインターフェースで `Enabling` 状態を表示します

バージョン: 1.13.1

症状: ユーザークラスタの作成時に MonitoringTarget に Not Ready ステータスが表示され、事前トレーニング済みの API がユーザーインターフェースで Enabling 状態を継続的に表示します。

回避策:

Chrome ブラウザのメニュー（その他アイコン）を開きます。
[その他のツール] > [デベロッパーツール] をクリックして、コンソールを開きます。
コンソールの [ネットワーク] タブをクリックします。
ai-service-status リクエストを見つけます。
ai-service-status リクエストの [レスポンス] タブをクリックして、そのリクエストの内容を表示します。
MonitoringTarget コンポーネントと LoggingTarget コンポーネントを除き、すべてが準備完了になっていることを確認します。

Speech-to-Text の事前トレーニング済み API 関数 `streaming_recognize` が失敗する

バージョン: 1.13.3

現象: Speech-to-Text の streaming_recognize 事前トレーニング済み API 関数を呼び出すと、クライアントライブラリの問題により、次のような 400 エラーメッセージが表示されます。

google.api_core.exceptions.InvalidArgument: 400 The header 'x-goog-user-project' should be set

回避策: 次の Python スクリプトを使用して、streaming_recognize 関数が動作するようにします。

import base64

from google.cloud import speech_v1p1beta1
from google.cloud.speech_v1p1beta1.services.speech import client
import google.auth
from google.auth.transport import requests
import requests as reqs
from google.api_core.client_options import ClientOptions
import os

audience= "https://ENDPOINT:443"
api_endpoint="ENDPOINT:443"
os.environ["GOOGLE_APPLICATION_CREDENTIALS"] = "APPLICATION_DEFAULT_CREDENTIALS_FILENAME"
os.environ["GRPC_DEFAULT_SSL_ROOTS_FILE_PATH"] = "CERT_NAME"

def get_client(creds):
  opts = ClientOptions(api_endpoint=api_endpoint)
  return client.SpeechClient(credentials=creds, client_options=opts)

def main():
  creds = None
  try:
    creds, project_id = google.auth.default()
    creds = creds.with_gdch_audience(audience)
    sesh = reqs.Session()
    sesh.verify = False
    req = requests.Request(session=sesh)
    creds.refresh(req)
  except Exception as e:
    print("Caught exception" + str(e))
    raise e
  return creds

def speech_func(creds):
  tc = get_client(creds)
  content="[ENCODED CONTENT STRING HERE]"

  audio = speech_v1p1beta1.RecognitionAudio()
  audio.content = base64.standard_b64decode(content)
  config = speech_v1p1beta1.StreamingRecognitionConfig()
  config.config.encoding= speech_v1p1beta1.RecognitionConfig.AudioEncoding.LINEAR16
  config.config.sample_rate_hertz=16000
  config.config.language_code="en-US"
  config.config.audio_channel_count=1

  request_config = speech_v1p1beta1.StreamingRecognizeRequest(
    streaming_config = config,
  )

  request_audio = speech_v1p1beta1.StreamingRecognizeRequest(
    audio_content = audio.content
  )

  requests = [request_config, request_audio]

  def request_generator():
      for request in requests:
          yield request

  metadata = (("x-goog-user-project", "projects/vtx-pretrained"),)
  resp = tc.streaming_recognize(requests=request_generator(), metadata=metadata)

  for response in resp:
    print(response)

if __name__=="__main__":
  creds = main()
  speech_func(creds)

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

ENDPOINT: Speech-to-Text エンドポイント。詳細については、サービスステータスとエンドポイントを表示するをご覧ください。
APPLICATION_DEFAULT_CREDENTIALS_FILENAME: プロジェクトで作成したサービスアカウントキーを含む JSON ファイルの名前（my-service-key.json など）。
CERT_NAME: 認証局（CA）証明書ファイルの名前（org-1-trust-bundle-ca.cert など）。詳細については、開発環境でトラストバンドル CA 証明書ファイルを生成するをご覧ください。

Python スクリプトでは、streaming_recognize の回避策が機能するように、streaming_recognize 関数と recognize 関数の間に次の違いを導入しています。

4 行目: recognize スクリプト（from google.cloud.speech_v1p1beta1.services.speech import client）と比較して、import ステートメントが追加されています。
18 行目: クライアントは speech_v1p1beta1.SpeechClient() ではなく client.SpeechClient() によって返されます。

Translation フロントエンドの Pod とサービスが初期化に失敗する

バージョン: 1.11.x、1.12.x、1.13.x

症状: アップグレード中に Translation DB クラスタが再作成されるため、ODS システムクラスタの secret-store シークレットが古くなり、同期しなくなります。そのため、Translation フロントエンドの Pod とサービスは初期化に失敗します。

回避策:

システムクラスタ内のシークレットを削除します。

kubectl --kubeconfig SYSTEM_CLUSTER_KUBECONFIG delete secret postgres-secret-store -n ai-translation-system

SYSTEM_CLUSTER_KUBECONFIG は、システムクラスタ内の kubeconfig ファイルのパスに置き換えます。

コントローラはシークレットを自動的に再作成し、DB クラスタと再同期します。

`batchTranslateDocument` API ではジョブステータスのポーリングはサポートされていません

バージョン: 1.13.3

症状: Vertex AI は、Translation サービス API の GET オペレーションと LIST オペレーションをサポートしていません。Translation BatchTranslateDocument API を呼び出すと、次の例のような長時間実行オペレーションが返されます。

{
  "name": "projects/PROJECT_ID/operations/OPERATION_ID",
  "metadata": {
    "@type": "type.googleapis.com/google.cloud.translation.v3.BatchTranslateDocumentMetadata",
    "state": "RUNNING"
  }
}

この問題は、エンドポイントを直接呼び出すことができない APIP（承認）の制限によるものです。エンドポイントはジョブステータスのポーリングをサポートしていません。また、APIP の制限により、長時間実行オペレーションで GET オペレーションを実行できません。

回避策: アプリケーションオペレーター（AO）として、s3_destination フォルダを定期的に確認し、新しく作成されたジョブ出力ファイルを探して、ジョブのステータスを確認します。フォルダに出力ファイルが含まれている場合、ジョブは正常に完了しています。

`batchTranslateDocument` リクエストが原因でパフォーマンスの問題が発生する可能性がある

バージョン: 1.13.3

現象: バッチドキュメント翻訳サービスは、1 つ以上のユーザー入力ファイルを読み取り、一時処理ファイルと翻訳された出力ファイルを StorageGRID に書き込みます。クライアントの再利用が失敗するため、読み取り / 書き込みアクションごとに新しい curl クライアントが作成されます。

バイナリ内の S3 curl クライアントは 1 回限りの使用です。つまり、各クライアントは StorageGRID バケットに対して 1 回の読み取り / 書き込みアクションのみを実行できます。そのため、batchTranslateDocument サーバーから StorageGRID クライアントとの通信が確立され、バケット内のファイルの読み取りと書き込みが行われるたびに、新しい curl クライアントが作成されます。

ただし、これは curl クライアントには最適ではありません。次のような問題が発生する可能性があります。

パフォーマンスの低下: レイテンシの増加とスループットの低下
リソースの枯渇: メモリと CPU のオーバーヘッド、ソケットの枯渇
サーバーの過負荷: レート制限またはスロットリング

事前トレーニング済み API を有効にした後、GDC コンソールに一貫性のないステータスが表示される

バージョン: 1.13.3

現象: 事前トレーニング済み API を初めて有効にすると、有効にしたサービスについて、数分後に GDC コンソールに一貫性のないステータスが表示されることがあります。GDC コンソールは Enabling 状態を Disabled に戻し、サービスが実際に有効になっている場合でも、ユーザーインターフェースに [有効にする] ボタンを再び表示します。

回避策: 数分後にステータスが整合し、サービスに正しいステータスが反映されます。

サービスのステータスを確認するには、ブラウザコンソールの [ネットワーク] タブを開き、ai-service-status リクエストのステータスを確認します。ペイロードには、L2 オペレーターが有効になっていることが示されている必要があります。

250 文字を超える変換リクエストで `translation-prediction-server` Pod がクラッシュする

バージョン: 1.13.3

現象: 約 250 文字以上の翻訳リクエスト（ドキュメント翻訳リクエストを含む）を送信すると、translation-prediction-0 または translation-prediction-1 Pod がクラッシュし、モデルの再読み込みが必要になることがあります。モデルの再読み込みは自動的に行われ、この処理が完了するまで 30 分ほどかかることがあります。

この問題は、Translation コンテナの制限が原因で発生します。

回避策: 変換リクエストを 250 文字未満になるように分割します。200 ～ 250 文字の範囲であれば、どの言語でも安全です。長いリクエストによって Pod がクラッシュした場合、問題を軽減するために他の対応は必要ありません。

共有サービスクラスタの `GPUAllocation` が正しく構成されていない

バージョン: 1.13.3

症状: 十分な GPU リソースがないため、Vertex AI ワークロードをスケジュールできません。たとえば、Vertex AI サービスエンドポイントを表示または有効にできない場合は、十分な GPU リソースがないことが原因である可能性があります。

このリソースの問題は、共有サービスクラスタ内にある一部の GPUAllocation リソースに次のアノテーションがないことが原因で発生する可能性があります。

processed: "true"

回避策:

IAM-R0004 に沿って、g-ORG_NAME-shared-service-cluster の kubeconfig ファイルを生成します。

processed: "true" アノテーションのないサービスクラスタ内のすべての GPU 割り当てを一覧表示します。

kubectl get gpuallocations -A -n vm-system \
    --kubeconfig SERVICE_CLUSTER_KUBECONFIG \
    -o json | jq \
    '.items[] | select(.metadata.annotations.processed == null ) | .metadata.name'

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

zi-ad-bm08

割り当てられていない GPUAllocation リソースをエディタで開きます。
```
kubectl edit gpuallocation -n vm-system NODE_NAME
```
サービスクラスタに存在する GPU 割り当ての合計数に基づいて、GPU 割り当てを編集します。
- GPU 割り当てカスタムリソースが 1 つしかない場合は、それに processed: "true" アノテーションを追加し、次のように仕様を変更します。
```
annotations:
  processed: "true"
spec:
  mig:
    allowNodeReboot: true
    count: 4
    profiles:
    - mixed-5
    - uniform-3g.40gb
    - uniform-3g.40gb
    - uniform-7g.80gb
  node: $node_name // unchanged
  pod: 0
  vm: 0
```
- GPU 割り当てカスタムリソースが 2 つある場合は、processed: "true" アノテーションのないリソースを見つけて processed: "true" アノテーションを追加し、次のように仕様を変更します。
```
annotations:
  processed: "true"
spec:
  mig:
    allowNodeReboot: true
    count: 2
    profiles:
    - mixed-5
    - uniform-3g.40gb
  node: $node_name // unchanged
  pod: 0
  vm: 0
```
- GPU 割り当てカスタムリソースが 4 つある場合は、processed: "true" アノテーションのないリソースを見つけて processed: "true" アノテーションを追加し、次のように仕様を変更します。
```
annotations:
  processed: "true"
spec:
  mig:
    allowNodeReboot: true
    count: 1
    profiles:
    - mixed-5
  node: $node_name // unchanged
  pod: 0
  vm: 0
```

GPUAllocation カスタムリソースに対する変更を保存し、割り当てステータスが true に更新されたことを確認します。

kubectl get gpuallocations -A --kubeconfig SERVICE_CLUSTER_KUBECONFIG

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

NAMESPACE   NAME         ALLOCATED   DEVICEMODEL
vm-system   zi-ad-bm08   true        H100L 94GB
vm-system   zi-ad-bm09   true        H100L 94GB

バージョン 1.9.x から 1.13.3 にアップグレードすると、OCLCM コントローラにエラーが表示される

バージョン: 1.13.3

現象: バージョン 1.9.x から 1.13.3 にアップグレードすると、Vertex AI サブコンポーネントの Operable Component Lifecycle Management（OCLCM）コントローラでエラーが表示されることがあります。この問題は、ai_platform アドオンジョブのエラーが原因で発生します。アップグレード中に発生したエラーは、OCLCM がこれらの Vertex AI コンポーネントの所有権を移転できないことを示しています。

組織管理クラスタで影響を受ける Vertex AI コンポーネントは次のとおりです。

名前	名前空間
`aip-l1operator-deployment`	`ai-system`
`aip-l2operator-deployment`	`ai-system`
`aip-web-plugin-frontend`	`ai-system`
`aip-web-plugin-backend`	`ai-system`
`aip-l1operator-sa`	`ai-system`
`aip-l2operator-sa`	`ai-system`
`aip-web-plugin-sa`	`ai-system`
`aip-l1operator-role`	なし
`aip-l2operator-role`	なし
`aip-web-plugin-role`	なし
`aip-l1operator-rolebinding`	なし
`aip-l2operator-rolebinding`	なし
`aip-web-plugin-rolebinding`	なし
`aip-l1operator-log`	`ai-system`
`aip-l2operator-log`	`ai-system`
`aip-web-plugin-frontend-log`	`ai-system`
`aip-web-plugin-backend-log`	`ai-system`
`log-rule-aipl-a004`	`platform-obs`
`mon-rule-aipl-a0001`	`platform-obs`
`mon-rule-aipl-a0003`	`platform-obs`
`aip-l1operator-mon`	`ai-system`
`aip-l1operator-mon-cm`	`ai-system`
`aip-l2operator-mon`	`ai-system`
`aip-l2operator-mon-cm`	`ai-system`
`aip-l1operator-webhook-svc`	`ai-system`
`aip-web-plugin-frontend-svc`	`ai-system`
`aip-web-plugin-backend-svc`	`ai-system`
`aip-web-plugin-frontend-virtualsvc`	`ai-system`
`aip-web-plugin-backend-virtualsvc`	`ai-system`
`aip-l1operator-selfsigned-issuer`	`ai-system`
`aip-l1operator-serving-cert`	`ai-system`
`aip-l1operator-validating-webhook`	`ai-system`
`aip-l1operator-mutating-webhook`	`ai-system`

回避策: この問題を解決するには、影響を受ける Vertex AI コンポーネントを組織管理者クラスタから手動で削除する必要があります。その後、Vertex AI の新しい OCLCM ベースのバージョンが再インストールします。

組織管理クラスタで影響を受ける Vertex AI コンポーネントを手動で削除します。

kubectl --kubeconfig=ORG_ADMIN_CLUSTER_KUBECONFIG delete deployment -n NAMESPACE COMPONENT_NAME

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

ORG_ADMIN_CLUSTER_KUBECONFIG: 組織管理クラスタの kubeconfig ファイルへのパス。
NAMESPACE: 削除する Vertex AI コンポーネントの名前空間。コンポーネントに Namespace がない場合は、コマンドから -n NAMESPACE を削除します。
COMPONENT_NAME: 削除する Vertex AI コンポーネントの名前。

次の例は、組織管理クラスタの ai-system Namespace に存在する aip-l1operator-deployment コンポーネントを削除する方法を示しています。

kubectl --kubeconfig=ORG-ADMIN-CLUSTER-KUBECONFIG delete deployment -n ai-system aip-l1operator-deployment

翻訳リクエストで `RESOURCE_EXHAUSTED` エラーコードが生成されることがある

バージョン: 1.13.3

現象: 変換リクエストを送信した後、レスポンスメッセージで RESOURCE_EXHAUSTED エラーコードが返されます。このエラーは、システム周波数の上限を超えた場合に発生します。ユーザーごとの割り当て、1 秒あたりの最大クエリ数、ファイルシステム全体で容量が不足しているなど、リソースが枯渇しています。

回避策: インフラストラクチャオペレーター（IO）に、翻訳サービスバックエンドシャードの再起動を依頼します。次に、リクエスト間の遅延を長くするか、リクエストを短くして、変換リクエストを再度送信します。

`batchTranslateDocument` リクエストがエラー `503` を返す

バージョン: 1.13.3

現象: batchTranslateDocument リクエストを送信した後、レスポンスメッセージで 503 "Batch Document translation is not implemented" エラーコードが返されます。このエラーは、BatchTranslateDocument メソッドで Aspose サービスが必要になることが原因で発生します。Aspose サービスは、クラスタで enableRAG 操作可能パラメータが true に設定されている場合にのみデプロイされます。

回避策: インフラストラクチャオペレーター（IO）に、次の手順に沿って組織管理クラスタで enableRAG 操作可能パラメータを true に設定してもらいます。

enableRAG 操作可能パラメータが true に設定された vai-translation.yaml という名前の YAML ファイルに SubcomponentOverride カスタムリソースを作成します。
```
apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: "vai-translation"
  namespace: ORG_ADMIN_NAMESPACE
spec:
  subComponentRef: "vai-translation"
  backend:
    operableParameters:
      enableRAG: true
```
ORG_ADMIN_NAMESPACE は、組織管理者クラスタの Namespace に置き換えます。
SubcomponentOverride カスタムリソースを組織管理クラスタに適用します。
```
kubectl --kubeconfig ORG_ADMIN_KUBECONFIG apply -f vai-translation.yaml
```
ORG_ADMIN_KUBECONFIG は、組織管理クラスタ内の kubeconfig ファイルのパスに置き換えます。

Vertex AI 事前トレーニング済みサービスが利用できない

バージョン: 1.13.7、1.13.9

症状: Kubernetes のスケジューリングの問題により、Vertex AI OCR サービスと Translation サービスが起動しません。ログに次のような警告が表示されることがあります。

 Warning  FailedScheduling  105s (x40 over 3h18m)  default-scheduler  0/9 nodes are available: 1 Insufficient nvidia.com/mig-3g.40gb-NVIDIA_A100_80GB_PCIE, 1 node(s) had untolerated taint {serviceenvironment.private.gdc.goog/dbs-billing-
system-billing-dbcluster: }, 1 node(s) had untolerated taint {serviceenvironment.private.gdc.goog/dbs-g-vai-ocr-sie-g-vai-ocr-sie: }, 1 node(s) had untolerated taint {serviceenvironment.private.gdc.goog/dbs-g-vai-translation-sie-g-v-1gvg:
 }, 3 Insufficient cpu, 3 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }. preemption: 0/9 nodes are available: 3 No preemption victims found for incoming pod, 6 Preemption is not helpful for scheduling.

回避策: デフォルトプールにワーカーノードを追加し、GPU ノードの Pod を強制排除して、AI ワークロードをスケジュールできるようにします。

仮想マシン

qcow2 イメージと raw イメージの BYO イメージのインポートが失敗する

バージョン: 1.13.1、1.13.3

現象: gdcloud compute images import CLI を使用してローカル VM イメージをインポートすると、インポートステータスが WaitingForTranslationVM または ImportJobNotCreated のままになります。これは、変換またはインポート用に作成された一時ディスクが qcow2/raw イメージとまったく同じサイズを使用するのに対し、LUKS は数 MiB のオーバーヘッドを追加するため、ディスクプロビジョニングが失敗するためです。

回避策:

同じイメージ名で、より大きな spec.minimumDiskSize を使用して、新しい VirtualMachineImageImport を手動で作成します。

たとえば、イメージのインポートに使用されたコマンドが次のとおりだったとします。

gdcloud compute images import $IMPORT_NAME --project $PROJECT --source-file=$LOCAL_FILENAME --os=$OS

CLI によって自動的に作成された元の VirtualMachineImageImport の X が minimumDiskSize Gi の場合は、X+1 Gi で新しい VirtualMachineImageImport を作成します。値は、インポートするイメージのサイズに基づきます。qcow2 の場合は仮想サイズになります。たとえば、20Gi は 21Gi に置き換えます。

CLI の呼び出し方法に基づいて、プレースホルダの値を置き換えます。

VirtualMachineImageImport を見つけます。
```
kubectl get virtualmachineimageimport $IMPORT_NAME -n $PROJECT -o yaml
```
オブジェクトが存在しない場合は、gdcloud compute images import ... コマンドを再度トリガーします。コンソール出力が Uploading image to .. から Image import has started for ... に移行したら、Ctrl+C キーを押して、ローカルイメージがオブジェクトストレージにアップロードされ、新しいイメージを作成するための参照として VirtualMachineImageImport が保持されるようにします。

より大きな minimumDiskSize を使用して新しい VirtualMachineImageImport を作成します。

apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineImageImport
metadata:
  name: $IMPORT_NAME_NEW
  namespace: $NAMESPACE
spec:
  imageMetadata:
    minimumDiskSize: $NEW_SIZE
    name: $IMAGE_NAME
    operatingSystem: $OS
  source:
    objectStorage:
      bucketRef:
        name: vm-images-bucket
      objectName: $LOCAL_FILENAME

イメージからのディスクのプロビジョニングが失敗する

バージョン: 1.13.1、1.13.3

症状: カスタムイメージからディスクをプロビジョニングするときに、minimumDiskSize が仮想サイズに近すぎるため、ディスクのプロビジョニングが失敗することがあります。VM ディスクが保留状態のままで、プロビジョニングされない。

回避策: より大きな spec.minimumDiskSize を使用して、新しいディスクを手動で作成します。

クラスタに GPU がある場合、NVIDIA デバイスプラグイン `DaemonSet` が失敗する

バージョン: 1.13.3

現象: GPU を搭載したクラスタノードで、NVIDIA デバイスプラグイン DaemonSet が driver rpc error メッセージで失敗します。

kubectl --kubeconfig KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system

KUBECONFIG は、クラスタ内の kubeconfig ファイルのパスに置き換えます。

次のような出力が得られます。

Warning  Failed     23m (x4 over 25m)  kubelet            Error: failed to create containerd task: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error running hook #0: error running hook: exit status 1, stdout: , stderr: Auto-detected mode as 'legacy'
nvidia-container-cli: initialization error: driver rpc error: timed out: unknown

この問題により、仮想マシン（VM）と Pod で GPU を使用できなくなります。影響は、次のクラスタタイプに基づいています。

システムクラスタ: そのベアメタルノードに対して GPUAllocation カスタムリソースが作成されず、そのノードの GPU はサービスクラスタとユーザークラスタで使用するために VM モードで構成されません。この問題を解決するには、システムクラスタの回避策をご覧ください。
サービスクラスタまたはユーザークラスタ: その VM ノードに対して GPUAllocation カスタムリソースが作成されず、そのノードの GPU はクラスタ上の Pod で使用できません。この問題を解決するには、サービスまたはユーザークラスタの回避策をご覧ください。

システムクラスタの回避策:

システムクラスタの問題を解決するには、次の手順を行います。

KUBECONFIG 環境変数に、システムクラスタ内の kubeconfig ファイルのパスを設定します。詳細については、IAM-R0004 ランブックをご覧ください。
問題が発生しているノードを特定します。
```
kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system  | grep -i Node:
```
出力には、ノード名と Kubernetes ノードの IP アドレスが表示されます。

複数のノードがある場合は、すべてのノードで手順を実行します。この場合、出力は次の例のようになります。
```
Node:                 yy-ab-bm04/172.20.128.26
```
ノード名を使用して NODE_NAME 環境変数を設定します。次に例を示します。
```
export NODE_NAME=yy-ab-bm04
```
ノードとの SSH 接続を確立します。詳細については、PLATAUTH-G0001 ランブックをご覧ください。

注: 管理ノードの IP アドレスは、前のコマンドの IP アドレスとは異なります。ランブックに記載されている管理ノードの IP アドレスを使用します。

ノードに GPU があることを確認します。

nvidia-smi -L

出力には、次の例のようにノード内の GPU が出力されます。

GPU 0: NVIDIA H100 NVL (UUID: GPU-0f6179a7-71a8-c654-44f0-1542bddf2574)
GPU 1: NVIDIA H100 NVL (UUID: GPU-4debf794-d8a5-74a2-e521-0c763288ea79)
GPU 2: NVIDIA H100 NVL (UUID: GPU-5827b65a-3841-d877-fc17-881a2b71d416)
GPU 3: NVIDIA H100 NVL (UUID: GPU-31448904-9ae2-c95a-1986-a56cce004f49)

GPU で永続モードを有効にします。
```
nvidia-smi -pm 1
```
このアクションにより、NVIDIA ドライバが常に読み込まれ、デバイスプラグインがタイムアウトしないようにします。

出力は次の例のようになります。
```
Enabled persistence mode for GPU 00000000:4E:00.0.
Enabled persistence mode for GPU 00000000:62:00.0.
Enabled persistence mode for GPU 00000000:C9:00.0.
Enabled persistence mode for GPU 00000000:DE:00.0.
All done.
```
注: 永続モードは現在の起動で有効になっています。この操作は、次回の再起動時に元に戻ります。再起動してもこの問題が解決しない場合は、上記の手順をもう一度行ってください。
SSH セッションを終了します。
```
exit
```
DaemonSet をクエリして、デバイスプラグインが実行されていることを確認します。
```
kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system
```

GPUAllocation カスタムリソースが作成され、VM モードで構成されていることを確認します。

kubectl --kubeconfig $KUEBCONFIG get gpuallocation -n vm-system $NODE_NAME -o yaml

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

apiVersion: gpu.cluster.gke.io/v1
kind: GPUAllocation
metadata:
  annotations:
    processed: "true"
  creationTimestamp: "2024-08-21T07:03:18Z"
  generation: 2
  name: yy-ab-bm04
  namespace: vm-system
  resourceVersion: "12179728"
  uid: b840cb53-5b0b-45bf-ab26-66db98fd64a4
spec:
  node: yy-ab-bm04
  pod: 0
  vm: 4
status:
  allocated: true
  conditions:
  - lastTransitionTime: "2024-08-21T07:05:49Z"
    message: ""
    observedGeneration: 2
    reason: AllocationFulfilled
    status: "True"
    type: AllocationStatus
  - lastTransitionTime: "2024-08-21T07:03:53Z"
    message: ""
    observedGeneration: 2
    reason: DeviceStateUpdated
    status: "True"
    type: DeviceStateUpdated
  consumption:
    pod: 0/0
    vm: 4/4
  deviceModel: H100L 94GB

サービスクラスタまたはユーザークラスタの回避策:

サービスまたはクラスタの問題を解決するには、次の手順を行います。

サービスクラスタまたはユーザークラスタの kubeconfig ファイルのパスを使用して KUBECONFIG 環境変数を設定します。詳細については、IAM-R0004 ランブックをご覧ください。
問題が発生しているノードを特定します。
```
kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system  | grep -i Node:
```
出力には、ノード名と Kubernetes ノードの IP アドレスが表示されます。

複数のノードがある場合は、すべてのノードで手順を実行します。この場合、出力は次の例のようになります。
```
Node:                 vm-948fa7f4/172.20.128.21
```
ノード名を使用して NODE_NAME 環境変数を設定します。次に例を示します。
```
export NODE_NAME=vm-948fa7f4
```
ノードとの SSH 接続を確立します。詳細については、PLATAUTH-G0001 ランブックをご覧ください。

注: 管理ノードの IP アドレスは、前のコマンドの IP アドレスとは異なります。ランブックに記載されている管理ノードの IP アドレスを使用します。

ノードに GPU があることを確認します。

nvidia-smi -L

出力には、次の例のようにノード内の GPU が出力されます。

GPU 0: NVIDIA H100 NVL (UUID: GPU-0f6179a7-71a8-c654-44f0-1542bddf2574)
GPU 1: NVIDIA H100 NVL (UUID: GPU-4debf794-d8a5-74a2-e521-0c763288ea79)

GPU で永続モードを有効にします。
```
nvidia-smi -pm 1
```
このアクションにより、NVIDIA ドライバが常に読み込まれ、デバイスプラグインがタイムアウトしないようにします。

出力は次の例のようになります。
```
Enabled persistence mode for GPU 00000000:05:00.0.
Enabled persistence mode for GPU 00000000:06:00.0.
All done.
```
注: 永続モードは現在の起動で有効になっています。この操作は、次回の再起動時に元に戻ります。再起動してもこの問題が解決しない場合は、上記の手順をもう一度行ってください。
SSH セッションを終了します。
```
exit
```
DaemonSet をクエリして、デバイスプラグインが実行されていることを確認します。
```
kubectl --kubeconfig $KUBECONFIG describe pods -lgpu-device-plugin=nvidia -n vm-system
```

GPUAllocation カスタムリソースが作成され、VM モードで構成されていることを確認します。

kubectl --kubeconfig $KUBECONFIG get gpuallocation -n vm-system $NODE_NAME -o yaml

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

apiVersion: gpu.cluster.gke.io/v1
kind: GPUAllocation
metadata:
  annotations:
    processed: "true"
  creationTimestamp: "2024-08-21T07:03:18Z"
  generation: 2
  name: vm-948fa7f4
  namespace: vm-system
  resourceVersion: "12179728"
  uid: b840cb53-5b0b-45bf-ab26-66db98fd64a4
spec:
  node: vm-948fa7f4
  pod: 2
  vm: 0
status:
  allocated: true
  conditions:
  - lastTransitionTime: "2024-08-21T07:05:49Z"
    message: ""
    observedGeneration: 2
    reason: AllocationFulfilled
    status: "True"
    type: AllocationStatus
  - lastTransitionTime: "2024-08-21T07:03:53Z"
    message: ""
    observedGeneration: 2
    reason: DeviceStateUpdated
    status: "True"
    type: DeviceStateUpdated
  consumption:
    pod: 0/2
    vm: 0/0
  deviceModel: H100L 94GB

システムクラスタ VM の準備ができていない

バージョン: 1.13.3

事象: システムクラスタ VM の準備ができていません。次のようなメッセージが表示されることがあります。

│ Conditions:                                                                                                                                   │
│   Type                          Status    LastHeartbeatTime                 LastTransitionTime                Reason                          │
│  Message                                                                                                                                      │
│   ----                          ------    -----------------                 ------------------                ------                          │
│  -------                                                                                                                                      │
│   KubeletUnhealthy              False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:37 +0000   KubeletIsHealthy                │
│  kubelet on the node is functioning properly                                                                                                  │
│   KernelDeadlock                False     Tue, 20 Aug 2024 02:10:42 +0000   Sun, 30 Jun 2024 16:53:33 +0000   KernelHasNoDeadlock             │
│  kernel has no deadlock                                                                                                                       │
│   ReadonlyFilesystem            False     Tue, 20 Aug 2024 02:10:42 +0000   Sun, 30 Jun 2024 16:53:33 +0000   FilesystemIsNotReadOnly         │
│  Filesystem is not read-only                                                                                                                  │
│   FrequentUnregisterNetDevice   False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:40 +0000   NoFrequentUnregisterNetDevice   │
│  node is functioning properly                                                                                                                 │
│   ContainerRuntimeUnhealthy     False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:39 +0000   ContainerRuntimeIsHealthy       │
│  Container runtime on the node is functioning properly                                                                                        │
│   FrequentKubeletRestart        False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:41 +0000   NoFrequentKubeletRestart        │
│  kubelet is functioning properly                                                                                                              │
│   FrequentDockerRestart         False     Tue, 20 Aug 2024 02:10:42 +0000   Tue, 20 Aug 2024 02:10:40 +0000   NoFrequentDockerRestart         │
│  docker is functioning properly                                                                                                               │
│   FrequentContainerdRestart     False     Tue, 20 Aug 2024 02:10:42 +0000   Thu, 15 Aug 2024 01:44:23 +0000   NoFrequentContainerdRestart     │
│  containerd is functioning properly                                                                                                           │
│   MemoryPressure                Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.                                                                                                         │
│   DiskPressure                  Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.                                                                                                         │
│   PIDPressure                   Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.                                                                                                         │
│   Ready                         Unknown   Tue, 20 Aug 2024 01:25:55 +0000   Tue, 20 Aug 2024 01:27:22 +0000   NodeStatusUnknown               │
│  Kubelet stopped posting node status.

回避策:

VirtualMachineInstance を見つけて削除します。
新しい VM を再起動します。

データ量のレポートでスクラッチスペースが見つからない

バージョン: 1.13.3、1.13.4

現象: VM ディスクの作成時に、データボリュームが成功として報告されます。

gdch-vm-infra   gdc-vm-disk-vm-ce34b8ea-disk   Succeeded   100.0%     1          18h

ただし、importer-gdc-vm-disk-vm-ce34b8ea-disk などのインポーター Pod が次のようなメッセージでクラッシュループします。

E0823 16:14:15.920008       1 data-processor.go:251] scratch space required and none found
E0823 16:14:15.920017       1 importer.go:185] scratch space required and none found

回避策: データ量のステータスが Succeeded であることを確認してから、インポーター Pod を削除します。

名前が 45 文字を超えるプロジェクト内の VM は停止状態のままになる

バージョン: 1.13.5

現象: VM の作成時に、プロジェクト名が 45 文字を超えると、VM が Stopped 状態のままになります。

回避策: 45 文字以内の名前でプロジェクトを作成します。

サービスクラスタで GPU の割り当てが不足している

バージョン: 1.13.5

症状: gpu-org の共有サービスクラスタに GPUAllocation がありません。GPU 割り当てを取得するときに、次のメッセージが表示されることがあります。

KUBECONFIG=/root/release/user/gpu-org-shared-service-kubeconfig kubectl get gpuallocations -A

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

No resources found

回避策:

GPU ノードに taint を追加します。

taints:
  - effect: NoExecute
    key: vmm.gdc.goog/gpu-node
    value: a3-highgpu-4g

VM virt-launcher Pod のスケジューリングを許可するように、Taint を削除します。

共有サービスクラスタのワーカー VM をスケジュールできない

バージョン: 1.13.6

症状: 指定されたノードに十分な CPU リソースがないため、使用可能な GPU があるにもかかわらず、Kubernetes ワーカー VM のスケジュール設定に失敗しました。次のようなイベントが表示されることがあります。

Warning  FailedScheduling  33m (x29 over 92m)    default-scheduler  0/9 nodes are available: 1 Insufficient memory, 3 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }, 5 Insufficient cpu, 5 Insufficient nvidia.com/gpu-vm-H100L_94GB. preemption: 0/
9 nodes are available: 3 Preemption is not helpful for scheduling, 6 No preemption victims found for incoming pod.

回避策:

GPU を使用しない VM を手動で停止して、CPU リソースを解放します。
保留中の VM がスケジュールされたら、GPU 以外の VM を起動します。

Google Distributed Cloud エアギャップ 1.13.x の既知の問題 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

Artifact Registry

サブコンポーネント sar-failoverregistry の調整エラー

バックアップと復元

ボリューム容量の不足によりスナップショットが失敗する

メモリ不足のため、エージェント Pod とコントロール プレーン Pod が再起動する

PVC スナップショットのバックアップが失敗する

SVM 割り当てと互換性のないバックアップからの復元

課金

請求先ダッシュボードに請求先指標が正しく表示されない

検証 Webhook のバグのため、ユーザーが BillingAccountBinding を作成できない

ブロック ストレージ

ボリューム マウント エラーのため、Grafana Pod が Init 状態のままになる。

仮想マシン ランチャー Pod がボリュームをマッピングできない

ストレージ関連の障害

サイズが正しくない永続ボリュームが作成される

ストレージ仮想マシンを削除できない

組織を無効にしてもリソースはクリーンアップされない

削除の調整の失敗

ベアメタルのアップグレードが停止する

Trident のマルチアタッチ エラー

IPsec 構成のエラー

ストレージ仮想マシンが作成されない

ストレージ クラスタ間ネットワークの調整に失敗する

クラスタ管理

クラスタのプロビジョニング中に machine-init ジョブが失敗する

サービス クラスタからオブジェクト ストレージ バケットへの接続がない

プリフライト チェックが失敗する

ユーザー クラスタのワーカーノードプールの作成が失敗する

再作成されたユーザー クラスタが、不適切なクリーンアップにより調整で停止することがある

データベース サービス

AlloyDB Omni データベースのクローン作成が停止する

IOPS の適用がストレージ パフォーマンスに影響する

dbs-fleet サブコンポーネントのアップグレード時の調整エラー

DBCluster の作成に失敗する

DNS

DNSSEC は resolved.conf で明示的にオフにする必要があります

港湾サービス

Harbor サービスの作成に失敗しました

Harbor インスタンスを削除しても、関連付けられたレジストリ ミラーは削除されない

ハードウェア セキュリティ モジュール

HSM の無効化されたトライアル ライセンスは検出可能

HSM ホストデーモン ファイル記述子のリーク

HSM 証明書の有効期限が切れている

ID とアクセスの管理

opa-system Namespace の gatekeeper-audit Pod が頻繁に再起動する

Infrastructure as Code（IAC）

GitLab トークンの過剰な作成により、GitLab データベースが満杯になるリスクがある

鍵管理システム（KMS）

ルートキーのタイプを変更すると、既存のキーがすべて無効になります

kms-rootkey-controller CrashLoopBackOff（OOMKILL）

ロギング

オブジェクト ストレージ監査ロガーが DNS ホストを解決できない

HaaS Logger がルート管理クラスタでエラーを表示する

Santricity Logger が失敗する

ロギング ターゲットのログが間違ったプロジェクトに送信される

プラットフォーム Namespace の監査ログは PA に表示されない

Pod がコンテナの初期化に失敗する

Marketplace

Prisma Cloud イメージの pull が失敗する

モニタリング

ServiceNow で大量のアラートが作成される

ServiceNow で重複するアラートが複数作成される

Vertex AI 指標を表示できない

mon-cortex の調整エラー

システム クラスタの metrics-server-exporter Pod がクラッシュ ループしている

ObservabilityPipeline の調整エラー メッセージを無視する

mon-prober-backend-prometheus-config ConfigMap がリセットされる

Cortex ストア ゲートウェイ コンポーネントの OOMKilled crashloop

ユーザー クラスタで Kube コントロール プレーン指標プロキシ イメージのプル バックオフが発生する

WAL の増加により、Prometheus が大量のメモリを使用する

マルチゾーン ブートストラップ

クラスタロールがない

互換性のない Bootstrap リソース

GlobalAPIZone リソースがグローバル API に作成されない

ネットワーキング

Object Storage Nodes Grid Network down

ノードに到達できない

ClusterCIDRConfig が作成されても PodCIDR がノードに割り当てられない

NTP のドリフト

Google Distributed Cloud エアギャップ 1.13.x の既知の問題

サブコンポーネント `sar-failoverregistry` の調整エラー

メモリ不足のため、エージェント Pod とコントロールプレーン Pod が再起動する

検証 Webhook のバグのため、ユーザーが `BillingAccountBinding` を作成できない

ブロックストレージ

ボリュームマウントエラーのため、Grafana Pod が `Init` 状態のままになる。

仮想マシンランチャー Pod がボリュームをマッピングできない

Trident のマルチアタッチエラー

ストレージクラスタ間ネットワークの調整に失敗する

クラスタのプロビジョニング中に `machine-init` ジョブが失敗する

サービスクラスタからオブジェクトストレージバケットへの接続がない

プリフライトチェックが失敗する

ユーザークラスタのワーカーノードプールの作成が失敗する

再作成されたユーザークラスタが、不適切なクリーンアップにより調整で停止することがある

データベースサービス

IOPS の適用がストレージパフォーマンスに影響する

`dbs-fleet` サブコンポーネントのアップグレード時の調整エラー

Harbor インスタンスを削除しても、関連付けられたレジストリミラーは削除されない

ハードウェアセキュリティモジュール

HSM の無効化されたトライアルライセンスは検出可能

HSM ホストデーモンファイル記述子のリーク

`opa-system` Namespace の `gatekeeper-audit` Pod が頻繁に再起動する

`kms-rootkey-controller` `CrashLoopBackOff`（`OOMKILL`）

オブジェクトストレージ監査ロガーが DNS ホストを解決できない

ロギングターゲットのログが間違ったプロジェクトに送信される

`mon-cortex` の調整エラー

システムクラスタの `metrics-server-exporter` Pod がクラッシュループしている

`ObservabilityPipeline` の調整エラーメッセージを無視する

`mon-prober-backend-prometheus-config` ConfigMap がリセットされる

Cortex ストアゲートウェイコンポーネントの OOMKilled crashloop

ユーザークラスタで Kube コントロールプレーン指標プロキシイメージのプルバックオフが発生する

マルチゾーンブートストラップ

互換性のない `Bootstrap` リソース

`GlobalAPIZone` リソースがグローバル API に作成されない

`ClusterCIDRConfig` が作成されても `PodCIDR` がノードに割り当てられない

クラスタメッシュがゾーン情報で構成されていない

上部のネットワーキングコントロールプレーンダッシュボードにデータが表示されない

ネットワークインストールで表示されるミスリードエラー

オブジェクトストレージ

一部のオブジェクトストレージのアップグレード警告は無視できます

`ObjectStorageStorageNodeReconciler` レポート `maintenance.gdu.gdu_server_locked`

Postflight 1.12.x -> 1.13.x アップグレードのオブジェクトストレージチェックが失敗する

データネットワークでノードにアクセスできない

オペレーティングシステム

Pod が `init` 状態で停止する

`bm-system-machine-preflight-check` ベアメタルまたは VM ノードの Ansible ジョブが失敗する

Pod が `ContainerCreating` 状態で停止する

組織のブートストラップ中に組織システムクラスタが停止する

PANW ファイアウォールのアドレスグループが CIDR クレームの変更で更新されない

`bm-system` と他のジョブが停止している

`storagecluster` のバージョン番号が表示されない

ベアメタルサーバーがプロビジョニング状態で停止する

オブジェクトストレージのアップグレードで、ポストフライトチェックまたはプリフライトチェック中にエラーが表示される

`OrganizationUpgrade` がノードのアップグレード段階で停止している

アップグレード中に `Incorrect version of Trident` エラーが表示される

`iac-zoneselection-global` サブコンポーネントでアップグレードが失敗する

アップグレードチェックジョブの期限が超過しました

strongswan の場所が別のランタイムディレクトリにあるため、`meta-monitoring` アドオンが失敗する

テナント組織のアップグレードがプリフライトチェックステージで `ErrImagePull` により失敗する

ルート組織のアップグレード中に `serviceaccount` が見つからない

`shared-service-cluster upgrade` でアップグレードが失敗する

`system-dashboards` アドオンのインストールに失敗しました

`NodeUpgradeTask` CR が `NodeOSInPlaceUpgradePostProcessingCompleted` 条件で停止する

ユーザークラスタのアップグレード中にノードが失敗する

ルート管理者のアップグレードが再作成され、プリフライトチェックで失敗する

Namespace `platform-obs-obs-system` または `platform-obs` が終了状態のままになる

ブートストラップ中に KIND クラスタで UPORC クラッシュループが発生する

`NodeUpgradeTask` CR が `NodeBIOSFirmwareUpgradeCompleted` 条件で停止する

ノードがメンテナンスモードに移行できないため、クラスタのアップグレードがブロックされる

初期ルート `organizationupgrade` 中の永続的なタイムアウト

サブコンポーネント `obj-syslog-server` がルート組織で調整に失敗する

ABM またはノードのアップグレードが `maintenanceMode false` で停止する