Trident: blkidタイムアウトによるランダムなpvcマウントの失敗

作成日 2020年10月14日  ·  4コメント  ·  ソース: NetApp/trident

バグを説明する
ネットアップのpvcをマウントできないため、多くのポッドがContainerCreatingの状態でランダムにスタックしていることがわかります。 ポッドの説明は、iSCSIデバイス情報とトライデントデーモンセットログの取得中のタイムアウトを示しています。これは、ホストでblkidコマンドを実行しているときのタイムアウトが原因であることを示しています。
これはランダムに発生するものであり、特定のpvcおよびホストとはまだ相関していません。

環境

  • トライデントバージョン:20.07.1
  • 使用されるトライデントインストールフラグ:tridentctl install -n sys-trident --generate-custom-yaml(次に、生成されたマニフェストに対してkubectl apply -f-)
  • コンテナランタイム: docker://19.3.12
  • Kubernetesバージョン:v1.19.2
  • Kubernetesオーケストレーター:なし
  • Kubernetes対応の機能ゲート:kubernetesのデフォルトのみ
  • OS:Kinvolk2605.6.0によるFlatcarContainer Linux(Oklo)5.4.67-flatcar
  • NetAppバックエンドタイプ:ontap-san、ONTAP 9.7.0

再現するには
クラスタノードでランダムに観察できます(特定のホストグループに関連していないようです)

予想される行動
妥当な時間枠内での一貫したマウント動作。

追加のコンテキスト
「スタックした」ポッドを説明すると、次のことがわかります。

Events:
  Type     Reason       Age                  From     Message
  ----     ------       ----                 ----     -------
  Warning  FailedMount  51m (x5 over 72m)    kubelet  Unable to attach or mount volumes: unmounted volumes=[data], unattached volumes=[data thanos-storage vault-tls thanos-store-token-lj9j5]: timed out waiting for the condition
  Warning  FailedMount  42m (x3 over 56m)    kubelet  Unable to attach or mount volumes: unmounted volumes=[data], unattached volumes=[thanos-storage vault-tls thanos-store-token-lj9j5 data]: timed out waiting for the condition
  Warning  FailedMount  17m (x15 over 74m)   kubelet  Unable to attach or mount volumes: unmounted volumes=[data], unattached volumes=[vault-tls thanos-store-token-lj9j5 data thanos-storage]: timed out waiting for the condition
  Warning  FailedMount  14m (x22 over 74m)   kubelet  MountVolume.MountDevice failed for volume "pvc-e22cdf07-acfc-42af-a46a-bffd5ac32514" : rpc error: code = Internal desc = error getting iSCSI device information: process killed after timeout
  Warning  FailedMount  4m11s (x4 over 69m)  kubelet  Unable to attach or mount volumes: unmounted volumes=[data], unattached volumes=[thanos-store-token-lj9j5 data thanos-storage vault-tls]: timed out waiting for the condition

トライデントデーモンセットの同じノードで、それぞれのポッドログ:

time="2020-10-14T14:32:41Z" level=debug msg=">>>> osutils.execCommandWithTimeout." args="[if=/dev/sdc bs=4096 count=1 status=none]" command=dd timeoutSeconds=5s
time="2020-10-14T14:32:41Z" level=debug msg="<<<< osutils.execCommandWithTimeout." command=dd error="<nil>"
time="2020-10-14T14:32:41Z" level=debug msg="<<<< osutils.ensureDeviceReadable"
time="2020-10-14T14:32:41Z" level=debug msg=">>>> osutils.getFSType" device=/dev/sdc
time="2020-10-14T14:32:41Z" level=debug msg=">>>> osutils.waitForDevice" device=/dev/sdc
time="2020-10-14T14:32:41Z" level=debug msg="Device found." device=/dev/sdc
time="2020-10-14T14:32:41Z" level=debug msg="<<<< osutils.waitForDevice" device=/dev/sdc
time="2020-10-14T14:32:41Z" level=debug msg=">>>> osutils.execCommandWithTimeout." args="[/dev/sdc]" command=blkid timeoutSeconds=5s
time="2020-10-14T14:32:46Z" level=error msg="process killed after timeout" process=blkid
time="2020-10-14T14:32:46Z" level=debug msg="<<<< osutils.execCommandWithTimeout." command=blkid error="process killed after timeout"
time="2020-10-14T14:32:46Z" level=debug msg="<<<< osutils.getFSType"
time="2020-10-14T14:32:46Z" level=debug msg="<<<< osutils.getDeviceInfoForLUN" iSCSINodeName="iqn.1992-08.com.netapp:sn.0205ffce026911ebb4d9d039ea1a7953:vs.9" lunID=1 needFSType=true
time="2020-10-14T14:32:46Z" level=debug msg="<<<< osutils.AttachISCSIVolume"
time="2020-10-14T14:32:46Z" level=debug msg="<<<< NodeStageVolume" Method=NodeStageVolume Type=CSI_Node
time="2020-10-14T14:32:46Z" level=debug msg="Released shared lock (NodeStageVolume-pvc-e22cdf07-acfc-42af-a46a-bffd5ac32514)." lock=csi_node_server
time="2020-10-14T14:32:46Z" level=error msg="GRPC error: rpc error: code = Internal desc = error getting iSCSI device information: process killed after timeout"

blkidは許可された時間枠内に戻ることができないようです(?)
ホストにSSHで接続し、同じコマンドを試してみると、次のようになります。

$ time sudo blkid /dev/sdc
/dev/sdc: UUID="f593b708-ed88-47b7-88ce-f9b8c85ab96b" TYPE="ext4"

real    0m36.393s
user    0m0.016s
sys     0m0.021s

バックエンドのjson構成:
`` `
{{
「バージョン」:1、
"storageDriverName": "ontap-san"、
"managementLIF": "10.20.50.6"、
"dataLIF": "10.20.50.4"、
"svm": "dev_kube"、
"igroupName": "dev_kube_trident"、
"ユーザー名": "xxxxxxxxx"、
"パスワード": "xxxxxxxxxxx"、
「デフォルト」:{
「暗号化」:「true」
}
}
`` ``

私たちは本当にここで立ち往生しているので、これに関するどんな助けも大いに感謝されるでしょう!

bug

最も参考になるコメント

ネットワークリンクの速度をデバッグして以来、これを見ていないので、これを閉じます。 助けてくれてありがとう! :))

全てのコメント4件

こんにちは@ffilippopoulos

ご指摘のとおり、blkidはホストレベルのコマンドです。 このコマンドがタイムアウトする前に戻る機能は、Tridentが制御できるものではありません。 トライデントは基本的に、ホストにSSHで接続し、シェルからblkidを実行するときと同じことを実行しています。 ホストの負荷を調べましたか?

また、この問題についてすぐにサポートが必要な場合は、ネットアップサポートにお問い合わせください。

ネットアップでケースを開くには、 https://mysupport.netapp.com/site/にアクセスしてください。
左下の[サポートに連絡]をクリックします
お住まいの地域から適切な番号を見つけて電話をかけるか、ログインしてください。
注:トライデントはページに表示されていませんが、サポートされているネットアップストレージSNに基づいてネットアップがサポートしている製品です。
NetAppストレージSNでケースを開き、問題の説明を入力します。
製品がKubernetesのTridentであることを必ず明記し、詳細を提供してください。 このGitHubに言及します。
ケースは、対応のためにトライデントのサポートエンジニアに転送されます。

ちょっと@gnarl迅速な対応ありがとうございます。 私が見る限り、このコマンドには5秒のハードタイムアウトがあります。これはトライデントフィールドにあります: https ://github.com/NetApp/trident/blob/0a245d3895af31f910a58c2f26e5a0f8b25f34f8/utils/osutils.go#L2306

ノードがまったくロードされていないことがわかる限り(たとえば、ノードではload average: 0.54, 0.62, 0.61の問題が発生します)、これが観察された動作を説明するとは思われません。
ハードコードされたタイムアウトの理由はありますか? それは私たちが気付いていないいくつかのケースを防いでいますか?

@ ffilippopoulos 、blkidの実行には5秒近くかかることはありません。 ホストの負荷が良好に見える場合、ホストとNetApp dataLIF間のネットワーク遅延を調べることができますか?

blkidが機能しない場合、Tridentはボリュームを安全に接続できないため、blkidにはハードタイムアウトがあります。

ネットワークリンクの速度をデバッグして以来、これを見ていないので、これを閉じます。 助けてくれてありがとう! :))

このページは役に立ちましたか?
0 / 5 - 0 評価