Trident: Kegagalan pemasangan pvc acak karena batas waktu blkid

Dibuat pada 14 Okt 2020  ·  4Komentar  ·  Sumber: NetApp/trident

Jelaskan bugnya
Kami mengamati banyak pod yang macet secara acak pada status ContainerCreating karena mereka tidak dapat memasang netapp pvcs. Menggambarkan pod menunjukkan timeout saat mendapatkan informasi perangkat iSCSI dan log daemonset trisula menunjukkan bahwa ini disebabkan oleh timeout saat menjalankan perintah blkid pada host.
Ini adalah kejadian acak dan belum dapat berkorelasi dengan pvc dan host tertentu.

Lingkungan

  • Versi trisula: 20.07.1
  • Bendera instalasi trisula yang digunakan: tridentctl install -n sys-trident --generate-custom-yaml (lalu kubectl apply -f - untuk manifes yang dihasilkan)
  • Waktu proses kontainer: buruh pelabuhan://19.3.12
  • Versi Kubernetes: v1.19.2
  • Orkestra Kubernetes: tidak ada
  • Gerbang fitur yang diaktifkan Kubernetes: hanya default kubernetes
  • OS: Flatcar Container Linux oleh Kinvolk 2605.6.0 (Oklo) 5.4.67-flatcar
  • Jenis backend NetApp: ontap-san, ONTAP 9.7.0

Untuk Mereproduksi
Kami dapat mengamatinya secara acak di node cluster kami (tampaknya tidak terkait dengan grup host tertentu)

Perilaku yang diharapkan
Perilaku pemasangan yang konsisten dalam jangka waktu yang wajar.

konteks tambahan
Dengan mendeskripsikan pod "macet" kita dapat melihat:

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

pada node yang sama dari trident daemonset masing-masing pod log:

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"

tampaknya blkid tidak dapat kembali di jendela waktu yang diizinkan(?)
jika kita ssh ke Host dan coba perintah yang sama:

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

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

konfigurasi json backend kami:
```
{
"versi 1,
"storageDriverName": "ontap-san",
"managementLIF": "10.20.50.6",
"dataLIF": "10.20.50.4",
"svm": "dev_kube",
"igroupName": "dev_kube_trident",
"nama pengguna": "xxxxxxxxx",
"kata sandi": "xxxxxxxxxxxx",
"default": {
"enkripsi": "benar"
}
}
````

Kami benar-benar terjebak di sini, jadi bantuan apa pun yang satu ini akan sangat kami hargai!

bug

Komentar yang paling membantu

Menutup yang ini karena kami belum melihatnya sejak kami men-debug kecepatan tautan jaringan kami. Terima kasih banyak atas bantuannya! :))

Semua 4 komentar

HI @ffilippopoulos ,

Seperti yang Anda tunjukkan blkid adalah perintah tingkat host. Kemampuan perintah ini untuk kembali sebelum waktu habis bukanlah sesuatu yang bisa dikendalikan oleh Trident. Trident pada dasarnya melakukan hal yang sama yang Anda lakukan ketika Anda ssh ke Host dan menjalankan blkid dari Shell. Sudahkah Anda memeriksa beban pada host?

Juga, jika Anda memerlukan bantuan segera dengan masalah ini, silakan hubungi Dukungan NetApp.

Untuk membuka kasing dengan NetApp, silakan kunjungi https://mysupport.netapp.com/site/.
Kiri bawah, Klik 'Hubungi Dukungan'
Temukan nomor yang sesuai dari wilayah Anda untuk menelepon, atau login.
Catatan: Trident tidak terdaftar di halaman, tetapi merupakan produk yang didukung oleh NetApp berdasarkan SN penyimpanan Netapp yang didukung.
Buka kasing di SN penyimpanan NetApp, dan berikan deskripsi masalahnya.
Pastikan untuk menyebutkan produknya Trident di Kubernetes, dan berikan detailnya. Sebutkan GitHub ini.
Kasus ini akan diarahkan ke teknisi dukungan Trident untuk ditanggapi.

hai @gnarl terima kasih atas tanggapan cepatnya. Sejauh yang saya bisa lihat ada batas waktu 5 detik yang sulit pada perintah ini, yang ada di bidang tridents: https://github.com/NetApp/trident/blob/0a245d3895af31f910a58c2f26e5a0f8b25f34f8/utils/osutils.go#L2306

sejauh yang saya bisa melihat node kita tidak dimuat sama sekali (misalnya pada node kita sekarang melihat masalah load average: 0.54, 0.62, 0.61 ) dan tidak berpikir bahwa ini akan menjelaskan perilaku yang kita amati.
Apakah ada alasan untuk batas waktu hardcoded? apakah itu mencegah beberapa kasus yang tidak kita sadari?

@ffilippopoulos , blkid seharusnya tidak mendekati 5 detik untuk dijalankan. Jika beban pada host Anda terlihat bagus, dapatkah Anda memeriksa latensi jaringan antara host dan dataLIF NetApp?

Kami memiliki batas waktu yang sulit pada blkid karena jika blkid tidak berfungsi maka Trident tidak dapat memasang volume dengan aman.

Menutup yang ini karena kami belum melihatnya sejak kami men-debug kecepatan tautan jaringan kami. Terima kasih banyak atas bantuannya! :))

Apakah halaman ini membantu?
0 / 5 - 0 peringkat