Help Center/ Cloud Container Engine_Autopilot/ FAQs/ Network Management/ How Do I Restore a Faulty Container Network Interface?
Updated on 2026-06-25 GMT+08:00

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

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:

    1. Log in to the CCE console and click the cluster name to access the cluster console.
    2. In the Networking Configuration area, check the subnet and whether there are enough IP addresses.

    3. 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.