Does communication failure between the kubelet and the Trident CSI plugin causes unexpected node reboot?
Applies to
Trident
Answer
No. Please find the detailed explanation.
dial unix /var/lib/kubelet/plugins_registry/csi.trident.netapp.io-reg.sock: connect: connection refused
This error is a communication failure between the kubelet and the Trident CSI plugin via a Unix domain socket. Specifically:
- The socket
/var/lib/kubelet/plugins_registry/csi.trident.netapp.io-reg.sockis either not present, not listening, or Trident CSI plugin is not running at that moment. - connection refused typically means the Trident CSI driver pod wasn’t running or not ready at the time kubelet tried to register it.
- This causes kubelet to delay the plugin registration, but it’s not a fatal kernel or system error.
This is not a reboot-causing error.
It’s a symptom that the Trident CSI plugin wasn’t available when kubelet tried to connect. If the node rebooted, the cause is likely elsewhere — and this CSI error may just be a consequence of the node or service restart, not the trigger.
Additional Information
additionalInformation_text
