How Do I Restore a Faulty Container Network Interface?
CCE Autopilot clusters use Cloud Native Network 2.0. In such a cluster, each pod is allocated a network interface during its creation. Restoration steps depend on the error events.
- Error "timed out waiting for the condition [arping timeout]" Reported During Pod Creation
- Error "no eni bound to pod" Reported During Pod Creation
- Pod Created and Started Successfully but Network Abnormal Later
Error "timed out waiting for the condition [arping timeout]" Reported During Pod Creation
This error indicates that the network interface allocated to the pod cannot access the subnet gateway of the pod using arping. The root cause is a fault in the underlying VPC network. If the VPC network is not restored within 10 minutes, CCE will allocate a new network interface to the pod. To restore the pod quickly, rebuild the pod. If the error persists, submit a service ticket and contact O&M personnel.
Error "no eni bound to pod" Reported During Pod Creation
This error indicates that no network interface is allocated to the pod. You need to check other events on the pod to further locate the fault.
- Error "[insufficient IP addresses in subnets]"
This error occurs because the IP addresses in the subnet configured by the container network for the pods are exhausted, or no subnet is configured. To solve the problem:
- Log in to the CCE console and click the cluster name to access the cluster console.
- In the Networking Configuration area, check the subnet and whether there are enough IP addresses.

- If no IP address is available, click Edit and select a container subnet in the same VPC. You can add multiple container subnets at a time. If no other subnets are available, create one on the VPC console.
- Error "[insufficient secgroup referred by nic]"
This error occurs because the number of network interfaces associated with the security group used by the pod exceeds the upper limit.
If the number of pods exceeds the maximum network interfaces per security group, configure multiple security groups to allow more pods.
Pod Created and Started Successfully but Network Abnormal Later
If a pod is created and started but the network disconnects later, possible causes include:
- Security group or network ACL rules deny network access. Ensure that security group or network ACL rules are correct.
- Access the subnet gateway of the pod in the container using arping.
arping -I eth0 <$pod-subnet-gateway>If this command fails, there is a high probability that the underlying VPC network is abnormal. To restore the pod, rebuild the pod or submit a service ticket and contact O&M personnel.
What is your overall rating for this page?
Thank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot