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

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

バックアップと復元

クラスタバックアップの復元プランの編集が機能しない

バージョン: 1.14.3、1.14.4、1.14.5、1.14.6、1.14.7

症状:

RestorePlan カスタムリソースは、GDC コンソールを使用して編集できません。

回避策:

新しい復元プランを作成して古いプランを削除するか、kubectl CLI を使用して復元プランを編集します。

ソースディスクのサイズが無効

バージョン: 1.14.4、1.14.5

症状: v2 組織アーキテクチャへの移行後にバックエンドデータモデルが変更されたため、UI でディスクサイズが 0 Mb と表示され、作成時間が「不明」と表示されます。

回避策: この情報を UI で表示する代替方法はありません。

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

バージョン: 1.14.3、1.14.4

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

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

バックアップと復元の SLO が適用されない

バージョン: 1.14.3、1.14.4

現象: 必要なカスタムリソース定義がインストールされていないため、GDC サービスレベル目標（SLO）の指標とアラートはデフォルトで構成されていません。これらのアラートは Grafana で使用されます。

回避策: GDC でバックアップと復元の SLO を有効にするには、BACK-T0001 ランブックの手順に沿って操作します。

インポートされたバックアップに保持ポリシーが適用されない

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

症状: バックアップリポジトリをクラスタに接続すると、すべてのバックアップと復元のメタデータが同期され、リポジトリがインポートされたバックアップとして扱われます。これらのインポートされたバックアップは調整中に誤ってスキップされるため、保持ポリシーが無視され、バックアップが無期限に保持されます。

回避策: インポートされたバックアップには backup.gdc.goog/imported-repository:BACKUP_REPOSITORY_NAME のラベルが付けられます。通常の調整と保持ポリシーの適用を許可するには、次の kubectl コマンドを使用して、バックアップからラベルを削除します。

必要な環境変数を設定します。
```
export KUBECONFIG=KUBECONFIG
export BACKUP_REPOSITORY_NAME=BACKUP_REPOSITORY_NAME
export NAMESPACE=BACKUP_PLAN_NAMESPACE
```
次のように置き換えます。
- KUBECONFIG: kubeconfig ファイルのパス。
- BACKUP_REPOSITORY_NAME: バックアップリポジトリの名前。
- NAMESPACE: バックアッププランを含む Namespace。

インポートされたすべてのバックアップを一覧表示します。

kubectl get backups.backup.gdc.goog -n $NAMESPACE -l backup.gdc.goog/imported-repository=$BACKUP_REPOSITORY_NAME

必要に応じてラベルを削除します。

すべてのバックアップからラベルを削除します。

kubectl get backups.backup.gdc.goog -l
backup.gdc.goog/imported-repository=$BACKUP_REPOSITORY_NAME -n $NAMESPACE
-o json | jq -r '.items[].metadata.name' | xargs -I{} kubectl label -n
$NAMESPACE backups.backup.gdc.goog {} backup.gdc.goog/imported-repository-

単一のバックアップのラベルを削除します。

export BACKUP_NAME= kubectl label backups.backup.gdc.goog $BACKUP_NAME -n
$NAMESPACE backup.gdc.goog/imported-repository-

VM の部分バックアップが失敗する

バージョン: 1.14.3、1.14.4

現象: 複数の VM のうち 1 つの VM のバックアップに失敗すると、VM 全体のバックアップが失敗としてマークされます。

回避策: バックアッププランあたりの VM の数を制限します。

ユーザークラスタまたはサービスクラスタの削除後に孤立したバックアップリソースをクリーンアップする

バージョン: 1.14.3、1.14.4、1.14.5、1.14.6、1.14.7

現象: ユーザークラスタまたはサービスクラスタが削除されると、組織のインフラストラクチャと管理クラスタで作成された関連するバックアップエージェントリソース（StatefulSet、Pod、シークレットなど）が自動的にクリーンアップされません。これにより、孤立したリソースが残り、同じ名前でクラスタが再度作成されると、バックアップエージェント Pod が機能しません。

回避策: 孤立したリソースは、組織のインフラストラクチャクラスタの専用 Namespace に存在します。これらをクリーンアップするには、この Namespace を削除する必要があります。

組織のインフラストラクチャクラスタと管理クラスタの kubeconfig ファイルを設定します。
```
export ORG_INFRA_KUBECONFIG=<path_to_org_infra_kubeconfig>
export MGMT_KUBECONFIG=<path_to_management_kubeconfig>
```
孤立したリソースの Namespace を特定します。Namespace は gpc-backup-<cluster-name>-system パターンに従います。次に例を示します。
- gpc-backup-user-vm-1-cluster-system
- gpc-backup-user-vm-2-cluster-system
- gpc-backup-g-org-1-shared-service-cluster-system
Namespace を削除します。これにより、バックアップエージェントの StatefulSet と Pod（インフラストラクチャ内）や Secret（管理クラスタ内）など、その中のすべてのリソースが削除されます。
```
# Replace <namespace-name> with the actual namespace
kubectl delete namespace <namespace-name> --kubeconfig "${ORG_INFRA_KUBECONFIG:?}"
kubectl delete namespace <namespace-name> --kubeconfig "${MGMT_KUBECONFIG:?}"
```
クリーンアップが成功したことを確認するには、get all コマンドを再度実行します。
```
# Replace <namespace-name> with the actual namespace
kubectl get all -n <namespace-name> --kubeconfig "${ORG_INFRA_KUBECONFIG:?}"
kubectl get all -n <namespace-name> --kubeconfig "${MGMT_KUBECONFIG:?}"
```
名前空間が存在しなくなったため、コマンドは失敗します。Error from server (NotFound): namespaces "<namespace-name>" not found のようなエラーが表示されます。

CLI または UI で VirtualMachineRestore の削除がサポートされていない

バージョン: 1.14.3、1.14.4、1.14.5、1.14.6、1.14.7

症状: VirtualMachineRestore リソースの削除時に、VirtualMachineRestore コントローラが基盤となるリソース（VolumeRestore、Restore）を自動的にクリーンアップしません。この場合、手動でクリーンアップを行う必要があります。これは、kubectl delete または UI を使用して削除する場合も当てはまります。

回避策: 回避策として、依存リソースを正しい順序で手動で削除し、VirtualMachineRestore リソースからファイナライザを削除します。

kubeconfig ファイルが管理クラスタを参照するように設定します。
```
export MGMT_KUBECONFIG=<path_to_management_kubeconfig>
```

削除する VirtualMachineRestore とその Namespace を特定します。

export VM_RESTORE_NAME=<vm-restore-to_be_deleted>
export NAMESPACE=<namespace-of-vm-restore>

関連付けられている VolumeRestore リソースを見つけて削除します。これらは、VirtualMachineRestore にリンクするラベルとともに作成されます。

# Find and delete all associated VolumeRestores.
kubectl delete volumerestores.backup.gdc.goog --all-namespaces -l "virtualmachine.gdc.goog/virtual-machine-restore-name=${VM_RESTORE_NAME:?}" --kubeconfig "${MGMT_KUBECONFIG:?}"

関連付けられている Restore リソースを見つけて削除します。これらは、VirtualMachineRestore にリンクするラベルとともに作成されます。

# Find and delete all associated Restores.
kubectl delete restores.backup.gdc.goog -n "${NAMESPACE:?}" -l "virtualmachine.gdc.goog/virtual-machine-restore-name=${VM_RESTORE_NAME:?}" --kubeconfig "${MGMT_KUBECONFIG:?}"

まだ kubectl delete を実行していない場合は実行し、VirtualMachineRestore リソースからファイナライザーを削除します。これは、Kubernetes ガベージコレクタがリソースを削除できるようにする最終ステップです。
```
kubectl patch virtualmachinerestores.virtualmachine.gdc.goog "${VM_RESTORE_NAME:?}" -n "${NAMESPACE:?}" --type=merge -p '{"metadata":{"finalizers":null}}' --kubeconfig "${MGMT_KUBECONFIG:?}"
```

削除を確認します。

kubectl get virtualmachinerestores.virtualmachine.gdc.goog "${VM_RESTORE_NAME:?}" -n "${NAMESPACE:?}" --kubeconfig "${MGMT_KUBECONFIG:?}"

このコマンドは NotFound エラーを返し、リソースが削除されたことを確認します。

メモリ不足のためバックアップコントロールプレーン Pod がクラッシュする

バージョン: 1.14.4 以降

現象: 組織のインフラストラクチャクラスタの gpc-backup システム Namespace の gpcbackup-controlplane-controller Pod のステータスが CrashLoopBackOff になっています。このエラーが発生すると、バックアップと復元のオペレーションが失敗したり、応答しなくなったり、期待どおりに機能しなくなったりします。

回避策: BACK-R0005 に従って、gpcbackup-controlplane-controller デプロイのメモリ上限を引き上げます。このメソッドは、SubcomponentOverride を適用して CPU、メモリリクエスト、上限を調整します。

ユーザークラスタの削除が停止したままの状態になる

バージョン: 1.14.7 以降

症状: ファイナライザの問題により、クラスタが削除状態のままになる。

回避策: クラスタを削除する前に、ストレージボリュームに SnapMirror 関係があるかどうかを確認します。詳しくは、BACK-R0109 をご覧ください。

保留中の Persistent Volume Claim が原因で復元が停止する

バージョン: 1.14.3 以降

症状: Persistent Volume Claim（PVC）コントローラが、組織のインフラストラクチャクラスタ内のバックアップエージェントと通信できないことがあります。この問題はバックアップ機能には影響しませんが、ボリュームの復元オペレーションが Pending 状態のままになり、最終的にタイムアウトする可能性があります。この問題は、クローニングの Database Service 復元機能やユーザーワークロードの復元など、ボリュームの復元を伴う復元オペレーションに影響します。

この問題が発生すると、対応するバックアップエージェントを手動で再起動するまで、影響を受けるクラスタ内の後続の復元オペレーションは失敗します。

復元に関する問題がこの特定の問題に関連していることを確認するには、バックアップエージェントのログを調べる必要があります。

IAM-R0005 に沿って、ExpirationClusterRoleBinding リソースを適用して必要な BACK Debugger ロール（back-cluster-debugger）を取得します。
IAM-R0004 に沿って、組織インフラストラクチャクラスタの kubeconfig ファイルを生成します。すべてのバックアップエージェントは、組織のインフラストラクチャクラスタで実行されます。

復元を容易にしているバックアップエージェントを特定します。

kubectl --kubeconfig ORG_INFRA_KUBECONFIG get statefulsets \
    --all-namespaces | grep gpcbackup-agent

ORG_INFRA_KUBECONFIG は、組織のインフラストラクチャクラスタの kubeconfig ファイルのパスに置き換えます。

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

NAMESPACE                                          NAME                                     READY   AGE
gpc-backup-g-org-1-shared-service-cluster-system   gpcbackup-agent-g-org-1-shared-service   1/1     22d
gpc-backup-system                                  gpcbackup-agent                          1/1     22d
gpc-backup-system                                  gpcbackup-agent-cp                       1/1     22d
gpc-backup-user-vm-1-cluster-system                gpcbackup-agent-user-vm-1                1/1     22d
gpc-backup-user-vm-2-cluster-system                gpcbackup-agent-user-vm-2                1/1     22d

出力を読み取り、復元に対応するバックアップエージェントを特定します。たとえば、出力で影響を受ける StatefulSet Namespace が gpc-backup-user-vm-1-cluster-system の場合、バックアップエージェントは gpcbackup-agent-user-vm-1 です。

ステートフルセットのログでエラーメッセージを検索して、問題を確認します。
```
kubectl --kubeconfig=ORG_INFRA_KUBECONFIG logs statefulsets/BACKUP_AGENT \
    -n NAMESPACE | grep "Failed to watch \*v1.PersistentVolumeClaim"
```
次のように置き換えます。
- ORG_INFRA_KUBECONFIG: 組織のインフラストラクチャクラスタの kubeconfig ファイルのパス。
- BACKUP_AGENT: 前の手順で特定したバックアップエージェント。
- NAMESPACE: 前の手順で特定した Namespace。
一致するログがある場合は、この既知の問題が発生しています。

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

バックアップエージェントを再起動します。
```
kubectl --kubeconfig=ORG_INFRA_KUBECONFIG rollout restart \
   statefulsets/BACKUP_AGENT -n NAMESPACE
```
次のように置き換えます。
- ORG_INFRA_KUBECONFIG: 組織のインフラストラクチャクラスタの kubeconfig ファイルのパス。
- BACKUP_AGENT: 問題の確認時に特定したバックアップエージェント。
- NAMESPACE: 問題の確認時に特定した Namespace。
出力は次のようになります。
```
statefulset.apps/gpcbackup-agent-g-org-1-shared-service restarted
```
保留中のオペレーションが自動的に再開されるまで、最大 20 分間待ちます。

バックアップエージェントの再起動が完了したら、同じ宛先クラスタに対して別の復元を実行できます。この回避策を完了すると、副作用はありません。この回避策は、影響を受けるクラスタごとに 1 回だけ実行する必要があります。

クラスタ管理

サブコンポーネント `kub-gpu-controller` が調整されない

バージョン: 1.14.3

症状: gdchservices 組織のサブコンポーネント g-gdchservices-shared-service-cluster/kub-gpu-controller が調整されません。次の出力が返されます。

│ Message: Reconciliation error: E0321 - runtime parameter: configRunner error
| (full log in oclcm-configrunner pod): rpc error: code = Unknown desc = failed
| to execute binary: exit status 1. Output:
│ <
│ I framework.go:159] "Reading input secret"
| inputSecretKey="g-gdchservices-shared-service-cluster/kub-gpu-controller-backend-parameter"
│ I framework.go:175] "Processing job" jobType=parameter
│ Error: no matched clusterName
│ >

このエラーにより、gdchservices 組織で GPU マシンを起動できません。

回避策: バージョン 1.14.4 以降にアップグレードして、問題を軽減します。

Standard クラスタでノードプールを削除できない

バージョン: 1.14.3、1.14.4、1.14.5

修正済み: 1.14.6

症状: Standard クラスタから古いノードプールを削除しようとすると失敗し、ノードプールが想定された時間内に削除されません。標準クラスタは非公開プレビュー版であり、一部のユーザーは利用できない場合があります。

回避策: 廃止されたノードプールを手動で削除します。

クラスタが削除状態で停止している

バージョン: 1.14.6 以降

事象: Kubernetes クラスタを削除すると、Deleting 状態のままになることがあります。次のコマンドを実行して、クラスタの状態を確認します。

kubectl get cluster CLUSTER_NAME -n platform \
    --kubeconfig MANAGEMENT_API_SERVER

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

NAMESPACE    NAME             STATE         K8S VERSION
platform     test-cluster     Deleting      1.28.15-gke.100

クラスタ Namespace の状態を確認して、問題を確認することもできます。

kubectl describe ns/CLUSTER_NAME-cluster \
    --kubeconfig MANAGEMENT_API_SERVER

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

Name:         test-cluster
Labels:       kubernetes.io/metadata.name=test-cluster
Status:       Terminating
Conditions:
  Type                            Status    LastTransitionTime      Reason                Message
  ----                            ------    ------------------      ------                -------
  NamespaceContentRemaining       True      DATE                    SomeResourcesRemain   Some resources are remaining: backendservices.networking.gdc.goog has 1 resource instances, forwardingruleinternals.networking.gdc.goog has 1 resource instances
  NamespaceFinalizersRemaining    True      DATE                    SomeFinalizersRemain  Some content in the namespace has finalizers remaining: backendservice.finalizers.networking.gdc.goog in 2 resource instances

クラスタ Namespace が Terminating ステータスのままになり、NamespaceContentRemaining 条件と NamespaceFinalizersRemaining 条件が True に設定されます。

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

転送ルール API をパッチ適用します。

kubectl patch forwardingruleinternals.networking.gdc.goog -n "CLUSTER_NAME-cluster" \
    cluster-control-plane-vip-fr -p '{"metadata":{"finalizers":[]}}' --type='merge'

バックエンドサービス API をパッチ適用します。

kubectl patch backendservices.networking.gdc.goog -n "CLUSTER_NAME-cluster" \
    cluster-control-plane-vip-bes -p '{"metadata":{"finalizers":[]}}' --type='merge'

データベースサービス

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

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

バージョン: 1.14.6 以前

修正済み: 1.14.7

現象: ユーザーが特定の時点から 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 で表示されます。

DNS

GlobalCustomerRootDNSServerNotReachable が誤ったアラートをトリガーする

バージョン: 1.14.3、1.14.4、1.14.5、1.14.6、1.14.7、1.14.8

症状: DNS アラート DNS-A0021 が発生し、GlobalCustomerRootDNSServerNotReachable が示されます。org-mp の global-customer-root-dns の Probe CR に spec に egress: true がない。

回避策:

org-mgmt の KUBECONFIG パスを設定します。
```
export MGMT_KUBECONFIG=MANAGEMENT_KUBECONFIG
```

プローブ CR を管理する core-mz サブコンポーネントを一時停止します。

kubectl --kubeconfig "${MGMT_KUBECONFIG:?}" annotate subcomponent  -n global-kube-system dns-core-mz lcm.private.gdc.goog/paused=true

org-mp から現在のプローブ CR を編集します。

kubectl --kubeconfig "${MGMT_KUBECONFIG:?}" edit probes -n dns-system global-customer-root-dns

egress: True を含むように仕様を更新し、変更を適用します。CLUSTER_NAME と GLOBAL_CUSTOMER_ROOT_IP は変更されていません。

apiVersion: prober.private.gdc.goog/v1alpha1
kind: Probe
metadata:
  name: global-customer-root-dns
spec:
  egress: True
  matchClusters:
  - CLUSTER_NAME
  probeJobs:
  - moduleName: dns_udp_global_customer_root
    name: healthy-dns-global-customer-root
    targets:
    - GLOBAL_CUSTOMER_ROOT_IP

この回避策により、プローバーが修正され、誤ったアラートは 15 分以内に収まります。

ファイル/ブロックストレージ

VM でファイル共有ボリュームをマウントできない

バージョン: 1.14.6、1.14.7

症状: クラスタに新しいノードが追加されたときにネットワークストレージ権限の更新に失敗し、NFS マウントリクエストが拒否されることがあります。NFS ファイル共有をマウントするときに、access denied by server エラーが表示されることがあります。

回避策: file-share または proxy-group の Reconciler を再起動するか、FileShare リソースを変更して更新をトリガーします。

ファイアウォール

Subnet CR のアドレスにセキュリティポリシールールがない

バージョン: 1.14.3

現象: 組織のグローバル API サーバーで顧客が作成したグローバルサブネットカスタムリソースにファイアウォールアドレスグループがないため、組織にアクセスできません。

回避策: サービスマニュアル FW-G0002 の手順に沿って、トラフィックを許可するセキュリティポリシールールを手動で追加します。

GDC ファイアウォールは、mgmt とデータプレーンの両方で OIR へのトラフィックを拒否します

バージョン: 1.14.3、1.14.4

症状: OCITTopology カスタムリソースをデプロイすると、OIR と GDC 管理プレーンおよびデータプレーン間の接続が切断されます。

回避策: サービスマニュアル FW-G0002 の手順に沿って、ルート管理クラスタにセキュリティポリシールールを手動で追加し、トラフィックを許可します。

次のセキュリティポリシールールが必要です。

  apiVersion: firewall.private.gdc.goog/v1alpha2
  kind: SecurityPolicyRule
  metadata:
    labels:
      firewall.private.gdc.goog/policy-org: root
      firewall.private.gdc.goog/policy-type: perimeter
    name: ocit-data-egress
    namespace: root
  spec:
    action: allow
    destination:
      addresses:
      - OCIT_CIDR
      zones:
      - vsys1-octransit-data
    firewallVirtualSystemRef:
      name: ocvsys1-root
    priority: 60000
    profile:
      type: none
    service:
      option: any
    source:
      addresses:
      - ZONE_INFRA_CIDR
      zones:
      - vsys1-oc-data
  ---
  apiVersion: firewall.private.gdc.goog/v1alpha2
  kind: SecurityPolicyRule
  metadata:
    labels:
      firewall.private.gdc.goog/policy-org: root
      firewall.private.gdc.goog/policy-type: perimeter
    name: ocit-data-igress
    namespace: root
  spec:
    action: allow
    source:
      addresses:
      - OCIT_CIDR
      zones:
      - vsys1-octransit-data
    firewallVirtualSystemRef:
      name: ocvsys1-root
    priority: 60000
    profile:
      type: none
    service:
      option: any
    destination:
      addresses:
      - ZONE_INFRA_CIDR
      zones:
      - vsys1-oc-data
  —-
  apiVersion: firewall.private.gdc.goog/v1alpha2
  kind: SecurityPolicyRule
  metadata:
    labels:
      firewall.private.gdc.goog/policy-org: root
      firewall.private.gdc.goog/policy-type: perimeter
    name: ocit-mgmt-egress
    namespace: root
  spec:
    action: allow
    destination:
      addresses:
      - OCIT_CIDR
      zones:
      - vsys1-octransit-mgmt
    firewallVirtualSystemRef:
      name: ocvsys1-root
    priority: 60000
    profile:
      type: none
    service:
      option: any
    source:
      addresses:
      - MGMT_CIDR
      zones:
      - vsys1-oc-mgmt
  ---
  apiVersion: firewall.private.gdc.goog/v1alpha2
  kind: SecurityPolicyRule
  metadata:
    labels:
      firewall.private.gdc.goog/policy-org: root
      firewall.private.gdc.goog/policy-type: perimeter
    name: ocit-mgmt-ingress
    namespace: root
  spec:
    action: allow
    source:
      addresses:
      - OCIT_CIDR
      zones:
      - vsys1-octransit-mgmt
    firewallVirtualSystemRef:
      name: ocvsys1-root
    priority: 60000
    profile:
      type: none
    service:
      option: any
    destination:
      addresses:
      - MGMT_CIDR
      zones:
      - vsys1-oc-mgmt

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

OCIT_CIDR: お客様入力アンケート（CIQ）の ocitCIDR フィールドの IP アドレス範囲。
MGMT_CIDR: お客様入力アンケート（CIQ）の oobManagementCIDRs フィールドの IP アドレス範囲。
ZONE_INFRA_CIDR: お客様入力アンケート（CIQ）の zoneInfraCIDRs フィールドの IP アドレス範囲。

GDC ファイアウォールでゾーン間および組織間のトラフィックを拒否する

バージョン: 1.14.3、1.14.4、1.14.5

症状: クロスゾーンクロス組織トラフィックは、デフォルトでファイアウォールによってブロックされます。

回避策: ランブックの手順に沿って、トラフィックを許可するセキュリティポリシールールを手動で追加します。

ファイアウォールは、ID が組織名と同じ AttachmentGroup をサポートしていません

バージョン: 1.14.3 以降

現象: AttachmentGroup のデプロイ後、その AttachmentGroup オブジェクトの identifier フィールドが orgName と同じ場合、ファイアウォールはこのオブジェクトの解析に失敗し、ファイアウォール構成の更新が停止します。問題のある AttachmentGroup の例を次に示します。

  apiVersion: system.private.gdc.goog/v1alpha1
  kind: AttachmentGroup
  metadata:
    name: attachment-group-org-1234
    namespace: gpc-system
  spec:
    identifier: myorg
    entities:
      - orgName: myorg
        domainType: OrgMixed

回避策: 組織名を識別子として使用しないでください。破損した AttachmentGroup を修正する方法はいくつかあります。

次のいずれかのオプションを選択して、問題のある AttachmentGroup を修正します。

元の識別子の末尾にダッシュ記号で文字列を追加します。

apiVersion: system.private.gdc.goog/v1alpha1
kind: AttachmentGroup
metadata:
  name: attachment-group-org-1234
  namespace: gpc-system
spec:
  identifier: myorg-orgdx
  entities:
    - orgName: myorg
      domainType: OrgMixed

元の識別子の先頭にダッシュ記号で文字列を追加します。

apiVersion: system.private.gdc.goog/v1alpha1
kind: AttachmentGroup
metadata:
  name: attachment-group-org-1234
  namespace: gpc-system
spec:
  identifier: orgdx-myorg
  entities:
    - orgName: myorg
      domainType: OrgMixed

元の識別子を別の文字列に置き換えます。

apiVersion: system.private.gdc.goog/v1alpha1
kind: AttachmentGroup
metadata:
  name: attachment-group-org-1234
  namespace: gpc-system
spec:
  identifier: dxidentifier
  entities:
    - orgName: myorg
      domainType: OrgMixed

港

バックアップと復元後に Harbor CLI シークレットが無効になる

バージョン: 1.14.3

現象: Harbor のバックアップと復元後、CLI シークレットが無効になり、再作成する必要があります。

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

IAP ユーザーアカウントで Harbor にログインします。
ユーザー名をクリックし、[ユーザープロフィール] を選択します。
[その他] をクリックします。
別の CLI シークレットを自動または手動で作成します。

GDC の Harbor の詳細については、Harbor の概要をご覧ください。

Harbor のバックアップと復元のジョブが権限を競合する

バージョン: 1.14.3、1.14.4

症状: 複数の Harbor インスタンスが異なるユーザープロジェクトに存在する場合、バックアップと復元オペレーションでロールベースのアクセス制御が競合し、失敗率が高くなります。

回避策: この問題を軽減するには、次の手順に沿って、Harbor インスタンスが作成される各 Namespace のロールバインディングを手動で作成します。

必要な環境変数を設定します。
```
INSTANCE_NAMESPACE=INSTANCE_NAMESPACE
INFRA_CLUSTER_KUBECONFIG=INFRA_CLUSTER_KUBECONFIG
```
次のように置き換えます。
- INFRA_CLUSTER_KUBECONFIG: インフラストラクチャクラスタの kubeconfig ファイルのパス。
- INSTANCE_NAMESPACE: Managed Harbor Service（MHS）Harbor インスタンスが作成される Namespace。

回避策のロールバインディングを作成します。

kubectl --kubeconfig ${INFRA_CLUSTER_KUBECONFIG:?} create \
rolebinding ${INSTANCE_NAMESPACE:?}-mhs-backup-manual-rolebinding \
--role=haas-backup-secret-access-role --serviceaccount=${INSTANCE_NAMESPACE:?}-haas-system:haas-backup-sa \
--namespace=haas-system

Harbor のバックアップサイズが 0 と表示される

バージョン: 1.14.3、1.14.4

現象: 現時点では、Harbor バックアップのバックアップサイズの測定は実装されていません。GDC コンソールでは、SizeBytes フィールドに 0 の値が表示され、[サイズ] 列に 0 MB の値が表示されます。この構成は、現時点では想定されている動作です。

Harbor Registry コンソールページのバックアップリソースで権限エラーが発生する

バージョン: 1.14.3、1.14.4

現象: Harbor インスタンス管理者ロールがない場合、GDC コンソールの Harbor Container Registry ページを表示すると、バックアップリソースに権限エラーが表示されます。このエラーは、バックアップ情報が Harbor Container Registry ページに新たに追加されたものの、バックアップリソースの読み取り権限が Harbor インスタンス管理者以外の IAM ロールに付与されていないために表示されます。

[Harbor Container Registry] ページの他の GDC コンソール要素は、引き続き正常に動作します。GDC のロールの詳細については、ロールの定義をご覧ください。

データベースパスワードのローテーションが停止しているページ

バージョン: 1.14.3、1.14.4、1.14.5、1.14.6

症状: DB へのリクエストの認証に関するエラー（failed SASL auth (FATAL: password authentication failed for user "dbsadmin" (SQLSTATE 28P01)) など）がスローされ、単一のローテーション可能なシークレットに対して多くの自動生成されたローテーションリクエストが存在します。

回避策: ローテーション可能なシークレットの追加の未完了のローテーションリクエストを削除します。

KUBECONFIG を mp API サーバーに設定します。
Namespace をエクスポートします。
```
NAMESPACE=haas-system
```

haas-system 内のローテーション可能なシークレットが準備できていないかどうかを確認します。

kubectl get rotatablesecrets -n ${NAMESPACE?}

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

NAME                        CREDENTIALID   READY     AGE
haasdb-pw-ar-test           HAAS-0002      True      109d
haasdb-pw-gardener-harbor   HAAS-0002      True      178d
haasdb-pw-haas-alice        HAAS-0002      Unknown   166d
haasdb-pw-myinstance        HAAS-0002      True      80d
haasdb-pw-osd               HAAS-0002      True      158d
haasdb-pw-saptest           HAAS-0002      True      91d

ローテーション可能なシークレットの名前をエクスポートします。次に例を示します。
```
ROTATABLE_SECRET=haasdb-pw-haas-alice
```

準備ができていない余分なローテーションリクエストを削除します。

CUR_ROTATABLE_SECRET=$(kubectl get rotatablesecret ${ROTATABLE_SECRET?} -n ${NAMESPACE?} -ojsonpath='{.status.currentRotationRequestRef.name}')

kubectl get rotationrequests -n ${NAMESPACE?} -o json | jq -r --arg rotatableSecret "${ROTATABLE_SECRET?}" --arg curRotatableSecret "${CUR_ROTATABLE_SECRET?}" '.items[] | select(.metadata.ownerReferences[0]? | .name==$rotatableSecret) | select(.status.conditions[0]? | .type=="Ready" and .status=="False") | select(.metadata.name != $curRotatableSecret) | .metadata.name' | xargs -r kubectl delete rotationrequests -n ${NAMESPACE?}

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

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

バージョン: 1.14.3、1.14.4、1.14.5

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

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

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

バージョン: 1.14.x

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

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

sudo systemctl restart host-daemon

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

起動後に HSM が `ValidateNetworkConfig` エラーで失敗する

バージョン: 1.14.x

症状: HSM カスタムリソースが Ready 状態にならず、ValidateNetworkConfig エラーで失敗します。このエラーでは、data0 interface MAC address {} is not active というメッセージが表示されます。このエラーは、システムが再起動され、別のプライマリデータインターフェースが設定された場合に発生します。

回避策: ランブック HSM-R0059 に沿って、データネットワークの HSM ネットワーク構成を再適用します。複数の HSM でこのエラーが発生した場合でも、このランブックの手順は安全に実行できます。

健全性

誤警報の SLO アラート

バージョン: 1.14.3

症状: successRange SLO が誤ってトリガーされます。

回避策: インフラストラクチャオペレーター（IO）に、アラートが実際の問題か誤報かを確認するようリクエストします。

これを行うには、アラートがトリガーされたら、対応するランブックに沿ってサービスレベル目標（SLO）アラートの根本原因に対処します。

ケース 1: ランブックで問題が正常に解決され、アラートの発生が停止した場合、IO は関連するインシデントをクローズできます。

ケース 2: ランブックが完了してもアラートが引き続き発生する場合は、誤報の可能性があります。SLO が破られているかどうかを確認します。

kubectl get servicelevelobjective {SLO_NAME} -n {SLO_NAMESPACE} -o yaml --kubeconfig root-admin-kubeconfig| awk '/successRange/ { found1 = 1 } /labelFilter/ { found2 = 1 } END { if (found1 && found2) print "Broken 1.14.3 SLO detected"; else print "SLO does not have a known 1.14.3 issue" }'

出力に基づいて、アラートが誤報であることを確認した場合は、IO は GDC のエアギャップインスタンス内でアラートをミュートします。それ以外の場合は、Cloud サポートにエスカレーションします。
いずれの場合も、IO が Cloud サポートにエスカレーションして、動作可能なコンポーネントが正常であることを確認することが適切です。

無効なゲージベースの SLO 構成

バージョン: 1.14.3、1.14.4

症状: 構成の誤りにより、サービスレベル目標（SLO）のサブセットに良好なイベント、不良なイベント、合計イベントが入力されません。問題の SLO は Prometheus ゲージに基づいており、それに応じて構成する必要があります。

回避策:

バージョン 1.14.3: 回避策はありません。そのため、影響を受ける SLO に対して SLO アラートは起動しません。

バージョン 1.14.4: SLO を修正するための回避策が用意されています。この問題を解決するには、SLO 仕様に isGauge: true 設定を適用する必要があります。

SLO のゲージ構成の例:

```yaml
apiVersion: monitoring.private.gdc.goog/v1alpha1
kind: ServiceLevelObjective
metadata:
  namespace: infra-obs
  name: fw-packet-discard-errors-slo
spec:
  successRange:
  - resource: fw
    description: Firewall packet discard rate with errors SLO
    runbookURL: FW-R0006
    goal: "0.995"
    isGauge: true
    period: 30d
    metricName: fw_packet_discard_errors_ps
    max: 2
```

この設定で修正される既知の SLO のリストは次のとおりです。

ファイアウォール SLO:
- fw-packet-discard-errors-slo
- fw-packet-discard-no-error-slo
- fw-packet-discard-unknown-protocol-slo
- fw-uptime-slo
ファイル SLO:
- file-ontap-appliance-availability-slo
- file-ipsec-networking-availability-slo
- file-ontap-networking-availability-slo
- file-iscsi-client-availability-slo
- file-multipath-client-availability-slo
- file-trident-client-availability-slo

ID とアクセスの管理

IAM ロールバインディングの作成エラー

バージョン: 1.14.3

症状: IAM ロールバインディング名はシステムによって生成されます。これらの名前の最大文字数は 63 文字で、形式は user-idp-prefix-rolename です。生成された名前が 63 文字の制限を超えると、ロールバインディングの作成に失敗します。そのため、事前定義ロールまたはカスタムロールを使用して定義された権限はユーザーに割り当てられません。

回避策: 事前定義ロールまたはカスタムロールの名前が非常に短い場合（4 ～ 5 文字など）、ロールバインディングの作成が成功することがあります。

project-service-accounts の IAM ロールバインディングの作成に失敗する

バージョン: 1.14.3、1.14.4、1.14.5、1.14.6

現象: organization-iam-admin ロールを持つプロジェクトサービスアカウント（PSA）は、gdcloud projects add-iam-policy-binding コマンドを使用して、project-iam-admin ロールなどの別のロールを自分自身に割り当てることができません。この欠陥により、PSA は独自の権限を管理できません。

回避策: organization-iam-admin ロールが付与されていることを確認します。次に、ターゲット PSA のプロジェクト名前空間で project-iam-admin ロールを自分に割り当て、PSA に project-iam-admin ロールを割り当てます。この権限設定により、PSA は自身または他の PSA に追加の権限を割り当てることができます。

新しいプロジェクトで事前定義されたロールの作成が遅延する

バージョン: 1.14.3

現象: 新しいプロジェクトを作成すると、project-bucket-object-admin などのデフォルトのロールがありません。

回避策: 15 ～ 60 分待つか、組織のインフラストラクチャクラスタの iam-system Namespace で iam-org-admin-cm-backend-controller コントローラを手動で再起動します。

GDC コンソールで最初のロールバインディングを作成できない

バージョン: 1.14.4

現象: GDC コンソールを使用して新しいサービス ID の最初のロールバインディングを作成すると、ロールバインディングの作成は成功したと報告されますが、実際には機能しません。サービス ID に対する追加のアクションは失敗し、効果がありません（追加のロールバインディングの追加やロールバインディングの削除など）。

回避策: gdcloud CLI を使用して、サービス ID の最初のロールバインディングを作成します。最初のロールバインディングが関連付けられた後は、GDC コンソールを使用してサービス ID で実行されるすべての操作が正しく機能します。詳細については、サービス ID にロールバインディングを割り当てるをご覧ください。

AO はインフラストラクチャクラスタのロールへのアクセス権を自分自身に付与できない

バージョン: 1.14.3。1.14.4

修正済み: 1.14.3 hotfix 21

症状: AO は、自分自身や他のユーザーにインフラストラクチャクラスタ内のロールへのアクセス権を付与できません。

回避策: AO ユーザーは IO に連絡して、必要なアクセス権を取得する必要があります。IO は IAC を使用して、AO ユーザーに必要なアクセス権を付与できます。

既存のサービスアカウントトークンが無効になる

バージョン: 1.14.3

修正済み: 1.14.3 hotfix 21

症状: ブートストラップ後にクラスタが実行状態になった後で service-account-issuer apiserver 引数が変更されたため、ユーザークラスタによって発行された既存のサービスアカウントトークンが無効になります。この問題により、ユーザークラスタの Pod（istio-proxy サイドカーコンテナを含む Pod など）は、サービスアカウントトークンを使用した認証に失敗します。また、サービスアカウントトークンが新しい構成で更新されるまでに数時間かかります。

回避策: ユーザークラスタで Pod を手動で再起動して、サービスアカウントトークンが新しい構成で更新されるようにします。

Infrastructure as Code（IAC）

Namespace がないため、サブコンポーネントの調整が失敗する

バージョン: 1.14.3

症状: サブコンポーネントの調整に失敗します。これは、必要な config-management-monitoring Namespace が gdchservices-mp クラスタに自動的に作成されないためです。

回避策: 次のマニフェストを使用して、gdchservices-mp クラスタに config-management-monitoring Namespace を作成します。

apiVersion: v1
kind: Namespace
metadata:
  labels:
    configmanagement.gke.io/system: "true"
  name: config-management-monitoring
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep

IAC ConfigSync の指標収集が失敗する

バージョン: 1.14.3、1.14.4

現象: IAC の ConfigSync モニタリングサブシステムの問題により、otel-collector デプロイが開始されません。ConfigSync 指標は、モニタリングとアラート用に収集されません。

回避策: root-admin クラスタで次の手順を完了します。

iac-configsync-mon サブコンポーネントを一時停止します。
config-management-monitoring Namespace の MetricsProxySidecar/iac-configsync-metrics オブジェクトを編集します。

MetricsProxySidecar/iac-configsync-metrics YAML で、次のものを見つけます。

spec:
  [...]
  destinations:
  - certificate:
      secretName: iac-configsync-mon-target-cert

このセクションを次のように変更します。

spec:
  [...]
  destinations:
  - certificate:
      secretName: iac-configsync-mon-mon-target-cert

config-management-monitoring Namespace の otel-collector Deployment を再起動します。

IAC RootSync が失敗する

バージョン: 1.14.3

症状: iac-creds シークレットがないため、ConfigSync が Gitlab からクラスタにリソースを同期する際に問題が発生します。iacmanager の問題により、iac-creds がローテーションされません。

回避策: クラスタで次の手順を完了します。

IAC-R0015 ランブックに沿って、欠落している Secret iac-creds の問題を解決します。IaC マネージャーと Configsync の認証情報をローテーションします。

在庫

在庫監査で調整に失敗する

バージョン: 1.14.3

症状: HarborRobotAccount は管理プレーンでのみ使用できるため、inv-audit サブコンポーネントの調整に失敗します。

回避策: AlertManager でミュートを作成して、component: inv の component_reconciliation_errors アラートをミュートします。

鍵管理システム

CTM ルート鍵を使用するように構成された KMS は、HSM が使用できない場合にフェイルオーバーしない

バージョン: 1.14.x

現象: HSM が使用できず、使用可能な他の HSM がある場合に、KMS へのリクエストの一部が失敗します。この問題は、CTM ルートキーを使用するように KMS が構成されている場合にのみ発生します。

回避策: HSM-P0006 ランブックに沿って、使用できない HSM を HSMCluster から削除します。次に、kms-backend デプロイを再起動します。

kubectl --kubeconfig=ORG_INFRA_KUBECONFIG rollout restart deployment/kms-backend -n kms-system

このコマンドは、kms-backend Pod を再起動し、HSMCluster 内の HSM への接続を再確立します。

ロードバランサ

サブネット CIDR の枯渇によりグローバルロードバランサの作成が失敗する

バージョン: 1.14.3

症状: グローバルサブネットの IP アドレスが不足しているため、グローバル外部または内部ロードバランサの作成が失敗します。コントローラが誤ったコードパスを使用しているため、システムはグローバルロードバランサの IP アドレスを動的に割り当てることができません。ロードバランサは 1 つのサブネットのみを参照します。そのサブネットに使用可能な IP アドレスがなくなると、別のサブネットに切り替えることはできません。この制限により、エラーが表示されます。

回避策: 独自のサブネットを作成し、ForwardingRule リソースの静的 IP アドレスを作成する必要があります。サブネットの作成の詳細については、ワークロードネットワーキングのサブネットを構成するをご覧ください。ForwardingRule リソースを作成するときに、cidrRef フィールドでサブネットを指定できます。

バージョン: 1.14.3

症状: ロードバランサオブジェクトが Ready 状態にならない。

回避策: spec フィールドに値がある Backend リソースを作成する必要があります。Backend リソースは、ロードバランサのエンドポイントを識別します。spec フィールドに値を指定しないと、エラー状態になる可能性があります。

ロードバランサリソースを変更してもサービスが調整されない

バージョン: 1.14.3

現象: ロードバランサのカスタムリソースを変更しても、ロードバランササービスが調整されません。

回避策: この問題を軽減するには、ロードバランサの BackendService リソースと ForwardingRule リソースを削除して、ロードバランサを削除して再作成します。

ゾーン名が正しくない場合でも拒否されない

バージョン: 1.14.3

現象: グローバル BackendService リソースが、正しくないゾーン名を拒否しません。ゾーンの名前が正しくない場合、ロードバランサは構成を検証して拒否するのではなく、失敗します。

回避策: 使用するゾーンの正しい名前を指定する必要があります。ロードバランサが正しく構成されていない場合は、ロードバランサのカスタムリソースを削除して再作成する必要があります。

グローバルロードバランサとゾーンロードバランサの webhook エラー

バージョン: 1.14.3

症状: 次のエラーが返されます。

Error from server (InternalError): error when creating "STDIN": Internal error
occurred: failed calling webhook
"projectnetworkpolicies.networking.global.gdc.goog": failed to call webhook:
Post
"https://unet-global-org-cm-webhooks.unet-system.svc/validate-networking-global-gdc-goog-v1-projectnetworkpolicy?timeout=10s":
context deadline exceeded

回避策: この問題を軽減するには、unet-global-cm Pod を再起動して削除します。

root@bootstrapper-zone1:~# k8s.org get pods -n unet-system
unet-global-org-cm-backend-controller-7df58cd9db-8szkh   1/1     Running   42 (7h22m ago)   9d

root@bootstrapper-zone1:~# k8s.org delete pods -n unet-system
unet-global-org-cm-backend-controller-7df58cd9db-8szkh

ロギング

WAL 再生中に Loki Pod がクラッシュするか、OOMKilled が発生する

バージョン: 1.14.3、1.14.4、1.14.5

症状:

obs-system Namespace の audit-logs-loki-io Pod が CrashLoopBackOff 状態になります。これは、wal_replay_ceiling 値が Pod のメモリ上限を超えているため、WAL（Write-Ahead Log）の再生中に liveness プローブが早期に失敗するか、メモリ不足（OOM）強制終了が発生することが原因です。

回避策:

次の手順に沿って Loki の構成を調整し、WAL の再生を成功させます。変更は、影響を受けるクラスタ（root-admin や org-infra など）に適用されます。

KUBECONFIG=/path/to/affected-cluster.kubeconfig を環境変数として設定します。

LoggingPipelineReconciler を一時停止して、コントローラが手動変更を元に戻さないようにします。このマニフェストを適用します。

apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: log-logging-pipeline-pause
  namespace: root
spec:
  subComponentRef: "log-admin"
  backend:
    operableParameters:
      controller:
        disableReconcilers: "LoggingPipelineReconciler"

オーバーライドが有効になっていることを確認します。出力には "disable-reconcilers=LoggingPipelineReconciler" が含まれます。

kubectl get deploy -n obs-system log-admin-backend-controller -o jsonpath='{.spec.template.spec.containers[0].args}' --kubeconfig=${KUBECONFIG} | jq

audit-logs-loki-io-cm ConfigMap の replay_memory_ceiling を 8GB に下げます。

kubectl edit cm audit-logs-loki-io-cm -n obs-system --kubeconfig=${KUBECONFIG}

wal セクションを変更します。

[...]
  wal:
    replay_memory_ceiling: 8GB ## <-- Change to 8GB
[...]

省略可: オブジェクトプロキシをスケーリングします。obj-proxy Pod がリソース上限に近づいている場合は、復元中の負荷の増加に対応するようにデプロイをスケーリングします。

a. リソースの使用状況を確認します。
```
kubectl top po -n gpc-system -l name=obj-proxy-manager --kubeconfig=${KUBECONFIG}
```
b. 使用率が高い場合は、デプロイをスケーリングします。
```
kubectl scale deployment obj-proxy -n gpc-system --replicas=7 --kubeconfig=${KUBECONFIG}
```
c. 必要に応じて、Pod のメモリ上限（12000Mi から 16000Mi など）を引き上げることもできます。
影響を受ける Pod の PVC サイズを増やします（例: loki-storage-audit-logs-loki-io-0（70Gi から 75Gi）を調整して、ディスクの圧力を防ぎます。内部手順 SUPP-R001 に沿って PVC のサイズを変更します。次のステップで再起動すると、新しいサイズが適用されます。
audit-logs-loki-io StatefulSet に startupProbe を追加して、liveness チェックが開始される前に WAL 再生に時間をかけられるようにします。変更を保存すると、Pod のローリング再起動がトリガーされます（5 ～ 10 分）。
```
kubectl edit sts audit-logs-loki-io -n obs-system --kubeconfig=${KUBECONFIG}
```
この startupProbe を audit-logs-loki-io コンテナ仕様に追加します。
```
startupProbe:
  failureThreshold: 1000
  httpGet:
    path: /ready
    port: loki
    scheme: HTTP
  periodSeconds: 10
  successThreshold: 1
  timeoutSeconds: 10
```

回避策を確認する

Pod と StatefulSet のステータスを確認する: すべての audit-logs-loki-io Pod が Running であり、StatefulSet のすべてのレプリカが準備完了と表示されていることを確認します。
```
kubectl get po -n obs-system -l app=audit-logs-loki-io --kubeconfig=${KUBECONFIG}
kubectl get sts -n obs-system audit-logs-loki-io --kubeconfig=${KUBECONFIG}
```

PVC のサイズが変更されたことを確認します。想定される出力は 75Gi です。

kubectl get pvc -n obs-system loki-storage-audit-logs-loki-io-0 -o jsonpath='{.status.capacity.storage}' --kubeconfig=${KUBECONFIG} ; echo

Pod ログで errors=false メッセージを確認して、WAL の復元が成功したことを確認します。
```
kubectl logs -n obs-system audit-logs-loki-io-0 --kubeconfig=${KUBECONFIG} | grep -i "wal"
```

Pod 内の /wal ディレクトリの使用率が低いことを確認します。

kubectl exec -n obs-system audit-logs-loki-io-0 -c audit-logs-loki-io --kubeconfig=${KUBECONFIG} -- df -Ph /wal

Loki Ring のステータスを確認します。

a. Loki サービスをポート転送します。
```
DATA_IP=$(ip -br -4 a s dev bond0| awk '{print $3}' | cut -d / -f 1)
kubectl port-forward -n obs-system svc/audit-logs-loki-io --address $DATA_IP 43100:3100 --kubeconfig=${KUBECONFIG}
```
b. http://<DATA_IP>:43100/ring で、すべてのインスタンスが正常であることを確認します。

オーバーライドとオブジェクトプロキシをクリーンアップする

検証に成功したら、次のクリーンアップ手順を行います。

サブコンポーネントのオーバーライドを削除します。

kubectl delete subcomponentoverride log-logging-pipeline-pause -n root --kubeconfig=${KUBECONFIG}

obj-proxy デプロイをスケールアップした場合は、元のサイズにスケールダウンします。

モニタリング

一部のクラスタで AlertManager Webhook がアラートを送信できない

バージョン: 1.14.3

症状: AlertManager Webhook が、ルート管理クラスタまたは ServiceNow インスタンスが存在するクラスタ以外のクラスタから ServiceNow にリクエストとアラート通知を送信できない。そのため、組織の ServiceNow でアラートは作成されません。

エラーログメッセージが繰り返し表示される場合は、Webhook がアラートを送信できていないことを特定できます。繰り返されるエラーを確認する手順は次のとおりです。

環境変数をエクスポートする
```
export MGMT_API_KUBECONFIG=MGMT_API_KUBECONFIG
```
MGMT_API_KUBECONFIG は、Management API サーバーの kubeconfig ファイルへのパスに置き換えます。

Pod を見つけます。

kubectl --kubeconfig ${MGMT_API_KUBECONFIG} get pods \
  -n mon-system -o name | grep mon-alertmanager-servicenow-webhook-backend-

ログを取得します。

kubectl --kubeconfig ${MGMT_API_KUBECONFIG} logs POD_NAME -n mon-system

POD_NAME は、Pod の名前に置き換えます。

次のようなエラーが繰り返されていないか確認します。
```
Errorsendingtherequest ... read: connection reset by peer
```

回避策: この問題の推奨される回避策は、メタモニタリングアラート用と通常のアラート用の 2 つのサブコンポーネントを一時停止することです。次に、影響を受けるクラスタの mon-alertmanager-servicenow-webhook-backend デプロイで、ラベル egress.networking.gke.io/enabled: "true" を networking.private.gdc.goog/infra-access: enabled に置き換えます。このラベルにより、Pod は Egress ゲートウェイに依存せずに他のインフラストラクチャクラスタと通信できます。

推奨される回避策を適用する手順は次のとおりです。

環境変数をエクスポートする
```
export ROOT_KUBECONFIG=ROOT_KUBECONFIG
export MGMT_API_KUBECONFIG=MGMT_API_KUBECONFIG
export ORG=ORG
```
次のように置き換えます。
- ROOT_KUBECONFIG: ルート管理クラスタの kubeconfig ファイルへのパス。
- MGMT_API_KUBECONFIG: Management API サーバーの kubeconfig ファイルへのパス。
- ORG: 組織の Namespace。

サブコンポーネントを一時停止します。

mon-alertmanager-servicenow-webhook サブコンポーネントを一時停止します。

kubectl --kubeconfig ${ROOT_KUBECONFIG} annotate subcomponent "mon-alertmanager-servicenow-webhook" \
  -n "${ORG}" lcm.private.gdc.goog/paused=true

mon-meta-monitoring サブコンポーネントを一時停止します。

kubectl --kubeconfig ${ROOT_KUBECONFIG} annotate subcomponent "mon-meta-monitoring" \
  -n "${ORG}" lcm.private.gdc.goog/paused=true

ほとんどのアラートをカバーする mon-alertmanager-servicenow-webhook-backend デプロイを更新します。

kubectl --kubeconfig ${MGMT_API_KUBECONFIG} edit deployment \
  -n mon-system mon-alertmanager-servicenow-webhook-backend

spec.template.metadata.labels のラベルを egress.networking.gke.io/enabled: "true" から networking.private.gdc.goog/infra-access: "enabled" に置き換えます。
モニタリングスタックに関連するアラートをカバーする meta-alertmanager-servicenow-webhook デプロイを更新します。
```
kubectl --kubeconfig ${MGMT_API_KUBECONFIG} edit deployment \
  -n mon-system meta-alertmanager-servicenow-webhook
```
spec.template.metadata.labels のラベルを egress.networking.gke.io/enabled: "true" から networking.private.gdc.goog/infra-access: "enabled" に置き換えます。

または、Grafana を使用して同じアラートを表示することもできます。

ServiceNow インシデントが重複することがある

バージョン: 1.14.3

症状: 同じ Pod に対して ServiceNow インシデントが重複して表示されることがあります。

回避策: インシデントの説明にあるフィンガープリントを照合することで、重複したチケットを特定できます。

インフラストラクチャ指標が過敏になる可能性がある

バージョン: 1.14.3

症状: アラート oclcm-reconciler-success-rate のアラームが表示されることがあります。

回避策: アラートをミュートしても問題ありません。これはノイズの多いアラートであり、シグナルの改善に取り組んでいます。

調整指標が過敏になっている可能性がある

バージョン: 1.14.3、1.14.4、1.14.5

症状: アラート component_reconciliation_errors のアラームが表示されることがあります。

回避策: ランブック MON-R2009 に沿って、アラートを安全にミュートできます。これはノイズが多すぎるアラートです。

ルート管理クラスタで 2 つの誤ったアラートが開いている

バージョン: 1.14.3

症状: ルート管理クラスタで MON-A0001_slow アラートと MON-A0001_fast アラートが発報状態になっています。

ServiceNow のインシデントは、次の例のようになります。

number        priority        sys_created_on        u_organization_id   short_description   active
INC004043     1 - Critical    2025-04-30 08:29:00   root                MON-A0001_slow      true
INC0040427    1 - Critical    2025-04-30 08:28:55   root                MON-A0001_fast      true

インシデントの説明は次のとおりです。

Description:
Message: "Blackbox monitoring metrics pipeline down"
Runbook URL: MON-R0001
Generator URL: cortex.mon-system.svc:9009/graph?g0.expr=%28mon_metrics_pipeline_error_rate1h%7B_slo_alert_id%3D%22mon-a0001-blackbox-monitoring-obs-system%2Finfra-obs-obs-system%22%7D+%3E+%2814.4+%2A+0.05%29+and+mon_metrics_pipeline_error_rate5m%7B_slo_alert_id%3D%22mon-a0001-blackbox-monitoring-obs-system%2Finfra-obs-obs-system%22%7D+%3E+%2814.4+%2A+0.05%29%29+or+%28mon_metrics_pipeline_error_rate6h%7B_slo_alert_id%3D%22mon-a0001-blackbox-monitoring-obs-system%2Finfra-obs-obs-system%22%7D+%3E+%286+%2A+0.05%29+and+mon_metrics_pipeline_error_rate30m%7B_slo_alert_id%3D%22mon-a0001-blackbox-monitoring-obs-system%2Finfra-obs-obs-system%22%7D+%3E+%286+%2A+0.05%29%29&g0.tab=1
AlertCode: MON-A0001
Severity: critical
Cluster: org-1-admin
Namespace: <no value>
Pod Name: <no value>
fingerprint: 3b386f1373178e97

回避策: この問題を解決するには、ルート管理者クラスタでのみ次の操作を行います。

mon-a0001-blackbox-monitoring-obs-system MonitoringRule で monitoring.gdc.goog/metamonitoring-project=mon-system ラベルを削除します。

mon-a0001-blackbox-monitoring-obs-system MonitoringRule から、名前が mon_metrics_pipeline_absent でクラスタラベルの値が ORG_NAME-admin のすべての記録ルールを削除します。

次の例は、削除する mon_metrics_pipeline_absent 録画ルールを示しています。

Expr:               absent(probe_success{job="mon-system/meta-monitoring-meta-prometheus/meta_prometheus_probe_metric",cluster="gdchservices-admin"}) OR on() vector(0)
    Labels:
      _source_project:  blackbox-monitoring-obs-system
      Cluster:          gdchservices-admin
      Job:              mon-system/meta-monitoring-meta-prometheus/meta_prometheus_probe_metric
    Record:             mon_metrics_pipeline_absent

MON_A0001_slow アラートと MON_A0001_fast アラートは、数分後（約 40 分後）に Normal 状態に戻ります。

ルート管理者コントローラマネージャーのエラー率が高い

バージョン: 1.14.3

症状: アラート ControllerReconciliationErrorRateHigh のアラームが表示されることがあります。コントローラマネージャーには、次のようなログが表示されます。ApplianceStorage.ceph.storage.private.gdc.goog \"appliance-storage\" not found

回避策: エラーが発生したコントローラは安全に無効にできます。

環境変数をエクスポートする
```
export ROOT_KUBECONFIG=ROOT_KUBECONFIG
```
ルート管理コントローラマネージャーのデプロイを編集します。
```
kubectl --kubeconfig ${ROOT_KUBECONFIG} edit deployment \
  -n gpc-system root-admin-controller
```
manager コンテナに引数 --disable-reconcilers がまだない場合は、値 --disable-reconcilers=ApplianceStorageTunnelReconciler を持つ引数 --disable-reconcilers を追加します。ある場合は、ApplianceStorageTunnelReconciler リコンサイラをカンマで区切って追加します。例: --disable-reconcilers=ManagementSwitch,ManagementAggSwitch,TORSwitch,AggSwitch,ApplianceTORSwitch,ApplianceStorageTunnelReconciler。

エラーログがクリアされます。

KUB ダッシュボードのすべての PA パネルにデータが表示されない

バージョン: 1.14.3

症状: KUB ダッシュボードの Grafana のすべてのパネルに、プラットフォーム管理者のデータが表示されません。

回避策: KSM サブコンポーネントを一時停止し、monitoringtarget と metricsproxysidecar を更新します。

サブコンポーネントを一時停止します。

export SUBCOMPONENT_NAME=mon-kube-state-metrics
export SUBCOMPONENT_NAMESPACE=ORG_NAME
kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG annotate subcomponent "${SUBCOMPONENT_NAME:?}" -n "${SUBCOMPONENT_NAMESPACE:?}" lcm.private.gdc.goog/paused=true

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

ORG_NAME: 組織の名前
ROOT_ADMIN_KUBECONFIG: root-admin kubeconfig へのパス

.spec.destinations セクションの mon-kube-state-metrics-metrics-proxy metricsproxysidecar に次を追加します。

  - certificate:
  secretName: mon-pa-kube-state-metrics-cert
port: 8091

更新された metricsproxysidecar は次のようになります。

...
spec:
  containerName: otel-collector
  destinations:
  - certificate:
      secretName: mon-io-kube-state-metrics-cert
    port: 8090
  - certificate:
      secretName: mon-pa-kube-state-metrics-cert
    port: 8091
  resources:
    limits:
...

mon-pa-kube-state-metrics monitoringtarget spec から matchClusters: セクションを削除します。更新された mon-pa-kube-state-metrics monitoringtarget spec は次のようになります。

...
spec:
  podMetricsEndpoints:
    metricsRelabelings:
    - action: replace
      replacement: platform-obs
      targetLabel: _gdch_project
    path:
      value: /metrics
    port:
      value: 8091
    scheme:
      value: http
    scrapeInterval: 60s
    scrapeTimeout: 45s
  selector:
    matchLabels:
      monitoringtarget: mon-kube-state-metrics

observability-admin-debugger ロールの権限が誤って構成されている

バージョン: 1.14.3、1.14.4

現象: IO は、mon-system Namespace の cortex または prometheus Pod を再起動できません。

回避策:

組織の場合:

iam-common サブコンポーネントを一時停止します。

observability-admin-debugger/iam-system roleTemplate を次のように更新します。

apiVersion: iam.private.gdc.goog/v1alpha1
kind: RoleTemplate
metadata:
  name: observability-admin-debugger
  namespace: iam-system
spec:
  metadata:
    roleType: predefined
    hierarchyLevel: org
    persona: infra-operator
    displayName: "Observability Admin"
    bindingType: rolebinding
    roleNamespace: "mon-system"
    operableComponent: IAM
  rules:
  - apiGroups:
    - "apps"
    resources:
    - "deployments"
    resourceNames:
    - "logmon-operator"
    - "cortex-tenant"
    - "meta-blackbox-exporter"
    - "blackbox-exporter"
    verbs:
    - "*"
  - apiGroups:
    - "apps"
    resources:
    - "statefulsets"
    resourceNames:
    - "anthos-prometheus-k8s"
    - "meta-prometheus"
    - "mon-prober-backend-prometheus"
    - "primary-prometheus-shard0-replica0"
    - "primary-prometheus-shard0-replica1"
    - "primary-prometheus-shard1-replica0"
    - "primary-prometheus-shard1-replica1"
    verbs:
    - "*"
  - apiGroups:
    - ""
    resources:
    - "secrets"
    resourceNames:
    - "anthos-prometheus-scrape-cert"
    - "kube-control-plane-metrics-proxy-cert"
    - "metrics-consumers-ca"
    - "metrics-providers-ca"
    - "anthos-prometheus-etcd-scrape"
    verbs:
    - "*"
  - apiGroups:
    - "cert-manager.io"
    resources:
    - "certificates"
    resourceNames:
    - "anthos-prometheus-scrape"
    - "kube-control-plane-metrics-proxy-cert"
    - "metrics-consumers-ca"
    - "metrics-providers-ca"
    verbs:
    - "get"
    - "list"
    - "watch"

ルート管理者の場合:

iam-common サブコンポーネントを一時停止します。

observability-admin-debugger-root/iam-system roleTemplate を次のように更新します。

apiVersion: iam.private.gdc.goog/v1alpha1
kind: RoleTemplate
metadata:
  name: observability-admin-debugger
  namespace: iam-system
spec:
  metadata:
    roleType: predefined
    hierarchyLevel: org
    persona: infra-operator
    displayName: "Observability Admin"
    bindingType: rolebinding
    roleNamespace: "mon-system"
    operableComponent: IAM
  rules:
  - apiGroups:
    - "apps"
    resources:
    - "deployments"
    resourceNames:
    - "logmon-operator"
    - "cortex-tenant"
    - "meta-blackbox-exporter"
    - "blackbox-exporter"
    verbs:
    - "*"
  - apiGroups:
    - "apps"
    resources:
    - "statefulsets"
    resourceNames:
    - "anthos-prometheus-k8s"
    - "meta-prometheus"
    - "mon-prober-backend-prometheus"
    - "primary-prometheus-shard0-replica0"
    - "primary-prometheus-shard0-replica1"
    - "primary-prometheus-shard1-replica0"
    - "primary-prometheus-shard1-replica1"
    verbs:
    - "*"
  - apiGroups:
    - ""
    resources:
    - "secrets"
    resourceNames:
    - "anthos-prometheus-scrape-cert"
    - "kube-control-plane-metrics-proxy-cert"
    - "metrics-consumers-ca"
    - "metrics-providers-ca"
    - "anthos-prometheus-etcd-scrape"
    verbs:
    - "*"
  - apiGroups:
    - "cert-manager.io"
    resources:
    - "certificates"
    resourceNames:
    - "anthos-prometheus-scrape"
    - "kube-control-plane-metrics-proxy-cert"
    - "metrics-consumers-ca"
    - "metrics-providers-ca"
    verbs:
    - "get"
    - "list"
    - "watch"

Grafana デバッガのロールがない

バージョン: 1.14.3、1.14.4

症状: grafana-debugger-cp ロールがオブザーバビリティシャドープロジェクトの Namespace（*-obs-system）に存在しません。ユーザーに、Grafana 関連の問題のデバッグに必要な適切な権限のセットを付与できない。

回避策: infra-cp に次の ClusterRoleTemplate カスタムリソースを作成し、作成された対応する ClusterRole を使用して grafana-debugger 権限を取得します。

apiVersion: iam.private.gdc.goog/v1alpha1
kind: ClusterRoleTemplate
metadata:
  name: grafana-debugger-cp
spec:
  metadata:
    roleType: predefined
    hierarchyLevel: infra-cp
    persona: infra-operator
    displayName: "Grafana Admin"
    bindingType: rolebinding
    operableComponent: MON
  rules:
  - apiGroups:
    - "apps"
    resources:
    - "deployments"
    resourceNames:
    - "grafana-proxy-server"
    verbs:
    - "delete"
    - "get"
    - "list"
    - "patch"
    - "update"
    - "watch"
  - apiGroups:
    - "apps"
    resources:
    - "statefulsets"
    resourceNames:
    - "grafana"
    verbs:
    - "delete"
    - "get"
    - "list"
    - "patch"
    - "update"
    - "watch"
  - apiGroups:
    - ""
    resources:
    - "pods"
    resourceNames:
    - "grafana-0"
    verbs:
    - "delete"
    - "get"
    - "list"
    - "patch"
    - "update"
    - "watch"
  - apiGroups:
    - ""
    resources:
    - "pods"
    verbs:
    - "get"
    - "list"
    - "watch"
  - apiGroups:
    - "monitoring.private.gdc.goog"
    resources:
    - "datasources"
    verbs:
    - "create"
    - "delete"
    - "get"
    - "list"
    - "update"
    - "patch"
    - "watch"
  - apiGroups:
    - "monitoring.global.private.gdc.goog"
    resources:
    - "datasourcereplicas"
    verbs:
    - "create"
    - "delete"
    - "get"
    - "list"
    - "update"
    - "patch"
    - "watch"

新しいゾーンを追加した後、ゾーン間の指標とログが表示されない

バージョン: 1.14.*

現象: grafana ダッシュボードに、新しく追加されたゾーンのログと指標が表示されない。

回避策 1: datasource-proxy デプロイを再起動します。

kubectl KUBECONFIG=${KUBECONFIG_ORG} rollout restart deployment datasource-proxy -n mon-system

これにより、datasource-proxy Pod が再起動し、新しく追加されたゾーンのクロスゾーンエンドポイント構成が更新されます。

`MonitoringTarget` ファイナライザが Namespace の削除をブロックする

バージョン: 1.14.3、1.14.4

症状: Namespace が削除されず、対応する組織に異常なクラスタが存在します。

回避策: Namespace の削除をブロックした MonitoringTarget カスタムリソースからファイナライザを手動で削除します。

ダッシュボードとデータソースのファイナライザが保留中のため、プロジェクトの削除が停止する

バージョン: 1.14.3、1.14.4

修正済み: 1.14.3 ホットフィックス 22

現象: プロジェクトが削除されず、Namespace の終了に次のようなエラーが発生します。

Some resources are remaining: dashboards.observability.gdc.goog has 2 resource instances, datasources.monitoring.private.gdc.goog has 2 resource instances.

回避策: ダッシュボードとデータソースのファイナライザーを手動で削除します。

KSM の指標が表示されない

バージョン: 1.14.3

修正済み: 1.14.3 ホットフィックス 22

症状: KUB ダッシュボードのすべてのパネルに No Data が表示されます。

回避策: KSM サブコンポーネントを一時停止し、monitoringtarget と metricsproxysidecar を更新します。

サブコンポーネントを一時停止:

export SUBCOMPONENT_NAME=mon-kube-state-metrics
export SUBCOMPONENT_NAMESPACE=ORG_NAME
kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG annotate subcomponent "${SUBCOMPONENT_NAME:?}" -n "${SUBCOMPONENT_NAMESPACE:?}" lcm.private.gdc.goog/paused=true

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

ORG_NAME: 組織の名前。
ROOT_ADMIN_KUBECONFIG: root-admin kubeconfig のパス。

以下を .spec.destinations の mon-kube-state-metrics-metrics-proxy metricsproxysidecar に追加します。

- certificate:
  secretName: mon-pa-kube-state-metrics-cert
port: 8091

更新された mon-kube-state-metrics-metrics-proxy metricsproxysidecar は、次の例のようになります。

...
spec:
  containerName: otel-collector
  destinations:
  - certificate:
      secretName: mon-io-kube-state-metrics-cert
    port: 8090
  - certificate:
      secretName: mon-pa-kube-state-metrics-cert
    port: 8091
  resources:
    limits:
...

mon-pa-kube-state-metrics monitoringtarget 仕様から matchClusters: セクションを削除します。更新された mon-pa-kube-state-metrics monitoringtarget 仕様は次のようになります。

...
spec:
  podMetricsEndpoints:
    metricsRelabelings:
    - action: replace
      replacement: platform-obs
      targetLabel: _gdch_project
    path:
      value: /metrics
    port:
      value: 8091
    scheme:
      value: http
    scrapeInterval: 60s
    scrapeTimeout: 45s
  selector:
    matchLabels:
      monitoringtarget: mon-kube-state-metrics`

システム指標パイプラインがダウンしている

バージョン: 1.14.3

症状: MON-R0001 ランブックに沿って操作しても、MON-A0001 アラートがアクティブなままです。

回避策:

管理クラスタで問題が発生した場合は、IAC-R0004 ランブックを使用して、root-admin に次の SubcomponentOverride を作成します。ユーザークラスタ、境界クラスタ、共有クラスタなどの他のクラスタの場合は、${ORG}-mp に SubcomponentOverride を作成します。
```
kind: SubcomponentOverride
metadata:
  name: mon-cortex-tenant
  namespace: <NAMESPACE>
spec:
  backend:
    operableParameters:
      concurrency: 1024
      resourcesLimit:
        cpu: "8"
        memory: 16Gi
  subComponentRef: mon-cortex-tenant
```

正しい NAMESPACE を見つけます。

kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG get subcomponent -A | grep "mon-cortex-tenant"

出力は次のとおりです。

org-1-mp             mon-cortex-tenant                      27h   ReconciliationCompleted
org-1                mon-cortex-tenant                      46h   ReconciliationCompleted
root                 mon-cortex-tenant                      47h   ReconciliationCompleted

パイプラインが root-admin でダウンしている場合はルート、org-1 admin でダウンしている場合は org-1 になります。

kubectl --kubeconfig=ORG_ADMIN_KUBECONFIG get subcomponent -A | grep "mon-cortex-tenant"

出力は次のとおりです。

g-org-1-perimeter-cluster        mon-cortex-tenant                     40h   ReconciliationCompleted
g-org-1-shared-service-cluster   mon-cortex-tenant                     40h   ReconciliationCompleted
user-vm-1-cluster                mon-cortex-tenant                     40h   ReconciliationCompleted
user-vm-2-cluster                mon-cortex-tenant                     40h   ReconciliationCompleted

ここで、正しい Namespace は、システム指標パイプラインがどのクラスタでダウンしているかによって、g-org-1-perimeter-cluster、g-org-1-shared-service-cluster、user-vm-1-cluster、user-vm-2-cluster のいずれかになります。

SubcomponentOverride を適用したら、それぞれのクラスタで cortex-tenant デプロイを再起動します。それぞれのクラスタで値が更新されていることを確認します。
```
kubectl --kubeconfig ${KUBECONFIG:?} get configmap cortex-tenant-config -n mon-system -o yaml
```
同時実行フィールドを更新します。

cortex-tenant Deployment を再起動します。

kubectl --kubeconfig ${KUBECONFIG:?} rollout restart deployment/cortex-tenant -n mon-system

マルチテナンシー

コンソールにノードプールの作成失敗が表示されない

バージョン: 1.14.4、1.14.5、1.14.6

修正済み: 1.14.7

症状: GDC コンソールでノードプールの作成に失敗すると、UI に creation in progress メッセージが誤って表示され、ノードプールが正常に作成されたことが示されます。

回避策: gdcloud CLI を使用して、ノードプールの作成を検証します。

マルチゾーン

アクセスできないゾーンが認証ページにリダイレクトされる

バージョン: 1.14.x

現象: ゾーンにアクセスできない場合、GDC コンソールは認証エラーを表示するページにリダイレクトされます。ただし、ゾーンにアクセスできない原因は認証の問題ではなく、ゾーンの停止である可能性があります。

回避策: ゾーン URL を使用して、この問題を回避します。ゾーン URL も機能しない場合は、インフラストラクチャオペレーター（IO）に、認証の問題が発生しているゾーンがダウンしているかどうかを診断してもらいます。

gdcloud CLI を使用してゾーンを表示するロールが適用されない

バージョン: 1.14.x

現象: gdcloud zones list コマンドを使用するために必要な IAM ロールが、デフォルトで GDC ユニバースに適用されていません。事前定義ロールとして使用できないロールがないため、gdcloud CLI を使用してゾーンを一覧表示できません。

回避策: IAM ロール global-zone-viewer とロールバインディングリソースをグローバル API サーバーに適用します。

次の内容で、global-zone-viewer.yaml などのロール YAML ファイルを作成します。

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: global-zone-viewer
  namespace: mz-system
rules:
- apiGroups:
  - location.mz.global.private.gdc.goog
  resources:
  - zones
  verbs:
  - get
  - list
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: global-zone-viewer-binding
  namespace: mz-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: global-zone-viewer
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:authenticated

YAML ファイルを組織のグローバル API サーバーに適用します。

kubectl --kubeconfig ORG_GLOBAL_API_SERVER_KUBECONFIG apply -f global-zone-viewer.yaml

このロールバインディングは、システム内のすべてのユーザーを認証して、gdcloud zones list を使用してゾーンを表示します。

グローバルコンソール URL のログインエラーが断続的に発生する

バージョン: 1.14.x

現象: グローバル URL を使用して GDC コンソールにログインすると、セッションが無効になったというエラーが表示されることがあります。このエラーは、基盤となるネットワークのバグが原因で発生する可能性があり、セッションステータスを正確に表していない可能性があります。

回避策: ゾーン URL を使用して GDC コンソールにログインし、各ゾーン内からグローバルリソースを管理します。GDC コンソールからゾーンコンテキストを切り替える方法については、ゾーン間のリソースを管理するをご覧ください。

ネットワーキング

`MultiZoneNetworkConfig` ゾーンの順序を調整すると、構成の置換が失敗する

バージョン: 1.14.x のすべてのバージョンが影響を受ける可能性があります。

症状:

トップオブラック（ToR）スイッチの READY ステータスが False です。これは、次のコマンドを実行して確認できます。
```
kubectl get torswitches -A
```
スイッチ構成の置換が失敗し、エントリがすでに存在することを示すエラーが表示されます。これはスイッチ構成の置換ログで確認できます。次のようなエラーメッセージが表示されます。
```
% Insertion failed - entry already exists
```

この問題は、MultiZoneNetworkConfig 内のゾーンの順序を調整したことが原因で発生します。システムは、構成リスト内の各ゾーンの位置に基づいて、BGP アクセスリストルールのシーケンス番号を生成します。ゾーンの順序が変更されると、システムは異なるシーケンス番号を持つ新しいルールを生成します。このルールは、スイッチにすでに存在するルールと競合します。

回避策:

この問題を解決するには、影響を受ける各 ToR スイッチから競合する BGP AS パスアクセスリスト構成を手動で削除します。これにより、システムは正しい構成を調整して適用できます。

Ready 状態でない各 ToR スイッチへの SSH 接続を確立します。
グローバル構成モードに入ります。
```
config t
```
競合するアクセスリスト構成を削除します。
```
no ip as-path access-list other-zones
```
構成モードを終了します。

このコマンドが影響を受けるすべてのスイッチで実行されると、Reconciler は正しい構成を適用し、スイッチは READY 状態に移行します。

構成置換のコミットの有効期限

バージョン: 1.14.x のすべてのバージョンが影響を受ける可能性があります。

症状:

アクセス制御リスト（ACL）の数が多すぎると、ネットワークスイッチの構成時にタイムアウトが発生します。BorderLeafSwitch カスタムリソースが Ready 状態ではなく、準備ができていないスイッチで SSH 接続を確立すると、Commit expiry ステータスが表示されます。

たとえば、次のコマンドはステータスを表示します。

sh config-replace log verify

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

  Config-replace type: atomic .replace_tmp_11924
  Start Time: Wed Jul 09 18:08:33 2025
  Operation Status: Success
  Commit Status: Commit expiry

回避策::

1.14.3 または 1.14.7 以降のバージョンでは、root Namespace の pnet-core-override という名前の SubcomponentOverride カスタムリソースを編集し、.spec.operableParameters.netDevGW に httpTimeout フィールドを追加します。

apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: pnet-core-override
  namespace: root
spec:
  backend:
    bootstrapParameters:
      enableMetricsEncryption: true
    operableParameters:
      disableNetworkReconcilerFeatures: ""
      enableOperationStoragePVC: false
      netDevGW:
        httpTimeout: 10m
  subComponentRef: pnet-core

自動化インフラストラクチャが新しい構成をスイッチに push するまで 15 分待ちます。Commit expiry メッセージが表示されなくなるまで、必要に応じて httpTimeout を構成します。

1.14.4、1.14.5、1.14.6 バージョンでは、config-replace を手動で実行し、変更を commit します。

スイッチを一時停止します。

export SWITCH_NAME=SWITCH_NAME # example: aa-aa-blsw01
export SWITCH_TYPE=SWITCH_TYPE # example: borderleafswitch

kubectl -n gpc-system annotate $SWITCH_TYPE $SWITCH_NAME system.private.gdc.goog/paused="true"

PNET-P0001 ランブックに沿ってスイッチアクセスを取得します。
置換する構成を見つけます。
```
switch-cli# dir | grep new_config
```
構成の置換を完了します。
```
switch-cli# configure replace <new_config_file>
```
この処理には 5 分以上かかる場合があります。
config-replace が成功したら、変更を commit します。
```
switch-cli# configure replace commit
```

スイッチの再開:

kubectl -n gpc-system annotate $SWITCH_TYPE $SWITCH_NAME system.private.gdc.goog/paused-

4 バイトの BGP ASN を使用したデプロイが失敗する

バージョン: 1.14.3、1.14.4

現象: ネットワークスイッチで 4 バイトの自律システム番号（ASN）を使用して Border Gateway Protocol（BGP）を構成すると、構成が失敗します。BGP 構成が正しく適用されていないと、その GDC ゾーン内のネットワークで適切なルーティングを確立できず、接続の問題、ルートのアドバタイズの失敗、ネットワークの不安定さにつながる可能性があります。現時点では回避策はありません。

グローバルエニーキャストトラフィックがブロックされた

バージョン: 1.14.3

症状: グローバルエニーキャストエンドポイントに向かうトラフィックがアクセス制御リスト（ACL）によってブロックされます。

回避策:

グローバルエニーキャストトラフィックがアクセス制御リスト（ACL）によってブロックされる問題を解決するには、ルート管理クラスタに SubcomponentOverride カスタムリソースを作成して、グローバル DNS サーバーのエニーキャスト CIDR ブロックへのトラフィックを明示的に許可する必要があります。手順は次のとおりです。

すべてのグローバルエニーキャスト CIDR ブロックを見つけます。更新するグローバルエニーキャスト CIDR ブロックを見つける手順は次のとおりです。
1. ルートグローバル API サーバーに接続します。
2. 次のコマンドを使用して、すべての Namespace のすべてのサブネットカスタムリソースを一覧表示します。
```
kubectl get subnet -A
```
3. 出力結果をフィルタして、metadata.name フィルタにキーワード anycast が含まれるサブネットリソースを見つけます。
4. 名前に anycast が含まれるサブネットリソースごとに、spec.subnet の値をメモします。この値は、グローバルエニーキャスト CIDR ブロックを表します。

ルート管理クラスタで、ルート Namespace に pnet-trafficpolicy-dc-override という名前の SubcomponentOverride カスタムリソースを作成します。前の手順で特定したエニーキャストサブネットごとに、YAML ファイルに示すようにルールを追加します。

apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: pnet-trafficpolicy-dc-override
  namespace: root
spec:
  backend:
    operableParameters:
      breakglassRules:
        default-traffic-policy-data:
        - IPVersions:
          - IPv4
          L4Protocol: IP
          action: Accept
          description: INTERCONNECT_RULE_DESCRIPTION
          destinationEndPoint:
            host:
              hostPrefix: GLOBAL_ANYCAST_CIDR
            port:
              portType: ANY
          direction: Ingress
          enforcePoints:
          - enableLogging: false
            enforcePointType: DataInterconnect
          sourceEndPoint:
            host:
              hostType: ANY
            port:
              portType: ANY
        - IPVersions:
          - IPv4
          L4Protocol: IP
          action: Accept
          description: HAIRPIN_RULE_DESCRIPTION
          destinationEndPoint:
            host:
              hostType: ANY
            port:
              portType: ANY
          direction: Ingress
          enforcePoints:
          - enableLogging: false
            enforcePointType: DataHairpin
          sourceEndPoint:
            host:
              hostPrefix: GLOBAL_ANYCAST_CIDR
            port:
              portType: ANY
  subComponentRef: pnet-trafficpolicy-dc

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

INTERCONNECT_RULE_DESCRIPTION: 相互接続ネットワークルールの説明テキスト。
GLOBAL_ANYCAST_CIDR: グローバルエニーキャスト CIDR ブロック（136.125.38.128/28 など）。前の手順で見つけたエニーキャストごとに、この YAML ファイルを使用してルールを作成します。
HAIRPIN_RULE_DESCRIPTION: ヘアピンネットワークルールの説明テキスト。

部分的な DCI の障害によりトラフィックが失われる

バージョン: 1.14.3

現象: ゾーンのボーダーリーフスイッチをキャリアスイッチに接続するデータセンター相互接続（DCI）リンクの両方がダウンした場合、またはゾーンのボーダーリーフスイッチでハードウェア障害が発生した場合、ゾーン間のネットワークトラフィックの約 50% が失われます。

VRF 名が長すぎる

バージョン: 1.14.2

症状: このコマンドを実行すると、スイッチが正常でないことを示す次のようなメッセージが表示されることがあります。

sh config-replace log verify

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

Operation            : Config-replace to user config
Checkpoint file name : .replace_tmp_20791
Scheme               : tmp
Cfg-replace done By  : admin
Cfg-replace mode     : atomic
Verbose              : disabled
Start Time           : Fri, 20:03:38 08 Nov 2024
Start Time UTC       : Fri, 20:03:38 08 Nov 2024
-------------------------------------------
Command : snmp-server context gdch-services-orginfrainternal-vrf vrf gdch-servic
es-orginfrainternal-vrf, parse error : -20, mode : /exec/configure/vrf
Failed to parse: snmp-server context gdch-services-orginfrainternal-vrf vrf gdch
-services-orginfrainternal-vrf
Configuration above is invalid or not supported via CR/rollback feature

回避策: 組織 CR の名前は最大 19 文字です。

StatefulSet Pod の通信が失敗する

バージョン: 1.14.3、1.14.4

修正済み: 1.14.3 hotfix 23、1.14.5

症状: 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*]

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

これは、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

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*]

マルチゾーンのクロスゾーンの可用性 SLO Grafana ダッシュボードの問題

バージョン: 1.14.3

現象: Grafana で、pnet-cross-zone-availability SLO ダッシュボードに指標が表示されません。

回避策: PNET-P0001 ランブックに沿ってスイッチへのアクセス権を取得し、マルチゾーン BGP セッションと接続ステータスを手動で確認します。

データプレーンと管理上り（内向き）ゲートウェイの調整に失敗する

バージョン: 1.14.3

症状: サブコンポーネント asm-dataplane-ingress または asm-management-ingress が次のエラーで調整に失敗します。

message: 'Reconciliation error: E0111 - upgrade chart: cannot patch "management-ingress-gateway" with kind BackendService: BackendService.networking.gdc.goog "management-ingress-gateway" is invalid: spec.targetPorts: Invalid value: "array": TargetPorts list is immutable'

エラー文字列で BackendService の代わりに指定できる値は、ForwardingRuleInternal と ForwardingRuleExternal です。同様に、リソース名は management-ingress-gateway ではなく dataplane-ingress-gateway、dataplane-ingress-gateway-global、management-ingress-gateway-global になることもあります。

回避策: リソースが Management API サーバーまたはグローバル API サーバーに存在するかどうかを確認します。これは、エラー文字列のリソースタイプの API バージョンから推測できます。たとえば、接尾辞 networking.gdc.goog のリソースは管理 API サーバーに存在しますが、接尾辞 networking.global.gdc.goog のリソースはグローバル API サーバーに存在します。

API サーバーを特定したら、対応する kubeconfig ファイルを使用してリソースを削除します。次に例を示します。

kubectl --kubeconfig API_SERVER_KUBECONFIG delete Backendservice dataplane-ingress-gateway -n istio-system

プロジェクトネットワークポリシーページで、ProjectNetworkPolicy API のプロジェクトセレクタフィールドがサポートされていない

バージョン: 1.14.3、1.14.4

現象: projectSelector フィールドを含むプロジェクトネットワークポリシーを作成し、GDC コンソールで表示すると、UI には projectSelector フィールドのプロジェクトではなく、ポリシーで選択されたすべてのプロジェクトが表示されます。

回避策: API を使用して、projectSelector フィールドを含むプロジェクトネットワークポリシーを作成して読み取ります。

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

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

バージョン: 1.14.3

現象: サーバーのプロビジョニング中に、Harbor レジストリから OS イメージをダウンロードすると、対応する BaremetalHost カスタムリソースに次の 401 エラーが表示され、サーバーがプロビジョニング解除と再プロビジョニングのループで停止します。

これらのエラーを確認するには、BaremetalHost カスタムリソースを記述します。

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG describe baremetalhost SERVER_NAME -n gpc-system

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

Normal  InspectionComplete     14m    metal3-baremetal-controller  Hardware inspection completed
Normal  ProvisioningStarted    5m39s  metal3-baremetal-controller  Image provisioning started for https://robot%24om5hgylsfvzxs43umvwtu43boiwwc4djmv4hizloonuw63rnmjqwg23fnzsc2ylqnfsxq5dfnzzws33ofvzwk4twmvza:4usy4JXE6BAdEVU2t8LMqDPhfM4EnW73@10.129.24
.66:31714/artifacts/serve/Z3BjLXN5c3RlbS1vcy1pbWFnZXMvZ2RjaC1ub2RlLW9zOnJvY2t5LTg2LTEuMTQtdjIwMjQxMDIzLTEuMTQtcjI4MQ==
Normal  ProvisioningError      5m28s  metal3-baremetal-controller  Image provisioning failed: Failed to prepare to deploy: Validation of image href https://robot%24om5hgylsfvzxs43umvwtu43boiwwc4djmv4hizloonuw63rnmjqwg23fnzsc2ylqnfsxq5dfnzzws33ofvzwk
4twmvza:4usy4JXE6BAdEVU2t8LMqDPhfM4EnW73@10.129.24.66:31714/artifacts/serve/Z3BjLXN5c3RlbS1vcy1pbWFnZXMvZ2RjaC1ub2RlLW9zOnJvY2t5LTg2LTEuMTQtdjIwMjQxMDIzLTEuMTQtcjI4MQ== failed, reason: Got HTTP code 401 instead of 200 in response to HEAD request.
Normal  DeprovisioningStarted  5m17s  metal3-baremetal-controller  Image deprovisioning started

回避策:

サーバーが属する nodePoolClaim の名前と名前空間を取得します。

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get server SERVER_NAME -n gpc-system -ojson | jq '.spec.nodePoolClaimRef'

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

{
"name": "control-plane-extension-pool-o2-standard1-96-gdc-metal",
"namespace": "gpu-org-lancer"
}

NodePoolClaim から OS イメージ名を取得します。

kubectl get nodepoolclaim NODEPOOLCLAIM_NAME -n NODEPOOLCLAIM_NAMESPACE -o json | jq '.spec.machineSpec.osImageName'

OSImageMetadata から OS イメージの URL を取得します。

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get osimagemetadata OS_IMAGE_NAME -o json | jq '.commonMetadata.servingURL'

最新の OS イメージ URL を使用して Server カスタムリソースを更新します。

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG patch server SERVER_NAME -n gpc-system --type=json -p='[{"op": "replace", "path": "/spec/image/urlSpec/url", "value" : "'OS_IMAGE_URL'"}]'

OS NodeUpgrade が NodeOSInPlaceUpgradePostProcessingCompleted ステップで停止する

バージョン: 1.14.3、1.14.4

症状:

ノードのアップグレード中に、NodeUpgradeTask が NodeOSInPlaceUpgradePostProcessingCompleted ステップで停止し、failed verifying delta after upgrade というメッセージを含む Reconciler エラーが発生して、完了できません。このエラーは、アップグレードの検証プロセスでノードに予期しないパッケージの不一致が見つかったことを示します。具体的には、アップグレード試行後も「need-upgrade」状態のままになっているか、「only-in-new」パッケージとして表示されるパッケージを特定します。

エラーメッセージには、検証に失敗した特定のパッケージが一覧表示されます。スニペットの例:

{"ts":1748758118826.9954,"caller":"controller/controller.go:329","msg":"Reconciler error","controller":"NodeUpgradeTask","controllerGroup":"upgrade.private.gdc.goog","controllerKind":"NodeUpgradeTask","NodeUpgradeTask":{"name":"lancer-org1-data-plane-pool-o2-standard1-96-gdc-metal-nmw2h-zx-ac-bm15","namespace":"lancer-org1"},"namespace":"lancer-org1","name":"lancer-org1-data-plane-pool-o2-standard1-96-gdc-metal-nmw2h-zx-ac-bm15","reconcileID":"26585774-7059-46b7-a0f7-0e627b2a2bb5","err":"failed verifying delta after upgrade: 2 errors occurred:\n\t* failed to make \"need-upgrade\" empty, found\n  - bind-export-libs\n  from: 9.11.36-16.el8_6.86ciq_lts.2\n  to: 9.11.36-16.el8_6.86ciq_lts.4\n...\n- strongswan-sqlite\n  from: 5.9.10-1.el8_6.ciqlts\n  to: 5.9.10-2.el8\n\t* failed to make \"only-in-new\" empty, found lsof=4.93.2-1.el8\nstrace=5.13-4.el8\n\n"}

この現象は、次の 2 つの問題が原因で発生する可能性があります。まず、どの問題が原因であるかを検出します。

Cause-A: マシンにアクセスできないため、OSArtifactSnapShot が古くなっています。

アップグレード中のノードが正常かどうか、対応する OSArtifactSnapShot ジョブが失敗しているかどうかを確認します。

OSArtifactSnapShot が古く、マシンに 20 分以上アクセスできない場合は、Mitigation-A に進みます。それ以外の場合は、Cause-B の確認を続けます。
Cause-B: サイレント RPM アップグレードの失敗

まれに、部分的なアップグレード後に、マシンの RPM アップグレードがサイレントに失敗することがあります。アップグレード前後のパッケージの差分を含む 2 つの ConfigMap が存在します。
```
in-place-delta-<CLUSTER_NAME>-<NODE_NAME>-before-upgrade
in-place-delta-<CLUSTER_NAME>-<NODE_NAME>-after-upgrade
```
「after-upgrade」に含まれるパッケージの数が「before-upgrade」の ConfigMap よりも少ない場合、アップグレードがサイレントに中止され、すべてのパッケージがアップグレードされなかったことを意味します。Mitigation-B に進みます。

回避策:

Mitigation-A: 接続できないマシンを修復する

マシンを再起動して修復を試みます。再起動を試してもマシンにアクセスできない場合は、SERV チームにお問い合わせください。マシンが再びアクセス可能になったら、OSArtifactSnapShot を削除して強制的に調整します。OSArtifactSnapShot が調整されると、NodeUpgradeTask は次のステップに進みます。

Mitigation-B: NodeUpgradeTask を再試行します。

アップグレードするマシンに SSH 接続し、今後のトラブルシューティングのために次のログを収集します。次のファイルを収集する必要があります。
- /var/log/dnf.log
- /var/log/dnf.rpm.log
- dnf history > dnf_history.log
- rpm -qa --last > rpm_last.log
障害が発生した NodeUpgradeTask を削除します。これにより、特定のノードで NodeUpgradeTask の再試行がトリガーされます。新しい NodeUpgradeTask は RPM アップグレードを完了し、次のステップに進みます。

OS NodeUpgrade がパッケージサーバーの作成ステップで停止する可能性がある

バージョン: 1.14.3、1.14.4

症状:

NodeUpgrade CR が作成されて一時停止が解除され、30 分以上 in-progress の状態が続くと、パッケージサーバーの作成段階でエラーが発生する可能性があります。症状は、NodeUpgrade が .status.upgradeStatus=in-progress のままになり、.status.tasks が読み込まれないことです。

status:
  duration: 0s
  upgradeStatus: in-progress

パッケージサーバーの作成時に失敗することをさらに確認するには、OS アップグレードコントローラのログを読み取ります。

kubectl logs deployment/os-upgrade-controller -n os-system --kubeconfig=/path/to/admin-cluster-kubeconfig-of-the-nodeupgrade-object

コントローラのログに failed to create package server と failed to create package repo server DNS registration が詳細な理由（次のいずれか）とともに表示されている場合

spec.fqdnPrefix already used in an existing DNS registration
name already used in an existing DNS。

次に、他の NodeUpgrade で使用されている他のパッケージサーバーリソースがまだ存在しており、現在のハングアップしている NodeUpgrade の作成対象リソースと競合していることを示します。

回避策:

さらに確認するには、実際のパッケージサーバーリソース（NodeUpgrade CR を管理するクラスタの管理 API サーバーの dnsregistration.network.private.gdc.goog など）を確認し、それらのリソースを所有する NodeUpgrade を見つけます。DNSRegistration を所有する NodeUpgrade がすでに完了しているにもかかわらず、DNSRegistration リソースがまだ削除されていない場合は、参照されているすべての NodeUpgrade オブジェクトが完了していれば、DNSRegistration オブジェクトを削除できます。

NodeUpgrade パッケージサーバーのすべての DNSRegistration CR を一覧表示します。

kubectl get dnsregistration.network.private.gdc.goog -n $NAMESPACE $NAME $ -ojson --kubeconfig=/path/to/mgmt-api-server-kubeconfig-of-the-nodeupgrade-object | grep nu-bm

特定の DNSRegistration のオーナー NodeUpgrade CR をクエリします。

kubectl get dnsregistration.network.private.gdc.goog -n $NAMESPACE $NAME $ -ojson --kubeconfig=/path/to/mgmt-api-server-kubeconfig-of-the-nodeupgrade-object | jq -r '.metadata.annotations."package-server-owners"'

ノード OS のアップグレードで問題が発生し、プロセスのどの段階でも停止する可能性がある

バージョン: 1.14.4、1.14.5、1.14.6

症状:

NodeUpgradeTask CR は 2 時間以上 in-progress のままですが、十分な時間があれば自動完了できる可能性があります。

NodeUpgradeTask CR が 2 時間以上進行中です。最終的には自動補完される可能性がありますが、根本的な問題は、os-policy-reconciler が大量の OSPolicy CR を効率的に管理できないことです。この問題は NodeOSInPlaceUpgradeCompleted ステップで発生します。

パッケージサーバーの作成中にこの障害をさらに確認するには、OS アップグレードコントローラのログを参照してください。

kubectl logs deployment/os-upgrade-controller -n os-system --kubeconfig=/path/to/admin-cluster-kubeconfig-of-the-nodeupgrade-object

コントローラログに NodeUpgradeTask からの OSPolicy エントリがない場合、コントローラが過負荷状態であることを示します。

回避策:

アップグレードプロセス中は、必須ではないすべての OSPolicy CR を一時停止します。

大容量ファイルの「storage cp」により org-mgmt kube-api がダウンする

バージョン: 1.14.3 以降

症状: OIC ワークステーションからの gdcloud storage cp オペレーションまたは gdcloud system container-registry load-oci オペレーション中に、org-infra へのアクセスが失われ、org-mgmt の kube-api がダウンする可能性があります。これはまれな問題であり、エンジニアリング用のデータを収集することが役立ちます。

回避策: この問題が発生した場合は、次の手順をお試しください。

コントロールプレーン（CP）ノードごとに uptime を実行して、過去 24 時間以内にノードが再起動されたかどうかを確認します。
再起動した時間をメモします。
dmesg | grep -i 'kernel panic' を実行して、再起動の直前に発生した各 CP ノードのカーネルパニックを確認します。
各 CP ノードで、lspci | grep -i eth | grep -i mellanox を実行して Mellanox NIC カードがインストールされているかどうかを確認します。Mellanox NIC がない場合は、この既知の問題の読み取りを停止します。
各 CP ノードで、data0 の次のネットワーク設定を確認します。
```
[root@cp-node-01 ~]# ethtool -k data0 | grep -E 'generic-receive-offload|large-receive-offload|rx-checksumming|rx-gro-hw'
rx-checksumming: off
generic-receive-offload: on
large-receive-offload: off
rx-gro-hw: on  # <--- Check this value
```
すべてのノードで rx-gro-hw（上記を参照）が「off」に設定されている場合は、この既知の問題の読み取りを停止してください。

Google が問題を診断するうえで役立つ情報を収集します。

k8s.org get po -n anthos-identity-service -l k8s-app=ais

k8s.org get po -n management-kube-system

k8s.org get po -n kube-system -l component=kube-apiserver

k8s.org get nodes -l node-role.kubernetes.io/control-plane

各 CP ノードで、次のコマンドを実行します。

dmesg | grep -i 'kernel panic'

journalctl -u disable-rx-gro-hw.service

systemctl status disable-rx-gro-hw

modinfo mlx5_core | grep ^version:

ネットワーク設定の問題を軽減するには、すべての CP ノードで次のコマンドを実行して、rx-gro-hw を off にする必要があります。
```
ethtool -K data0 rx off gro off lro off
ethtool -K data1 rx off gro off lro off
ethtool -K bond00 rx off gro off lro off
```

設定を再度確認します。

[root@cp-node-01 ~]# ethtool -k data0 | grep -E 'generic-receive-offload|large-receive-offload|rx-checksumming|rx-gro-hw'
rx-checksumming: off
generic-receive-offload: on
large-receive-offload: off
rx-gro-hw: off # <--- Check this, should be "off"

元のオペレーション（gdcloud storage cp、gdcloud system container-registry load-oci など）を再試行します。それでも失敗する場合は、エンジニアリングにお問い合わせください。

Operations Suite Infrastructure Core Services（OIC）

ジャンピングホストのパフォーマンスが低い

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

症状: ブラウザまたはシステムのオペレーションの完了に時間がかかりすぎる。

回避策:

BM03 と BM04 の Hyper-V マネージャーを使用して、ジャンプホストの vCPU 数を増やします。

ジャンプホスト VM を選択し、アクションペインで [設定] をクリックします。
[プロセッサ] を選択し、ワークロードに応じて [仮想プロセッサの数] のカウントを 4 以上に増やします。
残りのジャンプホストについても同様の手順を繰り返します。

リソース管理者

GDC コンソールでプロジェクトを削除できない

バージョン: 1.14.3、1.14.4

現象: GDC コンソールの [プロジェクトの詳細] ページに、既存のプロジェクトの [削除] 削除ボタンが表示されますが、このボタンが機能しません。

回避策: 既存のプロジェクトを削除するには、gdcloud CLI を使用する必要があります。詳細については、プロジェクトを削除するをご覧ください。

組織の Ansible Playbook が見つからない

バージョン: 1.14.3

現象: 組織の作成時に、必要な Ansible プレイブックを作成するジョブ create-ansible-playbooks がエラーを返さずに失敗します。Ansible プレイブックがないと、境界仮想マシンがない、グローバル組織の作成に関する問題が発生するなどの問題が発生します。

回避策: OS-R0009 ランブックに沿って、不足している組織の Ansible プレイブックを手動で作成します。

非対称のグローバル組織で存在しないゾーン構成が表示される

バージョン: 1.14.4

現象: ゾーン組織構成のサブセットのみを使用して v1 グローバル組織を作成すると、すべてのゾーンに組織レプリカのステータスが表示されます。たとえば、3 つのゾーンがある GDC ユニバースがあり、2 つのゾーンに対してのみゾーン組織構成を作成した場合、3 番目のゾーンには、存在しない 3 番目のゾーン組織のエラーレプリカステータスが表示されます。

誤ったステータスを確認するには、グローバル組織のステータスを出力します。

kubectl --kubeconfig GLOBAL_ROOT_ADMIN_KUBECONFIG get organization \
    ORG_NAME -n gpc-system -o yaml

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

...

- name: zone3
  replicaStatus:
    systemInfo:
      cidrInfo: {}
  rolloutStatus:
    conditions:
    - lastTransitionTime: "2025-03-12T02:09:21Z"
      message: ""
      observedGeneration: 1
      reason: Current
      status: "True"
      type: Synced
    - lastTransitionTime: "2025-03-12T02:09:22Z"
      message: rollout succeeded
      observedGeneration: 1
      reason: RolloutSucceeded
      status: "True"
      type: Replicated

...

非対称のゾーン構成は v2 組織ではサポートされていないため、これは v1 組織でのみ発生します。

回避策: ゾーン組織は明示的に作成しない限り存在しないため、誤ったレプリカステータスは無視できます。

クラスタ

インフラストラクチャクラスタのワーカーノードプールが削除されない

バージョン: 1.14.3、1.14.4

現象: Organization CR 仕様からワーカーノードプールを削除しても、ノードプールは自動的に削除されません。つまり、kubectl get nodepool data-plane-pool-{machine-class} -n {org-name} コマンドは削除されるノードプールをまだ出力します。

# Organization CR example
apiVersion: resourcemanager.private.gdc.goog/v1alpha1
kind: Organization
...
spec:
  resourceCapacities:
    workloadServers:
      o2-standard1-96-gdc-metal: 4 # worker node pool to remove
...

回避策: Organization CR 仕様からワーカーノードプールを削除した後、次のコマンドを実行して、このノードプールの NodePoolClaim CR をルート管理者クラスタから手動で削除します。sh kubectl delete nodepoolclaim data-plane-pool-{machine-class} -n {org-name}

NodePoolClaim とそれに関連付けられた NodePool CR が完全に削除されるまで待ちます。つまり、kubectl get nodepool data-plane-pool-{machine-class} -n {org-name} コマンドでワーカーノードプールが出力されなくなるまで待ちます。

ストレージ

`gdcloud config set zone` コマンドで作成したバケットを削除できない

バージョン: 1.14.7 以降

症状: gdcloud config set zone コマンドで作成されたバケットが、権限の問題により削除に失敗します。これは、コマンドが間違ったゾーンで動作しようとするためです。

回避策: コンソールを使用してバケットの特定のゾーンを設定するか、gdcloud コマンドで --zone フラグを --location に置き換えます。

OBJ SLO アラート起動

バージョン: 1.14.3、1.14.4

現象: OBJ プロキシの ErrFailedStreamingDecryptRequest エラーにより、OBJ の SLO アラート（obj-list-object-ops-availability-slo、obj-rw-object-ops-error-rate-slo）が発動します。

回避策: アラートをミュートします。ユーザーが接続を終了したことが原因で SLO の対象外であるにもかかわらず、エラーがシステムエラーとして誤って識別されています。

S3 UploadPart Empty ETag

バージョン: 1.14.3

現象: UploadPart リクエストを送信した後、レスポンスメッセージで 200 Success ステータスコードを取得しましたが、ETag フィールドが空です。このエラーは、ネットワークの中断により InternalServerError が発生し、ステータスコードが 500 InternalServerError に更新されないために発生します。

回避策: リクエストが以前に失敗したかのように再試行します。

Trident `mkfs.ext4` エラーにより Pod がマウントに失敗する

バージョン: 1.14.3

症状: Pod のマウントを試みた後、特定のノードとの間で移行するすべての Pod が失敗します。rpc エラーメッセージ DeadlineExceeded desc = context deadline exceeded が表示され、ノードが停止していることが示されます。このメッセージが表示されると、問題のノードで追加の Trident オペレーションを実行できなくなります。データを処理するボリュームは影響を受けませんが、ノードとの間で移動するボリュームは停止する可能性があります。

回避策:

Pod がマウントしようとしているノードの Trident ログを調べて、キューが増加していることを確認します。ログは次のようになります。

2025-01-24T00:27:22.783599667Z time="2025-01-24T00:27:22Z" level=debug msg="Attempting to acquire shared lock (NodeUnstageVolume-pvc-0f04a9c5-00fc-4c3c-9fc1-6730598f7caa); 421 position in the queue." lock=csi_node_server logLayer=csi_frontend requestID=94c8ad12-6479-4e1c-8791-118b565d6c6b requestSource=CSI workflow="node_server=unstage"

ノードにログインして、dmesg の出力を確認します。ログは次のようになります。

Jan 31 02:43:47 ap-ae-bm18 kernel: blk_cloned_rq_check_limits: over max size limit. (524280 > 128)
Jan 31 02:43:47 ap-ae-bm18 kernel: blk_cloned_rq_check_limits: over max size limit. (524280 > 128)
Jan 31 02:43:47 ap-ae-bm18 kernel: device-mapper: multipath: 253:40: Failing path 65:144.
Jan 31 02:43:47 ap-ae-bm18 kernel: blk_cloned_rq_check_limits: over max size limit. (524280 > 128)
Jan 31 02:43:47 ap-ae-bm18 kernel: device-mapper: multipath: 253:40: Failing path 65:160.
Jan 31 02:43:47 ap-ae-bm18 kernel: blk_cloned_rq_check_limits: over max size limit. (524280 > 128)

Trident mkfs.ext4 エラーが発生していることを確認したら、ノードを再起動します。

既存のエラーのため、Trident がボリュームの作成に失敗する

バージョン: 1.14.3

症状:

PVC がプロビジョニングされず、次のようなイベントが表示されます。

failed to create cloned volume {pvc-bab6bc52-fd37-4ead-a57b-e833e14c172a} on backend iscsi-san: volume trident_pvc_bab6bc52_fd37_4ead_a57b_e833e14c172a already exists

このイベントが発生すると、回避策を実行するまで PVC はプロビジョニングされません。

回避策:

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

イベントから内部ボリューム名をメモします。たとえば、症状セクションに表示されているサンプルイベントには、内部ボリューム名 trident_pvc_bab6bc52_fd37_4ead_a57b_e833e14c172a が表示されています。
FILE-R0105 ランブックに沿って ONTAP にアクセスします。

ボリュームを削除します。

volume delete trident_pvc_bab6bc52_fd37_4ead_a57b_e833e14c172a

`file_block_iscsi_sessions_unhealthy alert` で誤検出が報告される

バージョン: 1.14.3

症状: 一部の環境で、1 つ以上のノードで iSCSI エラーが発生していることを示す file_block_iscsi_sessions_unhealthy アラートがトリガーされます。file-observability コントローラは、カスタム指標コレクタを使用して各 Kubernetes ノードの iSCSI セッションの健全性を追跡しますが、場合によっては、指標コレクタが iscsiadm コマンドの出力を解析できず、iSCSI に正常なセッションがあるにもかかわらず、実行中の iSCSI セッションがゼロと報告します。

回避策:

次の手順に沿って、iSCSI で問題が発生していないことを確認し、アラートが誤検出の場合はアラートをミュートします。

Grafana の探索ページで、クエリ fb_sessions_running_count{job="file-observability-backend-target.file-system"} を実行します。このクエリは、クラスタ内のすべてのノードの指標を返します。fb_sessions_running_count 指標が 0 を報告しているノードがある場合は、そのノードの名前を書き留めます。
fb_sessions_running_count 指標が 0 を返すノードごとに、次のコマンドを実行します。
1. 影響を受けるノードとの SSH 接続を確立します。
2. iscsiadm -m session コマンドを実行します。複数の行が返されるはずです。各行は実行中の iSCSI セッションです。コマンドから何も返されない場合や、出力にエラーがある場合は、ファイルブロックエンジニアリングチームに問題をエスカレーションします。
3. 前のコマンドが iSCSI セッションを正常に返した場合は、このノードのアラートが誤検出であることを確認しました。
影響を受けるすべてのノードで iSCSI セッションが正常であり、アラートが誤って発生していることを確認したら、AlertManager でサイレンスを作成して file_block_iscsi_sessions_unhealthy アラートをサイレンスします。

スペアディスクに対して `file_block_storage_disk_failure` アラートがトリガーされる

バージョン: 1.14.3

現象: 環境によっては、ONTAP の 1 つ以上のディスクが異常であることを示す file_block_storage_disk_failure アラートがトリガーされます。file-observability コントローラは、カスタム指標コレクタを使用して ONTAP の各ディスクの健全性を追跡しますが、以前の GDC リリースでは、コレクタはスペアディスクを正常と見なさないため、スペアディスクのアラートがトリガーされます。

回避策:

次の手順に沿って、ディスクがスペアであることを確認し、ディスクのアラートをミュートします。

Grafana の探索ページで、クエリ disks_labels_healthy{job="file-observability-backend-target.file-system"} を実行します。このクエリは、ONTAP のすべてのディスクの指標を返します。指標が 0（異常）と報告されているディスクがある場合は、そのディスクの名前を書き留めます。
disks_labels_healthy 指標が 0 を返すディスクごとに、次のコマンドを実行します。
1. ONTAP クラスタに SSH で接続し、指標クエリから収集したディスク名を使用して disk show -disk <disk-name> -fields state コマンドを実行します。
2. コマンドの出力で、ディスクの状態が present または spare であることを確認します。ディスクが present または spare 以外の状態の場合は、ファイルブロックエンジニアリングチームに問題をエスカレーションします。
3. 問題のディスクが present または spare を報告している場合は、このディスクでアラートが発生しないことを確認できます。AlertManager でミュートを作成して、disk_name ラベルがディスクの名前に設定されている file_block_storage_disk_failure アラートをミュートします。
すべてのスペアディスクのミュートを作成したら、Grafana に移動して、アラートが停止したことを確認します。

接続が復元された後に file_block_storage_node_peer_connection_unhealthy アラートがトリガーされる

バージョン: 1.14.3

現象: 一部の環境で、ONTAP ノード間の 1 つ以上の接続が失敗したことを示す file_block_storage_node_peer_connection_unhealthy アラートがトリガーされます。file-observability コントローラは、カスタム指標コレクタを使用して、これらの接続の健全性を追跡します。接続の失敗が復元された後もこのアラートが引き続き発生するという既知の問題があります。

回避策:

次の手順に沿って、ノード間の接続が正常であることを確認し、ノードのアラートをミュートします。

Grafana の探索ページで、クエリ storage_node_peer_connections{job="file-observability-backend-target.file-system"} を実行します。このクエリは、クラスタ内のストレージノード間の接続ごとに指標を返します。接続のいずれかで storage_node_peer_connections 指標が 0 と報告されている場合は、指標から source_node、destination_ip、storage_cluster_name のラベルを書き留めます。
0 を返す storage_node_peer_connections 指標ごとに、次のコマンドを実行します。
1. storage_cluster_name ラベルから ONTAP ストレージクラスタとの SSH 接続を確立します。
2. source_node ラベルと destination_ip ラベルの値を使用して、ONTAP クラスタで次のコマンドを実行します。
```
ping -node <node-name> -destination <destination-ip> -verbose -show-detail
```
ping コマンドが失敗した場合は、ファイルブロックエンジニアリングチームに問題をエスカレーションします。ping コマンドが成功した場合、ノード接続は正常であり、アラートが誤って発生していることが確認されます。
1. AlertManager でミュートを作成し、source_node ラベルと destination_ip ラベルを指標の送信元ノードと宛先 IP に設定して、file_block_storage_node_peer_connection_unhealthy アラートをミュートします。
すべての正常なノードに対してミュートが作成されたら、Grafana に移動して、アラートが停止したことを確認します。

接続が復元された後に file_block_nodes_not_reachable アラートがトリガーされる

バージョン: 1.14.3

症状: 一部の環境では、Kubernetes ノードの IPsec サービスから ONTAP への 1 つ以上の接続が失敗したことを示す file_block_nodes_not_reachable アラートがトリガーされます。file-observability コントローラは、カスタム指標コレクタを使用して、これらの接続の健全性を追跡します。接続の失敗が復元された後もこのアラートが引き続き発生するという既知の問題があります。

回避策:

次の手順に沿って、ノードの接続が正常であることを確認し、ノードのアラートをミュートします。

Grafana の探索ページで、クエリ fb_all_nodes_reachable{job="file-observability-backend-target.file-system"} を実行します。このクエリは、クラスタ内のすべてのノードの指標を返します。fb_all_nodes_reachable 指標が 0 を報告しているノードがある場合は、そのノードの名前を書き留めます。
fb_all_nodes_reachable 指標が 0 を返すノードごとに、次のコマンドを実行します。
1. 影響を受けるノードとの SSH 接続を確立します。
2. 次のコマンドを実行します。
```
journalctl -u strongswan | grep "sending packet" | sed "s/\[/ /g" | sed "s/\]/ /g" | awk '{ print $14 }' | sort -n | uniq | awk '{print "ping -c 5 " $1}' | sh
```
  このコマンドは、すべての IPsec 接続を使用して ontap に ping を試みます。コマンドの ping が失敗した場合は、ファイルブロックエンジニアリングチームに問題をエスカレーションします。ping コマンドが成功した場合、ノード接続は正常であり、アラートが誤って発生していることが確認されます。
3. コマンド内のすべての ping が成功した場合、ノードの接続が正常であり、アラートが誤って発生していることが確認されます。AlertManager でサイレンスを作成して、node_name ラベルがノードの名前に設定されている file_block_nodes_not_reachable アラートをサイレンスします。
すべての正常なノードに対してミュートが作成されたら、Grafana に移動して、アラートが停止したことを確認します。

ワークロードの負荷が高いときに `file_block_storage_high_node_total_latency` アラートが発生する

バージョン: 1.14.3

症状: ストレージノードのワークロードが重い場合、特定の環境で file_block_storage_high_node_total_latency アラートがトリガーされることがあります。このアラートは、これらのワークロードが完全に処理されるまで継続します。ボリュームの読み取りと書き込みのパフォーマンスが高速であっても、ストレージノードは特定のブロックオペレーションで高レイテンシを報告することがあります。

回避策:

健全なボリュームレイテンシを確認し、ストレージノードレイテンシアラートをミュートする手順は次のとおりです。

ボリュームレイテンシアラートを確認します。
1. Grafana で、file_block_storage_high_volume_write_latency アラートと file_block_storage_high_volume_read_latency アラートがトリガーされず、ボリュームの最適なレイテンシ時間が報告されていることを確認します。
ボリュームレイテンシが高い場合はエスカレーションします。
1. ボリューム書き込みアラートまたはボリューム読み取りアラートのいずれかが発生している場合は、ストレージシステム全体のレイテンシが高いことを示します。この問題をファイルブロックのエンジニアリングチームにエスカレーションします。
ノードレイテンシアラートをミュートします（ボリュームが正常な場合）。
1. ボリューム書き込みアラートとボリューム読み取りアラートの両方が正常な場合、ノードレイテンシアラートは偽陽性である可能性があります。
2. AlertManager で file_block_storage_high_node_total_latency アラートのミュートを作成します。
3. ミュートを作成したら、Grafana に移動して、アラートが停止したことを確認します。

ブロックされたノードのアップグレード

バージョン: 1.14.3、1.14.4、1.14.5、1.14.6、1.14.7

症状: このブロックは、LUN（論理ユニット番号）が読み取り専用になったときに発生します。これは、スナップショットの問題が原因であることがよくあります。この場合、影響を受ける Pod を別のノードに移動するために、ノードが分離されます。ノードのアップグレードプロセスには、ノードが分離されていないことを確認する事前チェックがあるため、この状態ではアップグレードが続行されません。

回避策: アップグレードプロセスを開始する前に、file-read-only-lun-cleanup サブコンポーネントを手動で無効にします。

影響を受ける各組織を特定します。

環境内の各組織に SubcomponentOverride を適用します。

apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: file-read-only-lun-cleanup
  namespace: ORG_NAMESPACE
spec:
  subComponentRef: "file-read-only-lun-cleanup"
  disable: true

影響を受ける組織のノードが隔離されていないことを確認します。

組織内のノードを一覧表示します。

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get nodes

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

NAME                STATUS                     ROLES           AGE   VERSION
admin-node0-zone1   Ready,SchedulingDisabled   control-plane   14h   v1.30.8-gke.200
admin-node1-zone1   Ready                      control-plane   14h   v1.30.8-gke.200
admin-node2-zone1   Ready                      control-plane   14h   v1.30.8-gke.200

ステータスが SchedulingDisabled のノードの名前をメモします。このサンプル出力では、隔離されたノードは admin-node0-zone1 です。

前の手順でステータス SchedulingDisabled を返したノードの cordon を解除します。
```
kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG uncordon NODE_NAME
```

すべてのノードの準備ができていることを確認します。

kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get nodes

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

NAME                STATUS                     ROLES           AGE   VERSION
admin-node0-zone1   Ready                      control-plane   14h   v1.30.8-gke.200
admin-node1-zone1   Ready                      control-plane   14h   v1.30.8-gke.200
admin-node2-zone1   Ready                      control-plane   14h   v1.30.8-gke.200

マルチパスエラーが解決した後に `file_block_zombie_luns_present` アラートが発生する

バージョン: 1.14.3 以降

症状: file-observability コントローラが multipath -ll コマンドの出力を解析できないため、特定の環境で file_block_zombie_luns_present アラートがトリガーされることがあります。この状況では、すべてのノードでマルチパスサービスが正常な場合でも、ゾンビ LUN のアラートが常に発生します。

回避策:

問題のノードで健全なマルチパスサービスを確認する手順は次のとおりです。

Grafana の探索ページで、クエリ zombie_lun_exists{job="file-observability-backend-target.file-system"} を実行します。このクエリは、クラスタ内のすべてのノードの指標を返します。zombie_lun_exists 指標が 1 のノードがある場合は、そのノードの名前を書き留めます。
zombie_lun_exists 指標が 1 を返すノードごとに、次のコマンドを実行します。
1. 影響を受けるノードとの SSH 接続を確立します。
2. 次のコマンドを実行します。
```
multipath -ll
```
  このコマンドは、マルチパスサービスによって管理されているすべてのブロックデバイスに関する情報を返します。ブロックデバイスのステータスに文字列 failed undef unknown または文字列 failed faulty running が含まれていないことを確認します。
3. ステータス failed faulty running のデバイスがある場合は、FILE-R0020 ランブックに沿ってゾンビ LUN を解決します。
4. ステータス failed undef unknown のデバイスがある場合は、FILE-R0021 ランブックに沿ってスーパーゾンビ LUN を解決します。
ノードが正常な場合は、ゾンビ LUN アラートをミュートします。
1. どのノードにも無効なブロックデバイスが見つからない場合、ゾンビ LUN アラートは誤検出です。
2. AlertManager で file_block_zombie_luns_present アラートのミュートを作成します。
3. ミュートを作成したら、ServiceNow に移動して、アラートの発生が停止したことを確認します。

コンソールから空のバケットを削除できない

バージョン: 1.14.4 以降

症状: GDC コンソールで、空のバケットを削除できません。保持ポリシーでオブジェクトバージョニングが有効になっている場合、バケットには削除マーカーと、オブジェクトの他のバージョンが含まれている可能性があります。次のようなエラーが表示されることがあります。

can't delete bucket containing empty objects: Delete the bucket inside to delete
the object

回避策: gdcloud storage rm -a コマンドを使用して、削除マーカーを含むオブジェクトを削除し、バケットを削除可能にします。

システム Artifact Registry

Harbor レプリケーションジョブが停止する

バージョン: 1.14.3

症状: Harbor アーティファクトのレプリケーションジョブが停止します。この問題により、組織へのアーティファクトの配布がブロックされ、組織の作成が停止します。

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

Harbor ロボットアカウントのカスタムリソースを調整するときに一時的なエラーステータスがクリアされない

バージョン: 1.14.3

症状: kind=HarborRobotAccount と code=SAR2002 のラベルが付いた CustomResourceErrorStatusAlert アラートが誤って発生しています。たとえば、誤ったアラートの message フィールドが「Error getting robot: failed to list robots: 503 Service Unavailable」に設定されています。

回避策: インフラストラクチャオペレーター（IO）に、アラートが実際の問題か誤報かを確認するよう依頼し、誤報の場合は次の手順に沿ってアラートをミュートします。

アラートがトリガーされたら、ランブック SAR-E2002 に沿ってアラートの根本原因を特定し、対処します。

この既知の問題により、ランブックで根本原因が正常に解決されても、アラートが誤って発生し続ける可能性があります。アラートが送信されたターゲット HarborRobotAccount（HRD）カスタムリソース（CR）オブジェクトのエラーステータスを継続的に確認します。

必要な環境変数を設定します。
```
export KUBECONFIG=KUBECONFIG
export HRD_NAME=HRD_NAME
export HRD_NAMESPACE=HRD_NAMESPACE
```
次のように置き換えます。
- KUBECONFIG: kubeconfig ファイルのパス。
- HRD_NAME: ターゲット HarborRobotAccount CR の名前。
- HRD_NAMESPACE: ターゲット HarborRobotAccount CR を含む Namespace。

ターゲット HarborRobotAccount CR のエラーステータスを確認します。

kubectl get harborrobotaccount ${HRD_NAME?} -n ${HRD_NAMESPACE?} -ojsonpath='{.status.errorStatus} {"\n"}'

lastUpdateTime の値が errorStatus フィールドの最終更新が 30 分以上前であることを示している場合、アラートは誤報です。誤報を軽減するには、MON-R2009 ランブックに沿って、GDC のエアギャップインスタンス内でアラートを消音します。

SAR-R0003 アラートの誤警報

バージョン: 1.14.3 以降

症状: コード SAR-R0003、OC SAR、重大度 critical のアラートが誤ってトリガーされます。

回避策: MON-R2009 ランブックに沿ってアラートをミュートします。

チケット発行システム

ServiceNow MID Server が正常に起動しない

バージョン: 1.14.3

修正済み: 1.14.4

症状: Splunk と統合されている ServiceNow MID Server が、バージョンの不一致により起動時に ServiceNow に登録できません。

回避策:

ts-mid-server サブコンポーネントを一時停止します。

KUBECONFIG=ROOT_ADMIN_KUBECONFIG kubectl annotate subcomponent ts-mid-server -n gdchservices lcm.private.gdc.goog/paused=true

MID サーバーのバージョン文字列をオーバーライドします。

KUBECONFIG=GDCHSERVICES_ADMIN_KUBECONFIG kubectl set env statefulset/midserver-set -n support MID_CONFIG_mid__pinned__version=washingtondc-12-20-2023__patch5-06-21_06-26-2024_1335

アップグレード

クラスタのアップグレードが成功しても、共有サービスクラスタのアノテーションが更新されない

バージョン: 1.14.4

症状: clusters.baremetal.cluster.gke.io の境界と共有サービスクラスタの CR は、アップグレード後に正しい GKE バージョンを反映します。clusters.cluster.gdc.goog CR には、以前の GKE バージョンが引き続き表示されます。

回避策: clusters.baremetal.cluster.gke.io のアノテーション upgrade.gdc.goog/version を、アップグレードされた GKE バージョンに対応する新しい UserClusterMetadata 名に更新します。

組織管理者のノードのアップグレードが停止する

バージョン: 1.14.6

修正済み: 1.14.7

症状: gdchservices 組織の管理コントロールプレーンのノードアップグレードプロセスが停止します。ノードへの SSH 接続を確立できないため、ノードのアップグレードが失敗し、Connection timed out エラーが発生します。

アドオンのアップグレードが停止する

バージョン: 1.14.6

修正済み: 1.14.7

症状: 以前の 1.14.x バージョンから 1.14.6 にアップグレードする際に、ルート管理クラスタのアドオンアップグレードが停止します。ステータスメッセージに、アップグレードが想定された制限時間を超過したことが示される場合があります。

message: 'UPG1401: addon upgrade expected to finish within 2h0m0s but hasn''t
      after 8h8m24.00395866s, last message was: Addon upgrade for root-admin cluster
      in progress'

回避策: root-admin addonset リソースの spec.addOnSetTemplateRef を手動で更新して、新しいバージョンの正しいテンプレートを指すようにします。

サポートレポートが失敗する

バージョン: 1.14.3、1.14.4、1.14.5、1.14.6

修正済み: 1.14.7

現象: 権限の問題により、ユーザークラスタで gdcloud resource-support get-report コマンドを実行すると失敗します。

OS ノードのアップグレードが完了した後、VM の起動が停止する

バージョン: 1.14.6

症状: 1.14.3 から 1.14.6 へのアップグレード中に、境界クラスタまたは共有サービスクラスタ内の仮想マシンが起動に失敗し、OS アップグレード後にアクセスできなくなります。

たとえば、次のコマンドで問題を確認できます。

kubectl --kubeconfig CP_KUBECONFIG logs -n VM_NAMESPACE VIRT_LAUNCHER_POD_NAME -c guest-console-log

VM コンソールログの出力に、次のようなカーネルパニックメッセージが表示されます。

[    2.005806] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[    2.008100] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64 #1
[    2.011153] Hardware name: KubeVirt None/RHEL, BIOS 1.14.0-2 04/01/2014
[    2.013401] Call Trace:
[    2.015365]  dump_stack+0x41/0x60
[    2.016641]  panic+0xe7/0x2ac
[    2.017864]  mount_block_root+0x2be/0x2e6
[    2.019176]  ? do_early_param+0x95/0x95
[    2.020287]  prepare_namespace+0x135/0x16b
[    2.021476]  kernel_init_freeable+0x210/0x23a
[    2.022724]  ? rest_init+0xaa/0xaa
[    2.023721]  kernel_init+0xa/0x110
[    2.024698]  ret_from_fork+0x1f/0x40
[    2.025913] Kernel Offset: 0x33c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[    2.028706] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]---

回避策: この問題を回避するには、次の手順を完了します。

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

export MP_KUBECONFIG=MANAGEMENT_API_KUBECONFIG
export CP_KUBECONFIG=ORG_INFRA_KUBECONFIG
export VM_NAMESPACE=VM_NAMESPACE
export VM_NAME=FAILED_VM_NAME

失敗した VM を停止します。

kubectl --kubeconfig=$MP_KUBECONFIG patch gvm -n $VM_NAMESPACE \
    $VM_NAME --type='merge' -p='{"spec": {"runningState": "Stopped"}}'

エディタを開いて、障害が発生した VM からブートディスクを切断します。
```
kubectl --kubeconfig $MP_KUBECONFIG edit gvm -n $VM_NAMESPACE $VM_NAME
```

VM 仕様でブートディスクをプレースホルダ名に置き換えます。

# Several lines of code are omitted here.
spec:
  disks:
  - boot: true
    virtualMachineDiskRef:
      # This is a random placeholder name you put here. Doesn't need to exist
      name: VM_DISK_PLACEHOLDER_NAME

起動スクリプトシークレットを作成します。

cat <<'EOF' > script
#!/bin/bash
username="newuser"
password="Lime+blaze8legend"
sudo useradd -m -s /bin/bash "$username"
echo "$username:$password" | sudo chpasswd
sudo usermod -aG sudo "$username"
EOF

kubectl --kubeconfig=$MP_KUBECONFIG create secret generic configure-password -n $VM_NAMESPACE --from-file=script

ヘルパー VM を作成します。

VM ブートディスクの VM イメージを取得します。イメージは、問題の VM ノードのブートディスクと同じ OS ファミリーであってはなりません。grep を使用して Ubuntu イメージを見つけます。
```
# find the latest ubuntu-20.04 OS version
UBUNTU_OS_VERSION=$(kubectl --kubeconfig $MP_KUBECONFIG get vmimage -A --sort-by=.metadata.creationTimestamp | grep ubuntu-20.04 | tail -n 1 | awk '{print $2}')
```

VM ブートディスクと VM を作成します。新しいブートディスクと、アタッチされたセカンダリディスクとコンソールアクセス用の起動スクリプトを含む新しい VM を作成します。

kubectl --kubeconfig $MP_KUBECONFIG apply -n $VM_NAMESPACE -f - <<EOF
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineDisk
metadata:
  name: HELPER_VM_BOOT_DISK_NAME
spec:
  source:
    image:
      name: UBUNTU_OS_VERSION
      namespace: vm-system
  size: 20Gi
---
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachine
metadata:
  name: HELPER_VM_NAME
spec:
  compute:
    virtualMachineType: n3-standard-2-gdc
  disks:
  - virtualMachineDiskRef:
      name: HELPER_VM_NAME-disk
    boot: true
    autoDelete: true
  - virtualMachineDiskRef:
      name: PROBLEM_VM_BOOT_DISK
    autoDelete: false
  startupScripts:
  - scriptSecretRef:
      name: configure-password
    name: configure-password
EOF

ヘルパー VM が実行されていることを確認します。

kubectl --kubeconfig $MP_KUBECONFIG get gvm -n ${VM_NAMESPACE} HELPER_VM_NAME

コンソールでヘルパー VM に接続し、initramfs を再生成します。

ヘルパー VM のコンソール:

kubectl virt console HELPER_VM_NAME  -n ${VM_NAMESPACE} --kubeconfig=$CP_KUBECONFIG

次の認証情報を使用します。

username="newuser"

password="Lime+blaze8legend"

アタッチされたディスクのパーティションをマウントします。

sudo mkdir /mnt/kernelpanic/
sudo mount /dev/mapper/rocky-rl--root /mnt/kernelpanic/
sudo mount /dev/mapper/rocky-rl--root /mnt/kernelpanic/
sudo mount /dev/sdb2 /mnt/kernelpanic/boot/
sudo mount /dev/sdb1 /mnt/kernelpanic/boot/efi/
sudo mount /dev/rocky/rl-home /mnt/kernelpanic/home/
sudo mount /dev/rocky/rl-var /mnt/kernelpanic/var/
sudo mount /dev/rocky/rl-var_tmp /mnt/kernelpanic/var/tmp/
sudo mount /dev/rocky/rl-var_log /mnt/kernelpanic/var/log/
sudo mount /dev/rocky/rl-var_log_audit /mnt/kernelpanic/var/log/audit/
sudo mount /dev/rocky/rl-tmp /mnt/kernelpanic/tmp/

sudo mount -t sysfs sysfs /mnt/kernelpanic/sys/
sudo mount -t proc procfs /mnt/kernelpanic/proc/
sudo mount -t devtmpfs devtmpfs /mnt/kernelpanic/dev/
sudo mount -t devpts devpts /mnt/kernelpanic/dev/pts/
sudo mount -o bind /dev/pts/ /mnt/kernelpanic/dev/pts/

マウントポイントへの chroot 接続を確立し、initramfs を再生成します。
```
sudo chroot /mnt/kernelpanic/
dracut --regenerate-all --force
```

新しいカーネルバージョン 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64 の新しい initramfs が生成されていることを確認します。

ls /boot/initramfs-* -l

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

-rw-------. 1 root root 184937778 Feb  5  2025 /boot/initramfs-0-rescue-e4d67258cb64499f98609307ac4a93e8.img
-rw-------. 1 root root 119867729 Aug  7 17:35 /boot/initramfs-4.18.0-553.16.1.el8_6.ciqfips.0.6.1.x86_64.img
-rw-------. 1 root root  35321114 Aug  7 17:36 /boot/initramfs-4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64.img

ヘルパー VM を停止します。

kubectl --kubeconfig=$MP_KUBECONFIG patch gvm -n $VM_NAMESPACE HELPER_VM_NAME --type='merge' -p='{"spec": {"runningState": "Stopped"}}'

ヘルパー VM からディスクを切断します。

エディタでヘルパー VM の仕様を開きます。

kubectl --kubeconfig $MP_KUBECONFIG edit gvm -n $VM_NAMESPACE HELPER_VM_NAME

YAML ファイルから次のコードを削除します。

- virtualMachineDiskRef:
    name: PROBLEM_VM_BOOT_DISK
  autoDelete: false

ブートディスクを障害が発生した VM に再度アタッチします。

失敗した VM の仕様をエディタで開きます。

kubectl --kubeconfig $MP_KUBECONFIG edit gvm -n $VM_NAMESPACE $VM_NAME

次のように仕様を更新します。

# Several lines of code are omitted here.
spec:
  disks:
  - boot: true
    virtualMachineDiskRef:
      name: PROBLEM_VM_BOOT_DISK

失敗した VM を起動します。

kubectl --kubeconfig=$MP_KUBECONFIG patch gvm -n $VM_NAMESPACE $VM_NAME --type='merge' -p='{"spec": {"runningState": "Running"}}'

アップグレードが修正されていることを確認します。
1. この VM の Node カスタムリソースに Ready が表示され、新しいカーネルバージョン 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64 が使用されていることを確認します。
```
kubectl --kubeconfig=$CP_KUBECONFIG get node NODE_NAME -owide
```
  出力は次のようになります。
```
NAME          STATUS   ROLES           AGE    VERSION            INTERNAL-IP   EXTERNAL-IP   OS-IMAGE                           KERNEL-VERSION                               CONTAINER-RUNTIME
vm-45b03137   Ready    worker          139d   v1.30.12-gke.300   10.204.0.7    <none>        Rocky Linux 8.6 (Green Obsidian)   4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64   containerd://1.6.38-gke.0
```
2. VM への SSH 接続を確立した後、カーネルバージョンを確認します。
```
uname -a
```
  出力には、新しいカーネルバージョン 4.18.0-553.16.1.el8_6.ciqfips.0.8.1.x86_64 が表示されます。

アップグレード後に Ingester が異常状態のままで、自動的に忘れられない

バージョン: 1.14.x

症状: アップグレード後に log-infra サブコンポーネントが正常な状態になっていない。確認するには、次のコマンドを実行します。 none kubectl --kubeconfig ${KUBECONFIG:?} get subcomponent -n ${CLUSTER_NAMESPACE:?} log-infra サブコンポーネントの健全性を確認するには、KUBECONFIG に親クラスタの kubeconfig を使用し、CLUSTER_NAMESPACE に現在のクラスタの Namespace を使用する必要があります。このコマンドは、サブコンポーネントの STATUS を返します。STATUS が ReconciliationCompleted 以外の場合、そのクラスタでサブコンポーネントが異常であることを示します。

クラスタ内の一部の Loki Pod が異常です。すべての Loki Pod を一覧表示するには、次のコマンドを実行します。 none kubectl --kubeconfig ${KUBECONFIG:?} get pods -n obs-system | awk 'NR==1 || /loki/' このコマンドは、STATUS 列と READY 列を含むすべての Loki Pod を表示します。STATUS が Running でない場合、または一部のコンテナが準備完了でない場合、Pod は異常とみなされます。a/b 形式の READY 列は、合計 b のうち、準備完了したコンテナの数 a を示します。a と b が等しい場合、Pod は正常です。

異常な Loki Pod のログを確認します。none kubectl --kubeconfig ${KUBECONFIG:?} logs <pod-name> -n obs-system

異常な Pod の出力ログは次のようになります。

level=warn ts=2024-12-21T05:01:42.331048596Z caller=ingester.go:385 component=ingester msg="autoforget have seen 2 unhealthy ingesters out of 3, network may be partitioned, skip forgeting ingesters this round"
level=warn ts=2024-12-21T05:01:45.928939929Z caller=lifecycler.go:291 component=ingester msg="found an existing instance(s) with a problem in the ring, this instance cannot become ready until this problem is resolved. The /ring http endpoint on the distributor (or single binary) provides visibility into the ring." ring=ingester err="instance 10.99.196.153:9095 past heartbeat timeout"

回避策: Loki リングから健全でないインジェスタを削除するには、ランブック AL-R0031 を参照してください。

Vertex AI

翻訳リクエストで `RESOURCE_EXHAUSTED` エラーコードが生成されることがある

バージョン: 1.14.3

現象: 変換リクエストを送信した後、レスポンスメッセージで RESOURCE_EXHAUSTED エラーコードが返されます。このエラーは、システム周波数の上限を超えた場合に発生します。ユーザーごとの割り当て、1 秒あたりの最大クエリ数、ファイルシステム全体で容量が不足しているなど、リソースが枯渇しています。

回避策: インフラストラクチャオペレーター（IO）に、翻訳サービスバックエンドシャードの再起動を依頼します。次に、リクエスト間の遅延を長くするか、リクエストを短くして、変換リクエストを再度送信します。

`batchTranslateDocument` リクエストがエラー `503` を返す

バージョン: 1.14.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: SHARED_SERVICE_CLUSTER_NAMESPACE
spec:
  subComponentRef: "vai-translation"
  backend:
    operableParameters:
      enableRAG: true
```
SHARED_SERVICE_CLUSTER_NAMESPACE は、共有サービスクラスタの Namespace に置き換えます。
SubcomponentOverride カスタムリソースを組織管理クラスタに適用します。
```
kubectl --kubeconfig ORG_MGMT_KUBECONFIG apply -f vai-translation.yaml
```
ORG_MGMT_KUBECONFIG は、組織管理クラスタ内の管理 kubeconfig ファイルのパスに置き換えます。

翻訳または OCR のフロントエンド Pod とサービスが初期化に失敗します。

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

症状: アップグレード中に DB クラスタが再作成されるため、共有サービスクラスタの ODS シークレットストアシークレットが古くなり、同期されなくなります。このため、Translation または OCR のフロントエンド Pod とサービスは初期化に失敗します。

回避策:

共有サービスクラスタ内のシークレットを削除します。

kubectl --kubeconfig SHARED_SERVICEG_CLUSTER_KUBECONFIG delete secret postgres-secret-store -n VAI_API_NAMESPACE

SHARED_SERVICE_CLUSTER_KUBECONFIG は、共有サービスクラスタ内の kubeconfig ファイルのパスに置き換えます。

問題のあるサービスが Translation の場合は、VAI_API_NAMESPACE を「g-vai-translation-sie」に置き換えます。問題のあるサービスが OCR の場合は、VAI_API_NAMESPACE を「g-vai-ocr-sie」に置き換えます。

コントローラはシークレットを自動的に再作成し、DB クラスタと再同期します。

Vertex AI Search

検索コンポーネントが調整状態のままになる

バージョン: 1.14.6

症状: 組織に SearchConfig カスタムリソースが作成されていない場合、vaisearch-conversation サブコンポーネントと vaisearch-frontend サブコンポーネントが Reconciling 状態のままになります。

回避策: この問題は無視できます。SearchConfig カスタムリソースの作成時に、サブコンポーネントは調整を完了する必要があります。

サーバー

BIOS 認証情報のローテーションが reset-requested ステージで停止する

バージョン: 1.14.4

現象: BIOS 認証情報のローテーションが reset-requested 状態のままになる。これは、サーバーの bios-credentials Secret の gdch.cluster.gke.io/rotation-status アノテーションを確認することで検証できます。

kubectl get secret bios-credentials-SERVER_NAME -n gpc-system -o jsonpath='{.metadata.annotations.gdch\.cluster\.gke\.io/rotation-status}'

SERVER_NAME は、サーバーの名前に置き換えます。ローテーションが停止している場合、コマンドの出力は reset-requested になります。

回避策: BIOS 認証情報のローテーションを完了するには、SERV-R0018 ランブックに従ってください。

以前にインストールしたサーバーをプロビジョニングできない

バージョン: 1.14.6

症状: サーバーのプロビジョニング解除と再プロビジョニング後に、サーバーのプロビジョニングが失敗します。特に、iLO（Integrated Lights-Out）と HSM（ハードウェアセキュリティモジュール）の鍵管理に関する問題に関連しています。以前に無効化された組織に属していたサーバーで、イメージプロビジョニング中にエラーが発生し、適切なデバイスが見つからないことが示されます。これは、古いキーや削除されたキーによってディスクがロックされていることが原因であることがよくあります。次のようなエラーが表示されることがあります。

No suitable device was found for deployment - root device hints were not
provided and all found block devices are smaller than 4294967296B

回避策: 影響を受けるサーバーを削除して再インストールし、サーバーがプロビジョニングされた状態になるようにします。詳細については、SERV-R0020 と SERV-R0021 のランブックをご覧ください。

仮想マシン

イメージのインポートが失敗する

バージョン: 1.14.4。1.14.5

修正済み: 1.14.6

症状: gdcloud compute images import コマンドを使用したイメージのインポートが、セッションタイムアウトにより Unauthorized エラーで失敗します。

回避策: gdcloud CLI ではなく、KRM API を使用して独自のイメージをインポートします。

KRM イメージのインポートに時間がかかる

バージョン: 1.14.6 以降

現象: KRM API を使用したイメージのインポートに時間がかかる。VirtualMachineImageImport リソースが TranslationJobInProgress 状態のまま長時間経過している場合は、変換フェーズが想定どおりに完了していないことを示します。image-translation Pod が CrashLoopBackOff 状態になります。

回避策:

別の名前で新しい VirtualMachineImageImport リソースを作成して、インポートをもう一度試してください。
リソースのステータスが WaitingForTranslationJob に変わるまで、リソースを定期的にチェックして VirtualMachineImageImport ステータスをモニタリングします。詳細については、VMM R0007 ランブックをご覧ください。

Google Distributed Cloud エアギャップ 1.14.x の既知の問題 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

バックアップと復元

クラスタ バックアップの復元プランの編集が機能しない

ソースディスクのサイズが無効

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

バックアップと復元の SLO が適用されない

インポートされたバックアップに保持ポリシーが適用されない

VM の部分バックアップが失敗する

ユーザー クラスタまたはサービス クラスタの削除後に孤立したバックアップ リソースをクリーンアップする

CLI または UI で VirtualMachineRestore の削除がサポートされていない

メモリ不足のためバックアップ コントロール プレーン Pod がクラッシュする

ユーザー クラスタの削除が停止したままの状態になる

保留中の Persistent Volume Claim が原因で復元が停止する

クラスタ管理

サブコンポーネント kub-gpu-controller が調整されない

Standard クラスタでノードプールを削除できない

クラスタが削除状態で停止している

データベース サービス

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

DNS

GlobalCustomerRootDNSServerNotReachable が誤ったアラートをトリガーする

ファイル/ブロック ストレージ

VM でファイル共有ボリュームをマウントできない

ファイアウォール

Subnet CR のアドレスにセキュリティ ポリシー ルールがない

GDC ファイアウォールは、mgmt とデータプレーンの両方で OIR へのトラフィックを拒否します

GDC ファイアウォールでゾーン間および組織間のトラフィックを拒否する

ファイアウォールは、ID が組織名と同じ AttachmentGroup をサポートしていません

港

バックアップと復元後に Harbor CLI シークレットが無効になる

Harbor のバックアップと復元のジョブが権限を競合する

Harbor のバックアップ サイズが 0 と表示される

Harbor Registry コンソール ページのバックアップ リソースで権限エラーが発生する

データベース パスワードのローテーションが停止しているページ

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

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

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

起動後に HSM が ValidateNetworkConfig エラーで失敗する

健全性

誤警報の SLO アラート

無効なゲージベースの SLO 構成

ID とアクセスの管理

IAM ロール バインディングの作成エラー

project-service-accounts の IAM ロール バインディングの作成に失敗する

新しいプロジェクトで事前定義されたロールの作成が遅延する

GDC コンソールで最初のロール バインディングを作成できない

AO はインフラストラクチャ クラスタのロールへのアクセス権を自分自身に付与できない

既存のサービス アカウント トークンが無効になる

Infrastructure as Code（IAC）

Namespace がないため、サブコンポーネントの調整が失敗する

IAC ConfigSync の指標収集が失敗する

IAC RootSync が失敗する

在庫

在庫監査で調整に失敗する

鍵管理システム

CTM ルート鍵を使用するように構成された KMS は、HSM が使用できない場合にフェイルオーバーしない

ロードバランサ

サブネット CIDR の枯渇によりグローバル ロードバランサの作成が失敗する

ロードバランサ リソースを変更してもサービスが調整されない

ゾーン名が正しくない場合でも拒否されない

グローバル ロードバランサとゾーン ロードバランサの webhook エラー

ロギング

WAL 再生中に Loki Pod がクラッシュするか、OOMKilled が発生する

回避策を確認する

オーバーライドとオブジェクト プロキシをクリーンアップする

モニタリング

一部のクラスタで AlertManager Webhook がアラートを送信できない

ServiceNow インシデントが重複することがある

インフラストラクチャ指標が過敏になる可能性がある

調整指標が過敏になっている可能性がある

ルート管理クラスタで 2 つの誤ったアラートが開いている

ルート管理者コントローラ マネージャーのエラー率が高い

KUB ダッシュボードのすべての PA パネルにデータが表示されない

observability-admin-debugger ロールの権限が誤って構成されている

Grafana デバッガのロールがない

新しいゾーンを追加した後、ゾーン間の指標とログが表示されない

MonitoringTarget ファイナライザが Namespace の削除をブロックする

ダッシュボードとデータソースのファイナライザが保留中のため、プロジェクトの削除が停止する

KSM の指標が表示されない

システム指標パイプラインがダウンしている

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

クラスタバックアップの復元プランの編集が機能しない

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

ユーザークラスタまたはサービスクラスタの削除後に孤立したバックアップリソースをクリーンアップする

メモリ不足のためバックアップコントロールプレーン Pod がクラッシュする

ユーザークラスタの削除が停止したままの状態になる

サブコンポーネント `kub-gpu-controller` が調整されない

データベースサービス

ファイル/ブロックストレージ

Subnet CR のアドレスにセキュリティポリシールールがない

Harbor のバックアップサイズが 0 と表示される

Harbor Registry コンソールページのバックアップリソースで権限エラーが発生する

データベースパスワードのローテーションが停止しているページ

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

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

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

起動後に HSM が `ValidateNetworkConfig` エラーで失敗する

IAM ロールバインディングの作成エラー

project-service-accounts の IAM ロールバインディングの作成に失敗する

GDC コンソールで最初のロールバインディングを作成できない

AO はインフラストラクチャクラスタのロールへのアクセス権を自分自身に付与できない

既存のサービスアカウントトークンが無効になる

サブネット CIDR の枯渇によりグローバルロードバランサの作成が失敗する

ロードバランサリソースを変更してもサービスが調整されない

グローバルロードバランサとゾーンロードバランサの webhook エラー

オーバーライドとオブジェクトプロキシをクリーンアップする

ルート管理者コントローラマネージャーのエラー率が高い

`MonitoringTarget` ファイナライザが Namespace の削除をブロックする

グローバルコンソール URL のログインエラーが断続的に発生する

`MultiZoneNetworkConfig` ゾーンの順序を調整すると、構成の置換が失敗する

グローバルエニーキャストトラフィックがブロックされた

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

プロジェクトネットワークポリシーページで、ProjectNetworkPolicy API のプロジェクトセレクタフィールドがサポートされていない

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

OS NodeUpgrade がパッケージサーバーの作成ステップで停止する可能性がある

ジャンピングホストのパフォーマンスが低い

インフラストラクチャクラスタのワーカーノードプールが削除されない

`gdcloud config set zone` コマンドで作成したバケットを削除できない

Trident `mkfs.ext4` エラーにより Pod がマウントに失敗する

`file_block_iscsi_sessions_unhealthy alert` で誤検出が報告される

スペアディスクに対して `file_block_storage_disk_failure` アラートがトリガーされる

ワークロードの負荷が高いときに `file_block_storage_high_node_total_latency` アラートが発生する

マルチパスエラーが解決した後に `file_block_zombie_luns_present` アラートが発生する

Harbor レプリケーションジョブが停止する

Harbor ロボットアカウントのカスタムリソースを調整するときに一時的なエラーステータスがクリアされない

クラスタのアップグレードが成功しても、共有サービスクラスタのアノテーションが更新されない

サポートレポートが失敗する

翻訳リクエストで `RESOURCE_EXHAUSTED` エラーコードが生成されることがある

`batchTranslateDocument` リクエストがエラー `503` を返す