バックアップと復元
1.12.1
ボリューム バックアップのストレージ クラスタは、転送ではなく外部 DNS サーバーを使用するため、ボリューム バックアップで組織レベルのオブジェクト ストレージ エンドポイントを解決できません。バージョン 1.12 では、バックアップ トラフィックに各組織への新しいルートが必要です。
回避策:
IO は、組織レベルの DNS 解決を有効にし、各組織のレプリケーション論理インターフェース（LIF）からオブジェクト ストレージ エンドポイントへのルートを作成するために、ストレージ クラスタを更新する必要があります。ブートストラップから次のコマンドをコピーして貼り付けます。
KUBECONFIG 環境変数を設定します。
export KUBECONFIG = /root/release/root-admin/root-admin-kubeconfig
ストレージ クラスタを見つけます。
storage_cluster = $( kubectl get storagecluster -n gpc-system | awk 'NR == 2{print $1}' )
インスタンスの外部 CIDR を見つけます。
instance_external_cidr = $( kubectl get cidrclaim -n gpc-system instance-external-cidr -ojsonpath= '{.spec.ipv4Spec.staticCidrBlocks}' )
転送機能を使用し、インスタンスの外部 CIDR へのルートを使用して、ストレージ クラスタを更新します。
kubectl patch storagecluster " ${ storage_cluster } " -n gpc-system --type= 'json' -p= '[{"op": "replace", "path": "/spec/additionalNetworks/0/destinationSubnets", "value": ' " ${ instance_external_cidr } " '}, {"op": "replace", "path": "/spec/dnsConfig/serviceRef/name", "value": "gpc-coredns-forwarder-udp"}]'
変更が実装されるように、コントローラを再起動します。
kubectl rollout restart deploy/file-storage-backend-controller -n file-system
バックアップと復元
1.12.1
症状:
バックアップ サブネットから組織のコントロール プレーンへのルートがないため、ONTAP ノードから組織管理者の Ingress ゲートウェイを curl すると失敗します。
回避策:
IO は、組織レベルの DNS 解決を有効にし、各組織のレプリケーション論理インターフェース（LIF）からオブジェクト ストレージ エンドポイントへのルートを作成するために、ストレージ クラスタを更新する必要があります。ブートストラップから次のコマンドをコピーして貼り付けます。
KUBECONFIG 環境変数を設定します。
export KUBECONFIG = /root/release/root-admin/root-admin-kubeconfig
ストレージ クラスタを見つけます。
storage_cluster = $( kubectl get storagecluster -n gpc-system | awk 'NR == 2{print $1}' )
インスタンスの外部 CIDR を見つけます。
instance_external_cidr = $( kubectl get cidrclaim -n gpc-system instance-external-cidr -ojsonpath= '{.spec.ipv4Spec.staticCidrBlocks}' )
転送機能を使用し、インスタンスの外部 CIDR へのルートを使用して、ストレージ クラスタを更新します。
kubectl patch storagecluster " ${ storage_cluster } " -n gpc-system --type= 'json' -p= '[{"op": "replace", "path": "/spec/additionalNetworks/0/destinationSubnets", "value": ' " ${ instance_external_cidr } " '}, {"op": "replace", "path": "/spec/dnsConfig/serviceRef/name", "value": "gpc-coredns-forwarder-udp"}]'
変更が実装されるように、コントローラを再起動します。
kubectl rollout restart deploy/file-storage-backend-controller -n file-system
バックアップと復元
1.12.4
症状:
永続ボリュームが SnapMirror 関係にある場合、そのボリュームは削除できません。
回避策:
IO は、ボリュームを宛先とする SnapMirror 関係を削除します。
KUBECONFIG 環境変数を設定します。
export KUBECONFIG = /root/release/root-admin/root-admin-kubeconfig
問題のある PV の名前を変数に格納します。
PV_NAME ={ PV_NAME }
内部ボリューム名を取得します。
volume_name = $( kubectl get pv ${ PV_NAME ? } -o jsonpath = '{.spec.csi.volumeAttributes.internalName}' )
FILE-A0006 ランブックの手順に沿って、ONTAP にアクセスします。
以前に収集したパスワードを使用して、このボリュームをソースとする関係を削除します。
ssh ${ username ? } @${ mgmt_ip ? } snapmirror delete -source-volume ${ volume_name ? } -destination-path "*"
# enter the password collected from the breakglass secret
バックアップと復元
1.12.0
バックアップ リポジトリにエラー ステータスがないのに、アラートが生成された場合は、リポジトリのアラート指標が誤って生成された可能性があります。これは 1.12.0 の既知の問題であり、1.12.4 で修正されています。この問題の原因は、バックアップ リポジトリがヘルスチェックとしてオブジェクト ストレージへの接続を定期的に試み、接続に失敗すると異常な状態になることです。ただし、バックアップ リポジトリが復元しても、その健全性を示す指標が適切に切り替わらず、アラートが無限にトリガーされる状態のままになることがあります。この問題を解決するには、バックアップ リポジトリを手動で削除して再作成し、健全性指標をリセットします。BACK-R0003 ランブックの手順に沿って、バックアップ リポジトリを再作成します。
課金
1.12.4
症状:
エラー メッセージ: bil-storage-system-cluster - Reconciliation error: E0121- rollback chart: no Job with the name "billing-storage-system-init-job-628" found古いジョブが原因で、bil-storage-system-cluster サブコンポーネントの調整が失敗します。billing-storage-system-init-job-628 と billing-storage-system-init-job-629 は、正常に完了した後も残ります。
回避策:
次の手順を完了します。
古い課金ジョブのバックアップを作成します。
cd /root/USERNAME
kubectl --kubeconfig /root/release/gdchservices/gdchservices-system-kubeconfig get jobs billing-storage-system-init-job-628 -n billing-system -o yaml > billing-storage-system-init-job-628.yaml
kubectl --kubeconfig /root/release/gdchservices/gdchservices-system-kubeconfig get jobs billing-storage-system-init-job-629 -n billing-system -o yaml > billing-storage-system-init-job-629.yaml
サブコンポーネントを一時停止します。
export SUBCOMPONENT_NAME = bil-storage-system-cluster
export SUBCOMPONENT_NAMESPACE = gdchservices-system-cluster
kubectl annotate subcomponent " ${ SUBCOMPONENT_NAME :? } " -n " ${ SUBCOMPONENT_NAMESPACE :? } " lcm.private.gdc.goog/paused= true
古いジョブを削除します。
oclcm-backend-controller を再起動します。
サブコンポーネントのポーズを解除します。
ブロック ストレージ
1.12.4
症状:
ボリュームのマウントエラーのため、anthos-identity-service-obs-system Namespace と platform-obs-obs-system Namespace の Grafana Pod が Init 状態のままになります。kubelet ログのエラー メッセージは、マルチアタッチの問題を示しています。この問題は Trident のバグが原因で発生します。Trident は LUKS マッピングの基盤となるデバイスを正しく特定して検証できないため、マルチアタッチ エラーが発生します。
回避策:
PVC で deletionTimestamp を確認します。deletionTimestamp がない場合（Pod の移行）は、次の操作を行います。
PVC の VolumeAttachment を確認して、ボリュームが現在アタッチされている場所を特定します。
この値と一致しないクラスタ内の Nodes を分離します。
失敗した Pod を削除します。これにより、元の Node に移行されます。
確認後、deletionTimestamp（Volume の削除）がある場合は、次の手順を行います。
PVC の VolumeAttachment を確認して、ボリュームが現在アタッチされている場所を特定します。
Node で、トラッキング ファイルの内容を出力します。
cat /var/lib/trident/tracking/PVC_NAME .json
トラッキング ファイル出力の devicePath フィールドで見つかった LUKS デバイスが実際に閉じていることを確認します。この時点で、このパスは存在しません。
stat DEVICE_PATH
シリアル番号が現在マルチパス デバイスにマッピングされているかどうかを確認します。
トラッキング ファイルの iscsiLunSerial フィールドの値をコピーします。
この値を予想される 16 進数値に変換します。
echo 'iISCSILUNSERIAL >' | xxd -l 12 -ps
この新しい値を使用して、マルチパス エントリがまだ存在するかどうかを確認します。
multipath -ll | grep SERIAL_HEX
存在しない場合は、トラッキング ファイルを削除します。
存在する場合は、検索した値よりも少し長いシリアル 16 進数値（multipathSerial）が表示されます。次のコマンドを実行して、ブロック デバイスを見つけます。
multipath -ll MULTIPATH_SERIAL
次に、次のコマンドを実行します。最後のコマンドは、ブロック デバイスごとに一意に実行します。
systemctl restart iscsid
systemctl restart multipathd
multipath -f MULTIPATH_SERIAL
echo 1 > /sys/block/BLOCK_DEVICE_NAME /device/delete
クラスタ管理
1.12.0
症状:
クラスタのプロビジョニング中に、2 番目のコントロール プレーン ノードの machine-init ジョブが次のメッセージで失敗します。
FAILED! = > { "changed" : true, "cmd" : "/usr/bin/kubeadm join phase control-plane-prepare certs --config /dev/stdin --v 5" .
ログを表示します。
kubectl --kubeconfig= ADMIN_KUBECONFIG logs -p kube-apiserver-{ first_node_name} -n kube-system | grep "etcdmain: open /etc/kubernetes/pki/etcd/ca.crt: permission denied" 出力には空でない結果が表示されます。
回避策:
/etc/kubernetes/pki/etcd/ca.crt の権限を切り替えます。これは非常に時間依存性の高いオペレーションです。権限の切り替えは、machine-init ジョブの前の実行後、かつ machine-init ジョブの次の実行前に行う必要があります。これは、machine-init が権限をルートに上書きするためです。2 番目のノードで etcd を再起動して、最初のノードの etcd をクラッシュ ループから復元します。この 2 つの手順を完了すると、最初のノードの kube-apiserver が実行を開始し、次の machine-init ジョブが成功します。
クラスタ管理
1.12.2
症状:
cilium エージェントに次の警告が表示されます。
level = warning msg = "Waiting for k8s node information" error = "required IPv4 PodCIDR not available" subsys = k8s 回避策:
削除するノードの IP アドレスを確認します。
NodePool カスタム リソースの spec.nodes から IP アドレスを削除します。ノードが NodePool から完全に削除されるまで待ちます。ノードが削除されない場合は、force-remove を実行します。
Machine カスタム リソースに baremetal.cluster.gke.io/force-remove=true アノテーションを追加します。
kubectl -n org-1-system-cluster annotate machine IP_ADDRESS baremetal.cluster.gke.io/force-remove= true
NodePool カスタム リソースの spec.nodes に IP アドレスを追加します。
ロギング
1.12.0
症状:
外部 SIEM システムへのエクスポート の設定が完了すると、SIEM 入力が Fluent Bit 処理パイプラインに含まれず、Kubernetes API サーバーログがこの SIEM に存在しません。
ネットワーキング
1.12.4
症状:
バージョン 1.12.2 から 1.12.4 にアップグレードするときに、ノードが削除されてから再度追加されると、そのノードの machine-init プロセスが失敗する可能性があります。このエラーは、再追加されたノードから重要なコントロール プレーン サービスへのネットワーク トラフィックがポリシー ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes によって拒否されるために発生します。このエラーは、この出力例のステータス メッセージでハイライト表示されています。
Feb 17 18 :52:52.330: 30 .0.0.9:41046 ( world) <> 30 .0.0.7:2379 ( host) policy-verdict:none INGRESS DENIED ( TCP Flags: SYN)
Feb 17 18 :52:52.330: 30 .0.0.9:41046 ( world) <> 30 .0.0.7:2379 ( host) Policy denied DROPPED ( TCP Flags: SYN) 回避策:
この問題を軽減するには、次の手順を行います。
ルート管理クラスタの場合:
CIDRClaim/org-external-cidr -n root（特に .status.ipv4AllocationStatus.allocatedCidrBlocks フィールド）から CIDR を取得します。ルート管理クラスタで次のコマンドを実行します。
ROOTCIDRs = $( ka get cidrclaim/org-external-cidr -n root -o json | jq '.status.ipv4AllocationStatus.allocatedCidrBlocks' )
これらの CIDR を ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes（具体的には .spec.ingress.fromCIDR フィールド）に追加します。次のコマンドを使用して、ルート管理クラスタでこの変更を適用します。
ka get ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes -o json \
| jq '.spec.ingress += [{"fromCIDR":' " ${ ROOTCIDRs } " '}]' \
| ka apply -f -
組織管理クラスタの場合:
組織の CIDR を取得します（例: CIDRClaim/org-external-cidr -n org-1（特に .status.ipv4AllocationStatus.allocatedCidrBlocks フィールド）から org-1）を取得します。このコマンドは、ルート管理クラスタに対して実行され、'org-1' の CIDR を取得します。
ORGCIDRs = $( ka get cidrclaim/org-external-cidr -n org-1 -o json | jq '.status.ipv4AllocationStatus.allocatedCidrBlocks' )
これらの CIDR を ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes（具体的には .spec.ingress.fromCIDR フィールド）に追加します。次のコマンドを使用して、それぞれの組織の管理クラスタでこの変更を適用します。
ko get ciliumclusterwidenetworkpolicy/base-node-policy-for-control-plane-nodes -o json \
| jq '.spec.ingress += [{"fromCIDR":' " ${ ORGCIDRs } " '}]' \
| ko apply -f -
この変更は、アップグレードを開始する前に 1 回だけ行う必要があります。
ネットワーキング
1.12.0
症状:
システム クラスタのベアメタル ノードで、2 つの anetd コンテナを終了できません。プロセスを強制停止し、kubelet と containerd を再起動した後、anetd Pod が再作成されますが、すべてのコンテナが podInit で停止し、containerd が次のエラー メッセージを報告します。
` failed to create containerd task: failed to create shim task: context deadline exceeded: unknown` .これにより、Container Network Interface（CNI）の起動がブロックされ、他の Pod のスケジュール設定が停止します。
回避策:
このノード状態を防ぐには、次の緩和策を実施します。
単一ノードで一度に 10 個を超える PVC をスケジュール設定しないでください。マウントされるまで待ってから、追加のスケジュールを設定します。これは、VM の作成時に最も顕著に現れました。
すべてのノードの /etc/lvm/lvm.conf ファイルを更新して、devices{} ブロックに filter = [ "r|/dev/dm.|", "r|/dev/sg.|" ] 行を追加します。
ノードがボリュームのアタッチとマウントのタイムアウトを示す状態になった場合、またはボリュームを削除できない場合は、ノードでハングしている vgs プロセスの数を確認して、ノードがこの特に悪い状態にあるかどうかを特定します。この状態のノードを修正する最も確実な方法は、ノードを再起動することです。
発生する可能性のある障害モードは他にもあります。この障害モードでは、マウント試行時に mount(2) system call failed: No space left on device というシグネチャが生成されます。これは、ノードのマウント伝播によるものと考えられます。これを確認するには、cat /proc/mounts | grep devtmpfs | awk '{ print $2 }' | sort -n | uniq -c を実行します。いずれかの値が 1 より大きい場合は、その値を使用している Pod を削除します。これにより、マウント解除がトリガーされます。成功しない場合は、そのパスを手動でマウント解除します。それでも解決しない場合は、再起動します。
ネットワーキング
1.12.2
特定のシナリオでは、競合状態により、Google Distributed Cloud（GDC）エアギャップで、Distributed Cloud の初期ブートストラップ中に必要なスイッチ ACL Kubernetes カスタム リソースを作成できません。
症状:
スイッチ ACL CR を一覧表示します。
kubectl get switchacls -n gpc-system --kubeconfig= /root/release/root-admin/root-admin-kubeconfig このコマンドの出力は、mgmt スイッチ ACL（mgmt-switch-acl）が作成されていないことを示しています。
No resources found in gpc-system namespace. 回避策:
Traffic Policy CR を一覧表示します。
kubectl get trafficpolicies -n gpc-system --kubeconfig= /root/release/root-admin/root-admin-kubeconfig 出力には、2 つのトラフィック ポリシー Kubernetes CR が返されます。
NAME AGE NAME
default-traffic-policy-data 4d17h default-traffic-policy-data
default-traffic-policy-mgmt 4d17h default-traffic-policy-mgmt
default-traffic-policy-mgmt トラフィック ポリシー Kubernetes CR を編集します。
kubectl edit trafficpolicies default-traffic-policy-mgmt -n gpc-system --kubeconfig= /root/release/root-admin/root-admin-kubeconfig このファイルの最後のポリシー ルールに移動します。これはファイルの末尾にある可能性があります。
最後のポリシールールの説明フィールドを特定します。フィールドは次のようになります。
Deny All rule for Management Network
この説明を編集し、説明行の先頭に The を追加します。
The Deny All rule for Management Network
ファイルを保存して終了します。
Kubernetes スイッチ ACL CR を再度一覧表示します。
kubectl get switchacls -n gpc-system --kubeconfig= /root/release/root-admin/root-admin-kubeconfig
出力には、管理スイッチの ACL（mgmt-switch-acl）が一覧表示されます。
NAME AGE NAME
mgmt-switch-acl 23h mgmt-switch-acl
物理サーバー
1.12.1
症状:
クラスタの作成中に Server をプロビジョニングすると、サーバーがプロビジョニング済みとマークされるものの、Provision-Ready 条件が欠落する可能性があります。そのため、NodePool はこのサーバーを使用できません。NodePool のエラー イベント メッセージの例は次のようになります。
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning ReconcileError xxx Server policy failure PolicyPreflightCompleted( UnreachableError) : { PolicyPreflightCompleted False 3 2023 -11-07 22 :10:56 +0000 UTC UnreachableError reachability err: Failed to connect to the host via ssh: ssh: connect to host xx.xx.xx.xx port 22 : Connection timed out}
回避策:
次のスクリプトを実行して ILO をリセットします。
SERVER_NAME =
ROOT_ADMIN_KUBECONFIG =
ILO_IP = $( kubectl get servers ${ SERVER_NAME } -n gpc-system --template= {{.spec.bmc.ip}} --kubeconfig= ${ ROOT_ADMIN_KUBECONFIG } )
SECRET_NAME = $( kubectl get secrets -o go-template= '{{range $index,$pod := .items}}{{.metadata.name}}{{"\n"}}{{end}}' -n gpc-system --kubeconfig= ${ ROOT_ADMIN_KUBECONFIG } | grep bmc | grep ${ SERVER_NAME } )
ILO_USER = $( kubectl get secrets ${ SECRET_NAME } -n gpc-system --template= {{.data.username}} --kubeconfig= ${ ROOT_ADMIN_KUBECONFIG } | base64 -d)
ILO_PASS = $( kubectl get secrets ${ SECRET_NAME } -n gpc-system --template= {{.data.password}} --kubeconfig= ${ ROOT_ADMIN_KUBECONFIG } | base64 -d)
# Perform iLO Reset
curl -k -u ${ ILO_USER } :${ ILO_PASS } -H "Content-Type: application/json" -H "OData-Version: 4.0" https://${ ILO_IP } /redfish/v1/Managers/1/Actions/Manager.Reset --data '{"ResetType":"ForceRestart"}' -X POST | jq
# Perform server power cycle, start with power off target server
curl -k -u ${ ILO_USER } :${ ILO_PASS } -H "Content-Type: application/json" -H "OData-Version: 4.0" -X POST https://${ ILO_IP } /redfish/v1/Systems/1/Actions/ComputerSystem.Reset --data '{"ResetType":"ForceOff"}' | jq .
# Verify target server powered off successfully
curl -kqs -u ${ ILO_USER } :${ ILO_PASS } https://${ ILO_IP } /redfish/v1/Systems/1 | jq '.PowerState'
# Power server back
curl -k -u ${ ILO_USER } :${ ILO_PASS } -H "Content-Type: application/jsonls " -H "OData-Version: 4.0" -X POST https://${ ILO_IP } /redfish/v1/Systems/1/Actions/ComputerSystem.Reset --data '{"ResetType":"On"}' | jq .
まれに、上記の手順で iLO をリセットしても問題が完全に解決しないことがあります。その場合は、サーバーの再プロビジョニングが必要になります。詳細な手順については、OS-P0002 と OS-P0003 のランブックを参照してください。
物理サーバー
1.12.2
症状:
ベアメタル ノードのアップグレードが 3 時間以上 in-progress 状態のままになっている。
回避策:
SERV-R0005 ランブックの手順に沿って対応します。
ネットワーキング
1.12.1
症状:
POAP が繰り返し失敗し、POAP のログに次のようなメッセージが表示されます。
2024 Feb 27 20 :20:25 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[ FDO26391GHS] -MAC[ 98 :A2:C0:F8:60:6A] - Running: 'nxos.10.3.1.bin' - /script.sh
2024 Feb 27 20 :20:25 switch %$ VDC-1 %$ %USER-1-SYSTEM_MSG: S/N[ FDO26391GHS] -MAC[ 98 :A2:C0:F8:60:6A] - Target: 'nxos64-cs.10.3.4a.M.bin' - /script.shnxos.10.3.1.bin は見つかりませんが、スイッチの bootflash ディレクトリに nxos64-cs.10.3.1.F.bin などの類似のファイルが見つかります。
回避策:
ブートストラップ マシンで、次の操作を行います。これらの手順は、プリインストール プロセスが進行中のときに完了する必要があります。/tmp/preinstall-bootstrap- フォルダが複数ある場合は、プリインストール プロセスのログを確認して、プリインストール プロセスで使用されている現在のフォルダに変更を適用します。プリインストール コマンドを再起動する必要がある場合、このアクションでは新しい /tmp/preinstall-bootstrap- フォルダも作成されます。
/tmp/preinstall-bootstrap-RANDOM_NUMBER フォルダに移動します。フォルダ内で poap.py ファイルを見つけます。
このファイルで md5 チェックサムを含む行を完全に削除して、head -n 4 poap.py が次のようになるようにします。
#!/bin/env python3
import glob
import os
import pkgutil
同じファイルの version_to_image_file に次の行を追加します。
"nxos.10.2.1.bin" : "nxos64.10.2.1.F.bin" ,
"nxos.10.2.2.bin" : "nxos64-cs.10.2.2.F.bin" ,
"nxos.10.2.3.bin" : "nxos64-cs.10.2.3.F.bin" ,
"nxos.10.2.4.bin" : "nxos64-cs.10.2.4.M.bin" ,
"nxos.10.2.5.bin" : "nxos64-cs.10.2.5.M.bin" ,
"nxos.10.2.6.bin" : "nxos64-cs.10.2.6.M.bin" ,
"nxos.10.2.7.bin" : "nxos64-cs.10.2.7.M.bin" ,
"nxos.10.3.1.bin" : "nxos64-cs.10.3.1.F.bin" ,
"nxos.10.3.2.bin" : "nxos64-cs.10.3.2.F.bin" ,更新されたファイルのセクションは次のようになります。
version_to_image_file = {
"nxos.10.2.1.bin": "nxos64.10.2.1.F.bin",
"nxos.10.2.2.bin": "nxos64-cs.10.2.2.F.bin",
"nxos.10.2.3.bin": "nxos64-cs.10.2.3.F.bin",
"nxos.10.2.4.bin": "nxos64-cs.10.2.4.M.bin",
"nxos.10.2.5.bin": "nxos64-cs.10.2.5.M.bin",
"nxos.10.2.6.bin": "nxos64-cs.10.2.6.M.bin",
"nxos.10.2.7.bin": "nxos64-cs.10.2.7.M.bin",
"nxos.10.3.1.bin": "nxos64-cs.10.3.1.F.bin",
"nxos.10.3.2.bin": "nxos64-cs.10.3.2.F.bin",
"nxos.10.3.3.bin": "nxos64-cs.10.3.3.F.bin",
"nxos.10.3.4a.bin": "nxos64-cs.10.3.4a.M.bin",
}
md5sum poap.py を実行して md5 合計を取得し、poap.py に追加して head -n 4 poap.py を次のようにします。
#!/bin/env python3
#md5sum="396bed5a5f579b80da5fac6edf0b590c"
import glob
import os
ネットワーキング
1.12.1
pnet コントローラが hairpinlink カスタム リソース（CR）を正常に生成しないため、1.11.x から 1.12.1 へのアップグレードが失敗します。
回避策:
アップグレード後、ルート管理クラスタで clusterroles/pnet-core-backend-controllers-role ファイルを編集します。
hairpinlinks を検索し、create,update,delete 権限をリソースに追加します。hairpinlinks と hairpinbgpsessions の CR が生成されていることを確認します。
NTP サーバー
1.12.1
症状:
kubectl get pods コマンドを実行すると、次のメッセージが表示されることがあります。
ntp-system ntp-relay-server-75bbf 1 /2 CrashLoopBackOff 123 ( 5m12s ago) 24h ログにライブネス プローブの警告が表示されることがあります。
Warning BackOff 5m55s ( x82 over 28m) kubelet Back-off restarting failed container ntp-image in pod ntp-relay-server-75bbf_ntp-system( 28e4e28f-4f99-4c6e-8c26-d271f0c7995c)
Warning Unhealthy <invalid> ( x37 over 35m) kubelet Liveness probe failed: Leap status is Not synchronised
この問題により、サーバーの時刻が同期されなくなる可能性があります。
回避策:
編集する ntp DaemonSet を開きます。
kubectl edit daemonset/ntp-relay-server -n ntp-system
timeoutSeconds: 30 行までの livenessProbe: セクションを削除します。ntp-image コンテナに次のセクションを追加します。
securityContext:
capabilities:
add:
- SYS_TIME
これにより、次のような構成になります。
containers:
- name: ntp-image
image: "DOCKER_REGISTRY /DOCKER_REPOSITORY /ntp-relay-server:DOCKER_TAG "
imagePullPolicy: Always
securityContext:
capabilities:
add:
- SYS_TIME OS NTP ポリシーを開いて編集します。
kubectl edit ospolicy/bm-ntp-policy -n gpc-system
ポリシー セクションの NTP IP アドレスをすべて削除します。その後、ポリシーは次のようになります。
policy:
installPlaybook:
extraVars:
ntp_servers: {}
name: server-ntp-config
secrets: {}
NTP サーバー
1.12.1
症状:
kubectl get pods コマンドを実行すると、次のメッセージが表示されることがあります。
NAMESPACE NAME READY STATUS RESTARTS AGE
ntp-system ntp-relay-job-1707869137-kd7p4 0 /1 CrashLoopBackOff 3 ( 15s ago) 59s この問題は、アップグレード ジョブのクリーンアップが適切に行われていないことが原因で発生します。対応は不要です。ジョブはクラッシュ ループ状態のままにしておきます。
NTP サーバー
1.12.2
症状:
システム クラスタのログに次のメッセージが表示されることがあります。
INFO: task umount:200725 blocked for more than 120 seconds. これは、時刻を同期していないサーバーで問題になります。構成が正しく適用されていません。正しく適用するには、別の Namespace に変更する必要があります。
回避策:
次の手順をすべてのクラスタに適用します。
既存の OS ポリシーを一覧表示します。
kubectl get ospolicies -n ntp-system 出力には admin-ntp-policy または worker-ntp-policy が表示されます。
ポリシーの名前に基づいて、.yaml ファイルに保存します。
kubectl get ospolicy/admin-ntp-policy -n ntp-system -o yaml > ntp-ospolicy.yaml
kubectl get ospolicy/worker-ntp-policy -n ntp-system -o yaml > ntp-ospolicy.yaml
metadata.namespace を ntp-system から gpc-system に変更し、status: line とその後のすべての文字を削除して、ファイルを編集します。編集したファイルをクラスタに適用します。
kubectl apply -f ntp-ospolicy.yaml
コントローラが OS ポリシーを適用するまで数分待ちます。
OSPolicy が適用されるノードの 1 つに SSH 接続を確立し、cat /etc/chrony.conf を実行します。出力には、ファイルが Ansible によって管理され、構成から nist.time.gov サーバーまたは ntp.pool サーバーが削除されたことを示すメッセージがファイルの先頭に表示されます。
VM のバックアップと復元
1.12.0
症状:
VM マネージャーのロールベース アクセス制御（RBAC）とスキーマ設定が正しくないため、ユーザーが VM のバックアップと復元のプロセスを開始できません。
Internal error occurred: failed calling webhook
"vvirtualmachinebackupplantemplates.virtualmachine.gdc.goog" :
failed to call webhook: Post "https://vmm-vm-controller-webhooks.vm-system.svc:443/validate-virtualmachine-gdc-goog-v1-virtualmachinebackupplantemplate?timeout=10s" :
context deadline exceeded 回避策:
VM バックアップ プラン名は、VirtualMachineBackupPlanTemplate 名、リソースタイプ（vm または vm-disk）、そのリソースの名前を連結したものです。この連結された文字列は 63 文字以下にする必要があります。VM インスタンスの作成と起動 と VM のバックアップ プランを作成する をご覧ください。
データベース サービス
1.12.0
症状:
Database Service ワークロードは、Distributed Cloud システム クラスタの個別のプロジェクト内でプロビジョニングおよび構成されます。プロジェクトは Distributed Cloud で管理境界を適用するために使用されますが、ワークロードの実行方法や実行場所には影響しません。そのため、これらのワークロードは、基盤となるコンピューティング インフラストラクチャを他のデータベース インスタンスやさまざまなコントロール プレーン システムと共有できます。
回避策:
追加の分離が必要なデータベース ワークロードの場合、ユーザーはシステム クラスタでのノードプールの作成をリクエストできます。このノードプールは、プロジェクトの作成時に参照する必要があります。これにより、データベース ワークロードが専用のコンピューティング インフラストラクチャでプロビジョニングされ、実行されます。分離されたノードプールの構成は、インフラストラクチャ オペレーターが完了する必要があります。
データベース サービス
1.12.2
症状:
AlloyDB Omni バージョン 15.2.1 では、同じノードに複数の AlloyDB Omni クラスタが作成されると、最後に作成されたクラスタが調整状態のままになります。コマンドで postgresql ログを取得する
kubectl --kubeconfig $ORG_SYSTEM_KUBECONFIG exec -ti $DATABASE_POD_NAME -n $SHADOW_NS -- cat /obs/diagnostic/postgresql.log
2024 -08-19 21 :20:15.594 UTC: [ 9400 /walwriter] LOG: [ auxprocess.c:129] BaseInit started for AuxProcType: walwriter
2024 -08-19 21 :20:15.595 UTC: [ 9400 /walwriter] LOG: [ auxprocess.c:131] BaseInit finished for AuxProcType: walwriter
*** SIGABRT received at time = 1724102415 on cpu 25 ***
PC: @ 0x7f03140a9d3c ( unknown) ( unknown)
2024 -08-19 21 :20:15.601 UTC: [ 9399 /client backend] alloydbadmin@localhost( 33906 ) [ unknown] postgres 66c3b70f.24b7 57P03:FATAL: [ postmaster.c:2601] the database system is not yet accepting connections
2024 -08-19 21 :20:15.601 UTC: [ 9399 /client backend] alloydbadmin@localhost( 33906 ) [ unknown] postgres 66c3b70f.24b7 57P03:DETAIL: Consistent recovery state has not been yet reached.
@ 0x5557f3b17e31 208 absl::AbslFailureSignalHandler()
@ 0x7f031405afd0 4677136 ( unknown)
@ 0x7f0314e75b20 ( unknown) ( unknown)
[ PID: 9400 ] : *** SIGABRT received at time = 1724102415 on cpu 25 ***
[ PID: 9400 ] : PC: @ 0x7f03140a9d3c ( unknown) ( unknown)
[ PID: 9400 ] : @ 0x5557f3b17f75 208 absl::AbslFailureSignalHandler()
[ PID: 9400 ] : @ 0x7f031405afd0 4677136 ( unknown)
[ PID: 9400 ] : @ 0x7f0314e75b20 ( unknown) ( unknown) 回避策:
1. データベース Pod にシェルで接続する
kubectl --kubeconfig $ORG_SYSTEM_KUBECONFIG exec -ti $DATABASE_POD_NAME -n $SHADOW_NS -- bash
echo "enable_lux_wal_writer = off" > /mnt/disks/pgsql/data/postgresql.conf.d/55user.conf
supervisorctl restart postgres
Chose default config file: /etc/supervisor/supervisord.conf
postgres: ERROR ( not running)
postgres: started
ファイアウォール
1.12.0
症状:
お客様のデプロイでは、secret.yaml ファイルの管理者ユーザー名は admin にする必要があります。代わりに、ファイルには最初の作成後に TO-BE-FILLED が含まれます。admin ユーザー名は、ファイアウォールに最初の構成を初期化するために使用する必要があります。また、ループバック IP admin\admin を介して使用する必要があります。
回避策:
次のファイアウォール認証情報に TO-BE-FILLED が存在しないことを確認します。
CELL_ID /CELL_ID -secret.yamlCELL_ID -ab-rack/CELL_ID -secret.yamlCELL_ID -ac-rack/CELL_ID -secret.yamlすべてのファイアウォール管理者アカウントのユーザー名が admin であることを確認します。
ファイアウォール
1.12.2
症状:
デフォルトの IDPS ファイアウォール ポリシーは、Direct Connect（DX）Interconnect の組織のカスタム IP をサポートしていません。その結果、カスタム IP がルート管理者の Harbor に接続できないため、カスタム IP を使用した組織の作成は失敗します。
回避策:
トラフィックのブロックを解除するには、組織のカスタム IP の SecurityPolicyRule を手動で作成し、IDPS ファイアウォールにデプロイします。ランブック FW-G0002
1. ルート ファイアウォール仮想システムに上り（内向き）SecurityPolicyRule を作成して、組織のカスタム IP がルート Harbor にアクセスできるようにします。
apiVersion: firewall.private.gdc.goog/v1alpha2
kind: SecurityPolicyRule
metadata:
labels:
firewall.private.gdc.goog/policy-type: idps
name: root-default-ingress-ORG_NAME -custom
namespace: root
spec:
action: allow
destination:
addresses:
- root-external-group
zones:
- vsys1-gpc
firewallVirtualSystemRef:
name: vsys1-root
priority: 150
profile:
group: gdch-threat-profile-group
type: group
service:
option: selected
ports:
- ports: "123"
protocol: UDP
- ports: "1122"
protocol: TCP
- ports: "5140"
protocol: TCP
- ports: "10443"
protocol: TCP
source:
addresses:
- org.customIPConfig.externalCIDRs # example: 30.0.0.0/22
zones:
- vsys1-cp
2. 組織のファイアウォール vsys に上り（内向き）SecurityPolicyRule を作成して、ルートが組織の APIServer にアクセスできるようにします。
apiVersion: firewall.private.gdc.goog/v1alpha2
kind: SecurityPolicyRule
metadata:
labels:
firewall.private.gdc.goog/policy-type: idps
name: ORG_NAME -custom-default-ingress-root
namespace: ORG_NAME # example: gpu-org-1
spec:
action: allow
destination:
addresses:
- org.customIPConfig.externalCIDRs # example: 30.0.0.0/22
zones:
- ORG_VSYS_ID -gpc # example: vsys3-gpc
firewallVirtualSystemRef:
name: ORG_VSYS_ID -ORG_NAME # example: vsys3-gpu-org-1
priority: 110
profile:
group: gdch-threat-profile-group
type: group
service:
option: selected
ports:
- ports: "22"
protocol: TCP
- ports: "5140"
protocol: TCP
- ports: "6443"
protocol: TCP
- ports: "10443"
protocol: TCP
source:
addresses:
- root-external-group
zones:
- ORG_VSYS_ID -cp # example: vsys3-cp
3. ファイアウォール構成の置換をトリガーして、SecurityPolicyRules をデプロイします。
ハードウェア セキュリティ モジュール
1.12.0
症状:
CipherTrust Manager の既存の既知の問題により、無効にしたトライアル ライセンスが検出され、誤った有効期限切れの警告がトリガーされることがあります。
回避策:
HSM-R0003 を参照して、有効な通常ライセンスを確認し、無効化されたトライアル ライセンスを削除します。
ハードウェア セキュリティ モジュール
1.12.0
症状:
KMS CTMKey を削除すると、ハードウェア セキュリティ モジュール（HSM）が予期しない動作をします。たとえば、組織で KMS サービスが起動しないことがあります。
回避策:
ユーザーは、KMS ルート鍵ではなく KMS 鍵を削除することで、データを暗号シュレッダーできます。これは CTMKey として現れます。
ハードウェア セキュリティ モジュール
1.12.0
症状:
ローテーション可能な不明なシークレットのリストを取得します。
kubectl get rotatablesecret -A | grep -i unknown 出力は次のようになります。
gpc-system yz-aa-hsm01-kmip-certificate HSM-0016 Unknown
gpc-system yz-aa-hsm01-nae-certificate HSM-0016 3d19h <invalid> Unknown
gpc-system yz-aa-hsm01-web-certificate HSM-0016 2d <invalid> Unknown 要件 :
ルート管理クラスタへのアクセス
jq ツール
IAM-R0004 に沿って、ルート管理クラスタの KUBECONFIG を生成します。IAM-R0005 に沿って、ルート管理クラスタで clusterrole/hsm-admin を取得します。
回避策:
HSM のデータ ネットワーク IP アドレスのリストを取得します。
kubectl --kubeconfig ${ KUBECONFIG :? } get hsm -A -o json | jq -r '.items[] | "\(.spec.dataNetwork.ip)"' 出力は次のようになります。
10 .89.3.2
10 .89.3.3
10 .89.3.4
前の手順で取得した HSM データ ネットワークの IP アドレスごとに、次の操作を行います。
IP アドレスを HSM_DATA_IP という変数にエクスポートします。
export HSM_DATA_IP = HSM_DATA_IP_ADDRESS
ウェブ（ポート 443）、nae（ポート 9000）、kmip（ポート 5696）のサーバー証明書を取得し、証明書の有効性を調べます。
openssl s_client -showcerts -connect $HSM_DATA_IP :443 2 >/dev/null | openssl x509 -text
openssl s_client -showcerts -connect $HSM_DATA_IP :9000 2 >/dev/null | openssl x509 -text
openssl s_client -showcerts -connect $HSM_DATA_IP :5696 2 >/dev/null | openssl x509 -text 出力は次のようになります。
Validity
Not Before: Mar 12 20 :36:58 2024 GMT
Not After : Jun 16 20 :36:58 2026 GMT
Not After の日付が今日から 30 日以内の場合は、HSM T0016 ランブックの手順に沿ってサーバー証明書を更新します。
モニタリング
1.12.0
症状:
組織の作成時に証明書の準備ができない:
$ kubectl --kubeconfig /root/release/user/org-1-system-user-kubeconfig get certificate -n mon-system
NAME READY SECRET AGE
mon-node-exporter-backend-consumers False mon-node-exporter-backend-consumers-cert 20h
mon-node-exporter-backend-providers False mon-node-exporter-backend-providers-cert 20h `SecretForwarder` により、シークレットは引き続き存在します。
$ kubectl --kubeconfig /root/release/user/org-1-system-user-kubeconfig get secret -n mon-system | grep -E "node-exporter.+cert"
mon-node-exporter-backend-consumers-cert kubernetes.io/tls 3 20h
mon-node-exporter-backend-providers-cert kubernetes.io/tls 3 20h 回避策:
Lifecycle Manager を一時停止して、証明書の再作成と削除が行われないようにします。
kubectl --kubeconfig /root/release/org-admin/org-1-admin-kubeconfig annotate subcomponent mon-node-exporter -n org-1-system-cluster lcm.private.gdc.goog/paused= "true"
kubectl --kubeconfig /root/release/org-admin/org-1-admin-kubeconfig annotate subcomponent mon-node-exporter -n user-vm-1-cluster lcm.private.gdc.goog/paused= "true"
kubectl --kubeconfig /root/release/org-admin/org-1-admin-kubeconfig annotate subcomponent mon-node-exporter -n user-vm-2-cluster lcm.private.gdc.goog/paused= "true"
kubectl --kubeconfig /root/release/user/org-1-system-user-kubeconfig delete certificate -n mon-system mon-node-exporter-backend-consumers mon-node-exporter-backend-providers node-exporter はユーザー クラスタで調整されません。
モニタリング
1.12.0
症状:
ServiceNow Webhook を構成 すると、ライフサイクル管理（LCM）が再調整され、mon-system 名前空間の ConfigMap オブジェクト mon-alertmanager-servicenow-webhook-backend と Secret オブジェクト mon-alertmanager-servicenow-webhook-backend に行われた変更が元に戻ります。
回避策:
LCM サブコンポーネントを一時停止して、変更が元に戻らないようにします。
ルート管理クラスタと組織管理クラスタの kubeconfig ファイルのパスを取得します。パスをそれぞれ ROOT_ADMIN_KUBECONFIG 環境変数と ORG_ADMIN_KUBECONFIG 環境変数に保存します。
次のいずれかのクラスタで LCM サブコンポーネントを一時停止します。
ルート管理クラスタで LCM サブコンポーネントを一時停止します。
kubectl --kubeconfig $ROOT_ADMIN_KUBECONFIG annotate subcomponent mon-alertmanager-servicenow-webhook -n root lcm.private.gdc.goog/paused= "true"
組織管理クラスタで LCM サブコンポーネントを一時停止します。
kubectl --kubeconfig $ORG_ADMIN_KUBECONFIG annotate subcomponent mon-alertmanager-servicenow-webhook -n org-1-system-cluster lcm.private.gdc.goog/paused= "true"
モニタリング
1.12.0
症状:
ユーザー クラスタの一部の指標が収集されません。この問題は、ユーザー VM クラスタに影響しますが、システム クラスタには影響しません。
Prometheus サーバーから次のログを確認できます。
prometheus-server ts = 2024 -02-21T16:07:42.300Z caller = dedupe.go:112 component = remote level = warn remote_name = cortex-remote-write url = http://cortex-tenant.mon-system.svc:9009/push msg = "Failed to send batch, retrying" err = "server returned HTTP status 500 Internal Server Error: 2 errors occurred:"
Cortex テナントから次のログを確認できます。
cortex-tenant time = "2024-02-23T18:03:44Z" level = error msg = "proc: src=127.0.0.6:55021 lookup cortex.mon-system.svc on 172.25.38.10:53: no such host"
回避策:
問題を解決するには、以下の手順に沿って対応します。
クラスタの kubeconfig ファイルのパスを取得します。パスを KUBECONFIG 環境変数に保存します。
ユーザー VM クラスタにスタブ サービスをデプロイします。
kubectl --kubeconfig $KUBECONFIG apply -f - & lt& ltEOF
apiVersion: v1
kind: Service
metadata:
labels:
app: cortex
name: cortex
spec:
ports:
- protocol: TCP
targetPort: 9009
port: 9009
name: cortex
type: ClusterIP
sessionAffinity: ClientIP
EOF
Cortex テナントのデプロイを再起動します。
kubectl --kubeconfig $KUBECONFIG rollout restart deploy -n mon-system cortex-tenant
モニタリング
1.12.0
症状:
Infrastructure Operator の Grafana インスタンス用の指標は、Platform Administrator の Grafana インスタンスに存在することがあります。その逆も同様です。この問題は、デフォルトのテナントが異なるクラスタ境界を越えて ASM ロード バランシング リクエストが行われることが原因で発生します。
回避策:
この回避策では、private-cloud ソースへのアクセスと、コンポーネント アップデートをロールアウトする機能が必要です。メッシュ構成を変更して、cortex-tenant サービスがローカル クラスタからのトラフィックのみを受信するように制限し、ASM コンポーネントをロールアウトする必要があります。
manifests/plain/asm/1.19/asm-primary-cluster-operator.yaml ファイルを開きます。meshConfig フィールドの serviceSettings フィールドを紹介します。meshConfig フィールドは、元々次の例のようになっています。
...
profile: minimal
revision: 1 -19
meshConfig:
localityLbSetting:
enabled: false
...
したがって、meshConfig フィールドを次の例のように変更する必要があります。
profile: minimal
revision: 1 -19
meshConfig:
serviceSettings:
- settings:
clusterLocal: true
hosts:
- 'cortex-tenant.mon-system.svc.cluster.local'
localityLbSetting:
enabled: false
ASM コンポーネントをクラスタにロールアウトします。
アップグレード
1.12.0
症状:
1.11.0 から 1.11.3 にアップグレードすると、NodeOSInPlaceUpgradeCompleted でノードのアップグレードが失敗します。
ka logs -n gpc-system os-policy-preflight-os-upgrade-bm-86efcc8en8sh2-6h5cn | grep GDCH-OS-ANSIBLE-CHECK -A 50
[ GDCH-OS-ANSIBLE-CHECK]
{
"syntax" : {
"success" : true,
"msg" : ""
} ,
"apply" : {
"reachablity" : {
"success" : true,
"msg" : ""
} ,
"execution" : {
"success" : false,
"msg" : "errors found when simluating play execution on host: 10.3.20.9" ,
"tasks" : [
{
"task" : "os/upgrade : Copy GRUB file to BOOT location" ,
"error" : "Source /boot/efi/EFI/ubuntu/grubx64.efi not found"
}
]
}
} ,
"diff" : null
}
回避策:
アップグレードするベアメタル マシンにログインします。fstab に /boot/efi があり、ディレクトリがマウントされているかどうかを確認します。
# cat /etc/fstab
LABEL = cloudimg-rootfs / ext4 defaults 0 1
LABEL = UEFI /boot/efi vfat umask = 0077 0 1
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8 :0 0 3 .5T 0 disk
├─sda1 8 :1 0 3 .5T 0 part /
├─sda2 8 :2 0 64 .3M 0 part
├─sda14 8 :14 0 4M 0 part
└─sda15 8 :15 0 106M 0 part nodeupgradetask を一時停止します。
mount -a を実行し、ディレクトリがマウントされているかどうかを確認します。
# mount -a
root@mb-aa-bm04:~# ls /boot/efi/
EFIここで確認を進めます。次のコマンドを実行します。
C
# Ensure all three cmds prints `Files are identical`
if [ " $( sha256sum /boot/efi/EFI/ubuntu/shimx64.efi | awk '{ print $1 }' ) " == " $( sha256sum /boot/efi/EFI/BOOT/BOOTX64.EFI | awk '{ print $1 }' ) " ] ; then echo "Files are identical." ; else echo "Files are different." ; fi
if [ " $( sha256sum /boot/efi/EFI/ubuntu/grubx64.efi | awk '{ print $1 }' ) " == " $( sha256sum /boot/efi/EFI/BOOT/grubx64.efi| awk '{ print $1 }' ) " ] ; then echo "Files are identical." ; else echo "Files are different." ; fi
if [ " $( sha256sum /boot/efi/EFI/ubuntu/grub.cfg | awk '{ print $1 }' ) " == " $( sha256sum /boot/efi/EFI/ubuntu/grub.cfg | awk '{ print $1 }' ) " ] ; then echo "Files are identical." ; else echo "Files are different." ; fi
すべてのファイルが同一でない場合は、マシンでこのコマンドを実行し、チェックを繰り返します。
/usr/local/update-efi-files.sh
nodeupgradetask の一時停止を解除します
アップグレード
1.12.0
症状:
スイッチのアップグレードで bootflash を追加できない:
Conditions:
Last Transition Time: 2024 -01-10T20:06:30Z
Message: exception: add and activate package nxos.CSCwh72780-n9k_ALL-1.0.0-9.3.10.lib32_n9000.rpm: nx-api RPC request failed
with status code 400 and body "{\n\t\"jsonrpc\":\t\"2.0\",\n\t\"error\":\t{\n\t\t\"code\":\t-32602,\n\t\t\"message\":\t\"Invalid params\",\n\t\
t\"data\":\t{\n\t\t\t\"msg\":\t\"Adding the patch (/nxos.CSCwh72780-n9k_ALL-1.0.0-9.3.10.lib32_n9000.rpm)\\n\\n[### ] 10%\\n[#│ # [] 10%\\n[##### ] 20%\\n[####### ] 30%\\n[######### ] 40%\\n[######### ] 4
0%\\n[####################] 100%\\n[####################] 100%\\nInstall operation 21 failed because this patch already exists. at Wed Jan 10 2
1:00:06 2024\\n\\n\"\n\t\t}\n\t},\n\t\"id\":\t1\n}" for requests "install add bootflash:///nxos.CSCwh72780-n9k_ALL-1.0.0-9.3.10.lib32_n9000.rpm
activate forced" 回避策:
障害が発生しているスイッチにログインし、パッケージのスイッチから install activate コマンドを実行します。
install activate nxos.CSCwh72780-n9k_ALL-1.0.0-9.3.10.lib32_n9000.rpm
アップグレード
1.12.1、1.12.2、1.12.4
症状:
クラスタのアップグレードが 1 時間以上ハングしている。ベアメタル マシンのメンテナンス モードのステータスと仕様が一致しません。たとえば、次のコマンドを実行します。
kubectl get baremetalmachines -A -o custom-columns= NAMESPACE:.metadata.namespace,NAME:.metadata.name,MaintenanceMode:.spec.maintenanceMode,Status:.status.underMaintenance 表示されます。
root 10 .252.135.4 false true ベアメタル マシンのプリフライト チェックジョブに次のエラー メッセージが表示されます。
The error was: 'dict object' has no attribute 'stdout' \n\n The error appears to be in '/playbook/roles/machine_check_common/tasks/main.yaml' : line 215 , column 3 , but may\n be elsewhere in the file depending on the exact syntax problem.\n\n The offending line appears to be:\n\n\n - name: Check if bypass the time check in node agent mode\n ^ here\n "} 回避策:
次のコマンドを使用します。
export KUBECONFIG = ${ ROOT_OR_ORG_ADMIN_KUBECONFIG }
kubectl get cluster -A
kubectl annotate cluster ${ CLUSTER_NAME } -n= ${ CLUSTER_NAMESPACE } "baremetal.cluster.gke.io/bypass-check=ntp"
ノード OS
1.11.3
症状:
os-policy Pod の手動回避策の後に VM 再起動タスクが失敗します。次のメッセージが表示されます。
ko logs os-policy-preflight-os-reboot-vm-b1fb94147x8r9-nqmvp -n gpc-system
playbook: server-reboot.yaml
{
"custom_stats" : {} ,
"global_custom_stats" : {} ,
"plays" : [
{
"play" : {
"duration" : {
"end" : "2024-01-12T03:50:52.749714Z" ,
"start" : "2024-01-12T03:50:42.694226Z"
} ,
"id" : "5251f140-5a01-5cce-6150-000000000006" ,
"name" : "Run OS Upgrade Tasks"
} ,
"tasks" : [
{
"hosts" : {
"172.20.128.10" : {
"action" : "setup" ,
"changed" : false,
"msg" : "Failed to connect to the host via ssh: ssh: connect to host 172.20.128.10 port 22: Connection timed out" ,
"unreachable" : true
}
} ,
"task" : {
"duration" : {
"end" : "2024-01-12T03:50:52.749714Z" ,
"start" : "2024-01-12T03:50:42.704562Z"
} ,
"id" : "5251f140-5a01-5cce-6150-00000000000b" ,
"name" : "os/reboot : Gather OS distribution information"
}
}
]
}
] ,
"stats" : {
"172.20.128.10" : {
"changed" : 0 ,
"failures" : 0 ,
"ignored" : 0 ,
"ok" : 0 ,
"rescued" : 0 ,
"skipped" : 0 ,
"unreachable" : 1
}
}
}
[ GDCH-OS-ANSIBLE-CHECK]
{
"syntax" : {
"success" : true,
"msg" : ""
} ,
"apply" : {
"reachablity" : {
"success" : false,
"msg" : "Failed to connect to the host via ssh: ssh: connect to host 172.20.128.10 port 22: Connection timed out"
} ,
"execution" : {
"success" : false,
"msg" : "" ,
"tasks" : null
}
} ,
"diff" : null
}
[ GDCH-OS-ANSIBLE-CHECK]
Error: reachability err: Failed to connect to the host via ssh: ssh: connect to host 172 .20.128.10 port 22 : Connection timed out
回避策:
VM を停止して起動すると、問題が解決します。VM を起動して停止する の手順に沿って操作します。
上位ネットワーキング
1.12.0
症状:
ユーザー VM クラスタがスタックし、ContainerCreating 状態の Pod を記述すると、次の警告が表示されます。
# kubectl --kubeconfig path/to/usercluster_kubeconfig describe pods/bm-system-machine-preflight-check-172.204c807f67d2cab60d5d8q58q -n user-vm-1-cluster
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedCreatePodSandBox 108s ( x62 over 79m) kubelet ( combined from similar events) : Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "ec4d2021ae9d76adf49a6d3c88d678b3b5d9
50990daa6ffee3fcfeed8291dfa8" : plugin type = "cilium-cni" name = "cilium" failed ( add) : Unable to create endpoint: [ PUT /endpoint/{ id}][ 429 ] putEndpointIdTooManyRequests 回避策:
NET-P0001 ランブックの手順に沿って、システム クラスタで anetd を再起動します。
システム アーティファクト レジストリ
1.12.1
症状:
ルート組織を 1.11.1 から 1.12.1 にアップグレードすると、アドオン ステージで Helm pull エラーが発生し、アップグレードが失敗することがあります。
harbor-system harbor-harbor-harbor-core-657d86bcf8-zl8d2 1 /1 Running 0 14h
harbor-system harbor-harbor-harbor-core-7d66b4c7c-7g6t4 0 /1 CrashLoopBackOff 155 ( 76s ago) 12h 回避策:
サポート リクエストを送信します。詳しくは、サポートをリクエストする をご覧ください。
アップグレード
1.12.0
症状:
アップグレード中に、OPA Gatekeeper サブコンポーネントがシステム クラスタにインストールされません。ただし、制約はインストールされ、制約を適用する Webhook もインストールされます。
システム クラスタ内の複数の Pod が TaintToleration 状態のままになることがあります。
mon-system mon-cortex-pre-upgrade-job-mn29x 0 /1 TaintToleration 0 96m <none> zb-aa-bm07 <none> <none>
mon-system mon-kube-state-metrics-backend-d49b868dc-fmp62 0 /2 TaintToleration 0 97m <none> zb-aa-bm07 <none> <none>
mon-system primary-prometheus-shard1-replica0-0 0 /3 TaintToleration 0 103m <none> zb-aa-bm07 <none> <none>
netapp-trident netapp-trident-controller-7ffb4c5f89-rvwjj 0 /5 TaintToleration 0 103m <none> zb-aa-bm07 <none> <none>
obs-system alertmanager-0 0 /2 TaintToleration 0 98m <none> zb-aa-bm07 <none> <none>
obs-system audit-logs-loki-io-0 0 /3 TaintToleration 0 97m <none> zb-aa-bm07 <none> <none>
obs-system log-audit-backend-failure-detector-6lgsq 0 /1 TaintToleration 0 105m <none> zb-aa-bm07 <none> <none>
obs-system meta-alertmanager-0 0 /1 TaintToleration 0 102m <none> zb-aa-bm07 <none> <none>
obs-system meta-alertmanager-servicenow-webhook-5679f48895-ggkg6 0 /2 TaintToleration 0 102m <none> zb-aa-bm07 <none> <none>
platform-obs-obs-system grafana-proxy-server-7b6b79f787-2x92t 0 /2 TaintToleration 0 103m <none> zb-aa-bm07 <none> <none>
vm-system gdch-rocky-yum-repo-distributor-zfwp6 0 /1 TaintToleration 0 97m <none> zb-aa-bm07 <none> <none>
vm-system gdch-rocky-yum-repo-server-568768c97b-c9hm2 0 /2 TaintToleration 0 97m <none> zb-aa-bm07 <none> <none>
Istio
1.12.1
症状:
コンテナ名 istio-proxy の Pod の準備ができておらず、Back-off pulling image "auto" イベントで ImagePullBackOff ステータスになっています。
回避策:
istio-revision-tag-default 変更用 Webhook がクラスタに存在することを確認します。自動復元しない場合は、10 分ほど待ってから、システムが自動復元するかどうかを確認します。解決しない場合は、問題をエスカレーションします。変更用 Webhook が存在する場合は、問題のある Pod を削除し、Pod が復元されることを確認します。.spec.containers[].image は auto にしてはならず、gcr.io/gke-release/asm/proxyv2:<image version> のような実際の画像にする必要があります。
ロギング
1.12.1
症状:
1.11.1 から 1.12.1 にアップグレードすると、ログ コンポーネントによってデプロイされた ValidatingWebhookConfigurations、MutatingWebhookConfigurations、MonitoringRules のアップグレードが失敗する可能性があります。
回避策:
kubectl があり、IAM-R0004 ランブックにアクセスしてルート管理者クラスタの KUBECONFIG を取得できることを確認します。
ルート管理クラスタから ValidatingWebhookConfiguration root-admin-private-logging-validation-webhook を削除します。
kubectl delete validatingwebhookconfiguration root-admin-private-logging-validation-webhook ルート管理クラスタから MutatingWebhookConfiguration root-admin-private-logging-defaulter-webhook を削除します。
kubectl delete mutatingwebhookconfiguration root-admin-private-logging-defaulter-webhook ルート管理クラスタから ValidatingWebhookConfiguration root-admin-logging-webhook を削除します。
kubectl delete validatingwebhookconfiguration root-admin-logging-webhook ルート管理クラスタの infra-obs Namespace から MonitoringRule operational-logs-alerts を削除します。
kubectl delete monitoringrule operational-logs-alerts -n infra-obs ルート管理クラスタの infra-obs namespace から MonitoringRules audit-logs-alerts、audit-logs-sli-syslog-prober、audit-logs-sli-filelog-prober、audit-logs-sli-fluentbit-to-loki、audit-logs-sli-fluentbit-to-splunk、audit-logs-sli-fluentbit-backlog、audit-logs-sli-loki-ingester-failed-rate、audit-logs-sli-loki-io-up、audit-logs-sli-loki-pa-up を削除します。
kubectl delete monitoringrule audit-logs-alerts audit-logs-sli-syslog-prober audit-logs-sli-filelog-prober audit-logs-sli-fluentbit-to-loki audit-logs-sli-fluentbit-to-splunk audit-logs-sli-fluentbit-backlog audit-logs-sli-loki-ingester-failed-rate audit-logs-sli-loki-io-up audit-logs-sli-loki-pa-up -n infra-obs ルート管理クラスタでサブコンポーネント log-admin の準備ができていることを確認します。
export RECONCILING = "`kubectl get subcomponent log-audit -n root -o json | jq '.status.conditions | .[] | select(.type == " Reconciling") | .status'`" ; if [[ $RECONCILING = ~ "False" ]] ; then echo "log-audit is ready" ; else echo "log-audit is not ready" ; fi 成功した場合、コマンドは log-audit is ready を出力します。それ以外の場合、出力は log-audit is not ready です。
ルート管理クラスタでサブコンポーネント log-admin の準備ができていることを確認します。
export RECONCILING = "`kubectl get subcomponent log-operational -n root -o json | jq '.status.conditions | .[] | select(.type == " Reconciling") | .status'`" ; if [[ $RECONCILING = ~ "False" ]] ; then echo "log-operational is ready" ; else echo "log-operational is not ready" ; fi 成功した場合、コマンドは log-operational is ready を出力します。それ以外の場合、出力は log-operational is not ready です。
ロギング
1.12.1
log-infra-backend-preinstall ジョブの問題により、監査ログと運用ログの Loki がインストールされず、ログが収集されません。
症状:
システム クラスタで CrashLoopBackoff が発生することがあります。
obs-system anthos-log-forwarder-5ghbm 2 /3 CrashLoopBackOff 135 ( 3m52s ago) 15h
ロギング
1.12.1
症状:
mon-system Namespace の Pod のステータスが OOMKilled になることがあります。
NAMESPACE NAME READY STATUS RESTARTS AGE
mon-system cortex-ingester-0 1 /2 OOMKilled 6 ( 3h5m ago) 11h
回避策:
各インジェスタのメモリを増やすか、インジェスタの数を増やすか、またはその両方を行います。これを行うには、次の例に示すように、組織の管理クラスタに SubcomponentOverride をデプロイします。
apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
name: mon-cortex-ingester-override
namespace: org-1-system-cluster
spec:
backend:
operableParameters:
ingester:
resourcesLimit:
memory: "6Gi" # 6Gi is the default, increase to add more memory to each ingester
replicas: 4 # 4 is the default, increase to create more ingester instances.
subComponentRef: mon-cortex
アップグレード
1.12.1
症状:
1.11.x から 1.12.1 にアップグレードすると、ノードのアップグレードが失敗し、次のエラー メッセージが表示されます。
{
"lastTransitionTime" : "2024-02-13T22:53:36Z" ,
"message" : "following checks failed, ['check_registry_mirror_reachability_pass']" ,
"observedGeneration" : 3 ,
"reason" : "JobStatus" ,
"status" : "False" , <----
"type" : "MaintenanceModeHealthCheckReady"
} ,
回避策:
次のコマンドを使用します。
kubectl --kubeconfig= ${ ROOT_OR_ORG_ADMIN_KUBECONFIG } annotate cluster ${ CLUSTER_NAME } -n= ${ CLUSTER_NAMESPACE } "baremetal.cluster.gke.io/maintenance-mode-ignore-healthcheck=true"
アップグレード
1.12.1、1.12.2、1.12.4
症状:
1. OrganizationUpgrade が anthosBareMetal、addOn、node のステージで停止し、Succeeded 条件の Unknown ステータスが表示されます。
kubectl --kubeconfig= ${ ROOT_ADMIN_KUBECONFIG } get organizationupgrade -n gpc-system ${ ORG_NAME } -o yaml
addOn: {}
anthosBareMetal:
conditions:
- lastTransitionTime: "2024-09-12T12:10:55Z"
message: 'UPG1300: ABM upgrade expected to finish within 2h0m0s but hasn''t
after 39h18m50.606521473s, last message was: Cluster upgrade for root-admin
cluster: in-progress'
observedGeneration: 1
reason: ABMUpgradeTimeout
status: Unknown
type: Succeeded
startTime: "2024-09-12T12:10:55Z"
node:{}
check_registry_mirror_reachability_pass チェックの失敗が表示されます。
kubectl --kubeconfig= ${ ROOT_ADMIN_OR_ORG_ADMIN_KUBECONFIG } get baremetalmachines -A -o json | jq '.items[] | select(.status.underMaintenace != .spec.maintenanceMode) | .metadata.name as $name | .status.underMaintenace as $statm | .spec.maintenanceMode as $specm | .status.conditions[] | select(.status == "False") | select(.type == "MaintenaceModeHealthCheckReady")'
{
"lastTransitionTime" : "2024-02-13T19:17:27Z" ,
"message" : "following checks failed, ['check_registry_mirror_reachability_pass']" ,
"observedGeneration" : 3 ,
"reason" : "JobStatus" ,
"status" : "False" ,
"type" : "MaintenaceModeHealthCheckReady"
} ,
回避策:
次のコマンドを使用します。
export KUBECONFIG = ${ ROOT_OR_ORG_ADMIN_KUBECONFIG }
kubectl get cluster -A
kubectl annotate cluster ${ CLUSTER_NAME } -n= ${ CLUSTER_NAMESPACE } "baremetal.cluster.gke.io/maintenance-mode-ignore-healthcheck=true"
アップグレード
1.12.1、1.12.2、1.12.4
症状:
1. OrganizationUpgrade が anthosBareMetal、addOn、node のステージで停止し、Succeeded 条件の Unknown ステータスが表示されます。
kubectl --kubeconfig= ${ ROOT_ADMIN_KUBECONFIG } get organizationupgrade -n gpc-system ${ ORG_NAME } -o yaml
addOn: {}
anthosBareMetal:
conditions:
- lastTransitionTime: "2024-09-12T12:10:55Z"
message: 'UPG1300: ABM upgrade expected to finish within 2h0m0s but hasn''t
after 39h18m50.606521473s, last message was: Cluster upgrade for root-admin
cluster: in-progress'
observedGeneration: 1
reason: ABMUpgradeTimeout
status: Unknown
type: Succeeded
startTime: "2024-09-12T12:10:55Z"
node:{}
netutil が見つからないというエラーが表示されます。
kubectl --kubeconfig= ${ ROOT_ADMIN_OR_ORG_ADMIN_KUBECONFIG } get healthchecks -n kube-system -o json | jq '.items[].status | select(.lastHealthcheck.lastStatus == "Error")'
{
"lastHealthcheck" : {
"error" : {
"code" : "500" ,
"reason" : "[Errno 2] No such file or directory: /usr/local/bin/abm-tools10.5.23.4/netutil"
} ,
"lastCompletedTime" : "2024-09-14T05:11:39Z" ,
"lastStatus" : "Error" ,
"monitoredComponentVersion" : "1.28.900-gke.112" ,
"version" : "1.28.900-gke.112"
} ,
"lastScheduledTime" : "2024-09-14T05:26:00Z"
}
回避策:
失敗したヘルスチェックに対応する Kubernetes Job を削除する
kubectl --kubeconfig= ${ ROOT_ADMIN_OR_ORG_ADMIN_KUBECONFIG } get job -A -l Command = machine-health-check --field-selector status.successful= 0
NAMESPACE NAME COMPLETIONS DURATION AGE
root bm-system-10.200.0.2-machine-28771464 0 /1 67m 67m
root bm-system-10.200.0.2-machine-28771524 0 /1 7m33s 7m33s
kubectl --kubeconfig= ${ ROOT_ADMIN_OR_ORG_ADMIN_KUBECONFIG } delete job -A -l Command = machine-health-check --field-selector status.successful= 0
job.batch "bm-system-10.200.0.2-machine-28771464" deleted
job.batch "bm-system-10.200.0.2-machine-28771524" deleted
VM Manager
1.12.1
症状:
1.11.x から 1.12.x にアップグレードすると、Pod が多すぎるため VM の準備が整わず、ベアメタル ノードのドレインがブロックされることがあります。
回避策:
VM を再起動します。
物理サーバー
1.12.1
症状:
1.11.x から 1.12.1 にアップグレードすると、NodeUpgrade に同じハードウェア モデルの複数のバージョンが含まれ、ファームウェア アップグレードの検証がブロックされます。
回避策:
次の手順に沿って、NodeUpgrade CR spec を変更します。
アップグレードが HPE Gen10 サーバー（GDC-4D）の場合は、ilo6 モデルのファームウェアを削除します。それ以外の場合は、ilo5 モデルのファームウェアを削除します。
各説明の最新の redfishVersion を持つエントリを保持するセクション。2.98 Oct 10 2023 を含むエントリのみを保持します。
- description: SystemBMC
model: ilo5
redfishVersion: 2 .98 Oct 10 2023
- description: SystemBMC
model: ilo5
redfishVersion: 2 .95 Jul 19 2023
物理サーバー
1.12.1
症状:
Ironic が、サーバーの起動を待機中にタイムアウトしました。ステータスが cleaning から clean failed、そして available に変わります。
2024 -02-23 18 :53:00.659 1 DEBUG ironic.api.method [ req-3a22ed15-d5cd-4d77-bb0b-0e7a3042e793 - - - - -] Client-side error: Node facc133f-898c-46d4-974b-92e3560892d5 is locked by host 10 .128.120.2, please retry after the current operation is completed. format_exception /usr/lib/python3.6/site-packages/ironic/api/method.py:124スイッチがオンになっているかどうかを確認します。
curl -kqs -u ${ ILO_USER } :${ ILO_PASS } https://${ ILO_IP } /redfish/v1/Systems/1 | jq '.PowerState' スイッチがオンになっている場合、出力は "On" を返します。
回避策:
問題のあるサーバーから image ブロックを削除し、サーバーが使用可能な状態に戻るまで待ちます。利用可能になったら、image ブロックを元に戻します。
物理サーバー
1.12.2
症状:
次のようなデバッグ メッセージが表示されることがあります。
[ DEBUG] GET https://172.22.240.103/redfish/v1/
2024 /03/22 21 :46:46 [ DEBUG] GET https://172.22.240.111/redfish/v1/Systems/1/
panic: runtime error: invalid memory address or nil pointer dereferenceこの問題は、iLO エラーが無視され、HTTP レスポンスがすぐに返されずに読み取られることで、nil ポインタの逆参照が発生した場合に発生します。
システム アーティファクト レジストリ
1.12.1
症状:
1.11.1 から 1.12.1 にアップグレードすると、Harbor クラスタのステータスが unhealthy になり、次のエラーが発生することがあります。
root@abc-bootstrapper:/home/ubuntu# ka get harborclusters -A
NAMESPACE NAME PUBLIC URL STATUS
harbor-system harbor https://10.252.119.11:10443 unhealthy 診断の手順:
harborclusters のステータスを確認します。
root@abc-bootstrapper:/home/ubuntu# ka get harborclusters -A
NAMESPACE NAME PUBLIC URL STATUS
harbor-system harbor https://10.252.119.11:10443 unhealthy 異常な場合は、Harbor コンポーネントのステータスを確認します。
root@abc-bootstrapper:~# ka get pods -n harbor-system
NAME READY STATUS RESTARTS AGE
harbor-harbor-harbor-core-68d9764d8c-rgg4h 0 /1 Running 0 3d2h
harbor-harbor-harbor-exporter-54d559fdb8-nzjk7 1 /1 Running 0 3d2h
harbor-harbor-harbor-jobservice-6f5db4779-sqmlc 1 /1 Running 0 3d2h
harbor-harbor-harbor-portal-8458c847dc-z2l6n 1 /1 Running 0 3d4h
harbor-harbor-harbor-registry-7577f5d9d6-qp45c 3 /3 Running 0 3d4h
harbor-operator-harbor-operator-755b5cfc96-x2bxh 1 /1 Running 0 3d4h
harbor-operator-redisoperator-bf96ffc59-5d457 1 /1 Running 0 3d4h
harbor-operator-redisoperator-bf96ffc59-tbd8j 1 /1 Running 0 3h38m
harbor-operator-redisoperator-bf96ffc59-vlqfl 1 /1 Running 0 3h38m
pg-harbor-db-0 0 /3 Pending 0 3h37m
pg-harbor-db-monitor-776b946c74-c7pt9 0 /1 Pending 0 3h38m
rfr-harbor-redis-0 1 /1 Running 0 3d4h
rfr-harbor-redis-1 1 /1 Running 0 3d4h
rfr-harbor-redis-2 1 /1 Running 0 3h37m
rfs-harbor-redis-64d9d8df4f-fds79 1 /1 Running 0 3d4h
rfs-harbor-redis-64d9d8df4f-p9l9h 1 /1 Running 0 3d3h
rfs-harbor-redis-64d9d8df4f-x5x8c 1 /1 Running 0 3h38m harbor-core と pg-harbor-db の準備ができていない場合は、harbor-db のステータスを確認します。
root@abc-bootstrapper:~# ka get dbclusters.postgresql.dbadmin.gdc.goog harbor-db -n harbor-system
NAME PRIMARYENDPOINT PRIMARYPHASE DBCLUSTERPHASE
harbor-db 172 .20.0.146 InProgress DBClusterReconciling harbor-db が InProgress モードの場合、root-admin-control-plane ノードが UNDERMAINTENANCE モードかどうかを確認します。
root@abc-bootstrapper:~# ka get nodepool -A
NAMESPACE NAME READY RECONCILING STALLED UNDERMAINTENANCE UNKNOWN
org-1 admin-control-plane-node-pool 0 0 0 0 0
root root-admin-control-plane 3 0 0 1 0 アップグレード中はノードがメンテナンス モードになることが想定されます。1 つのノードがメンテナンス中の場合、harbor-db をスケジュールするのに十分なリソースがない可能性があります。
回避策:
この問題を解決するには、次の手順を行います。
KUBECONFIG を設定する
:
export KUBECONFIG = /root/release/root-admin/root-admin-kubeconfigdbs コントローラをスケールダウンします。
kubectl scale --replicas= 0 deployment -n dbs-fleet-system fleet-controller-manager
kubectl scale --replicas= 0 deployment -n dbs-postgres-system pg-controller-manager Pod テンプレートで優先度クラス名を system-cluster-critical または system-node-critical に設定します。
kubectl patch statefulset pg-harbor-db -n harbor-system --type= 'json' \
-p= '[{"op": "add", "path": "/spec/template/spec/priorityClassName", "value": "system-cluster-critical"}]' pg-harbor-db Pod を再起動します。
kubectl delete pods -n harbor-system pg-harbor-db-0 harborcluster が正常であることを確認したら、dbs コントローラをスケールアップします。
kubectl scale --replicas= 1 deployment -n dbs-fleet-system fleet-controller-manager
kubectl scale --replicas= 1 deployment -n dbs-postgres-system pg-controller-manager
システム アーティファクト レジストリ
1.12.2
症状:
ジョブ サービス Pod の準備が整わない。
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning Unhealthy 35m ( x8153 over 3d16h) kubelet Readiness probe failed: Get "https://172.16.1.142:8443/api/v1/stats" : net/http: request canceled while waiting for connection ( Client.Timeout exceeded while awaiting headers)
Warning Unhealthy 10m ( x60 over 13h) kubelet Readiness probe failed: Get "https://172.16.1.142:8443/api/v1/stats" : context deadline exceeded
Normal Pulled 5m47s ( x1733 over 3d16h) kubelet Container image "gcr.io/private-cloud-staging/goharbor/harbor-jobservice:v2.8.4-gke.7" already present on machine
Warning BackOff 43s ( x21352 over 3d16h) kubelet Back-off restarting failed container jobservice in pod harbor-harbor-harbor-jobservice-6f59fbf974-q9h9g_harbor-system( 51ab9697-98b9-4315-9ab9-f67b19a28d0a) 回避策:
ジョブサービス Pod を再起動します。
kubectl delete pod POD_NAME -n NAMESPACE 出力は次のようになります。
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 2m20s default-scheduler Successfully assigned harbor-system/harbor-harbor-harbor-jobservice-6f59fbf974-p872s to zx-ab-bm02
Normal Pulling 2m15s kubelet Pulling image "gcr.io/private-cloud-staging/goharbor/harbor-jobservice:v2.8.4-gke.7"
Normal Pulled 2m12s kubelet Successfully pulled image "gcr.io/private-cloud-staging/goharbor/harbor-jobservice:v2.8.4-gke.7" in 3 .25s ( 3 .25s including waiting)
Normal Created 2m12s kubelet Created container jobservice
Normal Started 2m12s kubelet Started container jobservice
ブートストラップで、組織のステータスを取得します。
kubectl get org -A 出力は次のようになります。
NAMESPACE NAME CURRENT VERSION DESIRED VERSION READY
gpc-system org-1 1 .12.1-gdch.402 1 .12.1-gdch.402 True
gpc-system org-2 1 .12.1-gdch.402 1 .12.1-gdch.402 True
gpc-system root 1 .12.1-gdch.402 1 .12.1-gdch.402 True
モニタリング
1.12.1
症状:
1.11.1 から 1.12.1 にアップグレードすると、Cortex バケットの削除が次のエラーで失敗することがあります。
upgrade_post_root_org_validation.go:74: unable to create cortex client to check metrics creating Cortex client failed: can' t make a metrics API because of an error getting the Cortex pod: unable to find any matching cortex pods using list options / label selector: { TypeMeta:{ Kind: APIVersion:} LabelSelector:app= cortex FieldSelector: Watch:false AllowWatchBookmarks:false ResourceVersion: ResourceVersionMatch: TimeoutSeconds: Limit:0 Continue: SendInitialEvents:}
upgrade_post_root_org_validation.go:117: Bucket( s) not ready: 3 errors occurred:
* Bucket "obs-system/cortex-metrics-alertmanager" not ready
* Bucket "obs-system/cortex-metrics-blocks" not ready
* Bucket "obs-system/cortex-metrics-ruler" not ready回避策:
次の手順に沿って、bucket を強制的に削除します。
MON-R0017 toil タスクの手順を完了して、StorageGRID UI にアクセスします。
UI で bucket に移動します。
[バケット内のオブジェクトを削除 ] ボタンをクリックして、データを削除します。
モニタリング
1.12.0
症状:
Prometheus StatefulSet オブジェクトが、standard-rwo ではなく standard ストレージ クラスで誤って構成されています。この問題により、モニタリング コンポーネントからの Anthos Prometheus StatefulSet オブジェクトの起動が失敗します。
この問題は、ObservabilityPipeline Reconciler がこの値を最初のインストール時にのみ設定し、ObsProjectInfra Reconciler がクラスタ カスタム リソースを監視することが原因で発生します。
回避策:
組織の管理クラスタで fleet-admin-controller Deployment を再起動して、問題を解決します。
モニタリング
1.12.2
症状:
mon-common サブコンポーネントは、Cortex のすべてのリクエストの監査ロギングを防ぐため、組織管理者クラスタに Istio Telemetry オブジェクトをデプロイする必要があります。ただし、マニフェスト ファイルはビルドファイルに含まれていません。
回避策:
次の手順に沿って、組織管理クラスタに Istio Telemetry オブジェクトをデプロイします。
組織の管理クラスタの mon-system Namespace で Istio Telemetry カスタム リソース（CR）を定義する YAML ファイルを作成します。
# Disable access logging from workloads internal to GDCH.
# Telemetry CR to disable Istio access logs from obs-system namespace.
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
name: disable-audit-logging
namespace: mon-system
spec:
accessLogging:
- providers:
- name: otel
disabled: true マニフェスト ファイルを mon-system Namespace の組織管理クラスタに適用します。
kubectl apply -f disable-audit-logging.yaml
モニタリング
1.12.0
症状:
アラート MON-A0001 がトリガーされます。
mon-prober-backend-prometheus-config ConfigMap がリセットされ、プローブジョブが含まれなくなります。次に例を示します。
apiVersion: v1
data:
prometheus.yaml: |
remote_write:
- url: http://cortex-tenant.mon-system.svc:9009/push
name: cortex-tenant
kind: ConfigMap
metadata:
creationTimestamp: "2024-06-26T14:55:07Z"
name: mon-prober-backend-prometheus-config
namespace: mon-system
resourceVersion: "6606787"
uid: 1a495af0-1fdc-40b8-845b-4976e3b0f899
回避策:
問題を解決するには、以下の手順を行ってください。
次の環境変数を設定します。
KUBECONFIG: クラスタ内の kubeconfig ファイルのパス。TARGET_CLUSTER: 問題を解決するクラスタの名前。
すべてのクラスタで mon-prober サブコンポーネントを一時停止します。
kubectl --kubeconfig $KUBECONFIG annotate subcomponent mon-prober -n $TARGET_CLUSTER lcm.private.gdc.goog/paused= true
次に例を示します。
kubectl --kubeconfig ~/root-admin-kubeconfig annotate subcomponent mon-prober -n my-org lcm.private.gdc.goog/paused= true
各管理クラスタで MON 管理コントローラを再起動します。
kubectl --kubeconfig $KUBECONFIG rollout restart deploy -n obs-system mon-admin-backend-controller
Prober ConfigMap は、各プローブが登録されるたびに設定されます。
このアラートは継続的に発生するため、ランブック MON-R2009 に沿って MON-A0001 アラート Blackbox monitoring metrics pipeline down をミュートします。
ノード プラットフォーム
1.12.1
症状:
1.11.x から 1.12.x にアップグレードすると、スイッチ イメージ ダウンロード Pod が ErrImagePull 状態のまま停止し、次の警告が表示されることがあります。
Warning Failed 145m ( x4 over 169m) kubelet Failed to pull image "gcr.io/private-cloud-staging/switch-image-downloader:1.12.1-gdch.330" : failed to pull and unpack image "gcr.io/private-cloud-staging/switch-image-downloader:1.12.1-gdch.330" : failed to resolve reference "gcr.io/private-cloud-staging/switch-image-downloader:1.12.1-gdch.330" : failed to do request: Head "https://10.252.119.4:5000/v2/library/private-cloud-staging/switch-image-downloader/manifests/1.12.1-gdch.330?ns=gcr.io" : dial tcp 10 .252.119.4:5000: connect: no route to host
Warning Failed 45m ( x262 over 25h) kubelet Failed to pull image "gcr.io/private-cloud-staging/switch-image-downloader:1.12.1-gdch.330" : failed to pull and unpack image "gcr.io/private-cloud-staging/switch-image-downloader:1.12.1-gdch.330" : failed to resolve reference "gcr.io/private-cloud-staging/switch-image-downloader:1.12.1-gdch.330" : pulling from host 10 .252.119.11:10443 failed with status code [ manifests 1 .12.1-gdch.330] : 401 Unauthorized
Normal Pulling 40m ( x287 over 26h) kubelet Pulling image "gcr.io/private-cloud-staging/switch-image-downloader:1.12.1-gdch.330"
Normal BackOff 22s ( x6504 over 25h) kubelet Back-off pulling image "gcr.io/private-cloud-staging/switch-image-downloader:1.12.1-gdch.330" 回避策:
この問題を解決するには、イメージ pnet-core-switch-image-downloader に switch-image-downloader のタグを付け直します。
ノード プラットフォーム
1.12.1
症状:
1.11.x から 1.12.1 にアップグレードすると、ホスト ファイアウォールで使用されるインターフェースの不一致により、ホスト ファイアウォールがスイッチ イメージのダウンロードをブロックします。
回避策:
1.11.x から 1.12.x にアップグレードする場合にのみ、アップグレード前に次の回避策を適用します。
ルート管理者クラスタと組織管理者クラスタを更新します。
ルート管理者ベアメタル ノードと組織管理者ベアメタル ノードのノードプール名と Namespace を取得します。ルート管理者クラスタの場合は、ルート管理者 kubeconfig を使用します。次のコマンドは、マシンのインベントリを一覧表示し、ベアメタル マシンでリストをフィルタします。
kubectl --kubeconfig= KUBECONFIG get inventorymachines -l cluster.private.gdc.goog/provisioner= baremetal-provisioner.cluster.private.gdc.goog -o json | jq -c -r '.items[].spec.nodePoolRef | [.name, .namespace] | @csv | sub("\"";"";"g")' | sort | uniq
admin-control-plane-node-pool,org-1
root-admin-control-plane,root 出力の値は次のとおりです。
ORG_ADMIN_NODEPOOL_NAME: admin-control-plane-node-poolORG_ADMIN_NODEPOOL_NAMESPACE: org-1ROOT_ADMIN_NODEPOOL_NAME: root-admin-control-planeROOT_ADMIN_NODEPOOL_NAMESPACE: root
ルート管理者クラスタと組織管理者クラスタに次のオブジェクトを作成して、ノードの eth0 の名前を mgmt0 に変更します。
apiVersion: system.private.gdc.goog/v1alpha1
kind: AnsiblePlaybook
metadata:
name: eth0-to-mgmt0-int-rename
namespace: gpc-system
spec:
playbook: |
- name: Rename interface from eth0 to mgmt0
hosts: all
gather_facts: no
tasks:
- name: Rename interface in netplan file
ansible.builtin.lineinfile:
path: /etc/netplan/50-cloud-init.yaml
regexp: '^(.*)set-name: eth0(.*)$'
line: '\1set-name: mgmt0\2'
backrefs: true
register: netplan
- name: Disable cloud-init network configuration
ansible.builtin.lineinfile:
path: /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg
line: 'network: {config: disabled}'
state: present
create: true
- name: Restart netplan
command: netplan apply
when: netplan.changed
---
apiVersion: system.private.gdc.goog/v1alpha1
kind: OSPolicy
metadata:
name: interface-renaming
namespace: gpc-system
labels:
ospolicy.system.private.gdc.goog/override-maintenance: "true"
spec:
interval:
period: 1m
inventory:
- apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
name: ${ ORG_ADMIN_NODEPOOL_NAME }
namespace: ${ ORG_ADMIN_NODEPOOL_NAMESPACE }
- apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
name: ${ ROOT_ADMIN_NODEPOOL_NAME }
namespace: ${ ROOT_ADMIN_NODEPOOL_NAMESPACE }
policy:
installPlaybook:
name: eth0-to-mgmt0-int-rename
上記の YAML ファイルがデプロイされると、NODEPOOL_NAME フィールドと NODEPOOL_NAMESPACE フィールドに、それぞれのクラスタ内のすべてのノードプールのリストが入力されます。
実際のルート管理ノードプールと組織管理ノードプールの名前を含むルート管理クラスタの YAML ファイルの例は次のようになります。
apiVersion: system.private.gdc.goog/v1alpha1
kind: AnsiblePlaybook
metadata:
name: eth0-to-mgmt0-int-rename
namespace: gpc-system
spec:
playbook: |
- name: Rename interface from eth0 to mgmt0
hosts: all
gather_facts: no
tasks:
- name: Rename interface in netplan file
ansible.builtin.lineinfile:
path: /etc/netplan/50-cloud-init.yaml
regexp: '^(.*)set-name: eth0(.*)$'
line: '\1set-name: mgmt0\2'
backrefs: true
register: netplan
- name: Disable cloud-init network configuration
ansible.builtin.lineinfile:
path: /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg
line: 'network: {config: disabled}'
state: present
create: true
- name: Restart netplan
command: netplan apply
when: netplan.changed
---
apiVersion: system.private.gdc.goog/v1alpha1
kind: OSPolicy
metadata:
name: interface-renaming
namespace: gpc-system
labels:
ospolicy.system.private.gdc.goog/override-maintenance: "true"
spec:
interval:
period: 1m
inventory:
- apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
name: admin-control-plane-node-pool
namespace: org-1
- apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
name: root-admin-control-plane
namespace: root
policy:
installPlaybook:
name: eth0-to-mgmt0-int-rename YAML ファイルをルート管理クラスタに適用します。
kubectl --kubeconfig= ROOT_ADMIN_KUBECONFIG -f YAML_FILE_NAME
システム クラスタを更新します。
マシンのインベントリを取得し、ベアメタル マシンでリストをフィルタします。
kubectl --kubeconfig= _ORG_ADMIN_KUBECONFIG get inventorymachines -l cluster.private.gdc.goog/provisioner= baremetal-provisioner.cluster.private.gdc.goog -o json | jq -c -r '.items[].spec.nodePoolRef | [.name, .namespace] | @csv | sub("\"";"";"g")' | sort | uniq
worker-node-pool-o1-highgpu1-48-gdc-metal,org-1-system-cluster 出力の値は次のとおりです。
SYSTEM_CLUSTER_NODEPOOL_NAME: worker-node-pool-o1-highgpu1-48-gdc-metalSYSTEM_CLUSTER_NODEPOOL_NAMESPACE: org-1-system-cluster
NODEPOOL_NAME フィールドと NODEPOOL_NAMESPACE フィールドには、前のコマンドの出力リストから値が入力されます。
システム クラスタに次のオブジェクトを作成して、ノードの eth0 を mgmt0 に変更し、OS ポリシーを更新します。
apiVersion: system.private.gdc.goog/v1alpha1
kind: AnsiblePlaybook
metadata:
name: eth0-to-mgmt0-int-rename
namespace: gpc-system
spec:
playbook: |
- name: Rename interface from eth0 to mgmt0
hosts: all
gather_facts: no
tasks:
- name: Rename interface in netplan file
ansible.builtin.lineinfile:
path: /etc/netplan/50-cloud-init.yaml
regexp: '^(.*)set-name: eth0(.*)$'
line: '\1set-name: mgmt0\2'
backrefs: true
register: netplan
- name: Disable cloud-init network configuration
ansible.builtin.lineinfile:
path: /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg
line: 'network: {config: disabled}'
state: present
create: true
- name: Restart netplan
command: netplan apply
when: netplan.changed
---
apiVersion: system.private.gdc.goog/v1alpha1
kind: OSPolicy
metadata:
name: interface-renaming
namespace: gpc-system
labels:
ospolicy.system.private.gdc.goog/override-maintenance: "true"
spec:
interval:
period: 1m
inventory:
- apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
name: ${ SYSTEM_CLUSTER_NODEPOOL_NAME }
namespace: ${ SYSTEM_CLUSTER_NODEPOOL_NAMESPACE }
policy:
installPlaybook:
name: eth0-to-mgmt0-int-rename 実際のノードプール名を含むシステム クラスタの yaml ファイルの例は次のようになります。
apiVersion: system.private.gdc.goog/v1alpha1
kind: AnsiblePlaybook
metadata:
name: eth0-to-mgmt0-int-rename
namespace: gpc-system
spec:
playbook: |
- name: Rename interface from eth0 to mgmt0
hosts: all
gather_facts: no
tasks:
- name: Rename interface in netplan file
ansible.builtin.lineinfile:
path: /etc/netplan/50-cloud-init.yaml
regexp: '^(.*)set-name: eth0(.*)$'
line: '\1set-name: mgmt0\2'
backrefs: true
register: netplan
- name: Disable cloud-init network configuration
ansible.builtin.lineinfile:
path: /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg
line: 'network: {config: disabled}'
state: present
create: true
- name: Restart netplan
command: netplan apply
when: netplan.changed
---
apiVersion: system.private.gdc.goog/v1alpha1
kind: OSPolicy
metadata:
name: interface-renaming
namespace: gpc-system
labels:
ospolicy.system.private.gdc.goog/override-maintenance: "true"
spec:
interval:
period: 1m
inventory:
- apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
name: worker-node-pool-o1-highgpu1-48-gdc-metal
namespace: org-1-system-cluster
policy:
installPlaybook:
name: eth0-to-mgmt0-int-rename
YAML ファイルを組織管理クラスタに適用します。
kubectl --kubeconfig= ORG_ADMIN_KUBECONFIG -f YAML_FILE_NAME
下位ネットワーキング
1.12.2
症状:
スイッチの想定バージョンが 10.3(4a) であるため、9.3.10 より前のバージョンがプリロードされたネットワーク スイッチはブートストラップに失敗します。
回避策:
スイッチのファームウェアを 9.3.5 から 9.3.10 に、次に 9.3.10 から 10.3.4a に手動でアップグレードします。
下位ネットワーキング
1.12.2
症状:
スイッチの証明書の有効期限が切れているため、スイッチに最新の構成がなく、スイッチで接続が切断されます。
回避策:
スイッチの証明書をローテーションします。
新しい証明書を有効にします。
nxapi certificate httpskey keyfile bootflash:api-private-key.pem
nxapi certificate httpscrt certfile bootflash:api-certificate.pem
nxapi certificate enable
ファイル ストレージとブロック ストレージ
1.12.1
症状:
Linux Unified Key Setup（LUKS）サブコンポーネントは、アップグレード中に再デプロイされません。file-netapp-trident サブコンポーネントを確認するには:
エイリアスを設定します。
alias ka = 'kubectl --kubeconfig=/path/to/root-admin/root-admin-kubeconfig'
alias ko = 'kubectl --kubeconfig=/path/to/org-admin/org-admin-kubeconfig'
サブコンポーネントを取得します。
ka get subcomponent -n root file-netapp-trident -o yaml
ko get subcomponent -n root file-netapp-trident -o yaml
出力は次のようになります。
conditions:
- lastTransitionTime: "2024-03-28T01:37:20Z"
message: 'Reconciliation error: E0100 - deploy: failed to install chart: release
file-netapp-trident-backend failed, and has been uninstalled due to atomic being
set: cannot patch "standard-rwo" with kind StorageClass: StorageClass.storage.k8s.io
"standard-rwo" is invalid: parameters: Forbidden: updates to parameters are
forbidden. && cannot patch "standard-block" with kind StorageClass: StorageClass.storage.k8s.io
"standard-block" is invalid: parameters: Forbidden: updates to parameters are
forbidden.'
observedGeneration: 1
reason: ReconciliationError
status: "True"
type: Reconciling この例では、standard-rwo と standard-block の 2 つのストレージ クラスが失敗しています。
回避策:
ジョブの作成に失敗した StorageClasses（standard-rwo、standard-block、standard-rwo-non-luks、standard-block-non-luks など）を削除します。
クラスタの oclcm-backend-controller（ルート クラスタと組織クラスタのルート管理者コントローラ、システム クラスタとユーザー クラスタの組織管理者コントローラ）を再起動して、StorageClasses の再作成をトリガーします。
バージョン 1.12.4 の場合、インストールされているストレージ クラスの disk.gdc.goog/luks-encrypted: アノテーションが true に設定されていることを確認します（非 luks ストレージ クラスを除く）。アノテーションが true に設定されていない場合は、手順 1 と 2 を繰り返します。 クラスタ内の netapp-trident Deployment と netapp-trident DaemonSet を再起動します。
PersistentVolumeClaim（PVC）リソースに対して LUKS シークレットが作成されたことを確認します。すべての PVC には、g-luks-$pvc_name 形式のシークレットが必要です。file-netapp-trident サブコンポーネントのステータスにエラーがないことを確認します。
オブジェクト ストレージ
1.12.2
症状:
ルート組織を 1.12.1 から 1.12.x にアップグレードすると、アップグレード後の検証が次のエラーで失敗します。
upgrade_post_root_org_validation.go:121: Bucket( s) not ready: 8 errors occurred:
* Bucket "atat-system/invoice-export-bucket" not ready
* Bucket "mon-system/cortex-metrics-alertmanager" not ready
* Bucket "mon-system/cortex-metrics-blocks" not ready
* Bucket "mon-system/cortex-metrics-ruler" not ready
* Bucket "obs-system/audit-logs-loki-io" not ready
* Bucket "obs-system/cortex-metrics-alertmanager" not ready
* Bucket "obs-system/cortex-metrics-blocks" not ready
* Bucket "obs-system/cortex-metrics-ruler" not ready
回避策:
アップグレードを開始する前に、ファイナライザーを手動で追加します。
クラスタ管理
1.12.1、1.12.2
症状:
Kubernetes バージョン 1.27.x で実行されているユーザー クラスタ内のノードプールが初期化されないため、ユーザー クラスタがコンテナ ワークロードを処理できないことがあります。
回避策:
Kubernetes バージョン 1.27.x を使用してユーザー クラスタを作成しないでください。
仮想マシン
1.12.0
症状:
Ubuntu ソースイメージに sources.list のデフォルトの APT ソースが含まれている場合、VM イメージのインポートはイメージ変換ステップで失敗します。
回避策:
ソースイメージの /var/lib/apt/lists/ ディレクトリが空であることを確認します。
仮想マシン
1.12.2
症状:
インポーター Pod のリストを取得します。
kubectl get pods -A | grep import 出力は次のようになります。
user-vm-1-cluster importer-vm-1b19e25c-disk-8dwzz 0 /1 ContainerCreating 0 2d9h
user-vm-1-cluster importer-vm-72b96d39-disk-frv4f 0 /1 CreateContainerError 124 ( 43h ago) 2d9h
user-vm-1-cluster importer-vm-c7a7a320-disk-qjgt2 0 /1 CreateContainerError 124 ( 43h ago) 2d9h
user-vm-2-cluster importer-vm-06ca7e94-disk-b66fz 0 /1 CreateContainerError 124 ( 43h ago) 2d9h
user-vm-2-cluster importer-vm-7e63b71b-disk-jxqfz 0 /1 CreateContainerError 116 ( 43h ago) 2d9h
user-vm-2-cluster importer-vm-e0651556-disk-k8scf 0 /1 CreateContainerError 123 ( 43h ago) 2d9h ログには次のようなイベントが表示されることがあります。
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedAttachVolume 2m14s ( x1630 over 2d9h) attachdetach-controller AttachVolume.Attach failed for volume "pvc-2000efe0-b4a0-4856-899b-7e0c9fd33405" : rpc error: code = Unknown desc = error publishing ontap-san driver: problem mapping LUN /vol/trident_pvc_2000efe0_b4a0_4856_899b_7e0c9fd33405/lun0: results: { http://www.netapp.com/filer/admin results}
status,attr: failed
reason,attr: No such LUN exists
errno,attr: 9017
lun-id-assigned: nil 回避策:
エラー メッセージ（pvc-2000efe0-b4a0-4856-899b-7e0c9fd33405 など）から PersistentVolumeClaim（PVC）の名前を取得します。
この名前で PersistentVolume（PV）を検索し、後で使用する spec.csi.volumeAttributes.internalName をメモします。
FILE-A0006 ランブックの手順に沿って、ストレージ クラスタへの SSH 接続を確立します。ボリュームを表示し、コマンドが返す vserver 名をメモします。
volume show -volume INTERNAL_NAME
ボリュームをオフラインにする:
volume offline -volume INTERNAL_NAME -vserver VSERVER_NAME
ボリュームを削除します。
volume delete -volume INTERNAL_NAME -vserver VSERVER_NAME
仮想マシン
1.12.1
症状:
ターゲット クラスタ（管理クラスタまたはシステム クラスタ）の VMRuntime の status.ready = false で、kube-system Namespace の network-controller-manager が保留中である
kubectl --kubeconfig= ${ TARGET_CLUSTER_KUBECONFIG } get vmruntime vmruntime
apiVersion: virtualmachine.private.gdc.goog/v1
kind: VMRuntime
metadata:
...
spec:
...
status:
ready: false
kubectl --kubeconfig= ${ TARGET_CLUSTER_KUBECONFIG } describe deploy network-controller-manager -n kube-system
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedMount 3m36s ( x122 over 3h55m) kubelet MountVolume.SetUp failed for volume "cert" : secret "network-webhook-server-cert" not found
回避策:
デプロイ network-controller-manager を削除すると、VMM オペレータによって必要な証明書を使用してデプロイが自動的に再作成されます。デプロイが Running 状態になり、その後 VMRuntime のステータスが ready=true に変わります。
kubectl --kubeconfig= ${ TARGET_CLUSTER_KUBECONFIG } delete deploy network-controller-manager -n kube-system
仮想マシン
1.12.2
症状:
VM インポーター Pod がクラッシュ ループし、データ ボリュームが 90 分以上インポート ステータスのままになります。Pod のステータスは次のようになります。
test-vm-project importer-disk-ops-test-vm-boot-disk-tbdtz 0 /1 CrashLoopBackOff 14 ( 47s ago) 90m 172 .16.20.94 zb-aa-bm08 <none> <none>
test-vm-project importer-test-vm-1-boot-disk-plsxk 1 /1 Running 1 ( 2m53s ago) 8m59s 172 .16.22.244 zb-ab-bm09 <none> <none>
test-vm-project importer-test-vm-2-boot-disk-npjc8 1 /1 Running 6 ( 12m ago) 40m 172 .16.22.180 zb-ab-bm09 <none> <none> すべてのディスク インポートは、最終的に 3 時間以内に完了します。
アップグレード
1.12.2
症状:
次のようなエラー メッセージが表示されます。
message: 'Reconciliation error: E0111 - upgrade chart: release unet-nodenetworkpolicy-infra-assets
failed, and has been rolled back due to atomic being set: cannot patch "mgmt-network"
with kind Network: admission webhook "vnetwork.networking.gke.io" denied the
request: Network.networking.gke.io "mgmt-network" is invalid: Spec.NodeInterfaceMatcher:
Forbidden: Field is immutable'
observedGeneration: 2
回避策:
障害がルートで発生した場合は、次の手順で KUBECONFIG をルート管理 kubeconfig に置き換えます。
失敗が組織で発生した場合は、次の手順で KUBECONFIG を組織管理者の kubeconfig に置き換えます。
次のコマンドを実行します。
alias k = "kubectl --kubeconfig=KUBECONFIG "
k get networks mgmt-network -o json | jq '.spec.nodeInterfaceMatcher.interfaceName'
出力が eth0 の場合は、次のコマンドを実行します。
k patch network mgmt-network -p '{"metadata":{"finalizers":null}}' --type= merge
mgmt-network を削除します。
k delete network mgmt-network unet-nodenetworkpolicy-infra のステータスにエラーがないことを確認します。次に例を示します。
alias k = "kubectl kubeconfig=KUBECONFIG "
k get subcomponent unet-nodenetworkpolicy-infra -n org-1
出力は次のようになります。
NAME AGE STATUS
unet-nodenetworkpolicy-infra 34d ReconciliationCompleted
アップグレード
1.12.2
症状:
1.11.x から 1.12.2 へのアップグレード中またはアップグレード後に、bm-system-add-ons-* という名前のジョブが次のエラーで失敗することがあります。
E0326 17 :04:22.997270 1 main.go:180] configdrift: Config drift health check failed
F0326 17 :04:22.997365 1 main.go:184] One or more checks failed.回避策:
1.11 から 1.12.2 へのアップグレードを開始する前に、次のアノテーションをすべての Kubernetes クラスタに適用します。
# To bypass preflight check errors:
baremetal.cluster.gke.io/bypass-check= "vip_subnet"
たとえば、ルート管理クラスタでは次のようにします。
kubectl annotate -n root cluster root-admin baremetal.cluster.gke.io/bypass-check= "vip_subnet" --kubeconfig= ROOT_ADMIN_KUBECONFIG
アップグレード
1.12.2
症状:
この問題は、1.11.1 から 1.12.2 にアップグレードするときに発生します。
file-observability サブコンポーネントの .yaml ファイルを確認します。
kubectl get subcomponent file-observability -n org-1-system-cluster -o yaml このファイルの backendStatus セクションに次のメッセージが表示されることがあります。
message: 'E0100 - deploy: failed to install chart: release file-observability-backend
failed, and has been uninstalled due to atomic being set: deployments.apps
"file-observability-backend-controller" not found' 回避策:
file-system Namespace を確認して、org-admin cluster で終了していないことを確認します。
kubectl --kubeconfig ORG_ADMIN_KUBECONFIG get namespace file-system 終了処理中の場合は、file-system Namespace のモニタリング ターゲットを削除します。
kubectl --kubeconfig ORG_ADMIN_KUBECONFIG delete monitoringtarget -n file-system --all
次のアノテーションをサブコンポーネントに追加して、mon-admin サブが起動するまで file-observability サブコンポーネントを一時停止します。
kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG annotate -n org-1 subcomponent file-observability lcm.private.gdc.goog/paused= 'true'
kubectl --kubeconfig ORG_ADMIN_KUBECONFIG annotate -n org-1-system-cluster subcomponent file-observability lcm.private.gdc.goog/paused= 'true'
アップグレードの完了後にサブコンポーネントを一時停止するには、アノテーションを削除します。
kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG annotate -n org-1 subcomponent file-observability lcm.private.gdc.goog/paused-
kubectl --kubeconfig ORG_ADMIN_KUBECONFIG annotate -n org-1-system-cluster subcomponent file-observability lcm.private.gdc.goog/paused-
アップグレード
1.12.2
症状:
この問題は、1.11.1 から 1.12.2 にアップグレードするときに発生します。
hsmupgraderequest と ctmclusterupgraderequest のアップグレード手順がすべて完了すると、次のエラーが表示されます。
HSMCluster "hsmcluster" is not ready. 次に例を示します。
- lastTransitionTime: "2024-04-08T15:18:45Z" message: HSMCluster "hsmcluster" is not ready observedGeneration:
2 reason: ziabhsm01PostUpgradeCheckFailed status: "False" type: AllComplete回避策:
HSM でアップグレードが完了したことを確認し、各 HSM の IP アドレスを取得します。
kubectl get hsm -A --kubeconfig= ROOT_ADMIN_KUBECONFIG 出力は次のようになります。
NAMESPACE NAME AGE IP READY REASON
gpc-system zi-aa-hsm01 11d 10 .252.96.192 True ReconcileHSMSuccess
gpc-system zi-ab-hsm01 11d 10 .252.97.192 True ReconcileHSMSuccess
gpc-system zi-ac-hsm01 11d 10 .252.98.192 True ReconcileHSMSuccess
ksctl をダウンロードして構成します。ksctl system info get --url=https://HSM_MANAGEMENT_IP を実行して、HSM のすべてのバージョンが ctmclusterupgraderequest の .Spec.TargetVersion にアップグレードされていることを確認します。出力は次のようになります。
ksctl system info get
{
"name" : "zi-aa-hsm01" ,
"version" : "2.13.1+10196" ,
"model" : "CipherTrust Manager k570" ,
"vendor" : "Thales Group" ,
"crypto_version" : "1.7.0" ,
"uptime" : "0 days, 1 hours, 20 minutes" ,
"system_time" : "2024-04-08T19:51:27Z"
}
前の手順で取得したアップグレード バージョンに、各 HSM の Status.FirmwareVersion フィールドを更新します。次に例を示します。
kubectl edit-status hsm HSM_NAME -n gpc-system
ctmclusterupgraderequest.status.conditions の最後の条件ステータスを False から True に更新します。その後、hsmupgraderequest.status.conditions の最後の条件ステータスも true になります。次に例を示します。
kubectl edit-status ctmclusterupgraderequest CTM_VERSION -n gpc-system
kubectl get ctmclusterupgraderequest CTM_VERSION -n gpc-system -o yaml
アップグレード
1.12.2
アップグレード 中、特にスイッチ OS のアップグレード後に、サーバーの管理 IP にアクセスできなくなります。
Rocky Linux では、静的ルートを追加する前に、静的ルートに到達するために使用される宛先 IP に到達できる必要があります。OS のアップグレード後にスイッチが再起動している場合、その管理 IP に一時的にアクセスできなくなる可能性があります。
回避策:
データ IP アドレスを使用してサーバーへの SSH 接続を確立し、ネットワーク サービスを再起動して、欠落している静的ルートを再作成します。
systemctl restart NetworkManager.service
チケット発行システム
1.12.2
症状:
ナレッジベースの同期 中に、次のエラーが表示されることがあります。
Error: Article creation request failed status:400, body:map[ error:map[ detail:Rejected large REST payload with content-length = 10725676 bytes. Max allowed: 10485760 bytes. 回避策:
システム プロパティを追加して最大長を増やします。
ServiceNow プラットフォームで、ナビゲーション フィルタに「sys_properties.list」と入力します。
[New ] をクリックします。
[名前 ] フィールドに「glide.rest.max_content_length」と入力します。
[型 ] フィールドで string を選択します。
[値 ] に「15」と入力します。
[送信 ] をクリックします。
ナレッジベースを再度同期します。
チケット発行システム
1.12.2
症状:
gdchservices 組織を手動でデプロイすると、チケット発行システムに正常なアップストリームがなく、VM が作成されず、support 名前空間の gdchservices-system クラスタで midserver Pod が異常になります。
回避策:
gdchservices-admin クラスタで正しい VM イメージを使用して、新しい TicketingSystem カスタム リソースを作成します。
apiVersion: ticketing.private.gdc.goog/v1
kind: TicketingSystem
metadata:
name: as-replacement
namespace: support
spec:
replicas: 2
spec:
image: ts-controller-app-server-2024-02-07-231907
imagenamespace: vm-system
memory: 12G
size: 100G
vcpus: 8
version:
name: glide-vancouver-07-06-2023__patch5-12-01-2023_12-11-2023_2006.zip
アップグレード
1.12.2
症状:
管理 IP を持つ VM でログイン アクセスが機能しない。anetd Pod のログに次のようなエラーが表示されることがあります。
Unable to create endpoint:[ PUT /endpoint/{ id}][ 400 ] putEndpointIdInvalid failed setting up layer2 interface
回避策:
VM の virt-launcher Pod を削除します。
アップグレード
1.12.2
症状:
1.11x から 1.12.x へのアップグレード中に、次のようなエラーが表示されることがあります。
kubectl --kubeconfig PATH_TO_ROOT_ADMIN_KUBECONFIG get subcomponent -n root mz-etcd -o yaml
kubectl --kubeconfig PATH_TO_ROOT_ADMIN_KUBECONFIG get subcomponent -n org-1 mz-etcd -o yamlアップグレード前の mz-etcd サブコンポーネントの仕様は次のとおりです。
spec:
crds:
helmManifestSpec:
chartURL: gcr.io/mz-etcd-crds:1.11.1-gdch.260
upgradeHookPolicy: OnVersionChange
deployTarget: Local
namespace: ""
回避策:
ルート管理クラスタで次のサブコンポーネントを削除します。
kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG delete subcomponent -n root mz-etcd
kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG delete subcomponent -n org-1 mz-etcd
ルート Namespace と組織 Namespace の両方でサブコンポーネントを確認します。
kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get subcomponent -n root mz-etcd -o yaml
kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get subcomponent -n org-1 mz-etcd -o yaml
新しいサブコンポーネントには次の仕様があり、chatURL にはクラスタがすでにアップグレードされているバージョンが表示されている必要があります。
backend:
helmManifestSpec:
chartURL: gcr.io/mz-etcd-backend:1.12.2-gdch.785
...
dash:
helmManifestSpec:
chartURL: gcr.io/mz-etcd-dash:1.12.2-gdch.785
...
deployTarget: Remote
namespace: mz-system
mon:
helmManifestSpec:
chartURL: gcr.io/mz-etcd-mon:1.12.2-gdch.785
upgradeHookPolicy: OnVersionChange
...
targetClusterName: root-admin
targetClusterNamespace: root
webhooks:
helmManifestSpec:
chartURL: gcr.io/mz-etcd-webhooks:1.12.2-gdch.785
upgradeHookPolicy: OnVersionChange
アップグレード
1.12.2
症状:
プリフライト チェックまたはポストフライト チェックがエラーで失敗します。ログを確認します。
kubectl logs -n gpc-system upgrade-managed-check-objectstorageupgrade-87698-rrjhrW0410 次のようなエラーが表示されることがあります。
03 :42:05.701163 1 upgrade_check.go:276] 1 error occurred:
* Group "/rbac.sysstd.role.vm-system.wtwf7txfmbhvujhpxrfampnrkdwqsvzro6i7rmo5tsfst4wbxldq" not ready for RBAC resource { Role vm-system g-vm-image-bucket-reader }
Error: check "ObjectStorageUpgrade" preflight check failed: 1 error occurred:
* Bucket "gpc-system/range-read-internal" not ready
F0410 03 :42:05.701901 1 main.go:80] check "ObjectStorageUpgrade" preflight check failed: 1 error occurred:
* Bucket "gpc-system/range-read-internal" not ready
回避策:
エラーが postflight チェック中に発生し、他のすべてのチェックがエラーなしで完了した場合は、postflight チェックをスキップします。アップグレードが再開されたら、ルート管理者 kubeconfig を使用してプリフライト チェックもスキップする必要があります。
kubectl delete organizationupgrade -n gpc-system ORG_NAME && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-postflight-check= ok && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-preflight-check= okたとえば、エラーが org-1 で発生した場合、コマンドは次のようになります。
kubectl delete organizationupgrade -n gpc-system org1 && kubectl annotate -n gpc-system organization org-1 upgrade.private.gdc.goog/skip-postflight-check= ok && kubectl annotate -n gpc-system organization org-1 upgrade.private.gdc.goog/skip-preflight-check= okプリフライト チェック中にエラーが発生し、他のすべてのプリフライト チェックがエラーなく完了した場合は、プリフライト チェックをスキップします。
kubectl delete organizationupgrade -n gpc-system ORG_NAME && kubectl annotate -n gpc-system organization ORG_NAME upgrade.private.gdc.goog/skip-preflight-check= ok
たとえば、エラーが org-1 で発生した場合、コマンドは次のようになります。
kubectl delete organizationupgrade -n gpc-system org-1 && kubectl annotate -n gpc-system organization org-1 upgrade.private.gdc.goog/skip-preflight-check= ok この回避策が適用されない場合は、複数回適用する必要がある場合があります。
ATAT ポートフォリオ
1.12.0
症状:
ConfigSync が次のメッセージでエラーを返す:
KNV2009: failed to apply Portfolio.atat.config.google.com, atat-system/***: failed to create typed patch object ( atat-system/***; atat.config. ││ google.com/v1alpha1, Kind = Portfolio) : .spec.portfolioName: field not declared in schema.
回避策:
GDC バージョン 1.12 では、Portfolio スキーマが変更されました。portfolioName フィールドが portfolioID にリファクタリングされました。エラー メッセージに記載されているポートフォリオ カスタム リソースを含む YAML ファイルを見つけます。フィールド portfolioName の名前を portfolioID に変更します。
アップグレード
1.12.2
症状:
プリフライト ジョブのみが完了したパッチジョブに対して実行中のジョブが作成されない理由として、次のことが考えられます。
NTP が失敗すると、他のすべてのパッチ ジョブが実行されなくなります。
ノードが異常な状態です。
OS Config エージェントが実行されていません。
OS Config エージェントが OS Config サービスと通信できません。
OS Config サービスに問題があります。
回避策:
ノードの `NodeTargetPolicy` CR を確認します。
`ref.name=admin-ntp-policy` と `type: Ready` があり、ステータスが false の `NodeTargetPolicy` CR の `.spec.osPolicies` を検索します。
# Enter the node InventoryMachine name.
NAME =
kubectl get nodetargetpolicy -n gpc-system $NAME -ojsonpath= "{.spec.osPolicies}" | jq
出力は次のようになります。
- conditions:
- lastTransitionTime: "2024-04-19T19:12:01Z"
message: ""
observedGeneration: 7
reason: Complete
status: "True"
type: PolicyPreflightCompleted
- lastTransitionTime: "2024-04-19T19:12:01Z"
message: ""
observedGeneration: 7
reason: None
status: "True"
type: PolicyConflictNone
- lastTransitionTime: "2024-04-19T19:56:35Z"
message: ""
observedGeneration: 7
reason: Reconciled
status: "True"
type: Ready
diff: os-policy-preflight-admin-ntp-policymf2w4-dpbxw
playbookName: server-ntp-config
ref:
name: admin-ntp-policy
namespace: gpc-system
これらの `osPolicies` のすべての条件を削除し、次の部分のみを残します。
- conditions:
diff: os-policy-preflight-admin-ntp-policymf2w4-dpbxw
playbookName: server-ntp-config
ref:
name: admin-ntp-policy
namespace: gpc-system
アップグレード
1.12.3
症状:
アップグレードされるノードが Ubuntu であっても、NodeUpgrade CR の仕様で version: rocky-86-xyz が言及されています。
回避策:
この情報は無害であるため、回避策は必要ありません。ノードが Ubuntu の新しいバージョンに正しくアップグレードされます。
SIEM
1.12.0
症状:
ルート管理クラスタのルートと org-1 名前空間の siem-*-preinstall ジョブが繰り返し失敗します。
回避策:
SIEMComponent 機能ゲートが無効になっている場合、ジョブは失敗することが想定されます。失敗は、コンポーネントが壊れていることを示すものではありません。ノイズが妨げになる場合は、SIEM コンポーネントの調整を一時停止できますが、可能な限りコンポーネントを有効にしておくことをおすすめします。コンポーネントの調整が一時停止されている場合は、今後のアップグレードで SIEM コンポーネントのインストールがゲートされなくなったときに、手動で再度有効にする必要があります。
ノードのアップグレード
1.12.0
症状:
vgs、blkid、Ansible の gather_facts が応答しないという問題が発生する可能性があります。この問題は、Rocky と Ubuntu の両方の OS に影響します。
ノードがすでにアップグレードされている場合は、次の手順を行います。lvm.conf ファイルを更新するプロセスは、次の手順で構成されます。
すべてのノードのリストを取得して、この修正をすべてのノードに適用できるようにします。
Ansible プレイブックと OS ポリシー ファイルを作成します。
ノードに修正を適用します。
修正が適用されているかどうかを確認します。
前提条件:
IAM-R0004 ランブックの手順に沿って、ルート管理クラスタの ROOTCONFIG と組織管理クラスタの ORGCONFIG を生成します。IAM-R0005 ランブックの手順に沿って、組織の次のロールを取得します。
回避策:
クラスタに対応する InventoryMachines を特定します。
kubectl --kubeconfig= $ROOTCONFIG get inventorymachines
kubectl --kubeconfig= $ORGCONFIG get inventorymachines 出力を別々にします。一度に 1 つのクラスタを修正します。出力は次のようになります。
NAME
bm-2bca8e3f
bm-4caa4f4e
ハンドブックとポリシー ファイルを作成します。
apiVersion: system.private.gdc.goog/v1alpha1
kind: AnsiblePlaybook
metadata:
name: lvm-conf-device-filter-node-update
namespace: gpc-system
spec:
playbook: |
- name: Add a device filter to /etc/lvm/lvm.conf
hosts: all
gather_facts: no
tasks:
# Change lvm.conf
- name: Configure lvm for filtering out "dm" and "sg" devices
ansible.builtin.lineinfile:
path: /etc/lvm/lvm.conf
insertafter: '^(\s+|)devices(\s+|)\{'
line: ' filter = [ \"r|/dev/dm.|\", \"r|/dev/sg.|\" ]'
---
apiVersion: system.private.gdc.goog/v1alpha1
kind: OSPolicy
metadata:
name: lvm-conf-device-filter-node-update
namespace: gpc-system
spec:
interval:
period: 1m
inventory:
# this is the inventory from step 1 above,
# see the syntex below
policy:
installPlaybook:
name: lvm-conf-device-filter-node-update
上記の在庫セクションは、次の例のように入力する必要があります。ステップ 1 で見つかったノードごとに 1 つの段落を追加します。一度に 1 つのクラスタを処理するため、インベントリ セクションには 1 つのクラスタのノードを入力します。
inventory:
# Node: bm-2bca8e3f
- apiVersion: baremetal.cluster.gke.io/v1
kind: InventoryMachine
name: bm-2bca8e3f
# Node: bm-4caa4f4e
- apiVersion: baremetal.cluster.gke.io/v1
kind: InventoryMachine
name: bm-4caa4f4e
修正をルート管理クラスタに適用します。
kubectl --kubeconfig= $ROOTCONFIG apply -f PRECEDING_FILENAME_WITH_ROOT_NODES
修正を組織管理クラスタに適用します。
kubectl --kubeconfig= $ORGCONFIG apply -f PRECEDING_FILENAME_WITH_ORG_NODES
新しい設定を有効にするには、サーバーを再起動します。
OS-P0005 ランブックの手順に沿って、ノードが更新されていることを検証します。ポリシーが正常に完了したことを確認したら、k9s ツールを使用してポリシーを削除します。
:ospolicies などの OS ポリシーに移動します。lvm-conf-device-filter-node-update ポリシーを見つけて選択します。Ctrl+d キーを押します。削除を確認します。
この問題をエスカレーションするには、SUPP-G0008 ランブックを使用してチケットを送信します。チケットには次の情報を含める必要があります。
実行されたコマンドとその出力メッセージ
InventoryMachineName やクラスタなどの詳細ログ メッセージ
オペレーティング システム（OS）
1.12.0
症状:
この問題は、環境が以前に 1.11 でデプロイされ、その後 1.12 にアップグレードされた場合に発生します。1.12.x バージョンで新しいクラスタまたは組織を作成すると、ReleaseMetadata CR と Userclustermetadata CR で指定された Rocky OS バージョンにより、ベアメタルと仮想マシン ノードのプロビジョニングに Ubuntu OS ではなく Rocky OS が選択されます。
回避策:
新しい組織を作成する前に、次の回避策を適用してください。
Succeeded: true 状態でない OrganizationUpgrade CR があるかどうかを確認します。
for item in $( kubectl --kubeconfig= KUBECONFIG get OrganizationUpgrade -A -o custom-columns= NAME:.metadata.name,NAMESPACE:.metadata.namespace --no-headers) ; do
NAME = $( echo $item | awk '{print $1}' )
NAMESPACE = $( echo $item | awk '{print $2}' )
STATUS = $( kubectl --kubeconfig= KUBECONFIG get organizationupgrade ${ NAME } -n ${ NAMESPACE } -o json | jq '.status.conditions[] | select(.type=="Succeeded") | .status' )
if [[ " $STATUS " != "True" ]] ; then
echo "Not in Succeeded: true state, stop following operations"
fi
done その場合は、次の手順に進む前にエンジニアリング チームにエスカレーションします。
誤ってノードの OS をアップグレードしないように、既存の OrganizationUpgrade CR をすべて削除します。
for item in $( kubectl --kubeconfig= KUBECONFIG get OrganizationUpgrade -A -o custom-columns= NAME:.metadata.name,NAMESPACE:.metadata.namespace --no-headers) ; do
NAME = $( echo $item | awk '{print $1}' )
NAMESPACE = $( echo $item | awk '{print $2}' )
echo "Deleting OrganizationUpgrade $NAME in namespace $NAMESPACE "
kubectl --kubeconfig= KUBECONFIG delete OrganizationUpgrade $NAME -n $NAMESPACE
done
新しい組織の作成のターゲット GDC バージョンを定義します。このターゲット バージョンに対応する ReleaseMetadata が必要です。
TARGET_RELEASE =
ルート管理クラスタでターゲットの Ubuntu OS の最新の OSImageMetadata CR を特定し、OS_VERSION 変数を定義します。
OS_VERSION = $( kubectl --kubeconfig= KUBECONFIG get osimagemetadata --sort-by= .metadata.creationTimestamp | grep -wv rocky | tail -1 | awk '{print $1}' | sed 's/gdch-node-os-//g' )
echo $OS_VERSION 出力は次のようになります。
1 .12.4-gdch.4変数で、TARGET_RELEASE と同じメジャー.マイナー.パッチ バージョン（1.12.4 など）が使用されていることを確認します。解決しない場合は、次の手順に進む前にエンジニアリング チームにエスカレーションします。
ルート管理クラスタで Ubuntu OS_VERSION を使用するように、ターゲット ReleaseMetadata を更新します。
kubectl --kubeconfig= KUBECONFIG patch releasemetadata " ${ TARGET_RELEASE } " --type= 'json' -p= '[{"op": "replace", "path": "/spec/adminCluster/bmNodeImage", "value": ' " ${ OS_VERSION } " '}, {"op": "replace", "path": "/spec/adminCluster/vmNodeImage", "value": ' " ${ OS_VERSION } " '}, {"op": "replace", "path": "/spec/systemCluster/bmNodeImage", "value": ' " ${ OS_VERSION } " '}, {"op": "replace", "path": "/spec/systemCluster/vmNodeImage", "value": ' " ${ OS_VERSION } " '}]'
ターゲット ReleaseMetadata にマッピングされた UserclusterMetadata リストを特定します。
UCMS = $( kubectl --kubeconfig= KUBECONFIG get releasemetadata " ${ TARGET_RELEASE } " -o json | jq -r '.spec.userClusters[].name' )
各組織のルート管理クラスタと組織管理クラスタで Ubuntu OS_VERSION を使用するように、ターゲット UserclusterMetadata を更新します。クラスタごとに次のコマンドを実行します。
for UCM in ${ UCMS } ; do
echo "Updating UserclusterMetadata $UCM "
kubectl --kubeconfig= KUBECONFIG patch userclustermetadata.upgrade.private.gdc.goog " ${ UCM } " --type= 'json' -p= '[{"op": "replace", "path": "/spec/vmNodeImage", "value": ' " ${ OS_VERSION } " '}]'
done
仮想マシン
1.12.1
症状:
gdcloud compute images import CLI を使用してローカル VM イメージをインポートすると、インポート ステータスが WaitingForTranslationVM または ImportJobNotCreated のままになります。これは、変換またはインポート用に作成された一時ディスクが qcow2 または raw イメージと同じサイズを使用するのに対し、LUKS は数 MiB のオーバーヘッドを追加するため、ディスク プロビジョニングが失敗するためです。
回避策:
同じイメージ名で、より大きな spec.minimumDiskSize を使用して、新しい VirtualMachineImageImport を手動で作成します。たとえば、イメージのインポートに使用されたコマンドが次のとおりだったとします。
gdcloud compute images import $IMPORT_NAME --project $PROJECT --source-file= $LOCAL_FILENAME --os= $OS CLI によって自動的に作成された元の VirtualMachineImageImport の minimumDiskSize が X Gi の場合は、X+1 Gi で新しい VirtualMachineImageImport を作成します。値は、インポートされる画像のサイズに基づきます。qcow2 の場合は仮想サイズになります。たとえば、20 Gi は 21 Gi に置き換えます。
CLI の呼び出し方法に基づいて、プレースホルダの値を置き換えます。
VirtualMachineImageImport を見つけます。
kubectl get virtualmachineimageimport $IMPORT_NAME -n $PROJECT -o yaml オブジェクトが存在しない場合は、gdcloud compute images import ... コマンドを再度トリガーします。コンソール出力が Uploading image to ... から Image import has started for ... に移行したら、Ctrl+C キーを押して、ローカル イメージがオブジェクト ストレージにアップロードされ、VirtualMachineImageImport が保存されて新しいイメージの作成に使用されるようにします。
より大きな minimumDiskSize を使用して新しい VirtualMachineImageImport を作成します。
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineImageImport
metadata:
name: $IMPORT_NAME_NEW
namespace: $NAMESPACE
spec:
imageMetadata:
minimumDiskSize: $NEW_SIZE
name: $IMAGE_NAME
operatingSystem: $OS
source:
objectStorage:
bucketRef:
name: vm-images-bucket
objectName: $LOCAL_FILENAME
仮想マシン
1.12.0
症状:
システム クラスタのプロジェクトの Namespace の importer-image-import-$VMII Pod がクラッシュし、次のエラーが表示されます: Unable to process data: Unable to transfer source data to target file: unable to write to file: stream error: stream ID 1; NO_ERROR; received from peer`)。VirtualMachineImageImport VMII オブジェクトの条件タイプは Ready で、インポートの開始から 2 時間後にステータスが False、理由が TranslationInProgress になります。
回避策:
速度を向上させるには、イメージの最小ディスクサイズを次のように 200Gi に変更します。
kubectl get validatingwebhookconfiguration vmm-image-controller-v1-webhook -oyaml > /tmp/vmm-image-controller-v1-webhook.yaml
kubectl delete validatingwebhookconfiguration vmm-image-controller-v1-webhook
kubectl patch virtualmachineimageimport $VMII -n $PROJECT -p '{"spec": {"imageMetadata": {"minimumDiskSize": "200Gi"}}}'
kubectl apply -f /tmp/vmm-image-controller-v1-webhook.yaml ValidatingWebhookConfiguration を削除して適用するには、組織管理クラスタのクラスタ管理者 kubeconfig が必要です。次のランブック IAM-R0004 を入手できます。
gdcloud を使用してインポートを開始する場合、minimumDiskSize パラメータを指定する方法はありません。VMII オブジェクトを作成し、前のコマンドに示すように VMII を変更する必要があります。
VirtualMachineImageImport プロセスは続行されますが、次のステップで再び停止します。システム クラスタのプロジェクト Namespace で、image-import-$VMII ジョブが error: stream error: stream ID x; NO_ERROR; received from peer エラーで継続的に失敗します。この時点で、画像のインポートが完了します。最終的な画像はオブジェクト ストレージにアップロードされますが、VirtualMachineImage がありません。VirtualMachineImage は、次のように手動で作成できます。
kubectl apply -f - <<EOF
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineImage
metadata:
name: $NAME
namespace: $PROJECT
spec:
minimumDiskSize: 200Gi
operatingSystem:
name: $OS_NAME
EOF `$NAME` は `VMII.ImageMetadata.Name` と一致する必要があります。`$OS_NAME` は [`ubuntu-2004`、`ubuntu-2204`、`windows-2019`、`rhel-8`] のいずれかで、インポートされたイメージのタイプと一致する必要があります。
Istio
1.12.4
症状:
istio-system Namespace の istio-eastwestgateway デプロイがスタックし、Pod イベントに kubelet からの Back-off pulling image "auto" エラーが表示されます。
問題を診断するには、スタックしたゲートウェイ デプロイと同じクラスタに istio-revision-tag-default という名前の mutatingwebhookconfiguration が存在するかどうかを確認します。
kubectl --kubeconfig= KUBECONFIG get mutatingwebhookconfiguration istio-revision-tag-default 回避策:
構成が存在する場合は、istio-system Namespace で Deployment istio-eastwestgateway を再起動します。
kubectl --kubeconfig= KUBECONFIG rollout restart deployment/istio-eastwestgateway -n istio-system
構成が存在しない場合は、Webhook が存在するまで待ちます。Webhook は調整ループ内にあるため、すぐに存在します。
モニタリング
1.12.2
症状:
cortex-store-gateway Pod が再起動し、ログに次のエラー メッセージが記録されます。
panic: runtime error: slice bounds out of range 回避策:
システム クラスタの mon-cortex サブコンポーネントを一時停止します。
kubectl --kubeconfig $ORG_ADMIN_CONFIG annotate subcomponent mon-cortex -n $SYSTEM_CLUSTER_NAMESPACE lcm.private.gdc.goog/paused= true
システム クラスタの cortex-config configMap を変更し、index_cache 内の memcached のタイムアウトを 2 秒に設定します。これにより、index_cache 構成は次のようになります。
index_cache:
backend: memcached
memcached:
addresses: dnssrvnoa+_memcached._tcp.cortex-index-memcached.mon-system.svc.cluster.local
timeout: 2s
更新された構成を使用するように、システム クラスタの cortex-store-gateway Pod を再起動します。
アップグレード
1.12.4
症状:
ベアメタルノードが NotReady として表示され、サーバーが起動画面で停止し、最後のメッセージが Retrieving encryption keys と表示されます。
回避策:
iLO を再起動します。
iLO が復旧したら、サーバーを再起動します。
アップグレード
1.12.4
症状:
アップグレード後、StorageCluster CR の StorageVersion ステータス フィールドに値が表示されません。バージョンを確認します。
kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get StorageCluster -n gpc-system
回避策:
file-storage-backend-controller デプロイを再起動します。
kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG rollout restart deployment -n file-system file-storage-backend-controller
Operations Suite Infrastructure（OI）
1.12.4
症状:
fluent-bit インストーラの場所が operations_center\bin\fluent-bit-win64.msi に変更されました。Copy-ConfigHostFiles.ps1 は、fluent-bit クライアント インストーラが fluent-bit-*-win64.* パターンと一致することを想定しています。そのパターンが一致しなくなったため、インストーラはインストーラを見つけられません。
回避策:
Copy-ConfigHostFiles.ps1 ファイルを開きます。次の行を探します。
$( Get-Item -Path 'H:\operations_center\bin\fluent-bit-*-win64.*' ) .FullName
前の行を編集して、正しいインストーラの場所を追加します。
$( Get-Item -Path 'H:\operations_center\bin\fluent-bit-win64.*' ) .Name
Operations Suite Infrastructure（OI）
1.12.4
症状:
Nessus インストーラの場所が operations_center\bin\NessusAgent-x64.msi に変更されました。Copy-ConfigHostFiles.ps1 は、クライアント インストーラのファイル名が /NessusAgent-10.4.1-x64.msi と一致することを想定しています。そのパターンが一致しなくなったため、インストーラはインストーラを見つけられません。
回避策:
Copy-ConfigHostFiles.ps1 ファイルを開きます。次の行を探します。
[ pscustomobject] @{ source = "H:\operations_center\bin\Nessus-10.4.1-x64.msi" ; destination = "C:\config\nessus_mgr\Nessus-10.4.1-x64.msi" }
[ pscustomobject] @{ source = "H:\operations_center\bin\Nessus-10.4.1-x64.msi" ; destination = "C:\config\nessus_oob\Nessus-10.4.1-x64.msi" }
上記の行を編集して、正しいインストーラの場所を追加します。Nessus-10.4.1-x64.msi を NessusAgent-x64.msi に変更します。
[ pscustomobject] @{ source = "H:\operations_center\bin\NessusAgent-x64.msi" ; destination = "C:\config\nessus_mgr\NessusAgent-x64.msi" }
[ pscustomobject] @{ source = "H:\operations_center\bin\NessusAgent-x64.msi" ; destination = "C:\config\nessus_oob\NessusAgent-x64.msi" }
オブジェクト ストレージ
1.12.4
症状:
次のようなメッセージが表示されることがあります。
Reason: NamespaceCreated
Status: True
Type: ObjectNamespaceReady
Last Transition Time: 2024 -07-12T00:49:29Z
Message: awaiting images distribution to be finished
Observed Generation: 1
Reason: VMImageDistributing
Status: Unknown
Type: Ready この問題は、新しい組織の S3 エンドポイント構成がないことが原因で発生します。
回避策:
新しい組織の HA グループを手動で作成します。
ブレークグラス手順で、次のリソースに対する読み取りアクセス権を持つルート管理クラスタの kubeconfig を取得します。
組織
ObjectStorageAdminNode
SubnetClaim
ObjectStorageSite
シークレット
組織名をメモします。
kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG_ABSOLUTE_PATH get Organization -A
ルート管理クラスタの ObjectStorageAdminNode CR のクライアント IP アドレスをメモします。
kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG_ABSOLUTE_PATH get ObjectStorageAdminNode 各 AdminNode CR に対して、次の操作を行います。
kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG_ABSOLUTE_PATH get ObjectStorageAdminNode NODE_NAME -o jsonpath = '{.spec.network.clientIP}'
使用可能な IP アドレス範囲と、その範囲内で予約されている IP をメモします。
kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG_ABSOLUTE_PATH get SubnetClaim -n root external-objectstorage-client-lif-subnet -o jsonpath = '{.status.ipv4SubnetStatus}'
ルート管理クラスタの gpc-system/objectstorage-breakglass-root-level1 Secret から StorageGRID 管理 UI のログイン認証情報を取得します。
前の手順で取得した認証情報を使用して、StorageGRID 管理 UI にログインします。URL が ObjectStorageSite ステータスの場合:
kubectl --kubeconfig /root/release/root-admin/root-admin-kubeconfig get ObjectStorageSite -n gpc-system mb-obj-site-1 -o jsonpath = '{.status.managementAPIEndpointURL}'
[構成 ] タブに移動し、[高可用性グループ ] をクリックします。
各 HA グループの詳細ビューを開き、仮想 IP アドレス（VIP）をメモします。
新しい HA グループを作成します。
グループ名 : 名前パターンは ORGANIZATION_NAME -haorg-2-ha です。グループの説明 : 説明パターンに既存の HA グループを使用します。インターフェース : すべての eth2 を選択します。優先順位 : プライマリ インターフェースの優先順位を最も高くする必要があります。SubnetCIDR : このフィールドは StorageGRID によって自動的に入力されます。サブネットが SubnetClaim external-objectstorage-client-lif-cidr の status.ipv4SubnetStatus.cidrBlock と一致することを確認します。仮想 IP : 使用可能な IP 範囲内の次の IP。IP は、予約済み IP、管理ノードのクライアント IP、既存の HA グループの VIP と競合できません。
StorageGRID のブレークグラス認証情報をローテーションします。
アップグレード
1.12.4
症状:
ルート組織を 1.12.2 から 1.12.4 にアップグレードすると、iac-gitlab サブコンポーネントの調整ステータスが進行中になります。問題を診断するには、prometheus ログを確認します。例:
kubectl logs gitlab-prometheus-server-5d6d9599f-l2l7s -n gitlab-system -c prometheus-server ログに次のようなエラーが含まれている可能性があります。
unexpected fault address 0x7f217cf26000
fatal error: fault
[ signal SIGBUS: bus error code = 0x2 addr = 0x7f217cf26000 pc = 0x46c302]
goroutine 1 [ running] :
runtime.throw({ 0x3018bed?, 0x0?})
/usr/local/go/src/runtime/panic.go:992 +0x71 fp = 0xc000a3b098 sp = 0xc000a3b068 pc = 0x438431 回避策:
たとえば、実行中のコンテナでシェルを取得するには、sleep 3600 を実行します。
kubectl exec --stdin --tty POD_NAME -n gitlab-system -c prometheus-server -- /bin/sh
/prometheus $ df -h POD_NAME は、Pod の名前（gitlab-prometheus-server-d7969c968-hppsl など）に置き換えます。
出力を確認して、/data フォルダがいっぱいになっているかどうかを確認します。
Filesystem Size Used Available Use% Mounted on
overlay 866 .4G 147 .1G 719 .3G 17 % /
tmpfs 64 .0M 0 64 .0M 0 % /dev
tmpfs 94 .3G 0 94 .3G 0 % /sys/fs/cgroup/dev/mapper/luks-trident_pvc_6fb4dc48_72df_4bf1_825f_267818e3fefd
7 .8G 7 .3G 0 100 % /data
アップグレード中にこの問題が発生した場合は、移行ジョブを削除します。移行ジョブのタイムアウトは 3, 600 秒です。その後、アップグレードを続行します。
kubectl delete job gitlab-migrations-1-fe7-2 -n gitlab-system
アップグレード
1.12.4
症状:
問題を診断するには、IAM アップグレード ログを確認します。
kubectl logs -n gpc-system upgrade-managed-check-iamupgrade-qbdm5-tl264 出力は次のようになります。
I0724 21 :57:20.456782 1 upgrade_check.go:39] IAM preflight check failed after 60000000000 : Org iam-system deployments not ready: Deployment iam-authzpdp-backend-server is not ready; ready replicas 2 ,replicas 3 回避策:
前のエラー メッセージを参照して、デプロイの Namespace と名前をメモします。この例では、NAME は iam-authzpdp-backend-server で、NAMESPACE は iam-system です。
Pod のリストを取得します。
kubectl get pods -n NAMESPACE | grep NAME
結果は次の形式で表示されます。
iam-authzpdp-backend-server-6875654c4b-64h4t 2 /2 Running 0 29h
iam-authzpdp-backend-server-6875654c4b-pvscg 1 /2 Running 0 29h
iam-authzpdp-backend-server-6875654c4b-v7jnl 2 /2 Running 0 29h すべてのコンテナの準備ができていない Pod をメモします。この場合、POD_NAME は iam-authzpdp-backend-server-6875654c4b-pvscg で、2 つのコンテナのうち 1 つの準備ができていないことが 1/2 ステータスで示されています。このような Pod が複数ある場合は、影響を受ける Pod ごとに次の手順を繰り返します。
完全に正常でない Pod を削除します。
kubectl delete pod -n NAMESPACE POD_NAME>
手順 2 のコマンドをもう一度実行します。すべての Pod が正常な状態になっていることを確認します。このステップには数分かかることがあります。
削除された Pod が正常な Pod に置き換えられない場合は、サポート チケットを開きます。
アップグレード
1.12.1
症状:
アップグレードが完了すると、OrganizationUpgrade ステータスは Unknown になります。
回避策:
Organization のバージョン フィールドが targetVersion フィールドと一致する場合、Unknown ステータスは無視して構いません。
アップグレード
1.12.4
症状:
テナント組織を 1.12.2 から 1.12.4 にアップグレードする際に、opa gatekeeper サブコンポーネントのアップグレードが ReconciliationError で失敗します。
回避策:
影響を受けるユーザー クラスタの mutatingwebhookconfiguration オブジェクト edr-sidecar-injector-webhook-cfg を編集します。影響を受けるユーザー クラスタが複数ある場合は、影響を受けるユーザー クラスタごとに次の手順を繰り返します。
kubectl edit mutatingwebhookconfiguration edr-sidecar-injector-webhook-cfg
webhooks > (edr-sidecar-injector.gpc-system.internal) > namespaceSelector > matchExpressions > (key: kubernetes.io/metadata.name) > values セクションを編集して、次の 2 つの値を追加します。
更新されたオブジェクトは次のようになります。
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
...
webhooks:
- admissionReviewVersions:
name: edr-sidecar-injector.gpc-system.internal
namespaceSelector:
matchExpressions:
- key: kubernetes.io/metadata.name
operator: NotIn
values:
- kube-system
- opa-system
- cert-manager
...
変更が反映されるまでに最長で 1 時間ほどかかることがあります。
アップグレード
1.12.4
症状:
1.12.2 から 1.12.4 にアップグレードする場合、ansibleplaybook はクラスタのアップグレードの一部としてアップグレードされません。ansibleplaybook で更新された修正が適用されず、以前のバージョンの ansibleplaybook を実行する os-policy がブロックされます。
回避策:
create-ansible-playbooks Kubernetes Job を削除します。
JOB_NAME = create-ansible-playbooks-xxx
JOB_NAMESPACE = xxx
kubectl delete job $JOB_NAME -n JOB_NAMESPACE --kubeconfig= /path/to/admin-cluster-config os-core-controller デプロイを再起動します。このアクションにより、ジョブが再トリガーされ、プレイブックが更新されます。
DNS
1.12.4
症状:
新しい組織を作成するときに、ログに core-dns サブコンポーネントのタイムアウトが表示されることがあります。
[ INFO] 192 .0.2.0:60741 - 40400 "A IN objectstorage-tenant-mgmt.gdch.example.com. udp 72 false 1232" - - 0 2 .000828817s
[ ERROR] plugin/errors: 2 objectstorage-tenant-mgmt.gdch.example.com. A: read udp 10 .244.4.184:59927->192.0.2.1:53: i/o timeout
[ INFO] 192 .0.2.0:51401 - 5813 "AAAA IN objectstorage-tenant-mgmt.gdch.example.com. udp 72 false 1232" - - 0 2 .000585231s
[ ERROR] plugin/errors: 2 objectstorage-tenant-mgmt.gdch.example.com. AAAA: read udp 10 .244.4.184:48542->192.0.2.1:53: i/o timeout回避策:
ルート管理クラスタの gpc-coredns-forwarder-udp サービスと gpc-coredns-forwarder-tcp サービスを更新し、ロードバランサのソース範囲に新しい IP 範囲を追加します。
CR の変更がオーバーライドされた場合は、アノテーション lcm.private.gdc.goog/paused="true" を使用して dns-core サブコンポーネントを一時停止します。
ファイル ストレージとブロック ストレージ
1.12.4
症状:
1.12.2 から 1.12.4 にアップグレードすると、file-netapp-trident サブコンポーネントが StorageClasses の削除で停止します。次のステータスが表示されます。
status:
backendStatus:
conditions:
- lastTransitionTime: "2024-05-02T06:04:14Z"
message: 'E0121 - rollback chart: no StorageClass with the name "standard-rwo-non-luks"
found'
observedGeneration: 2
reason: ReconciliationError
status: "True"
type: Reconciling
- lastTransitionTime: "2024-04-08T00:12:53Z"
message: Successfully pulled chart
observedGeneration: 2
reason: ChartPullDone
status: "True"
type: ChartPull
- lastTransitionTime: "2024-05-01T10:10:08Z"
message: Fetched parameters from default, runtime
observedGeneration: 2
reason: ParametersDone
status: "True"
type: Parameters
- lastTransitionTime: "2024-05-02T06:04:04Z"
message: 'E0121 - rollback chart: no StorageClass with the name "standard-rwo-non-luks"
found'
observedGeneration: 2
reason: DeployError
status: "False"
type: Deployed
- lastTransitionTime: "2024-04-23T06:50:12Z"
message: Readiness check job passed
observedGeneration: 1
reason: ReadinessCheckDone
status: "True"
type: Ready
deploymentFinished: false
lastDeployTimestamp: "2024-05-02T06:03:16Z"
readyAfterDeploy: true
version: ""
conditions:
- lastTransitionTime: "2024-05-02T06:04:14Z"
message: 'Reconciliation error: E0121 - rollback chart: no StorageClass with the
name "standard-rwo-non-luks" found'
observedGeneration: 2
reason: ReconciliationError
status: "True"
type: Reconciling
crdsStatus:
conditions:
- lastTransitionTime: "2024-04-07T08:02:33Z"
message: Successfully pulled chart
observedGeneration: 2
reason: ChartPullDone
status: "True"
type: ChartPull
- lastTransitionTime: "2024-04-07T08:02:33Z"
message: No parameters to fetch
observedGeneration: 2
reason: ParametersDone
status: "True"
type: Parameters
- lastTransitionTime: "2024-04-07T08:02:34Z"
message: Readiness source is empty
observedGeneration: 2
reason: ReadinessCheckSkipped
status: "True"
type: Ready
- lastTransitionTime: "2024-05-01T18:37:52Z"
message: Ready
observedGeneration: 2
reason: ReconciliationCompleted
status: "False"
type: Reconciling
deploymentFinished: true
lastDeployTimestamp: "2024-05-02T06:04:03Z"
readyAfterDeploy: true
version: 1 .12.3-gdch.312
回避策:
file-netapp-trident サブコンポーネントを一時停止します。
## Set KUBECONFIG to root-admin KUBECONFIG
export KUBECONFIG = ROOT_ADMIN_KUBECONFIG
kubectl annotate subcomponent file-netapp-trident -n $cluster_namespace lcm.private.gdc.goog/paused= true
ジョブの作成に失敗した StorageClasses（standard-rwo、standard-block、standard-rwo-non-luks、standard-block-non-luks など）を削除します。
kubectl delete storageclass $( kubectl get storageclasses -o jsonpath = ' { .items[ ?( @.provisioner== "csi.trident.netapp.io" ) ] .metadata.name}
クラスタの oclcm-backend-controller（ルート クラスタと組織クラスタのルート管理者コントローラ、システム クラスタとユーザー クラスタの組織管理者コントローラ）を再起動して、StorageClasses の再作成をトリガーします。
kubectl rollout restart deployment oclcm-cm-backend-controller -n oclcm-system
クラスタで netapp-trident Deployment と netapp-trident DaemonSet を再起動します。
kubectl rollout restart deployment netapp-trident-controller -n netapp-trident
kubectl rollout restart daemonset netapp-trident-node-linux -n netapp-trident
PersistentVolumeClaim（PVC）リソースに対して LUKS シークレットが作成されたことを確認します。すべての PVC には、g-luks-$pvc_name 形式のシークレットが必要です。
kubectl get secret -n $pvc_namespace g-luks-$pvc_name file-netapp-trident サブコンポーネントのステータスにエラーがないことを確認します。
kubectl get subcomponent -n $cluster_namespace file-netapp-trident -o jsonpath = '{.status}' | jqオーバーライドを有効にするには、サブコンポーネントの一時停止を解除します。
物理サーバー
1.12.4
症状:
サーバーをブートストラップすると、ベアメタル ログに次のようなメッセージが表示されることがあります。
Conditions:
Last Transition Time: 2024 -08-12T17:10:23Z
Message: Introspection timeout
Observed Generation: 2
Reason: FailedProvision
Status: True
Type: BaremetalFailure
Last Transition Time: 2024 -08-10T12:23:30Z
Message:
Observed Generation: 2
Reason: KeyManagerConfigurationSucceeded
Status: True
Type: KeyManagerConfigured
Last Transition Time: 2024 -08-10T12:11:17Z
Message: The server is powered off or unknown
Observed Generation: 2
Reason: NotPoweredOn
Status: False
Type: Ready 回避策:
停止したフェーズごとに、次のランブックの手順に沿って操作します。
SERV-R0006 SERV-R0007 SERV-R0008
問題が解決しない場合は、SERV-R0001 ランブックの手順に沿って対応します。
それでも問題が解決しない場合は、サポート チケットを送信してください。
アップグレード
1.12.0
症状:
primary-prometheus-shardX-replicaX Pod は、obs-system Namespace と mon-system Namespace に表示されます。1.12 にアップグレードした後、primary-prometheus-shardX-replicaX が obs-system Namespace にのみ存在する場合は、別の不明な問題であるため、回避策は実行しないでください。
想定される動作は、1.12 へのアップグレードが完了した後に primary-prometheus-shardX-replicaX が mon-system 名前空間にのみ存在することです。
回避策:
obs-system Namespace の primary-prometheus-shardX-replicaX StatefulSet を手動で削除します。mon-system Namespace の primary-prometheus-shardX-replicaX StatefulSet を削除しないでください。
ネットワーキング
1.12.4
症状:
ClusterCIDRConfig は、PodCIDRs を割り当てるために必要なオブジェクトです。ClusterCIDRConfig が作成されたにもかかわらず、PodCIDRs が割り当てられませんでした。この問題は、ipam-controller Pod のブートストラップと同時に ClusterCIDRConfig が作成された場合に発生します。クラスタの作成が調整状態で停止している:
クラスタに ClusterCIDRConfig オブジェクトが作成されているかどうかを確認します。
kubectl --kubeconfig= CLUSTER_KUBECONFIG get clustercidrconfigs -oyaml 出力は次のようになります。
apiVersion: v1
items:
- apiVersion: networking.gke.io/v1alpha1
kind: ClusterCIDRConfig
metadata:
annotations:
baremetal.cluster.gke.io/managed: "true"
kubectl.kubernetes.io/last-applied-configuration: |
{ "apiVersion" :"networking.gke.io/v1alpha1" ,"kind" :"ClusterCIDRConfig" ,"metadata" :{ "annotations" :{ "baremetal.cluster.gke.io/managed" :"true" } ,"creationTimestamp" :null,"name" :"root-admin-control-plane" } ,"spec" :{ "ipv4" :{ "cidr" :"172.24.0.0/21" ,"perNodeMaskSize" :23} ,"ipv6" :{ "cidr" :"fd00:1::2:0/112" ,"perNodeMaskSize" :119}} ,"status" :{}}
creationTimestamp: "2024-06-17T05:27:55Z"
finalizers:
- networking.kubernetes.io/cluster-cidr-config-finalizer
generation: 1
name: root-admin-control-plane
resourceVersion: "2172"
uid: d1216fe3-04ed-4356-a105-170d72d56c90
spec:
ipv4:
cidr: 172 .24.0.0/21
perNodeMaskSize: 23
ipv6:
cidr: fd00:1::2:0/112
perNodeMaskSize: 119
kind: List
metadata:
resourceVersion: ""
調整が停止しているクラスタのノード オブジェクトのいずれかで describe を実行し、ノード オブジェクトに CIDRNotAvailable イベントが存在するかどうかを確認します。
kubectl --kubeconfig= CLUSTER_KUBECONFIG describe node NODE_NAME 出力イベントは次のようになります。
Type Reason Age From Message
---- ------ ---- ---- -------
Normal CIDRNotAvailable 3m22s ( x96 over 21h) cidrAllocator Node gpc-adhoc-4f533d50vm-worker-node2-zone1 status is now: CIDRNotAvailable
Warning ReconcileError 3m22s ( x96 over 21h) ipam-controller CIDRAssignmentFailed, retrying: failed to get cidrs for node gpc-adhoc-4f533d50vm-worker-node2-zone1, unable to get clusterCIDRs for node gpc-adhoc-4f533d50vm-worker-node2-zone1, no available CIDRs
回避策:
ipam-controller-manager Pod を再起動します。
kubectl --kubeconfig= CLUSTER_KUBECONFIG -n kube-system rollout restart ds ipam-controller-manager ipam-controller-manager Pod が実行状態になったら、podCIDR がノードに割り当てられているかどうかを確認します。
kubectl --kubeconfig= CLUSTER_KUBECONFIG get nodes -oyaml | grep podCIDR 出力は次のようになります。
podCIDR: 172 .24.4.0/23
podCIDRs:
podCIDR: 172 .24.2.0/23
podCIDRs:
podCIDR: 172 .24.0.0/23
podCIDRs:
Vertex AI
1.12.0
MonitoringTarget は、ユーザー クラスタの作成時に Not Ready ステータスを表示するため、事前トレーニング済みの API はユーザー インターフェースで Enabling 状態を継続的に表示します。
回避策:
Chrome ブラウザのメニュー（その他アイコン）を開きます。
[その他のツール ] > [デベロッパー ツール ] をクリックして、コンソールを開きます。
コンソールの [ネットワーク ] タブをクリックします。
ai-service-status リクエストを見つけます。ai-service-status リクエストの [レスポンス ] タブをクリックして、そのリクエストの内容を表示します。MonitoringTarget コンポーネントと LoggingTarget コンポーネントを除き、すべてが準備完了になっていることを確認します。
オブジェクト ストレージ
1.12.4
症状:
オブジェクト ストレージをアップグレードすると、次のような警告が表示されることがあります。
Type Reason Age From Message
---- ------ ---- ---- -------
Warning ReconcileError 55m ( x2 over 55m) ObjectStorageAdminNodeReconciler Reconcile error, retrying: error storing the ssh creds: 500 Internal Server Error:ErrorMessage: { "text" :"The GDU service is currently busy. Try again later. Contact technical support if the issue persists." ,"key" :"maintenance.gdu.gdu_server_locked 回避策:
各ノードに対応する SSH 認証情報がシークレットに保存されていることを確認します。
管理ノードを確認します。
kubectl get objectstorageadminnodes -o json | jq -r '.items[].metadata.name' | while read -r nodeName; do kubectl get secret -n gpc-system $nodeName -ssh-creds; done
ストレージ ノードを確認します。
kubectl get objectstoragestoragenodes -o json | jq -r '.items[].metadata.name' | while read -r nodeName; do kubectl get secret -n gpc-system $nodeName -ssh-creds; done
正常な出力は、ストレージ ノードの場合、次の例のようになります。
NAME TYPE DATA AGE
gpcstgecn01-gce-gpcstgesite01-ssh-creds Opaque 2 3d23h
NAME TYPE DATA AGE
gpcstgecn02-gce-gpcstgesite01-ssh-creds Opaque 2 3d23h
NAME TYPE DATA AGE
gpcstgecn03-gce-gpcstgesite01-ssh-creds Opaque 2 3d23h シークレットが見つからない場合、エラーは次のようになります。
Error from server ( NotFound) : secrets "gpcstgeadm02-gce-gpcstgesite01-ssh-creds" not found
コマンドがエラーを返さない場合は、Reconciler によって報告されたエラーを無視しても問題ありません。
Vertex AI
1.11.x
症状:
アップグレード中、Translation DB クラスタが再作成されるため、ODS システム クラスタの secret-store シークレットが古くなり、同期されなくなります。そのため、Translation フロントエンドの Pod とサービスは初期化に失敗します。
回避策:
システム クラスタ内のシークレットを削除します。
kubectl --kubeconfig SYSTEM_CLUSTER_KUBECONFIG delete secret postgres-secret-store -n ai-translation-system SYSTEM_CLUSTER_KUBECONFIG
コントローラはシークレットを自動的に再作成し、DB クラスタと再同期します。
物理サーバー
1.12.4
症状:
サーバーがキーマネージャーに接続できないため、サーバーの状態が使用可能になりません。この問題により、server-encrypt-and-create-logical-drive ジョブが失敗し、管理クラスタが準備完了になりません。ジョブログに次のようなエラーが表示されることがあります。
Error: Error during command execution: ansible-playbook error: one or more host failed
Command executed: /usr/local/bin/ansible-playbook --extra-vars { "server_generation" :"gen10" ,"ssa_crypto_pwd" :"vf{kXgbL?VFcV]%0" ,"ssa_master_key" :"ten-admin-org-2" } --inventory 192 .0.2.0, --private-key /etc/ssh-key/id_rsa --become serve
r/encrypt_and_create_logical_drive.yaml
exit status 2 回避策:
AuxCycle を実行し、iLO がキー マネージャーに接続できることを確認します。
ロギング
1.12.4
症状:
Loki には、ログ先行書き込み（WAL）とインデックスの両方に対して 1 つの永続ボリューム（PV）しかありません。Loki Pod が数時間ストレージ バケットに接続できない場合、WAL によって PV がいっぱいになる可能性があります。PV に空き容量がない場合、PV を削除して StatefulSet を再起動しない限り、Loki は復元できません。
回避策:
この状態から Loki Pod を復元するには、対応する StatefulSet をスケールダウンし、空き容量のない PV を削除する必要があります。
注意: このアクションの結果として、ストレージ バケットに転送されなかった WAL に現在存在するログは完全に失われます。
Loki Pod を復元する手順は次のとおりです。
ワークステーションに IO ツール コンテナがインストールされていることを確認します。詳細については、OOPS-P0065 運用マニュアルをご覧ください。
リソースの編集に必要な権限を取得するには、セキュリティ管理者に次のロールの付与を依頼してください。
observability-viewerobservability-admin
KUBECONFIG 環境変数に、ルート管理クラスタの kubeconfig ファイルのパスを設定します。詳細については、IAM-R0004 ランブックをご覧ください。影響を受ける組織の名前で ORG_NAME 環境変数を設定します。
次の内容を log-admin-overrides.yaml という名前の YAML ファイルに保存します。
apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
name: log-admin-overrides
spec:
subComponentRef: log-admin
backend:
operableParameters:
controller:
disableReconcilers: "LoggingPipelineReconciler"
LoggingPipelineReconciler を無効にします。
kubectl apply -f log-admin-overrides.yaml -n ${ ORG_NAME } 影響を受ける Loki Pod が実行されているクラスタの kubeconfig ファイルのパスを使用して、KUBECONFIG 環境変数を設定します。詳細については、IAM-R0004 ランブックをご覧ください。
影響を受ける Loki Pod の名前で LOKI_POD_NAME 環境変数を設定します。
Loki StatefulSet 名を取得します。
export LOKI_STATEFULSET_NAME = $( kubectl get pod $LOKI_POD_NAME -n obs-system -o json | jq -r '.metadata.labels.app' )
Loki PVC 名を取得します。
export LOKI_PVC_NAME = $( kubectl get pod $LOKI_POD_NAME -n obs-system -o json | jq -r '.spec.volumes[] | select(.persistentVolumeClaim != null) | .persistentVolumeClaim.claimName' )
Loki StatefulSet レプリカを取得します。
export LOKI_STATEFULSET_REPLICAS = $( kubectl get statefulset $LOKI_STATEFULSET_NAME -n obs-system -o json | jq -r '.status.replicas' )
Loki StatefulSet をスケールダウンします。
kubectl scale statefulset $LOKI_STATEFULSET_NAME -n obs-system --replicas= 0
StatefulSet Pod が実行されていないことを確認します。
kubectl get statefulset $LOKI_STATEFULSET_NAME -n obs-system 出力は次の例のようになります。
NAME READY AGE
audit-logs-loki-io 0 /0 4d3h 影響を受ける PVC を削除します。
kubectl delete pvc $LOKI_PVC_NAME -n obs-system
Loki StatefulSet をスケールアップします。
kubectl scale statefulset $LOKI_STATEFULSET_NAME -n obs-system --replicas= ${ LOKI_STATEFULSET_REPLICAS }
影響を受ける組織の管理クラスタにある kubeconfig ファイルのパスを使用して、KUBECONFIG 環境変数を設定します。詳細については、IAM-R0004 ランブックをご覧ください。
log-admin-overrides.yaml YAML ファイルの内容を次のように編集します。
apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
name: log-admin-overrides
namespace: root
spec:
subComponentRef: log-admin
backend:
operableParameters:
controller:
disableReconcilers: "" LoggingPipelineReconciler を有効にします。
kubectl apply -f log-admin-overrides.yaml -n ${ ORG_NAME } すべての StatefulSet Pod が実行中で正常であることを確認します。
kubectl get statefulset $LOKI_STATEFULSET_NAME -n obs-system 出力は次の例のようになります。
NAME READY AGE
audit-logs-loki-io 5 /5 2d5h この場合、StatefulSet には 5 つのレプリカ（5/5）のうち 5 つが使用可能です。
アップグレード
1.12.4
症状:
ジョブは継続的にスケジュールされます。ジョブが終了するとすぐに、新しいジョブがスケジュールされます。継続的にスケジュールされているジョブは次のとおりです。
unet-networkpolicy-assets-parameterunet-nodenetworkpolicy-assets-parameterunet-nodenetworkpolicy-assets-readinessunet-userclusterpolicy-assets-parameterunet-clustermesh-backend-parameterunet-clustermesh-backend-readiness
回避策:
次のサブコンポーネントを一時停止します。
unet-networkpolicyunet-nodenetworkpolicyunet-nodenetworkpolicyunet-userclusterpolicyunet-clustermesh
ルート管理クラスタの fleet-info シークレットが変更されるたびに、サブコンポーネントのポーズを解除します。この問題は、インスタンスの管理スイッチ（kr get managementswitches -A など）が変更された場合や、組織 Namespace の cidrclaim が変更された場合に発生します。
組織管理クラスタ内の NodePool リソースが変更されるたびに、サブコンポーネントのポーズを解除します。開始する前にサブコンポーネントのポーズを解除します。
アップグレード
1.12.4
症状:
1.12.2 から 1.12.4 にアップグレードすると、ServiceNow の正常なアップストリームが使用できなくなります。failed to stage volume: LUKS passphrase cannot be empty というメッセージが表示されることがあります。
system-performance-rwo ストレージ クラスで LUKS が有効になっていません。ボリューム アタッチメントは、PVC で LUKS が有効になっていることを示します。Reconciler は、LUKS パスフレーズを含むシークレットを検索します。ボリューム アタッチメントは LUKS が有効になっていると示していますが、ストレージ クラスでは LUKS が有効になっていないため、シークレット パスフレーズは作成されません。
回避策:
問題が発生しているルート クラスタまたは組織管理者クラスタの Kubeconfig を取得します。
export KUBECONFIG = ${ ROOT_OR_ORG_ADMIN_KUBECONFIG }
system-performance-rwo ストレージ クラスを削除して再作成します。
kubectl delete storageclass system-performance-rwo
kubectl apply -f system-performance-rwo.yamlsystem-performance-rwo ストレージ クラスの新しい YAML を作成し、LUKS を有効にします。
# kubectl get sc system-performance-rwo -o yaml
allowVolumeExpansion: true
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
annotations:
disk.gdc.goog/luks-encrypted: "true"
helm.sh/resource-policy: keep
lcm.private.gdc.goog/claim-by-force: "true"
meta.helm.sh/release-name: file-netapp-trident-backend
meta.helm.sh/release-namespace: netapp-trident
storageclass.kubernetes.io/is-default-class: "false"
labels:
app.kubernetes.io/managed-by: Helm
name: system-performance-rwo
parameters:
backendType: ontap-san
csi.storage.k8s.io/node-expand-secret-name: g-luks-${ pvc .name }
csi.storage.k8s.io/node-expand-secret-namespace: ${ pvc .namespace }
csi.storage.k8s.io/node-publish-secret-name: g-luks-${ pvc .name }
csi.storage.k8s.io/node-publish-secret-namespace: ${ pvc .namespace }
csi.storage.k8s.io/node-stage-secret-name: g-luks-${ pvc .name }
csi.storage.k8s.io/node-stage-secret-namespace: ${ pvc .namespace }
fsType: ext4
selector: tier = performance
provisioner: csi.trident.netapp.io
reclaimPolicy: Delete
volumeBindingMode: Immediate
アップグレード
1.12.4
症状:
file-netapp-trident サブコンポーネントのステータスが Reconciling と ReconciliationCompleted の間で切り替わる場合があります。
回避策:
次の条件が満たされている場合、進行中の調整は無視しても安全です。
「TridentBackend」は「online」です。
TridentBackend 構成は bound です。netapp-trident-controller デプロイメントは正常です。netapp-trident-node-linux DaemonSet が正常である。
アップグレード
1.12.4
症状:
1.12.2 から 1.12.4 にアップグレードすると、組織のアップグレードが NodeUpgrade ステージで停止し、ノードのアップグレード タスクに次のエラーが表示されます。
Message: failed to generate delta between manifest and snapshot: failed to create or update delta configmap: failed to calculate delta between snapshot and manifest: failed to get valid OS distribution for delta comparison, distribution:
この問題を確認するには、次の手順を行います。
ノードのアップグレードが失敗しているルート クラスタまたは組織管理者クラスタの Kubeconfig を取得し、nodeupgradetask が失敗したかどうかを確認します。
export KUBECONFIG = ${ ROOT_OR_ORG_ADMIN_KUBECONFIG }
kubectl get nodeupgradetask -A -ojsonpath= '{.items[*].status.conditions[?(@.status != "True")]}' | jq
メッセージが以前のエラー メッセージと一致していることを確認します。
Message: failed to generate delta between manifest and snapshot: failed to create or update delta configmap: failed to calculate delta between snapshot and manifest: failed to get valid OS distribution for delta comparison, distribution:
osartifactsnapshot に欠落している分布があることを確認します。
kubectl get osartifactsnapshots.system.private.gdc.goog -A -o json | jq '.items[] | select(.status.distribution == "") | .metadata.name' 印刷されたスナップショットが少なくとも 1 つあり、配布が設定されていないことを確認します。
回避策:
ノードが属するクラスタの Kubeconfig を取得します。
export KUBECONFIG = ${ CLUSTER_KUBECONFIG }
kubectl rollout restart -n os-system os-core-controller
スナップショットに分布が設定されていることを確認します。（このコマンドには数分かかることがあります）。
kubectl get osartifactsnapshots.system.private.gdc.goog -A -o json | jq '.items[] | select(.status.distribution == "") | .metadata.name'
このコマンドは結果を返しません。引き続き配信が表示されない場合は、サポート リクエストを送信してください。
アップグレード
1.12.4
症状:
kubelet は、次のスパムログを繰り返し出力します。
May 22 23 :08:00 control-1--f1c6edcdeaa9e08-e387c07294a9d3ab.lab.anthos kubelet[ 3751 ] : time = "2024-05-22T23:08:00Z" level = warning msg = "Failed to remove cgroup (will retry)" error = "rmdir /sys/fs/cgroup/freezer/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope: device or resource busy"
……
May 22 23 :09:04 control-1 kubelet[ 3751 ] : time = "2024-05-22T23:09:04Z" level = warning msg = "Failed to remove cgroup (will retry)" error = "rmdir /sys/fs/cgroup/net_cls,net_prio/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope: device or resource busy" runc init プロセスがフリーズし、kubelet が cgroup Pod を削除できなくなります。
回避策:
次のスクリプトを使用して、cgroup の削除をブロックしているプロセスを見つけます。
# Find matching cgroup directories
MATCHING_CGROUPS = $( find /sys/fs/cgroup -type d -name "*74353c*" )
if [ -z " $MATCHING_CGROUPS " ] ; then
echo "No cgroups found containing 'd06aac'."
exit 0
fi
echo "Matching cgroups:"
for cgroup in $MATCHING_CGROUPS ; do
echo "- $cgroup " # Print cgroup path
# Check if cgroup.procs exists
if [ -f " $cgroup /cgroup.procs" ] ; then
echo " Processes:"
# List PIDs in cgroup.procs
for pid in $( cat " $cgroup /cgroup.procs" ) ; do
# Get process details
ps -o pid,comm,cmd --no-headers $pid 2 >/dev/null # Suppress errors if process doesn't exist
done
else
echo " No cgroup.procs file found." # Handle cases where cgroup.procs is missing
fi
echo # Add a newline for better readability
done
cat freezer.state を使用して、フリーザーの状態を確認します。状態は FROZEN である必要があります。Echo "THAWED" > freezer.state
cgroup が正常に削除されます。Kubelet はログへのスパム送信を停止します。
パフォーマンス
1.12.4
症状:
perf-ptaas サブコンポーネントに次のエラーコードが表示され、PTaaS のデプロイが妨げられます。
Reconciliation error: E0100 - deploy: failed to transfer ownership of conflicting resources for install: these resources need to be force claimed, but they are not annotated: [ Resource: "resourcemanager.gdc.goog/v1, Resource=projects" , GroupVersionKind: "resourcemanager.gdc.goog/v1, Kind=Project"
回避策:
PTaaS は gdchservices 組織にデプロイされます。
perftest Namespace gdch-perftest の PTaaS プロジェクト gdch-perftest とバケット perftest-bucket-reports のアノテーションとラベルを検査します。バケットにラベル app.kubernetes.io/managed-by=Helm とアノテーション meta.helm.sh/release-name=perf-ptaas-assets、meta.helm.sh/release-namespace=gdch-perftest がない可能性があります。次のラベルとアノテーションを手動で追加します。
kubectl --kubeconfig gdchservices-admin-kubeconfig label buckets -n gdch-perftest perftest-bucket-reports app.kubernetes.io/managed-by= Helm
kubectl --kubeconfig gdchservices-admin-kubeconfig annotate buckets -n gdch-perftest perftest-bucket-reports meta.helm.sh/release-name= perf-ptaas-assets
kubectl --kubeconfig gdchservices-admin-kubeconfig annotate buckets -n gdch-perftest perftest-bucket-reports meta.helm.sh/release-namespace= gdch-perftest
kubectl --kubeconfig gdchservices-admin-kubeconfig annotate buckets -n gdch-perftest perftest-bucket-reports lcm.private.gdc.goog/claim-by-force= true
PTaaS プロジェクト gdch-perftest のアノテーションを検査します。プロジェクトがアノテーション meta.helm.sh/release-name=perf-ptaas-assets で誤って構成されている可能性があります。このアノテーションを meta.helm.sh/release-name=perf-ptaas-backend に変更します。
kubectl --kubeconfig gdchservices-admin-kubeconfig annotate projects -n gpc-system gdch-perftest meta.helm.sh/release-name= perf-ptaas-backend --overwrite= true
kubectl --kubeconfig gdchservices-admin-kubeconfig annotate projects -n gpc-system gdch-perftest lcm.private.gdc.goog/claim-by-force= true
サブコンポーネントが root-admin クラスタで調整されることを確認します。
kubectl get subcomponent -n gdchservices perf-ptaas
