ストレージのトラブルシューティング

このドキュメントでは、ストレージの問題についてのトラブルシューティングについて説明します。

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'.

この問題を解決するには:

仮想ディスクが間違った仮想マシンにアタッチされている場合は、手動での切断が必要になる場合があります。

  1. ノードをドレインします。 ノードを安全にドレインするをご覧ください。--ignore-daemonsets と --delete-local-data のフラグを kubectl drain コマンドに追加することもできます。

  2. VM の電源を切ります。

  3. vCenter で VM のハードウェア構成を編集し、Volume を削除します。

  4. VM の電源を入れます。

  5. ノードの閉鎖を解除します。

Volume が失われる

この問題は、仮想ディスクが完全に削除された場合に発生することがあります。これは、仮想ディスクまたはアタッチしている仮想マシンを手動で削除した場合に発生します。VMDK ファイルに関して「not found」というエラーが表示される場合は、仮想ディスクが完全に削除されている可能性があります。

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 リソースを手動でクリーンアップする必要があります。

  1. kubectl delete pvc [PVC_NAME] を実行して、PV を参照している PVC を削除します。

  2. kubectl delete pod [POD_NAME] を実行して、PVC を参照している Pod を削除します。

  3. 手順 2 を繰り返します。（Kubernetes の問題 74374 をご覧ください）。

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   
csi-8d9c3d0439f413fa9e176c63f5cc92bd67a33a1b76919d42c20347d52c57435c   
csi-e40d65005bc64c45735e91d7f7e54b2481a2bd41f5df7cc219a2c03608e8e7a8

この問題を解決するには、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 : 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 ドライバの既知の問題 は、ノードがシャットダウンされたか、削除されたか、または障害が発生したときに発生します。

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

この問題を解決するには:

  1. 上の出力の PersistentVolumeClaim（PVC）の名前をメモし、PVC に関連付けられた VolumeAttachments を見つけます。例:

    kubectl get volumeattachments | grep pvc-xxxxx

    出力に VolumeAttachments の名前が表示されます。例:

    csi-yyyyy   csi.vsphere.vmware.com   pvc-xxxxx   node-zzzzz ...

  2. VolumeAttachments を記述します。例:

    kubectl describe volumeattachments csi-yyyyy | grep "Deletion Timestamp"

    出力内の削除タイムスタンプを記録します。

    Deletion Timestamp:   2021-03-10T22:14:58Z

  3. 削除タイムスタンプで指定された時間まで待機してから、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)

この問題を解決するには、次の手順に沿ってボリュームあたりのスナップショットの最大数を更新します。

  1. vSphere の構成を vSphere CSI コントローラに提供する Secret の名前を取得します。

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get deployment vsphere-csi-controller \
   --namespace USER_CLUSTER_NAME \
   --output json \
   | jq -r '.spec.template.spec.volumes[] \
   | select(.name=="vsphere-secret") .secret.secretName'

    以下を置き換えます。

    • ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス
    • USER_CLUSTER_NAME: ユーザー クラスタの名前

  2. Secret から data.config の値を取得し、base64 デコードして、config.txt という名前のファイルに保存します。

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret SECRET_NAME \
   --namespace USER_CLUSTER_NAME  \
   --output json | jq -r '.data["config"]' | base64 -d > config.txt

    SECRET_NAME は、前の手順の Secret の名前に置き換えます。

  3. 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

  4. Secret を削除して再作成します。

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG delete secret SECRET_NAME \
   --namespace USER_CLUSTER_NAME

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG create secret generic SECRET_NAME \
   --namespace USER_CLUSTER_NAME \
   --from-file=config

  5. vsphere-csi-controller Deployment を再起動します。

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG rollout restart deployment vsphere-csi-controller \
   --namespace USER_CLUSTER_NAME