-
Bug
-
Resolution: Not a Bug
-
Normal
-
None
-
4.14.z
-
Important
-
No
-
SDN Sprint 257, SDN Sprint 258, SDN Sprint 259, SDN Sprint 260
-
4
-
False
-
-
-
-
07/08 workaround is to restart ovnkube-node
-
On a v4.14 cluster with OVN-kubernetes CNI at one master node (master-0) CRI-O cannot add or delete containers from the CNI network.
The error is the below:
crio[3397]: 2024-06-19T01:00:10Z [error] CmdCheck (shim): CNI request failed with status 400: '& {ContainerID:1e * 8943f9a2f076f6e66c867aa38f2396c335493507d3c5dbd6e9ece463b058f8 Netns:/var/run/netns/79cb69cd-e844-444f-bf62-52054c8cc0b9 IfName:eth0 Args:IgnoreUnknown=1;K8S_POD_NAMESPACE=openshift-compliance;K8S_POD_NAME=ocp4-cis-node-<node-name>-pod;K8S_POD_INFRA_CONTAINER_ID=1e8943f9a2f076f6e66c867aa38f2396c335493507d3c5dbd6e9ece463b058f8;K8S_POD_UID=b0c0f2ff-dc70-4951-86c6-dd17d01961b5 Path: StdinData:[123 34 98 105 110 68 105 114 34 58 34 47 118 97 114 47 108 105 98 47 99 110 105 47 98 105 110 34 44 34 99 104 114 111 111 116 68 105 114 34 58 34 47 104 111 115 116 114 111 111 116 34 44 34 99 108 117 115 116 101 114 78 101 116 119 111 114 107 34 58 34 47 104 111 115 116 47 114 117 110 47 109 117 108 116 117 115 47 99 110 105 47 110 101 116 46 100 47 49 48 45 111 118 110 45 107 117 98 101 114 110 101 116 101 115 46 99 111 110 102 34 44 34 99 110 105 67 111 110 102 105 103 68 105 114 34 58 34 47 104 111 115 116 47 101 116 99 47 99 110 105 47 110 101 116 46 100 34 44 34 99 110 105 86 101 114 115 105 111 110 34 58 34 48 46 51 46 49 34 44 34 100 97 101 109 111 110 83 111 99 107 101 116 68 105 114 34 58 34 47 114 117 110 47 109 117 108 116 117 115 47 115 111 99 107 101 116 34 44 34 103 108 111 98 97 108 78 97 109 101 115 112 97 99 101 115 34 58 34 100 101 102 97 117 108 116 44 111 112 101 110 115 104 105 102 116 45 109 117 108 116 117 115 44 111 112 101 110 115 104 105 102 116 45 115 114 105 111 118 45 110 101 116 119 111 114 107 45 111 112 101 114 97 116 111 114 34 44 34 108 111 103 76 101 118 101 108 34 58 34 118 101 114 98 111 115 101 34 44 34 108 111 103 84 111 83 116 100 101 114 114 34 58 116 114 117 101 44 34 109 117 108 116 117 115 65 117 116 111 99 111 110 102 105 103 68 105 114 34 58 34 47 104 111 115 116 47 114 117 110 47 109 117 108 116 117 115 47 99 110 105 47 110 101 116 46 100 34 44 34 109 117 108 116 117 115 67 111 110 102 105 103 70 105 108 101 34 58 34 97 117 116 111 34 44 34 110 97 109 101 34 58 34 109 117 108 116 117 115 45 99 110 105 45 110 101 116 119 111 114 107 34 44 34 110 97 109 101 115 112 97 99 101 73 115 111 108 97 116 105 111 110 34 58 116 114 117 101 44 34 112 101 114 78 111 100 101 67 101 114 116 105 102 105 99 97 116 101 34 58 123 34 98 111 111 116 115 116 114 97 112 75 117 98 101 99 111 110 102 105 103 34 58 34 47 118 97 114 47 108 105 98 47 107 117 98 101 108 101 116 47 107 117 98 101 99 111 110 102 105 103 34 44 34 99 101 114 116 68 105 114 34 58 34 47 101 116 99 47 99 110 105 47 109 117 108 116 117 115 47 99 101 114 116 115 34 44 34 99 101 114 116 68 117 114 97 116 105 111 110 34 58 34 50 52 104 34 44 34 101 110 97 98 108 101 100 34 58 116 114 117 101 125 44 34 115 111 99 107 101 116 68 105 114 34 58 34 47 104 111 115 116 47 114 117 110 47 109 117 108 116 117 115 47 115 111 99 107 101 116 34 44 34 116 121 112 101 34 58 34 109 117 108 116 117 115 45 115 104 105 109 34 125]}
ContainerID:"1e8943f9a2f076f6e66c867aa38f2396c335493507d3c5dbd6e9ece463b058f8" Netns:"/var/run/netns/79cb69cd-e844-444f-bf62-52054c8cc0b9" IfName:"eth0" Args:"IgnoreUnknown=1;K8S_POD_NAMESPACE=openshift-compliance;K8S_POD_NAME=ocp4-cis-node-<node-name>-pod;K8S_POD_INFRA_CONTAINER_ID=1e8943f9a2f076f6e66c867aa38f2396c335493507d3c5dbd6e9ece463b058f8;K8S_POD_UID=b0c0f2ff-dc70-4951-86c6-dd17d01961b5" Path:"" ERRORED: DelegateDel: error invoking DelegateDel - "ovn-k8s-cni-overlay": error in getting result from DelNetwork: failed to send CNI request: Post "http://dummy/": dial unix /var/run/ovn-kubernetes/cni//ovn-cni-server.sock: connect: connection refused
It is not observed the issue only with this pod but with multiple pods.
From my so far investigation i can see that the container that is listening on this socket is ovnkube-controller that is one of the containers of the ovnkube-node daemonset running on this master node. Other nodes seem to not be affected and only pods started or deleted on this specific node have this issue.
Key points:
- This issue is happening at random times every some weeks.
- At the last occurrence it started at 19th of June and were at this state till 26th of June where the ovnkube-node is manually restarted and the issue dissapears.
- The ovnkube-controller container logs report no issues at all. No errors. No restarts during this timewindow.
- There are no Selinux events related to this in the audit logs of the node to justify some permission enforcement.
- Customer is using IBM Security Cloudpack cp4s but i have not found any connection with this tool to be related to the issue.
Data Available in the attached case:
- Sosreport from the node after pod restart
- Must-gather report prior pod restart and while the issue is present.
Requested action:
Please check the data available and let me know how we can identify the Root Cause of the issue. Let me know if i need to share the available reports using another way if you cannot find them through the case.
