このドキュメントでは、ストレージの問題についてのトラブルシューティングについて説明します。
さらにサポートが必要な場合は、Cloud カスタマーケアにお問い合わせください。Volume を接続できない
この問題は、仮想ディスクが誤った仮想マシンに接続されている場合に、Kubernetes 1.12 の問題 #32727 が原因で発生することがあります。
gkectl diagnose cluster
の出力は、次の例のようになります。
Checking cluster object...PASS
Checking machine objects...PASS
Checking control plane pods...PASS
Checking gke-connect pods...PASS
Checking kube-system pods...PASS
Checking gke-system pods...PASS
Checking storage...FAIL
PersistentVolume pvc-776459c3-d350-11e9-9db8-e297f465bc84: virtual disk "[datastore_nfs] kubevols/kubernetes-dynamic-pvc-776459c3-d350-11e9-9db8-e297f465bc84.vmdk" IS attached to machine "gsl-test-user-9b46dbf9b-9wdj7" but IS NOT listed in the Node.Status
1 storage errors
この例では、1 つ以上の Pod が ContainerCreating
状態で停止し、次の出力例のような警告が表示されます。
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedAttachVolume 6s (x6 over 31s) attachdetach-controller AttachVolume.Attach failed for volume "pvc-776459c3-d350-11e9-9db8-e297f465bc84" : Failed to add disk 'scsi0:6'.
仮想ディスクが誤った仮想マシンにアタッチされている場合は、次の手順を使用して手動で接続解除できます。
ノードをドレインする。必要に応じて、kubectl drain コマンドで
--ignore-daemonsets
フラグと--delete-local-data
フラグを指定することもできます。vCenter で VM のハードウェア構成を編集し、Volume を削除します。
Volume が失われる
この問題は、仮想ディスクが完全に削除された場合に発生することがあります。この状況は、オペレーターが仮想ディスクを手動で削除した場合、またはディスクがアタッチされている VM を削除した場合に発生する可能性があります。
VMDK ファイルに関して「見つかりません」というエラーが表示される場合は、仮想ディスクが完全に削除されている可能性があります。
gkectl diagnose cluster
の出力は次の出力のようになります。
Checking cluster object...PASS
Checking machine objects...PASS
Checking control plane pods...PASS
Checking gke-connect pods...PASS
Checking kube-system pods...PASS
Checking gke-system pods...PASS
Checking storage...FAIL
PersistentVolume pvc-52161704-d350-11e9-9db8-e297f465bc84: virtual disk "[datastore_nfs] kubevols/kubernetes-dynamic-pvc-52161704-d350-11e9-9db8-e297f465bc84.vmdk" IS NOT found
1 storage errors
次の出力例に示すように、1 つ以上の Pod が ContainerCreating
状態で停止しています。
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedAttachVolume 71s (x28 over 42m) attachdetach-controller AttachVolume.Attach failed for volume "pvc-52161704-d350-11e9-9db8-e297f465bc84" : File []/vmfs/volumes/43416d29-03095e58/kubevols/
kubernetes-dynamic-pvc-52161704-d350-11e9-9db8-e297f465bc84.vmdk was not found
この問題の発生を回避するには、ユーザー クラスタのサイズ変更とクラスタのアップグレードの説明に従って仮想マシンを管理します。
この問題を解決するには、関連する Kubernetes リソースを手動でクリーンアップします。
kubectl delete pvc [PVC_NAME]
を実行して、PV を参照している PVC を削除します。kubectl delete pod [POD_NAME]
を実行して、PVC を参照している Pod を削除します。Kubernetes の問題 #74374 のため、手順 2 を繰り返します。
vSphere CSI Volume の切断に失敗する
この問題は、vSphere ユーザーに CNS > Searchable
権限が付与されていない場合に発生します。
ContainerCreating
フェーズで Pod が停止し、FailedAttachVolume
の警告が表示された場合は、別のノードにおける切断時の障害の発生が原因であることが考えられます。
CSI の切断のエラーを確認するには、次のコマンドを実行します。
kubectl get volumeattachments -o=custom-columns=NAME:metadata.name,DETACH_ERROR:status.detachError.message
出力は次のようになります。
NAME DETACH_ERROR
csi-0e80d9be14dc09a49e1997cc17fc69dd8ce58254bd48d0d8e26a554d930a91e5 rpc error: code = Internal desc = QueryVolume failed for volumeID: "57549b5d-0ad3-48a9-aeca-42e64a773469". ServerFaultCode: NoPermission
csi-164d56e3286e954befdf0f5a82d59031dbfd50709c927a0e6ccf21d1fa60192d <none>
csi-8d9c3d0439f413fa9e176c63f5cc92bd67a33a1b76919d42c20347d52c57435c <none>
csi-e40d65005bc64c45735e91d7f7e54b2481a2bd41f5df7cc219a2c03608e8e7a8 <none>
この問題を解決するには、vCenter ユーザー アカウントに CNS > Searchable
権限を追加します。切断オペレーションは、成功するまで自動的に再試行されます。
vSphere CSI ドライバは ESXi ホストではサポートされていない
この問題は、vSphere クラスタ内の ESXi ホストで、ESXi 6.7U3 より前のバージョンが実行されている場合に発生します。
gkectl check-config
の出力には、次の警告が含まれます。
The vSphere CSI driver is not supported on current ESXi host versions.
CSI requires ESXi 6.7U3 or above. See logs for ESXi version details.
この問題を解決するには、ESXi ホストをバージョン 6.7U3 以降にアップグレードしてください。
CSI ボリュームの作成が NotSupported
エラーで失敗する
この問題は、vSphere クラスタ内の ESXi ホストで、ESXi 6.7U3 より前のバージョンが実行されている場合に発生します。
kubectl describe pvc
の出力には、次のエラーが含まれます。
Failed to provision volume with StorageClass <standard-rwo>: rpc error:
code = Internal desc = Failed to create volume. Error: CnsFault error:
CNS: Failed to create disk.:Fault cause: vmodl.fault.NotSupported
この問題を解決するには、ESXi ホストをバージョン 6.7U3 以降にアップグレードしてください。
vSphere CSI ボリュームを接続できない
オープンソースの vSphere CSI ドライバのKubernetes の既知の問題 は、ノードがシャットダウンされたか、削除されたか、または障害が発生したときに発生します。
kubectl describe pod
の出力が次のようになります。
Events:
Type Reason From Message
---- ------ ... ---- -------
Warning FailedAttachVolume ... attachdetach-controller Multi-Attach error for volume
"pvc-xxxxx"
Volume is already exclusively attached to one
node and can't be attached to another
この問題を解決するには、次の操作を行います。
上の出力の PersistentVolumeClaim(PVC)の名前をメモし、PVC に関連付けられた VolumeAttachments を見つけます。
kubectl get volumeattachments | grep pvc-xxxxx
次の出力例は、VolumeAttachments の名前を示しています。
csi-yyyyy csi.vsphere.vmware.com pvc-xxxxx node-zzzzz ...
VolumeAttachments を記述します。
kubectl describe volumeattachments csi-yyyyy | grep "Deletion Timestamp"
次の出力例のように、削除のタイムスタンプをメモします。
Deletion Timestamp: 2021-03-10T22:14:58Z
削除タイムスタンプで指定された時間まで待機してから、VolumeAttachments を強制的に削除します。これを行うには、VolumeAttachments オブジェクトを編集し、ファイナライザを削除します。
kubectl edit volumeattachment csi-yyyyy
ファイナライザを削除します。
[...] Finalizers: external-attacher/csi-vsphere-vmware-com
バージョンが原因で vSphere CSI VolumeSnapshot の準備ができていない
この問題は、vCenter Server または ESXi ホストのバージョンが 7.0 Update 3 より低い場合に発生します。
kubectl describe volumesnapshot
の出力には、次のようなエラーが含まれます。
rpc error: code = Unimplemented desc = VC version does not support snapshot operations.
この問題を解決するには、vCenter Server と ESXi ホストをバージョン 7.0 Update 3 以降にアップグレードします。
vSphere CSI VolumeSnapshot の準備ができていない、ボリュームあたりの最大スナップショット
この問題は、ボリュームあたりのスナップショットの数が、vSphere Container Storage ドライバの最大値に達した場合に発生します。デフォルト値は 3 です。
kubectl describe volumesnapshot
の出力には、次の例のようなエラーが含まれます。
rpc error: code = FailedPrecondition desc = the number of snapshots on the source volume 5394aac1-bc0a-44e2-a519-1a46b187af7b reaches the configured maximum (3)
この問題を解決するには、次の手順に沿ってボリュームあたりのスナップショットの最大数を更新します。
vSphere の構成を vSphere CSI コントローラに提供する Secret の名前を取得します。
kubectl --kubeconfig <var class="edit">ADMIN_CLUSTER_KUBECONFIG</var> get deployment vsphere-csi-controller \ --namespace <var class="edit">USER_CLUSTER_NAME</var> \ --output json \ | jq -r '.spec.template.spec.volumes[] \ | select(.name=="vsphere-secret") .secret.secretName'
次のように置き換えます。
- ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス
- USER_CLUSTER_NAME: ユーザー クラスタの名前
Secret から
data.config
の値を取得し、base64 デコードして、config.txt
という名前のファイルに保存します。kubectl --kubeconfig <var class="edit">ADMIN_CLUSTER_KUBECONFIG</var> get secret <var class="edit">SECRET_NAME</var> \ --namespace <var class="edit">USER_CLUSTER_NAME </var> \ --output json | jq -r '.data["config"]' | base64 -d > config.txt
SECRET_NAME は、前の手順の Secret の名前に置き換えます。
config.txt
を編集用に開きます。次の例のように、
[Snapshot]
セクションのglobal-max-snapshots-per-block-volume
フィールドを編集または追加します。[Global] cluster-id = "my-user-cluster" insecure-flag = "0" user = "my-account.local" password = "fxqSD@SZTUIsG" [VirtualCenter "my-vCenter"] port = "443" datacenters = "my-datacenter1" [Snapshot] global-max-snapshots-per-block-volume = 4
Secret を削除して再作成します。
kubectl --kubeconfig <var class="edit">ADMIN_CLUSTER_KUBECONFIG</var> delete secret <var class="edit">SECRET_NAME</var> \ --namespace <var class="edit">USER_CLUSTER_NAME</var> kubectl --kubeconfig <var class="edit">ADMIN_CLUSTER_KUBECONFIG</var> create secret generic <var class="edit">SECRET_NAME</var> \ --namespace <var class="edit">USER_CLUSTER_NAME</var> \ --from-file=config
vsphere-csi-controller
Deployment を再起動します。kubectl --kubeconfig <var class="edit">ADMIN_CLUSTER_KUBECONFIG</var> rollout restart deployment vsphere-csi-controller \ --namespace <var class="edit">USER_CLUSTER_NAME</var>