| インストール |
1.9.0
1.9.1
1.9.2 |
iLO が HSM から鍵を取得できないことがある
症状:
`server.status.conditions` には、タイプ `KeyManagerConfigured` とステータス `True` のエントリがありますが、タイプ `DiskEncryptionEnabled` のエントリはありません。 エラー「ERROR: (3065) Error changing the Controller Encryption Mode UNABLE TO RETRIEVE KEY\tController: HPE Smart Array P408i-a SR Gen10, SLOT 0」が発生した `server-encrypt-and-create-logical-drive-$SERVER-xxxxx` という名前の失敗した Pod があります。 無効なキーが原因で Pod に SSH 接続できない。
回避策:
この問題を解決するには、次の手順に沿って操作します。
iLO UI > [Information] > [Diagnostics] > [Reset] に移動して、iLO をリセットします。 リセット中に iLO にサーバーがパワーオン セルフテスト（POST）中と表示された場合は、プロビジョニング フローを再起動します。
admin-cluster のインストールが成功した場合:
export KUBECONFIG=<root-admin-kubeconfig path>
SSH 認証鍵を更新します。
現在の公開 SSH 認証鍵を取得します（ローテーションされている可能性があるため、/root/.ssh/id_rsa.pub とは異なる場合があります）。
kubectl -n gpc-system get secret/ssh-key -ojsonpath={.data.'id_rsa\.pub'} | base64 -d
公開鍵を ironic-vars configmap に配置します。
kubectl -n gpc-system edit cm/ironic-vars
IRONIC_RAMDISK_SSH_KEY を追加します。\ ironic を再起動します。
kubectl -n gpc-system rollout restart deployment/root-admin-metal3-ironic
マシンを再プロビジョニングして IPA を再インストールします。
bmh を削除するとシークレットも削除されるため、bmc-credential-$SERVER をバックアップします。
kubectl -n gpc-system get secret bmc-credentials-$SERVER -oyaml > $SERVER
last-applied、creationtimestamp、finalizer、ownerreference、resourceversion、uid など、ファイルから適用できない属性を削除します。
BareMetalHost を削除します。
kubectl -n gpc-system delete bmh/$SERVER
cellcfg から Secret bmc-credentials-$SERVER または以前のバックアップを取得して適用します。
サーバーに別の処理を行うよう指示します。
キャッシュに保存された BMH ステータスを削除するには:
kubectl -n gpc-system annotate server/$SERVER baremetalhost.metal3.io/status-
サーバーがプロビジョニングされるまで待ちます。 BMH オブジェクトが作成される様子を確認します。 再トリガーするには、暗号化ジョブの削除が必要になることがあります。
|
| 運用 |
1.9.0
1.9.1
1.9.2 |
症状:
storageClassName が standard-block の場合、VM の状態は Provisioning または Starting の STATUS で保持されます。
回避策:
この問題を解決するには、次の手順に沿って操作します。
VM の STATUS に Provisioning または Starting が表示されていることを確認します。
kubectl --kubeconfig SYSTEM_KUBECONFIG get gvm -n PROJECT
SYSTEM_KUBECONFIG は、システム クラスタの kubeconfig ファイルパスです。
PROJECT は、VM が存在する GDC プロジェクトです。
省略可: 追加のステータスの詳細を取得します。
kubectl get gvm VM_NAME -n PROJECT -o \
jsonpath='{"State:"}{.status.state}{"\n"}{"Reason:"}{.status.reason}{"\n"}{"Message:"}{.status.message}{"\n"}'
VM_NAME は、応答しない VM の名前です。
VM を削除します。
kubectl --kubeconfig SYSTEM_KUBECONFIG delete gvm VM_NAME -n NAMESPACE_NAME
NAMESPACE_NAME は、Namespace の名前です。
削除が成功したことを確認します。
kubectl --kubeconfig SYSTEM_KUBECONFIG get gvm VM_NAME -n PROJECT
次のような結果が表示されれば成功です。
Error from server (NotFound): virtualmachines.vm.cluster.gke.io "VM_NAME" not found
その VM のすべてのディスクを削除します。
kubectl --kubeconfig SYSTEM_KUBECONFIG delete gdisk DISK_NAME_1 DISK_NAME_2 DISK_NAME_N -n NAMESPACE_NAME DISK_NAME_1、DISK_NAME_2、DISK_NAME_N をディスクのそれぞれの名前に置き換え、すべてのディスクが一覧表示されていることを確認します。
削除が成功したことを確認します。
kubectl --kubeconfig SYSTEM_KUBECONFIG get gdisk DISK_NAME_1 DISK_NAME_2 DISK_NAME_N -n $PROJECT
次のような結果が表示されれば成功です。
Error from server (NotFound): virtualmachinedisks.vm.cluster.gke.io "DISK_NAME_1" not found
Error from server (NotFound): virtualmachinedisks.vm.cluster.gke.io "DISK_NAME_2" not found
Error from server (NotFound): virtualmachinedisks.vm.cluster.gke.io "DISK_NAME_N" not found
VM とディスクを再作成します。
VM を再起動します。
|
| 運用 |
1.9.2 |
症状:
gdcloud system container-registry load-oci 件はエラーが発生したため保存できませんでした。コマンドを再実行すると、実行時間は異なり、プッシュや再タグ付けなどのプロセスで失敗するポイントも異なりますが、エラーは類似しています。
回避策:
この問題を解決するには、次の手順に沿って操作します。
KUBECONFIG をルート管理 kubeconfig にエクスポートします。
export KUBECONFIG=~/release/root-admin/root-admin-kubeconfig
- 次のコマンドを発行して、
deployment/root-admin-tftp-manager-controller を 0 個のレプリカにスケールバックします。
kubectl scale --replicas=0 deployment/root-admin-tftp-manager-controller -n gpc-system
- 失敗したオペレーションを実行します。
deployment/root-admin-tftp-manager-controller を 1 つのレプリカにスケールアップします。
kubectl scale --replicas=0 deployment/root-admin-tftp-manager-controller -n gpc-system
|
| 運用 |
1.9.1
1.9.2
1.9.3 |
症状:
gdcloud system container-registry load-oci 件はエラーが発生したため保存できませんでした。コマンドを再実行すると、実行時間は異なり、プッシュや再タグ付けなどのプロセスで失敗するポイントも異なりますが、エラーは類似しています。
回避策:
このメッセージは無視してかまいません。しばらくすると消えます。
|
| 運用 |
1.9.2 |
回避策:
この問題を解決するには、問題が発生している Pod を再起動します。
|
| 運用 |
1.9.0
1.9.1
1.9.2 |
症状:
サーバーの Ready 条件のステータスが「False」で、メッセージに「job server-encrypt-and-create-logical-drive-... failed with reason ... and message ...」が含まれています。失敗したジョブのログには、「Failed to connect to the host via ssh ... Permission denied (publickey).」が含まれています。
回避策:
この問題を解決するには、次の手順に沿って操作します。
ルート管理クラスタから現在の公開 SSH 認証鍵を取得します。
kubectl -n gpc-system get secret/ssh-key -ojsonpath={.data.'id_rsa\.pub'} | base64 -dキーを ironic-vars configmap に配置します。
kubectl -n gpc-system edit cm/ironic-vars 既存の IRONIC_RAMDISK_SSH_KEY を追加または置き換えます。
<SSH public key>
ironic デプロイを再起動します。
kubectl -n gpc-system rollout restart deployment/root-admin-metal3-ironic 影響を受けるサーバーごとに、次の操作を行います。
kubectl -n gpc-system annotate bmh/$SERVER inspect.metal3.io=""
|
| 運用 |
1.9.2 |
回避策:
IP アドレス不足の問題を回避するには、高可用性ユーザー クラスタの作成時に Pod CIDR のサイズを /21 以上に設定します。
|
| インストール |
1.9.2 |
回避策:
この問題を解決するには、Pod を再起動します。
詳細については、MON-R0001 ランブックをご覧ください。
|
| プラットフォーム認証 |
1.9.13 |
症状:
すべての cplb-init ジョブと storage-ipsec-config-bm-XXXXX ジョブに、Failed to connect to the host via ssh: ssh: connect to host 10.1.18.X port 22: Connection timed out というメッセージが表示されます。
回避策:
1. aggswitch で bgp vrf がダウンしているかどうかを確認します。
2. ファイアウォールで新しいステージング構成の未コミットの変更があるかどうかを確認します。
3. 名前の中に削除された組織が含まれているすべての securitypolicyrules をクリーンアップし、root-admin-controller を再起動します。
|
| アップグレード |
1.9.1
1.9.2
1.9.11 |
症状:
Server の .status.bareMetalHostStatus.provisionState が deprovisioning で 20 分以上停止しています。
アップグレードされるサーバーの管理 IP アドレスは、次のいずれかのコマンドの出力に含まれています。
kubectl -n gpc-system get cm/gpc-dhcp-conf -oyaml | grep dhcp-option=tag:mgmt,option:tftp-server
kubectl -n gpc-system get cm/gpc-dhcp-conf -oyaml | grep dhcp-option=tag:mgmt,tag:ipxe,option:bootfile-name
回避策:
この問題を解決するには、次のコマンドを実行します。
kubectl -n gpc-system rollout restart deploy/root-admin-controller
|
| アップグレード |
1.9.1
1.9.2
1.9.10
1.9.11
1.9.12
1.9.13
1.9.14
1.9.15
1.9.16
1.9.17
1.9.18 |
症状:
NodeUpgrade のアップグレード タスクが 2 時間以上完了していません。
対応する NodeUpgradeTask が条件 NodeResumeCompleted でハングし、1 時間以上終了しません。
bm-system-x.x.x.x-machine-init ジョブが長時間未完了のままになっている。x.x.x.x はノードのアドレスです。
回避策:
異常なノードのアドレスを確認するには、ハングした bm-system-x.x.x.x-machine-init ジョブの x.x.x.x をご覧ください。
異常なノードの正常なコントロール プレーンノードを見つけるには、次の手順を行います。
- 異常なノードのノードプールを見つけます。
異常なノードと同じクラスタ内のコントロール プレーン ノードプールを確認し、そのコントロール プレーン ノードプールの .spec.address からアドレスを選択します。
ブートストラップまたは OC IT で、次のコマンドを実行します。
HEALTHY_CP_NODE_IP=Y.Y.Y.Y # Needs to be entered.
alias ka="kubectl --kubeconfig=/root/release/root-admin/root-admin-kubeconfig"
HARBOR=$(ka get harborcluster harbor -n harbor-system -o=jsonpath="{.spec.externalURL}")
REGISTRY=${HARBOR#https://}
# Download `etcdctl`.
docker run --rm -v $(pwd):/workspace --workdir /workspace ${REGISTRY}/library/anthos-baremetal-release/etcd:v3.4.21-0-gke.1 /bin/sh -c "cp /usr/local/bin/etcdctl /workspace/etcdctl"
scp etcdctl "root@$HEALTHY_CP_NODE_IP:/root/etcdctl"
# SSH into the healthy control plane node.
ssh $HEALTHY_CP_NODE_IP
正常なコントロール プレーン ノード内で、次のコマンドを実行します。
UNHEALTHY_NODE_IP=X.X.X.X # Needs to be entered.
UNHEALTHY_MEMBER=$(ETCDCTL_API=3 ./etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key --endpoints=https://localhost:2379 member list | grep $UNHEALTHY_NODE_IP | cut -d',' -f1)
ETCDCTL_API=3 ./etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key --endpoints=https://localhost:2379 member remove $UNHEALTHY_MEMBER
|
| アップグレード |
1.9.1
1.9.2 |
症状:
ODS Fleet Operator Pod がクラッシュ ループしている。
Pod のステータスを確認するには、次のコマンドを実行します。
ko get pods -n ods-fleet-operator
ODS Fleet Operator ログに、次のようなリーダー選出エラーが表示されます。
E0413 18:06:48.614127 1 leaderelection.go:330] error retrieving resource lock ods-fleet-system/af0cf209.dbadmin.gdc.goog: Get "https://172.20.0.1:443/apis/coordination.k8s.io/v1/namespaces/ods-fleet-system/leases/af0cf209.dbadmin.gdc.goog": context deadline exceeded
I0413 18:06:48.614214 1 leaderelection.go:283] failed to renew lease ods-fleet-system/af0cf209.dbadmin.gdc.goog: timed out waiting for the condition
E0413 18:06:48.614460 1 main.go:473] "setup: problem running manager" err="leader election lost" log_name="l1_controller"
ODS Fleet Operator のログを確認するには、次のコマンドを実行します。
ko logs deployment/fleet-controller-manager -n ods-fleet-system
次のメッセージが表示されます。
Message: Error occurred during addon installation: failed to upgrade chart: an error occurred while rolling back the release. original upgrade error: post-upgrade hooks failed: timed out waiting for the condition: timed out waiting for the condition。
回避策:
デプロイを編集するには、次のコマンドを実行します。
ko edit deployment -n ods-fleet-system fleet-controller-manager
ku edit deployment oracle-controller-manager -n ods-oracle-system
ku edit deployment pg-controller-manager -n ods-postgres-system
manager コンテナの resources フィールドを次のように編集してください。
変更前:
resources:
limits:
cpu: 100m
memory: 512Mi
requests:
cpu: 100m
memory: 512Mi
変更後:
resources:
limits:
cpu: 1000m
memory: 1024Mi
requests:
cpu: 1000m
memory: 1024Mi
|
| アップグレード |
1.9.2
1.9.3 |
症状:
次のエラー メッセージが表示されます。
nvidia-driver-init run the action: init, with options: skip_driver
nvidia-driver-init Find the nvidia card, label this node
nvidia-driver-init node/MACHINE_NAME not labeled
nvidia-driver-init enable nvidia container runtime for ubuntu/debian system
nvidia-driver-init install nvidia container runtime package
nvidia-driver-init (Reading database ... 92144 files and directories currently installed.)
nvidia-driver-init Preparing to unpack .../libnvidia-container1_1.12.0-1_amd64.deb ...
nvidia-driver-init Unpacking libnvidia-container1:amd64 (1.12.0-1) over (1.12.0-1) ...
nvidia-driver-init Setting up libnvidia-container1:amd64 (1.12.0-1) ...
nvidia-driver-init Processing triggers for libc-bin (2.31-0ubuntu9.9) ...
nvidia-driver-init (Reading database ... 92144 files and directories currently installed.)
nvidia-driver-init Preparing to unpack .../libnvidia-container-tools_1.12.0-1_amd64.deb ...
nvidia-driver-init Unpacking libnvidia-container-tools (1.12.0-1) over (1.12.0-1) ...
nvidia-driver-init Setting up libnvidia-container-tools (1.12.0-1) ...
nvidia-driver-init dpkg: regarding .../nvidia-container-toolkit-base_1.12.0-1_amd64.deb containing nvidia-container-toolkit-base:
nvidia-driver-init nvidia-container-toolkit-base breaks nvidia-container-toolkit (<= 1.10.0-1)
nvidia-driver-init nvidia-container-toolkit (version 1.8.1-1) is present and installed.
nvidia-driver-init dpkg: error processing archive var/cache/apt/archives/nvidia-container-toolkit-base_1.12.0-1_amd64.deb (--install):
nvidia-driver-init installing nvidia-container-toolkit-base would break nvidia-container-toolkit, and
nvidia-driver-init deconfiguration is not permitted (--auto-deconfigure might help)
nvidia-driver-init Errors were encountered while processing:
nvidia-driver-init var/cache/apt/archives/nvidia-container-toolkit-base_1.12.0-1_amd64.deb
回避策:
この問題を解決するには、次の手順を行います。
プロビジョニングされたすべての GPU ノードにログインします。
# ka get servers -A | grep o1-highgpu1-48-gdc-metal
古いパッケージを削除します。
root@MACHINE_NAME:~# dpkg -r nvidia-container-runtime nvidia-container-toolkit
(Reading database ... 92154 files and directories currently installed.)
Removing nvidia-container-runtime (3.8.1-1) ...
Removing nvidia-container-toolkit (1.8.1-1) ...
スタックした kubevm-gpu-driver-daemonset Pod を削除します。これにより、インストールが再開されます。
# kug get pods -A | grep gpu | grep Init
（省略可）アドオンのインストールがタイムアウトした場合は、アドオンのインストールを再開します。
ku delete job vm-runtime-readiness -n gpu-org-system-cluster
|
| アップグレード |
1.9.10
1.9.11 |
症状:
gpcbackup-agent-0 は failed to stage volume: iSCSI login failed を示し、音量のステージングに失敗します。
Pod がボリュームの接続に失敗しているかどうかを確認します。次の例では、システム クラスタの kubeconfig を使用します。
-
Pod の説明を取得します。
kos describe pod -n gpc-backup-system gpcbackup-agent-0
Pod が失敗している場合は、次の例のような出力が表示されます。
Warning FailedMount 24m (x1064 over 7d17h) kubelet Unable to attach or mount volumes: unmounted volumes=[gpcbackup-agent-vol], unattached volumes=[kube-api-access-cr45d gpcbackup-agent-vol]: timed out waiting for the condition
Warning FailedMount 9m18s (x4109 over 7d17h) kubelet MountVolume.MountDevice failed for volume "pvc-5df41864-63c5-4589-9569-036fa011f64c" : rpc error: code = Internal desc = failed to stage volume: iSCSI login failed
Warning FailedMount 4m32s (x3840 over 7d17h) kubelet Unable to attach or mount volumes: unmounted volumes=[gpcbackup-agent-vol], unattached volumes=[gpcbackup-agent-vol kube-api-access-cr45d]: timed out waiting for the condition
-
Pod が失敗しているノードを確認します。
kos get pod -n gpc-backup-system gpcbackup-agent-0 -o wide
次のような出力が得られます。
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
gpcbackup-agent-0 0/1 ContainerCreating 0 7d17h [none] vm-e2b9792a [none] [none]
-
gpcbackup-agent-0 Pod が失敗した同じノードで netapp-trident Pod を取得します。
kos get pod -o wide -n netapp-trident
次のような出力が得られます。
netapp-trident-node-linux-6kgv4 2/2 Running 0 12h 10.249.20.12 vm-e2b9792a [none] [none]
-
gpcbackup-agent-0 Pod が失敗した同じノードで、netapp-trident Pod のログを確認します。
kos logs -n netapp-trident netapp-trident-node-linux-6kgv4 trident-main
次のような出力が得られます。
time="2024-01-25T17:35:29Z" level=error msg="Failed to discover targets" error="process killed after timeout" output= portal="172.20.131.41:3260" requestID=e377490f-5407-44ea-9691-1ee8990f8c3e requestSource=CSI
time="2024-01-25T17:35:29Z" level=error msg="unable to ensure iSCSI target exists: failed to discover targets: process killed after timeout" err="failed to discover targets: process killed after timeout" iface=default requestID=e377490f-5407-44ea-9691-1ee8990f8c3e requestSource=CSI targetIqn="iqn.1992-08.com.netapp:sn.944e1654ac1c11ee86b0d039ea524d51:vs.26" tp="172.20.131.41:3260"
time="2024-01-25T17:35:29Z" level=error msg="GRPC error: rpc error: code = Internal desc = failed to stage volume: iSCSI login failed" requestID=e377490f-5407-44ea-9691-1ee8990f8c3e requestSource=CSI
回避策:
この問題を解決するには、次の操作を行います。
-
InventoryMachine 名を取得します。
export ROOT_ADMIN_KUBECONFIG=[path to the root admin kubeconfig]
export INV_MACH=vm-e2b9792a
-
以前のジョブが存在することを確認します。
export ORG_ADMIN_KUBECONFIG=[path to the org admin kubeconfig]
kubectl --kubeconfig ${ORG_ADMIN_KUBECONFIG} get job -n gpc-system storage-ipsec-config-"${INV_MACH}"
次のような出力が得られます。
NAME COMPLETIONS DURATION AGE
storage-ipsec-config-vm-e2b9792a 1/1 17s 19d
-
ジョブを削除します。
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} delete storageencryptionconnections -n ${INV_MACH} ${INV_MACH}
次のような出力が得られます。
warning: deleting cluster-scoped resources, not scoped to the provided namespace
storageencryptionconnection.ontap.netapp.storage.private.gdc.goog "vm-e2b9792a" deleted
-
StorageEncryptionConnection が存在することを確認します。
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} get storageencryptionconnections -n ${INV_MACH} ${INV_MACH}
次のような出力が得られます。
NAME INVENTORYMACHINE STORAGEVIRTUALMACHINE STORAGECIDR PRESHAREDKEY READY AGE
vm-e2b9792a vm-e2b9792a org-1-user 172.20.131.32/27 vm-e2b9792a-pre-shared-key True 19d
-
StorageEncryptionConnection を削除します。
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} delete storageencryptionconnections -n ${INV_MACH} ${INV_MACH}
次のような出力が得られます。
warning: deleting cluster-scoped resources, not scoped to the provided namespace
storageencryptionconnection.ontap.netapp.storage.private.gdc.goog "vm-e2b9792a" deleted
-
root-admin-controller Pod を再起動します。
kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} rollout restart deploy -n gpc-system root-admin-controller && kubectl --kubeconfig ${ROOT_ADMIN_KUBECONFIG} rollout status deploy -n gpc-system root-admin-controller
-
新しいジョブが再作成され、正常に実行されたことを確認します。
kubectl --kubeconfig ${ORG_ADMIN_KUBECONFIG} get job -n gpc-system storage-ipsec-config-${INV_MACH}
次のような出力が得られます。
NAME COMPLETIONS DURATION AGE
storage-ipsec-config-vm-e2b9792a 1/1 19s 95s
|
| アップグレード |
1.9.10
1.9.11 |
症状:
Harbor レジストリ Pod に、次のようなエラー メッセージが表示されます。
Warning FailedMount 6m52s (x718 over 2d14h) kubelet Unable to attach or mount volumes: unmounted volumes=[storage], unattached volumes=[registry-config authentication-htpasswd internal-certificates sto │
│ age[]: timed out waiting for the condition
回避策:
この問題を解決するには、次の手順に従います。
-
Harbor レジストリの Persistent Volume Claim（PVC）を確認し、PVC ボリューム名をメモします。
kubectl get pvc harbor-registry -n harbor-system
-
ボリューム アタッチメントが Harbor レジストリ Pod と同じノードにあるかどうかを確認するには、volumeattachment を一覧表示し、ボリューム名に関連付けられているものを探します。
kubectl get volumeattachment | grep [volume-name]
-
ボリューム アタッチメントが Harbor レジストリ Pod とは異なるノードにある場合は、volumeattachment を削除します。
kubectl delete volumeattachment [volumeattachment-name]
-
Harbor レジストリ Pod を再起動します。
これで、ルート管理クラスタの Harbor レジストリが正常になり、ノードのアップグレードが正常に完了します。
|
| インストール |
1.9.2
1.9.3
1.9.4
1.9.5
|
症状:
次のエラー メッセージが表示されます。
pod "coredns-75bd7c95f7-fd4cr" in namespace "kube-system" is not ready yet.
Pod ログには次の情報が含まれます。
[INFO] plugin/ready: Still waiting on: "kubernetes,kubernetes"
CoreDNS のバージョンは 1.8.6 です。
回避策:
この問題を解決するには、coredns デプロイを再起動します。
KUBECONFIG が正しいクラスタに設定されたら、次のコマンドを実行します。
kubectl rollout restart deployment coredns -n kube-system
ユーザー クラスタ名はエラー メッセージに含まれています。
/root/release/user/ で kubeconfig ファイルを見つけるには、kubeconfig を見つけます。org-1-system-user-kubeconfig user-vm-1-user-kubeconfig user-vm-2-user-kubeconfig
kubeconfig ファイルがない場合は、次のように生成します。
export KUBECONFIG=/root/release/org-admin/org-1-admin-kubeconfig
kubectl get secrets -n user-vm-1-cluster user-vm-1-kubeconfig -o jsonpath='{.data.value}' | base64 -d > /tmp/user-vm-1-user-kubeconfig
|
| アップグレード |
1.9.2
1.9.3 |
症状:
次のエラー メッセージが表示されます。
Warning ReconcileBackoff 43m (x9 over 61m) OrganizationUpgrade [UPG1402: unable to set AddOn selector labels for root-admin cluster: Operation cannot be fulfilled on clusters.baremetal.cluster.gke.io "root-admin": the object has been modified; please apply your changes to the latest version and try again, UPG9900: unable to update status: OrganizationUpgrade.upgrade.private.gdc.goog "root" is invalid: [status.errorStatus.errors[0]. errorResource.name: Required value, status.errorStatus.errors[0].errorResource.namespace: Required value]]
通常、この問題は一時的なもので、解消されます。 |
| インストール |
1.9.3 |
アドオンのインストールが次のエラーで失敗します。
Error occurred during addon installation: failed to install chart: release netapp-trident failed, and has been uninstalled due to atomic being set: failed post-install: timed out waiting for the condition。
回避策:
ノードが NotReady 状態の場合、アドオンのインストールが失敗することがあります。次のコマンドを使用して、ノードが NotReady 状態かどうかを確認します。
kubectl get nodes
NotReady 状態のノードの詳細を取得します。
$ kubectl describe node | grep PodCIDRs
この問題が発生しているクラスタでは、ノードに PodCIDR が割り当てられていません。次に例を示します。
PodCIDRs:
For a healthy cluster, all the nodes should have PodCIDRs assigned to it(CIDR shown here is for example purposes only and might vary on the actual cluster based in the Configured ClusterCIDR): eg.
PodCIDRs: 192.168.6.0/24
この問題を解決するには、影響を受けるクラスタで ipam-controller Deployment を再起動します。
kubectl --kubeconfig KUBECONFIG_PATH -n kube-system rollout restart ds/ipam-controller-manager
|
| アップグレード |
1.9.3 |
アップグレードが次のエラーで失敗します。
Rollback "netapp-trident" failed: cannot patch "netapp-trident-csi-cert" with kind Certificate: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": dial tcp 172.20.5.144:443: i/o timeout && cannot patch "netapp-trident-server-cert" with kind Certificate: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded && cannot patch "netapp-trident-client-cert" with kind Certificate: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded && cannot patch "netapp-trident-csi-selfsigned-issuer" with kind Issuer: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded && cannot patch "netapp-trident-csi-issuer" with kind Issuer: Internal error occurred: failed calling webhook "webhook.cert-manager.io": failed to call webhook: Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded。
回避策:
AddOnSet abm-overrides のフィールド <code.spec.addonsettemplateref< code="" dir="ltr" translate="no"> を、アップグレードされるクラスタと同じ Namespace 内の目的のバージョンの AddOnSetTemplate の名前に手動で更新します。</code.spec.addonsettemplateref<>
|
| インストール |
1.9.3 |
症状:
フリート管理者コントローラが準備状態にならず、TestCreateFleetAdminCluster テストまたは TestSimOverlayCreateFleetAdminCluster テストに失敗します。 フリート管理コントローラがクラッシュ ループで停止している。 フリート管理コントローラのログに次のエラーが記録されます。Fleet admin controller manager stopped: failed to wait for auditloggingtarget caches to sync: timed out waiting for cache to be synced
回避策:
Logmon CRD を組織管理クラスタにデプロイします。
フリート管理コントローラを再起動します。
|
| インストール |
1.9.3 |
症状:
次のエラー メッセージが表示されます。
k8s_mt_system_cluster_healthcheck_test.go:147: system cluster did not become ready in time: cluster "org-1-system-cluster/org-1-system" did not become healthy in time: [waitingForClusterHealth] WaitForSuccess gave up [...] unable to retrieve logs for pod "anthos-prometheus-k8s-0" [...] pod "anthos-prometheus-k8s-0" in namespace "obs-system" is not ready yet. [...] Message:containers with unready status: [config-reload prometheus-server] [...]
回避策:
この問題を解決するには、クラスタ内のデプロイと DaemonSet の両方を再起動します。
kubectl rollout restart deploy/netapp-trident-csi -n netapp-trident
kubectl rollout restart daemonset/netapp-trident-csi -n netapp-trident
注: デプロイと DaemonSet を再起動する前に、次のコマンドを実行して正しいクラスタを指定します。
export KUBECONFIG=/root/release/system/org-1-system-kubeconfig
|
| アップグレード |
1.9.4
1.9.5
1.9.6
1.9.7
1.9.8 |
症状:
CPU が不足しているため、Pod をスケジュールできません。
回避策:
n2-standard-4 ワーカーノードで作成された既存のユーザー クラスタの場合は、アップグレードする前に、3 つのノードを含む新しい n2-standard-8 NodePool をこのクラスタに追加します。
新しいユーザー クラスタの場合は、3 つ以上のノードを含む 1 つの n2-standard-8 NodePool を作成します。詳細については、コンテナ ワークロード用のユーザー クラスタを作成するをご覧ください。
|
| 運用 |
1.9.0
1.9.2
1.9.3
1.9.4 |
症状:
VM インスタンス PHASE は Scheduling を示し、READY は False のままになり、True 状態になることはありません。この問題は、回避策に記載されている 2 つのマシンタイプに影響します。他のマシンタイプは影響を受けず、回避策を適用する必要はありません。
回避策:
- A100 40G GPU を使用するユーザー クラスタを作成する場合は、常に UI から a2-highgpu-1g-gdc マシンタイプを選択します。
- A100 80G GPU を使用するユーザー クラスタを作成する場合は、常に UI から a2-ultragpu-1g-gdc マシンタイプを選択します。
|
| 運用 |
1.9.0
1.9.2
1.9.3
1.9.4 |
症状:
メモリサイズが 32 GB を超える VM インスタンスを含むノードプールの場合、VM インスタンスが実行された後、停止して再度実行されることがあります。このシーケンスが繰り返されることもあります。最終的に、メモリ不足の OOMKilled エラーがスローされ、インスタンスが失敗します。
影響を受ける 3 つの VM タイプは次のとおりです。
- n2-highmem-8-gdc: 64 GB のメモリ
- a2-highgpu-1g-gdc: 85 GB のメモリ
- a2-ultragpu-1g-gdc: 170 GB のメモリ
回避策:
- マシンタイプを確認します。
kubectl --kubeconfig= get gvm vm-8c440bc4 -n gdch-vm-infra
- 次の場所で VM タイプを探します。出力に
spec.compute.virtualMachineTypeName が含まれている。
- VM タイプがリストされている 3 つのタイプのいずれかの場合は、メモリのオーバーライドを含めるように
configmap を編集します。
kubectl --kubeconfig=SYSTEM_CLUSTER_KUBECONFIG \
edit configmap NAME -n NAMESPACE
- 次の例のように、
memory.guest セクションと resources.overcommitGuestOverhead セクションを追加します。
apiVersion: v1
kind: ConfigMap
metadata:
name: vm-8c440bc4
namespace: gdch-vm-infra
data:
virtSpec: |
template:
spec:
domain:
...
...
memory:
guest: "MEMORY_SIZE"
resources:
overcommitGuestOverhead: true
...
...
memory で、guest を次の値に変更します。
- n2-highmem-8-gdc の場合は、MEMORY_SIZE を
63.6G にします。
- a2-highgpu-1g-gdc の場合は、MEMORY_SIZE を
84G にします。
- a2-ultragpu-1g-gdc の場合は、MEMORY_SIZE を
168G にします。
- 影響を受けるすべての VM に対してこの操作を繰り返します。
|
| アップグレード |
1.9.4 |
症状:
bm-system-* ジョブが Gathering Facts ステップでハングします。サーバーに手動で SSH 接続しようとすると、PTY allocation request failed on channel 0 が表示されます。
回避策:
次のいずれかの方法でサーバーを再起動します。
curl -X POST -H "content-type: application/json" -k -u $ILO_USER:$ILO_PWD https://$ILO_IP/redfish/v1/Systems/1/Actions/ComputerSystem.Reset
iLO UI kubectl --kubeconfig=$ROOT_ADMIN_KUBECONFIG annotate -n gpc-system bmh/$SERVER "reboot.metal3.io"=""
|
| アップグレード |
1.9.4
1.9.10 |
症状:
backup-ipsec-* ジョブが失敗したため、アップグレードが失敗します。
回避策:
次の手順を行います。
組織の管理クラスタの gpc-system Namespace で事前共有キーを見つけます。キーの名前は <node-name>-pre-shared-key です。
動作中のノードの pre-shared-key yaml からキーハッシュを取得するには、kubectl get --kubeconfig /root/release/org-admin/org-1-admin-kubeconfig -n gpc-system secret <not-failed-node-name>-pre-shared-key -o=jsonpath='{.data.pre-shared-key}' | awk '{ print $1 }' を使用します。
キーハッシュは、ipsec アップグレードが失敗したノード以外のノードから取得する必要があります。 この事前共有キーのハッシュを、組織管理クラスタの gpc-system の障害が発生したノードの事前共有キー シークレットに適用します。 ルート管理者クラスタで、失敗したノードと同じ名前の storageencryptionconnection オブジェクトを削除します。 組織管理クラスタで関連する storage-ipsec-config-<node-name> ジョブを削除します。 関連付けられている backup-ipsec-for-upgrade-<node-name> アップグレード ジョブを削除します。
|
| アップグレード |
1.9.4 |
症状:
組織クラスタのアップグレードに時間がかかる。
回避策:
clamav が自然にシャットダウンするまで待ちます。
|
| アップグレード |
1.9.5 |
症状:
さまざまな証明書が表示されます。
echo $(kubectl get secret harbor-cert-secret -n istio-system -o jsonpath='{.data.ca\.crt}') | openssl base64 -A -d
-----BEGIN CERTIFICATE-----
MIIBqjCCAS+gAwIBAgIQSve6hYhac9nZr/u/l/hPzjAKBggqhkjOPQQDAzAWMRQw
EgYDVQQDEwtoYXJib3ItY2VydDAeFw0yMzA3MTcwMzQ3MjhaFw0yODA3MTUwMzQ3
MjhaMBYxFDASBgNVBAMTC2hhcmJvci1jZXJ0MHYwEAYHKoZIzj0CAQYFK4EEACID
YgAEsGCynvjnSNNIdz3PxpEqvogHAITWyB3jJbA6jxQhics5MYuq2biaqLg38Ly1
3mF6CRh9Tzroxg2Wtu339McKTAC/7v61ZsbGXbj3eQiTECJut/a55BekG7FcwVG/
btbAo0IwQDAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4E
FgQUUh1ZUS9CUIHgQmJZTj8m3MIINS8wCgYIKoZIzj0EAwMDaQAwZgIxALDea5fh
IeafRNzR3pjYRgW++TCYZU3XVSJ04K8eIBy1wz1XRDR5SWFgJ/ejWZGUagIxAIQP
9A42lzd7gyqaAAlRB+TQ0sMJMOOyNl0gFg5ZVyhGdJfsZpv1XrcLcqX3tejydw==
-----END CERTIFICATE-----
echo $(kubectl get secret ca-cert-10.2.2.101.10443 -n anthos-creds -o jsonpath='{.data.ca\.crt}') | openssl base64 -A -d
-----BEGIN CERTIFICATE-----
MIIBazCCARKgAwIBAgIQKkDVSpMZf9CQEHxx7UFPmDAKBggqhkjOPQQDAjAWMRQw
EgYDVQQDEwtoYXJib3ItY2VydDAeFw0yMzA3MTYwOTQzMTlaFw0yNDA3MTUwOTQz
MTlaMBYxFDASBgNVBAMTC2hhcmJvci1jZXJ0MFkwEwYHKoZIzj0CAQYIKoZIzj0D
AQcDQgAEI4hXIh65Zc8sWaPQL9gqz3lrq22A1XJsRrMwl/pk3vZiNLGS3+Tt9tXc
WDP74IbinOxZ1Auw08e3s4sxCahfyqNCMEAwDgYDVR0PAQH/BAQDAgKkMA8GA1Ud
EwEB/wQFMAMBAf8wHQYDVR0OBBYEFN8ob6e8WeFELnVKPSdtMfyvRP95MAoGCCqG
SM49BAMCA0cAMEQCIF8P5THYBHcOdcn1u7zi+Y4jwDTdLAeaDZbVxUDEK2EaAiBW
zilvR3YvW7h5OdSUsgFkSQ42FcSIoNHWYNSZx16CeQ==
-----END CERTIFICATE-----
回避策:
注: 次の手順の前に harbor-harbor-https 証明書をローテーションします。
次の手順を行います。
クラスタ内のシークレットに証明書データのコピーが保存されています。harbor-harbor-https 証明書をローテーションしたら、シークレットのコピーも更新する必要があります。
- Artifact Registry の URL を取得します。
export registry_url=$(kubectl get harborcluster/harbor -n harbor-system -o json | jq -r '.spec.externalURL')
- 各 Namespace の Artifact Registry 証明書 Secret のコピーを更新します。
Artifact Registry 証明書シークレットのコピーを保存するすべての Namespace を取得します。
export ca_cert_secret_name=ca-cert-$(printf \"${registry_url}\" | jq -r 'ltrimstr("https://") | sub(":";".")')
export ca_cert_secret_namespaces=$(kubectl get secrets -A -o json | jq -j ".items[] | select(.metadata.name == \"${ca_cert_secret_name}\") | .metadata.namespace,\" \"")
各 Namespace で Artifact Registry 証明書 Secret のコピーを更新します。
export cert_data=$(kubectl -n istio-system get secret/harbor-harbor-https -o json | jq -r '.data."ca.crt"')
for namespace in ${ca_cert_secret_namespaces}; do kubectl patch secret/${ca_cert_secret_name} -n $namespace -p "{\"data\":{\"ca.crt\":\"${cert_data}\"}}"; done
- ルート管理クラスタの場合は、
anthos-creds Namespace の ca-cert-in-cluster-registry という名前の証明書 Secret コピーという修正も更新する必要があります。
export cert_data=$(kubectl -n istio-system get secret/harbor-harbor-https -o json | jq -r '.data."ca.crt"')
kubectl -n anthos-creds patch secret/ca-cert-in-cluster-registry -p "{\"data\":{\"ca.crt\":\"${cert_data}\"}}"
kube-system Namespace に保存されている registry-cert を更新します。
export cert_data=$(kubectl -n istio-system get secret/harbor-harbor-https -o json | jq -r '.data."ca.crt"')
kubectl -n kube-system patch secret/registry-cert -p "{\"data\":{\"registry-cert\":\"${cert_data}\"}}"
- org-admin クラスタの証明書をローテーションする場合は、root-admin クラスタに存在する証明書 Secret のコピーも更新する必要があります。
Artifact Registry 証明書 Secret のコピーを保存するすべての Namespace を取得します。
export ca_cert_secret_name=ca-cert-$(printf \"${registry_url}\" | jq -r 'ltrimstr("https://") | sub(":";".")')
export ca_cert_secret_namespaces=$(kubectl get secrets -A -o json | jq -j ".items[] | select(.metadata.name == \"${ca_cert_secret_name}\") | .metadata.namespace,\" \"")
各 Namespace で Artifact Registry 証明書 Secret のコピーを更新します。
export cert_data=$(kubectl -n istio-system get secret/harbor-harbor-https -o json | jq -r '.data."ca.crt"')
for namespace in ${ca_cert_secret_namespaces}; do kubectl patch secret/${ca_cert_secret_name} -n $namespace -p "{\"data\":{\"ca.crt\":\"${cert_data}\"}}"; done 。
|
| アップグレード |
1.10.0
1.10.1 |
症状:
OrganizationUpgrade の開始後、1 つ以上のノードで kube-apiserver Pod が実行されていません。
- アップグレードがブロックされているノードを特定します。
kubectl get po -n kube-system -l component=kube-apiserver
出力は次のようになります。
NAME READY STATUS RESTARTS AGE
kube-apiserver-ah-aa-bm01 1/1 Running 0 12h
kube-apiserver-ah-ab-bm01 1/1 Running 0 11h
kube-apiserver-ah-ac-bm01 1/1 Error 0 12h
- 更新したノードへの SSH 接続を確立します。
root@ah-ac-bm01:~# crictl ps -a | grep kube-api
コンテナのステータスが Exited と表示されます。
f1771b8aad929 bd6ed897ecfe2 17 seconds ago Exited kube-apiserver 2 8ceebaf342eb8 kube-apiserver-ah-ac-bm01
bd14d51b01c09 d0bac8239ee3a 5 minutes ago Exited
Exited Pod のログを確認します。crictl logs f1771b8aad929
出力は次のようになります。
Error: invalid argument "JobTrackingWithFinalizers=false" for "--feature-gates" flag: cannot set feature gate JobTrackingWithFinalizers to false, feature is locked to true
フラグは /etc/kubernetes/manifests/kube-apiserver.yaml ファイルで構成されます。 root@ah-ac-bm01:~# grep JobTrackingWithFinalizers /etc/kubernetes/manifests/kube-apiserver.yaml
- --feature-gates=JobTrackingWithFinalizers=false
回避策:
/etc/kubernetes/manifests/kube-apiserver.yaml ファイルからフラグを削除します。
- ファイルをバックアップします。
root@ah-ac-bm01:~# cp /etc/kubernetes/manifests/kube-apiserver.yaml ~/kube-apiserver.yaml.bak
- 次の行を削除します。
root@ah-ac-bm01:~# sed -i '/--feature-gates=JobTrackingWithFinalizers=false/d' /etc/kubernetes/manifests/kube-apiserver.yaml
- 行が削除されたことを確認します。
root@ah-ac-bm01:~# diff /etc/kubernetes/manifests/kube-apiserver.yaml ~/kube-apiserver.yaml.bak
35a36
> - --feature-gates=JobTrackingWithFinalizers=false
kube-apiserver コンテナを一覧表示します。root@ah-ac-bm01:~# crictl ps --name kube-apiserver
kubelet は変更を自動的に取得し、kube-apiserver Pod を起動します。CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID POD
e1344008dfed9 bd6ed897ecfe2 12 hours ago Running
- 影響を受けるすべてのノードで上記の手順を繰り返します。
|
| アップグレード |
1.9.2
1.9.3
1.9.3
1.9.4
1.9.5
1.9.6 |
症状:
証明書のローテーション後に、組織内の kube-state-metrics デプロイがクラッシュ ループします。この問題により、モニタリング データが失われる可能性があります。
|
| アップグレード |
1.9.6 |
症状:
アップグレード後、ワーカーノードのバランスが崩れます。
回避策:
ワーカーノードを手動でバランス調整します。
- Pod ワークロードの場合は、デプロイ内の Pod を削除します。
- VM ワークロードの場合は、コントロール プレーン GVM オブジェクトを変更せずに virt-launcher を削除します。
|
| アップグレード |
1.9.6 |
1.9.5 から 1.9.6 にアップグレードすると、GPU デバイス プラグインが起動しない可能性があります。 症状:
次のエラーが表示され、VM ランタイムの準備とアップグレード プロセスがブロックされることがあります。
Failed to initialize NVML: could not load NVML library
回避策:
- ノードで
nvidia-container-runtime が正しく構成されているかどうかを確認します。
- 問題があると思われるノードへの SSH 接続を確立します。
- Pod のリストを取得します。
crictl pods
- Pod を調べます。
crictl inspectp $pod_hash | grep runtimeOption -A1
出力がこのようになっている場合、ノードは正しく構成されています。出力がこのようにならない場合、ノードで nvidia-container-runtime が構成されていません。binary_name": "/usr/bin/nvidia-container-runtime"
nvidia-container-runtime が正しく構成されていない場合は、containerd を再起動して問題を解決します。systemctl restart containerd
|
| アップグレード |
1.9.7 |
1.9.7 にアップグレードすると、ルート管理クラスタ ノードプールのファームウェアが in process ステータスのままになります。
症状:
NodeUpgrade 側については、アーティファクト サーバーのタイムアウトの回避策をご覧ください。
NodeUpgrade が in process ステータスのままになり、Nodeupgradetask ステータスの NodeROMFirmwareUpgradeCompleted の条件が常に完了しません。NodeUpgrade オブジェクトの spec.firmware.firmwarePackages.url の URL が、たとえば次のような場合に接続できなくなることがあります。curl -k https://10.248.2.71:30938/artifacts/serve/Z2RjaC1ocGUtZmlybXdhcmUvaWxvOmlsbzU= -o /tmp/file.cow2
Harbor 側については、アーティファクト サーバーが承認されていないの回避策をご覧ください。
- アーティファクト サーバーログに、リポジトリへの不正アクセスに関連するエラー（
gdch-hpe-firmware/ilo など）が表示されることがあります。root@bootstrapper:~# kubectl --kubeconfig ${KUBECONFIG} logs -n gpc-system -l name=artifact-registry-services-artifact-server -f
artifact-server I1108 05:20:28.084320 1 artifact_server.go:171] Pulling artifact at path /artifacts/serve/Z2RjaC1ocGUtZmlybXdhcmUvaWxvOmlsbzU=
artifact-server E1108 05:20:28.159685 1 artifact_server.go:194] Error fetching image 10.249.23.11:10443/gdch-hpe-firmware/ilo:ilo5: GET https://10.249.23.11:10443/v2/gdch-hpe-firmware/ilo/manifests/ilo5: UNAUTHORIZED: unauthorized to access repository: gdch-hpe-firmware/ilo, action: pull: unauthorized to access repository: gdch-hpe-firmware/ilo, action: pull
- Harbor プロジェクトでは、
gdch-hpe-firmware の Spec.harborProjectConfig.accessLevel が private である必要があります。kubectl get --kubeconfig ${KUBECONFIG} HarborProject -n gpc-system gdch-hpe-firmware -o yaml
回避策:
|
| 下位ネットワーキング |
1.9.0 - 1.9.6 |
症状:
組織の内部ネットワークで BGP セッションがダウンしています。組織の内部 BGP ピアリング エンドポイントの 1 つのみが TORSwitchInternal オブジェクトに追加されます。
回避策:
{organization-name}-system-bgp-flat-ip-ipv4-apc AddressPoolClaim で使用されるサブネットを明示的に変更して、他の組織の類似する AddressPoolClaim リソースと重複しないようにします。
- 症状を調査します。
- 組織システム クラスタごとに、次のコマンドを実行します。
kubectl get bgpsessions -A --kubeconfig ORG_SYSTEM_KUBECONFIG
- 各
BGPSession オブジェクトの State フィールドで NotEstablished の State を確認します。後で使用できるように、関連付けられている各 NotEstablished BGPSession の LocalIP をメモしておきます。
"System cluster BGP Sessions cannot be established due to overlapping ClusterIPs" が根本原因かどうかを判断します。
- アクティブな組織ごとに、次のコマンドを実行します。
kubectl get clusterbgppeers -A --kubeconfig ORG_ADMIN_KUBECONFIG_FILE -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,CLUSTERIP:.spec.clusterIP | grep flat-ip
- 出力の
ClusterIP フィールド（3 列目）で、手順 1.b でメモした LocalIPs を検索します。出力の 3 列目のエントリと一致する LocalIP をメモしておきます。個別の組織管理クラスタが複数あり、2.a の出力に手順 1.b で説明した LocalIP が含まれている場合は、手順 3 に進みます。
- 組織のシステム クラスタに使用される重複する IP を解決します。
- 実行:
kubectl get subnetclaims -A --kubeconfig ROOT_ADMIN_KUBECONFIG -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,CIDRBLOCK:.status.ipv4SubnetStatus.cidrBlock | grep worker-node
- 3.a のクエリから返された
SubnetClaim オブジェクトの数をメモします。これは、有効な組織の数と同じである必要があります。
- 各行の Namespace（1 列目）と CIDR ブロック（3 列目）をメモします。各行の CIDR ブロックは、他のすべての行の CIDR ブロックと同じである必要があります。
- 組織ごとに、次の操作を行います。
- その組織の組織管理クラスタにある
{organization-name}-system-bgp-flat-ip-ipv4-apc AddressPoolClaim オブジェクトに移動します。
- その組織のワーカーノード アドレス プール クレームの
Start IP を計算します。これを行うには、3.c の CIDR ブロックと 3.d.i の AddressPoolClaim の Size フィールドを取得します。CIDR ブロックの最後から 2 番目の IP から Size IP をカウントダウンします。これは、最初の組織の新しい Start IP です（手順 3.d.iii で使用）。組織が追加されるたびに、前の組織の新しい Start IP から Size IP をカウントダウンします。次に例を示します。
CIDR block: 10.0.0.0/24
org-1, org-2, & org-3 AddressPoolClaim Size: 2
- New org-1 startIPAddress: 10.0.0.252
- New org-2 startIPAddress: 10.0.0.250
- New org-3 startIPAddress: 10.0.0.248
- ステップ 3.c.i の
AddressPoolClaim で、Spec フィールドに次のフィールドを追加します。staticIPRanges:
- startIPAddress: {Start IP from step 3.d.ii}
size: {Size from step 3.d.ii}
次のコマンドを使用します。`kubectl edit addresspoolclaim ADDRESS_POOL_CLAIM_NAME -n ORGANIZATION_NAME-system-cluster --kubeconfig ORGANIZATION_ADMIN_KUBECONFIG
たとえば、3.d.ii の org-1 を使用する場合、結果は次のようになります。apiVersion: system.private.gdc.goog/v1alpha1
kind: AddressPoolClaim
metadata:
name: org-1-system-bgp-flat-ip-ipv4-apc
namespace: org-1-system-cluster
...
spec:
category: InternalOverlayNetwork
...
parentReference:
name: worker-node-network-subnet
type: SubnetClaim
size: 2
staticIPRanges:
- startIPAddress: 10.0.0.252
size: 2
status:
allocatedIPRanges: ...
...
- TORSwitch ハードウェアで不要な BGP セッションを回避するためにクリーンアップします。
- 更新が必要なすべての
TORSwitchInternal リソースを一覧表示するには、次のコマンドを実行します。kubectl get torswitchinternals --kubeconfig ROOT_ADMIN_KUBECONFIG -A
- 前のコマンドの出力にリストされている
TORSwitchInternals ごとに、次のコマンドを実行します。kubectl edit torswitchinternal TOR_SWITCH_INTERNAL_NAME --kubeconfig ROOT_ADMIN_KUBECONFIG -n gpc-system
- すべての
TORSwitchInternal オブジェクトについて、ステップ 2.b の LocalIP のいずれかに等しい NeighborIP を持つ .spec.ebgpNeighbors リストからすべてのエントリを削除します。たとえば、ステップ 2.b で 2.2.2.2 の LocalIP が記録されています。以下に、クリーンアップ ステップの前後の TORSwitchInternal の例を示します。
クリーンアップ前:apiVersion: network.private.gdc.goog/v1alpha1
kind: TORSwitchInternal
metadata:
...
spec:
...
ebgpNeighbors:
- md5SecretReference: {}
neighborIP: 1.1.1.1
peerASN: 11111
updateSource:
loopbackID: ...
vrf: ...
- md5SecretReference: {}
neighborIP: 2.2.2.2
peerASN: 11111
updateSource:
loopbackID: ...
vrf: ...
l2Networks:
...
クリーンアップ後。削除された ebgpNeighbor エントリに注意してください。apiVersion: network.private.gdc.goog/v1alpha1
kind: TORSwitchInternal
metadata:
...
spec:
...
ebgpNeighbors:
- md5SecretReference: {}
neighborIP: 1.1.1.1
peerASN: 11111
updateSource:
loopbackID: ...
vrf: ...
l2Networks:
...
- ステップ 1 を実行し、すべての
BGPSession オブジェクト States が Established に戻ったことを確認して、検証します。すべての変更が物理 GDC TORSwitch 構成に反映されるまでに 10 分ほどかかることがあります。
|
| アップグレード |
1.9.7 - 1.9.21 |
アップグレード中に、ノードとオペレーティング システムのアップグレードが進行しない可能性があります。 症状:
数時間の間、ステータスが Ready, SchedulingDisabled のノードが表示されることがあります。 kubectl --kubeconfig $ROOT_ADMIN_KUBECONFIG get no
NAME STATUS ROLES AGE VERSION
aa-bm01 Ready, SchedulingDisabled control-plane 52d v1.27.4-gke.500
ab-bm01 Ready control-plane 52d v1.27.4-gke.500
ac-bm01 Ready control-plane 52d v1.27.4-gke.500
回避策:
- ランブック PLATAUTH-SSH 0001 に沿って、問題のノードの SSH 認証鍵を取得します。SSH でノードに接続したら、次のコマンドを実行します。
multipath -ll | grep fail
- 出力が次のようになる場合にのみ、次のステップに進みます。
size=1.0G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=0 status=enabled
| |- 7:0:0:7 sdad 65:208 failed faulty running
| `- 8:0:0:7 sdae 65:224 failed faulty running
`-+- policy='service-time 0' prio=0 status=enabled
|- 6:0:0:7 sdac 65:192 failed faulty running
`- 5:0:0:7 sdab 65:176 failed faulty running
- 問題を解決するには、次のコマンドを実行します。
systemctl stop multipathd
iscsiadm -m session -R
systemctl start multipathd
|
| アップグレード |
1.9.8-1.9.21 |
症状:
ABM クラスタのアップグレードが 2 時間以上停止している場合は、ノードのドレインがブロックされている可能性があります。
回避策:
次のオペレーションでは、ルート管理クラスタを例として使用します。${TARGET_KUBECONFIG} は、ノードのドレインがブロックされているターゲット ABM クラスタの `kubeconfig` を指します。${KUBECONFIG} は、ターゲット ABM クラスタを管理するクラスタの kubeconfig を指します。ルート管理クラスタの場合、どちらもルート管理 kubeconfig を参照します。
ABM クラスタのアップグレードが停止しているかどうかを確認する手順は次のとおりです。
- ドレインで停止しているノードを確認します。
kubectl --kubeconfig=${KUBECONFIG} get cluster -n root root-admin -ojsonpath={.status.controlPlaneNodePoolStatus.nodesDraining}; echo
結果は次のようになります。 {"10.200.0.2": 2}
これは、ノード「10.200.0.2」で 2 つの Pod がドレインされていることを意味します。
- Pod がノード（
${NODE_BEING_DRAINED}）から引き続きドレインされているかどうかを確認します。kubectl --kubeconfig=${KUBECONFIG} get baremetalmachine -n root ${NODE_BEING_DRAINED:?} -ojsonpath='{range .status.bareMetalMachineDrainingStatus.podsYetToDrain[?(@.kind=="Pod")]}{@.namespace}{", "}{@.name}{"\n"}{end}'
出力 Pod の数は、前のステップで報告されたドレイン中の Pod の数と同じである必要があります。
ステップ 1 でリストされた各 Pod yetToDrain について、Pod のステータスを確認します。kubectl --kubeconfig=${TARGET_KUBECONFIG} get pods -n ${POD_NAMESPACE} ${POD_NAME} -o wide
Pod が Running 状態の場合、または Pod が obs-system Namespace の audit-logs-loki-0 または loki-0 で、Pod に unable to unmount volume を示すイベントがない場合は、grace-period を使用して Pod を明示的に削除します。 kubectl --kubeconfig=${TARGET_KUBECONFIG} delete pods --grace-period=30 -n ${POD_NAMESPACE} ${POD_NAME}
- Pod がドレインされたままになっているその他のすべてのケースについては、オンコール サービスにエスカレーションします。
- ノードのドレインが完了したことをモニタリングします。
- 他のノードがドレインで停止している場合は、手順 1 を繰り返します。
|
| アップグレード |
1.9.6
1.9.7
1.9.8
|
署名付きアーティファクトを含む 1.9 リリースは、DistributionPolicy の Override フラグが false に設定されているため、配布できません。これにより、宛先レジストリに同じ名前のアーティファクトがある場合に配布できなくなります。
症状:
次の問題が発生することがあります。
- 署名付きのアーティファクトが push されます。ログは次のようになります。
pushing the manifest of artifact library/private-cloud-staging/goharbor/harbor-core:sha256-755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a.sig
- アーティファクトを push できませんでした。ログは次のようになります。
failed to push manifest of artifact library/private-cloud-staging/goharbor/harbor-core:sha256-755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a.sig
- 404 アーティファクトが見つかりません。ログは次のようになります。
http status code: 404, body: {"errors":[{"code":"NOT_FOUND","message":"artifact library/private-cloud-staging/goharbor/harbor-core@sha256:755d062eb3b310fa7f1dd0505a8047f1fc91864b04fdfc5c6bd173da8ce8b87a not found"}]}
- アーティファクトの配布に失敗します。
回避策:
この問題を解決するには、次の手順に沿って操作します。
DistributionPolicy カスタム リソース（CR）を更新して、Spec.Override を true に設定します。- SAR-1005 ランブックに沿ってレプリケーションを再トリガーします。
- 新しいレプリケーション実行が成功したら、成功した実行 ID で
Annotation の ManualDistribution CR execution-ids を更新します。
|
| ハードウェア セキュリティ モジュール（HSM） |
1.9.9 |
HSM が ServicesNotStarted を断続的に報告することがあります。これにより、ベアメタル サーバーが正常な状態にならず、次のメッセージが報告されることがあります。
"message": "failed to get master key name"
症状:
次の問題が発生することがあります。
回避策:
この問題を解決するには、次の手順に沿って、スタックした HSM を再起動します。
- 次のコマンドを実行して、最初の HSM から
kstl ツールをインストールします。export HSM_NAME=`kubectl get hsm \
-n gpc-system -o jsonpath={.items[0].metadata.name} | tr -d '"'`
export HSM_MGMT_IP=$(kubectl get hsm $HSM_NAME \
--namespace gpc-system \
--output jsonpath="{.spec.managementNetwork.ip}")
curl --insecure \
https://$HSM_MGMT_IP/downloads/ksctl_images.zip \
--output ksctl_images.zip
mkdir -p ~/bin
unzip ksctl_images.zip -d ~/bin
cp ~/bin/ksctl-linux-amd64 ~/bin/ksctl
export PATH=$PATH:~/bin
mkdir -p $HOME/.ksctl
export ADMIN_SECRET_NAME=`kubectl get secrets -n hsm-system -o json | jq .items[].metadata.name | tr -d '"' | grep "admin" | grep -v "luna-admin" | grep -v "ksadmin"`
export ADMIN_PW=$(kubectl get secrets $ADMIN_SECRET_NAME -n hsm-system -o jsonpath="{.data.password}" | base64 -d)
export ADMIN_SSH_SECRET_NAME=`kubectl get secrets -n hsm-system -o json | jq .items[].metadata.name | tr -d '"' | grep "ssh"`
kubectl get secret $ADMIN_SSH_SECRET_NAME \
--namespace=hsm-system \
--output jsonpath='{.data.ssh-privatekey}' \
| base64 --decode > $HOME/.ksctl/ssh-privatekey
chmod 0600 $HOME/.ksctl/ssh-privatekey
cat << EOF > $HOME/.ksctl/config.yaml
KSCTL_URL: https://$HSM_MGMT_IP:443
KSCTL_USERNAME: admin
KSCTL_PASSWORD: '$ADMIN_PW'
KSCTL_NOSSLVERIFY: true
EOF
- HSM の再起動に問題があることを確認します。
ServicesNotStarted で停止している各 HSM について、$HSM_MGMT_IP を取得し、サービスが停止していることを確認します。ksctl services status --url=https://$HSM_MGMT_IP
- すべての HSM、HSM クラスタ、HSM テナントを一時停止します。
kubectl annotate hsm --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused=true
kubectl annotate hsmcluster --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused=true
kubectl annotate hsmtenant --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused=true
- サービスが停止している状態で HSM への SSH 接続を確立します。
ssh -i $HOME/.ksctl/ssh-privatekey ksadmin@$HSM_MGMT_IP
- 正しい HSM にいることを確認します。正しい
$HSM_MGMT_IP で SSH 接続を確立したかどうかを確認します。
- HSM 内から最初の HSM を再起動します。
ksadmin@ciphertrust:~ sudo reboot
- 最初の HSM が HSM の外部から正常になるまで待ちます。
watch -c ksctl services status --url=https://$HSM_MGMT_IP
このステップでは、HSM の再起動に 5 分ほどかかることがあります。
- サービスが停止している他の HSM について、これらの手順を繰り返します。
- HSM、HSM クラスタ、HSM テナントのポーズを解除します。
kubectl annotate hsm --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused-
kubectl annotate hsmcluster --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused-
kubectl annotate hsmtenant --all \
--namespace=gpc-system \
hsm.security.private.gdc.goog/paused-
- すべてが調整されていることを確認します。HSM の調整には 5 ～ 10 分ほどかかることがあります。
|
| モニタリング |
1.9.0
1.9.1
1.9.2
1.9.3
1.9.4
1.9.5
1.9.6
1.9.7
1.9.8
1.9.9 |
症状:
GDC バージョン 1.11.3 より前の組織システム クラスタでは、alertmanager-servicenow-webhook アラートが ServiceNow に届きません。ログにエラー メッセージ read: connection reset by peer が含まれています。この問題は、下り（外向き）トラフィックを有効にするラベルがないことが原因で発生します。Webhook が組織間で通信する必要がある場合は、下り（外向き）NAT を使用する必要があります。
回避策:
組織のシステム クラスタで alertmanager-servicenow-webhook の下り（外向き）トラフィックを有効にする必要があります。この問題を解決するには、次の手順に沿って操作します。
- 必要な前提条件を設定します。
- gdcloud コマンドライン インターフェース（CLI）をインストールします。
- ルート管理クラスタと組織管理クラスタの kubeconfig ファイルのパスを取得します。パスをそれぞれ
ROOT_KUBECONFIG 環境変数と ORG_SYSTEM_KUBECONFIG 環境変数に保存します。
- セキュリティ管理者に、ルート管理者クラスタと組織管理者クラスタの両方の
obs-system 名前空間でオブザーバビリティ管理者（observability-admin）ロールを付与するよう依頼します。
- 環境で問題が発生していることを確認します。
alertmanager-servicenow-webhook デプロイを取得します。
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" get deployment alertmanager-servicenow-webhook -n obs-system
alertmanager-servicenow-webhook デプロイのログを表示します。
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" logs deployment/alertmanager-servicenow-webhook -n obs-system
ログにエラー メッセージ read: connection reset by peer が含まれている場合は、問題が存在するため、この回避策の手順を続行する必要があります。
- 下り（外向き）ラベルを追加します。
- 現在の
alertmanager-servicenow-webhook Deployment の YAML ファイルを取得します。
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" get deployment alertmanager-servicenow-webhook -o yaml \
-n obs-system > $HOME/alertmanager-servicenow-webhook-existing-deployment.yaml && \
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" get deployment alertmanager-servicenow-webhook -o yaml \
-n obs-system > $HOME/alertmanager-servicenow-webhook-new-deployment.yaml
- 下り（外向き）ラベルを
alertmanager-servicenow-webhook Deployment の YAML ファイルに追加します。
yq e -i '.spec.template.metadata.labels += {"egress.networking.gke.io/enabled": "true"}' $HOME/alertmanager-servicenow-webhook-new-deployment.yaml
alertmanager-servicenow-webhook デプロイ YAML ファイルを更新に置き換えます。
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" replace -f \
$HOME/alertmanager-servicenow-webhook-new-deployment.yaml -n obs-system
デプロイは自動的に再起動する必要があります。
- 環境で問題が存在することを確認するの手順をもう一度実行して、問題が解決したことを確認します。ログのエラー メッセージは表示されません。それ以外の場合は、エンジニアリング チームにエスカレーションします。
ロールバック戦略:
回避策の手順が失敗した場合や、指標の損失が見られる場合は、alertmanager-servicenow-webhook デプロイ YAML ファイルを元の状態に戻します。
kubectl --kubeconfig "${ORG_SYSTEM_KUBECONFIG:?}" replace -f \
$HOME/alertmanager-servicenow-webhook-existing-deployment.yaml -n obs-system
|
| アップグレード |
1.9.10 |
症状:
アップグレードが NodeMaintain のステップで停止しています。 gpc-system org-1-admin-control-plane-node-poolphdzg 1 in-progress 3h58m
Status: Tasks:
Name: zp-aa-bm06 Task Status: finished
Name: zp-aa-bm04
Task Status: finished
Name: zp-aa-bm05
Task Status: in-progress
Upgrade Status: in-progress
Events: none
進行中のノードプールの nodeupgradetask には、次の内容が表示されます。 Status: Conditions: Last Transition Time: 2023-11-09T18:26:31Z
Message:
Observed Generation:1
Reason: Succeeded
Status: True
Type: PreUpgradeValidationCompleted
Last Transition Time: 2023-11-09T18:26:31Z
Message:
Observed Generation:1
Reason: InProgress
Status: False
Type: NodeMaintainCompleted
Last Transition Time: 2023-11-09T18:26:31Z
Message: Observed Generation:1
Reason: Reconciling
Status: Unknown
Type: Succeeded
│ Data IP:10.249.20.4 bm-5f3d1782
│ Start Time: 2023-11-09T18:26:31Z
│ Events: none
回避策:
次の手順を行います。
- cap-controller-manager Deployment の名前を取得します。
kubectl --kubeconfig ${KUBECONFIG} get deployment -n kube-system | grep cap-controller-manager
cap-controller-manager-1.28.0-gke.435 1/1 1 1 30h
- cap-controller-manager の名前（例: cap-controller-manager-1.28.0-gke.435）を指定します。
export CAP_DEPLOYMENT_NAME=
- cap-controller-manager を再起動します。
kubectl --kubeconfig ${KUBECONFIG} rollout restart deployment ${CAP_DEPLOYMENT_NAME} -n kube-system
deployment.apps/cap-controller-manager-1.28.0-gke.435 restarted
|
| アップグレード |
1.9.10 |
症状:
アップグレードが AdminClusterHealth ポストフライト チェック ステップで停止しています。 Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning ReconcileBackoff 70s (x33 over 4h16m) OrganizationUpgrade admin cluster is not ready for org root
組織オブジェクトには次の情報が表示されます。 NAMESPACE NAME READY
gpc-system org-1 True
gpc-system root False
回避策:
次の手順を行います。
次のコマンドを使用して、事前チェックをスキップします。
kubectl delete organizationupgrade name -n gpc-system && kubectl annotate -n gpc-system organization name upgrade.private.gdc.goog/skip-preflight-check=ok
|
| アップグレード |
1.9.9 |
症状:
NodeUpgradeTask には、タスクの完了をブロックする failed to monitor failover registry recreation: failed to monitor job: job not complete 条件が含まれている場合があります。
回避策:
この問題を解決するには、ジョブを再起動します。
- 完了が「0/1」の
create-failover-registry-*** という名前のジョブを削除します。
- アップグレードする Server オブジェクトからアノテーション
failover-registry-creation-job-name を削除します。
コントローラがジョブを自動的に再作成します。
|
| アップグレード |
1.9.20 |
症状:
ノードは backup-ipsec-for-upgrade-bm ジョブで失敗します。 I0512 01:05:55.949814 7 main.go:24] BuildDate: 2023-04-01T15:48:57Z
I0512 01:05:55.949920 7 main.go:25] Version: 1.9.2-gdch.135.dirty
"
回避策:
`backup-ipsec-for-upgrade-bm` ジョブを削除し、再作成されるまで待ちます。
|
| Google Distributed Cloud |
1.9.9 |
症状:
etcd クラスタの起動に失敗したため、コントロール プレーン ノードプールが準備完了になりません。次の問題が発生することがあります。
--- FAIL: TestPlan (27563.26s)
--- FAIL: TestPlan/TestMTSystemClusterHealth (3445.24s)
k8s_mt_system_cluster_healthcheck_test.go:149: FATAL FLAKE: TestMTSystemClusterHealth: system cluster did not become ready in time: NodePool org-1-system-cluster/control-plane-node-pool didn't get ready: NodePool "control-plane-node-pool" is not ready
Error Routing:
{
"Name": "NODEPOOL_NOT_READY_ERR",
"Description": "NodePool is not ready",
"OwnerTeam": "Cluster Management",
"OwnerLDAP": "",
"TrackingBug""
}
FAIL
回避策:
この問題を解決するには、次の手順に沿って操作します。
- クラスタの作成がマシン初期化ジョブで停止しているかどうかを確認します。
kubeadm join タスクが失敗しました。理由は次のとおりです。error execution phase control-plane-join/etcd: error creating local etcd static pod manifest file: etcdserver: re-configuration failed due to not enough started members
次の理由で kubeadm reset タスクが失敗しました。panic: runtime error: invalid memory address or nil pointer dereference
- SSH を使用して、機能しているコントロール パネル ノードに接続します。
etcdctl コマンドを実行して、古いデータをクリーンアップします。etcd メンバーシップを確認します。# etcdctl --key=/etc/kubernetes/pki/etcd/peer.key --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/peer.crt member list
5feb7ac839625038, started, vm-72fed95a, https://10.252.164.11:2380, https://10.252.164.11:2379, false
99f09f145a74cb15, started, vm-8a5bc966, https://10.252.164.12:2380, https://10.252.164.12:2379, false
bd1949bcb70e2cb5, unstarted, , https://10.252.164.10:2380, , false
- 廃止されたメンバーシップを削除します。
# etcdctl --key=/etc/kubernetes/pki/etcd/peer.key --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/peer.crt member remove bd1949bcb70e2cb5
Member bd1949bcb70e2cb5 removed from cluster 9d70e2a69debf2f
|
| VM のバックアップと復元 |
1.9.0
1.9.1
1.9.2
1.9.3
1.9.4
1.9.5
1.9.6
1.9.7
1.9.8
1.9.9
1.9.10
1.9.11 |
症状:
VM マネージャーのロールベース アクセス制御（RBAC）とスキーマ設定が正しくないため、ユーザーが VM のバックアップと復元のプロセスを開始できません。
VM バックアップ プランの名前は 63 文字を超えることはできません。たとえば、次のようなエラー メッセージが表示されることがあります。 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.9.9 |
症状:
アップグレードでバックアップ ipsec ジョブが失敗し、次のテンプレート エラーが発生します。
"msg": "An unhandled exception occurred while templating '{'changed': True, 'stdout': 'connections {\\n # A connection id defined for this specific connection\\n pol_client {\\n children {\\n pol_cli
回避策:
次の手順を行います。
アップグレード タスクが失敗したノードにログインします。 swanctl.conf をバックアップとして保存します。
/etc/swanctl/swanctl.conf ファイルで、中かっこを含む行を削除します。
失敗した backup-ipsec-for-upgrade ジョブを削除して再作成されるまで待つと、後続のジョブが正常に完了します。 ステップ 3 で削除した行を /etc/swanctl/swanctl.conf に追加し直します。
|
| ノード プラットフォーム |
1.9.6
1.9.7
1.9.8
1.9.9 |
ルート管理クラスタでファームウェアのアップグレードが開始されると、ノードのアップグレードが完了したノードの 1 つがスタックしたように見えます。 症状:
nodeupgradetask が NodeResumeCompleted ステージで停止しています。machine-init ジョブが失敗し、ログに kubeadm join が失敗したことが示されます。- データプレーン IP アドレスを使用してノードへの SSH 接続を確立することはできません。
この問題は、アップグレードされたノードが受信ネットワーク トラフィックを受け入れなくなったことが原因で発生します。
回避策:
- 失敗した
job/nodeupgradetask ログを調べて、IP アドレスをメモし、どのノードに問題があるかを確認します。
- 影響を受けるノードの
anetd-client Pod を再起動します。
- 影響を受けるノードのデータプレーン IP で SSH 接続を確認します。
追加調査の省略可能な手順:
- 動作している anetd Pod のいずれかの cilium エージェント コンテナにシェルで接続します。
- cilium-bugtool を発行し、約 10 秒待ちます。ツールはログを
/var/log/network/policy_action.log ディレクトリに保存します。
deny を探して、トラフィックが拒否されているかどうかを確認します。grep -r "deny" /var/log/network/ to
拒否されているサーバー（ルート管理者ベアメタル ノードなど）をメモします。 |
| アップグレード |
1.9.13
1.9.14
1.9.15
1.9.16
1.9.17
1.9.18
1.9.19 |
症状:
|
| アップグレード |
1.9.13
1.9.14
1.9.15
1.9.16
1.9.17
1.9.18
1.9.19 |
症状:
- 1.9.12 から 1.9.13 にアップグレードする際に、テナント組織のベアメタルでノード OS のアップグレードが失敗します。次のメッセージが表示されます。
Reason: Succeeded
Status: True
Type: NodeMaintainCompleted
Last Transition Time: 2024-05-06T18:25:20Z
Message: the ssh cert rotation job is still in progress
Observed Generation: 1
Reason: ReconcileBackoff
Status: Unknown
Type: Succeeded
Last Transition Time: 2024-05-06T18:27:42Z
-
SSH generation fails. The following message appears:
"tasks": [
{
"hosts": {
"10.248.4.72": {
"action": "gather_facts",
"changed": false,
"msg": "Failed to connect to the host via ssh: Certificate invalid: name is not a listed principal\r\nHost key verification failed
.",
"unreachable": true
}
},
"task": {
"duration": {
"end": "2024-05-06T19:47:11.284055Z",
"start": "2024-05-06T19:47:11.146536Z"
},
"id": "98f2b32d-e15c-fe27-2225-00000000001c",
"name": "Gathering Facts"
}
} ]
回避策:
- ルート管理者と組織管理者サーバーの CR で
cluster.private.gdc.goog/ssh-trusted-ca-versions アノテーションを削除します。
- 失敗した Ansible ジョブを削除します。サーバー CR で
cluster.private.gdc.goog/host-key-rotation-in-progress アノテーションが true に設定されているため、新しいジョブが自動的に作成されます。
- ローテーション後、
cluster.private.gdc.goog/ssh-trusted-ca-versions アノテーションがサーバー CR に追加されます。
|
| ノード、アップグレード |
1.9.* |
症状:
アップグレード後、一部のベアメタル ノードの Pod が CrashLoopBackOff 状態になり、ノードの iptables -L -v -n | grep CILIUM が空の結果を返します。
回避策:
この問題を解決するには、次の操作を行います。
crictl pods --name anetd -o json | jq --raw-output '.items[].id' | xargs crictl rmp --force コマンドを実行します。iptables -L -v -n | grep CILIUM を再度実行し、出力があることを確認します。
|
| ロギング |
1.9.14
1.9.15 |
症状:
audit-logs-loki-0 Pod が CrashLoopBackOff 状態になっています。
Pod のステータスを確認します。
kubectl --kubeconfig $SYSTEM_KUBECONFIG get pod -n obs-system audit-logs-loki-0
ここで、SYSTEM_KUBECONFIG は kubeconfig ファイルのパスです。
Loki エラーは次の出力のように表示されます。ここで、CrashLoopBackOff はステータスです。
NAME READY STATUS RESTARTS AGE
audit-logs-loki-0 1/2 CrashLoopBackOff 9 (4m6s ago) 25m
回避策:
この問題を解決するには、次の操作を行います。
- kubeconfig ファイルのパスを
SYSTEM_KUBECONFIG という環境変数にエクスポートします。
- Logmon オペレーターをスケールダウンします。
kubectl scale deployment -n obs-system logmon-operator --replicas 0
- Loki リソースをスケールダウンします。
kubectl scale loki -n obs-system --replicas 0
kubectl scale statefulset audit-logs-loki -n obs-system --replicas 0
audit-logs-loki-storage-audit-logs-loki-0 と loki-storage-loki-0 の PersistentVolumeClaim（PVC）を削除します。obs-system/loki-storage-loki-0 と obs-system/audit-logs-loki-storage-audit-logs-loki-0 の永続ボリューム（PV）を削除します。- Logmon オペレーターをスケールアップします。
kubectl scale deployment -n obs-system logmon-operator --replicas 1
- 手順に沿って、バージョン 1.9 からロギング構成を更新します。
audit-logs-loki-0 Pod が実行されていることを確認します。 kubectl --kubeconfig $SYSTEM_KUBECONFIG get pod -n obs-system audit-logs-loki-0
Running のステータスは、次の例のように出力に表示される必要があります。
NAME READY STATUS RESTARTS AGE
audit-logs-loki-0 2/2 Running 0 15h
|
| Infrastructure as code |
1.9.16 |
症状:
1.9.16 にアップグレードすると、Gitlab アドオンのインストールが失敗します。次のようなエラーが表示されることがあります。
Error occurred during addon installation: failed to upgrade chart: an error occurred while rolling back the release. original upgr │
│ ade error: timed out waiting for the condition: deployments/gitlab-sidekiq-all-in-1-v2: release gitlab failed: client rate limiter Wait returned an error: ra │
│ te: Wait(n=1) would exceed context deadline
postgres Pod（gpc-system/gitlab-postgresql-0 など）が終了状態になっています。
回避策:
- 終了状態のままになっている postgres Pod を強制的に削除します。
kubectl delete pod POD_NAME --grace-period=0 --force --namespace NAMESPACE
- 削除後に postgres Pod が再作成されることを確認します。
|
| ID とアクセスの管理 |
1.9.19
1.9.20 |
症状:
1.9.18 からアップグレードして GDC コンソールにアクセスしようとすると、次のメッセージが表示されることがあります。
Authentication failed, please contact your system administrator
回避策:
- 必要な CA を取得します。
export KUBECONFIG=ORG_ADMIN_KUBECONFIG
kubectl get secret fakeoidcprovider-https -n istio-system -o jsonpath='{.data.ca\.crt}'
- クライアント構成ファイルを編集用に開きます。
kubectl edit clientconfig -n kube-public default
- クライアント構成で
certificateAuthorityData を見つけ、次のパスを使用して必要な CA を更新します。spec > authentication > (fake-oidc-provider) > oidc > certificateAuthorityData
|
