Skip to main content
NetApp Response to Russia-Ukraine Cyber Threat
In response to the recent rise in cyber threat due to the Russian-Ukraine crisis, NetApp is actively monitoring the global security intelligence and updating our cybersecurity measures. We follow U.S. Federal Government guidance and remain on high alert. Customers are encouraged to monitor the Cybersecurity and Infrastructure Security (CISA) website for new information as it develops and remain on high alert.
NetApp Knowledge Base

Trident - OpenShift pods stuck in containerCreating state due to iSCSI session authentication errors

Views:
608
Visibility:
Public
Votes:
0
Category:
trident-openshift
Specialty:
solidfire
Last Updated:

Applies to

  • Trident
  • SolidFire
  • OpenShift 4.4.13+
  • Red Hat Enterprise Linux CoreOS 4.5+
  • Red Hat Enterprise Linux 8.2+

Issue

1. While provisioning pods with NetApp Trident PVCs, pods get stuck in a 'containerCreating' state due to the OpenShift worker nodes being unable to establish an iSCSI session with Element because of a hash algorithm mismatch.

2. After upgrading to OpenShift 4.4.13+, existing pods with PVCs are unable to re-establish their iSCSI sessions.

 

The following can be done to confirm this condition:

Trident creates the PVC as expected.

[root@master k8s]# kubectl get pvc
NAME                           STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistent-volume-claim-sf     Bound    pvc-7489898e-087b-4db0-b211-e5b254074d56   2Gi        RWO            sf-gold        46h

Running iscsiadm -m discovery on the worker node will show the portal is correctly discovered.

[root@node-1 iscsi]# iscsiadm -m discovery
192.168.1.50:3260 via sendtargets

iscsiadm -m node will show the target correctly discovered.

[root@node-1 iscsi]# iscsiadm -m node
192.168.1.50:3260,1 iqn.2010-01.com.solidfire:3x71.pvc-7489898e-087b-4db0-b211-e5b254074d56.1

However, iscsiadm -m session will not show any entries.

[root@node-1 ~]# iscsiadm -m session
iscsiadm: No active sessions.

Reviewing /var/log/messages on the worker node where the pod resides will show the an authentication error while logging into the target.

Jul 30 04:12:36 node-1 iscsid[1372]: iscsid: Login authentication failed with target iqn.2010-01.com.solidfire:3x71.pvc-7489898e-087b-4db0-b211-e5b254074d56.1
Jul 30 04:12:36 node-1 iscsid[1372]: iscsid: Kernel reported iSCSI connection 207:0 error (1020 - ISCSI_ERR_TCP_CONN_CLOSE: TCP connection closed) state (1)
Jul 30 04:12:41 node-1 iscsid[1372]: iscsid: Login failed to authenticate with target iqn.2010-01.com.solidfire:3x71.pvc-7489898e-087b-4db0-b211-e5b254074d56.1
Jul 30 04:12:41 node-1 iscsid[1372]: iscsid: session 207 login rejected: Initiator failed authentication with target
Jul 30 04:12:41 node-1 iscsid[1372]: iscsid: Connection207:0 to [target: iqn.2010-01.com.solidfire:3x71.pvc-7489898e-087b-4db0-b211-e5b254074d56.1, portal: 192.168.1.50,3260] through [iface: default] is shutdown.

 

Scan to view the article on your device
CUSTOMER EXCLUSIVE CONTENT

Registered NetApp customers get unlimited access to our dynamic Knowledge Base.

New authoritative content is published and updated each day by our team of experts.

Current Customer or Partner?

Sign In for unlimited access

New to NetApp?

Learn more about our award-winning Support