FAQ about container networks and solutions - Container Service for Kubernetes

This topic provides answers to some frequently asked questions about the Terway and Flannel network plug-ins. For example, answers to questions such as how to select a network plug-in, whether a cluster supports third-party network plug-ins, and how to plan the cluster network are provided.

Can I switch the network plug-in for an existing ACK cluster?

You can select a network plug-in (Terway or Flannel) only when you create a Container Service for Kubernetes (ACK) cluster. You cannot change the plug-in after the cluster is created. You must create a new cluster if you want to switch the network plug-in. For more information, see Create an ACK managed cluster.

What do I do if a cluster installed with Terway cannot access the Internet after I create a vSwitch for the cluster?

Issue

In the Terway network, after a new vSwitch is created to provide more IP addresses for pods, the ACK cluster cannot access the Internet.

Cause

The new vSwitch that assigns IP addresses to pods does not have access to the Internet.

Solution

Create a NAT gateway and configure SNAT rules to enable the new vSwitch to access the Internet. For more information, see Enable an existing ACK cluster to access the Internet.

What do I do if Flannel becomes incompatible with clusters of Kubernetes 1.16 or later after I manually update Flannel?

Issue

After the Kubernetes version of a cluster is updated to 1.16 or later, the nodes in the cluster change to the NotReady state.

Cause

The Flannel plug-in is manually updated but the Flannel configuration is outdated. As a result, kubelet cannot recognize Flannel.

Solution

Run the following command to add the cniVersion field to the Flannel configuration file:
```
kubectl edit cm kube-flannel-cfg -n kube-system 
```
Add the cniVersion field to the configuration file.
```
"name": "cb0",   
"cniVersion":"0.3.0",
"type": "flannel",
```

Run the following command to restart Flannel:

kubectl delete pod -n kube-system -l app=flannel

What do I do if a pod is not immediately ready for communication after it is started?

Issue

After a pod is started, you must wait a period of time before the pod is ready for communication.

Cause

The network policies require a period of time to take effect. To resolve this issue, you can disable network policies.

Solution

Run the following command to modify the ConfigMap of Terway and disable network policies:
```
kubectl edit cm -n kube-system eni-config 
```
Add the following field to the ConfigMap:
```
disable_network_policy: "true"
```
Optional: If your Terway version is not up-to-date, update it to the latest version in the ACK console.
1. Log on to the ACK console. In the left-side navigation pane, click Clusters.
2. On the Clusters page, find the cluster that you want to manage and click its name. In the left-side pane, choose Operations > Add-ons.
3. On the Add-ons page, click the Networking tab, find the Terway plug-in, and then click Upgrade.
4. In the Note message, click OK.

Run the following command to restart all Terway pods:

 kubectl delete pod -n kube-system -l app=terway-eniip

How do I enable a pod to access a Service that is used to expose the pod?

Issue

Pods are not allowed to access Services that are used to expose them. If a pod accesses the Service that exposes the pod, the performance of the Service becomes unstable or scheduling errors may occur.

Cause

Your cluster uses a Flannel version that does not allow loopback requests.

Note

Flannel versions earlier than 0.15.1.4-e02c8f12-aliyun do not allow loopback requests. By default, loopback requests are not allowed if you directly update Flannel to 0.15.1.4-e02c8f12-aliyun or later.
To allow loopback requests, you must uninstall the current Flannel version and then install Flannel 0.15.1.4-e02c8f12-aliyun or later.

Solution

Use a headless Service to expose and access applications. For more information, see Headless Services.
Note
We recommend that you use this method.
Recreate the cluster to use Terway. For more information, see Work with Terway.
Modify the Flannel configuration, reinstall Flannel, and then recreate the pod.
Note
We recommend that you do not use this method because the Flannel configuration may be overwritten when you update Flannel.
1. Run the following command to modify cni-config.json:
```
kubectl edit cm kube-flannel-cfg -n kube-system
```
2. Add hairpinMode: true to the delegate parameter.
  Example:
```
cni-conf.json: |
    {
      "name": "cb0",
      "cniVersion":"0.3.1",
      "type": "flannel",
      "delegate": {
        "isDefaultGateway": true,
        "hairpinMode": true
      }
    }
```
3. Run the following command to restart Flannel:
```
kubectl delete pod -n kube-system -l app=flannel   
```
4. Delete and recreate the pod.

How do I choose between Terway and Flannel for an ACK cluster?

The following section describes the Flannel and Terway network plug-ins.

You can select one of the network plug-ins when you create an ACK cluster:

Flannel: a simple and stable Container Network Interface (CNI) plug-in developed by the Kubernetes community. You can use Flannel together with the high-speed network provided by Virtual Private Cloud (VPC) of Alibaba Cloud. This ensures that your clusters and containers run in a stable network with high performance. However, Flannel provides only basic features and does not support standard Kubernetes network policies.
Terway: a network plug-in developed by ACK. Terway provides all the features of Flannel and allows you to attach Alibaba Cloud elastic network interfaces (ENIs) to containers. You can use Terway to configure access control policies for containers based on standard Kubernetes network policies. Terway also supports bandwidth throttling on individual containers. If you do not want to use Kubernetes network policies, you can choose Flannel. In other cases, we recommend that you choose Terway. For more information about Terway, see Work with Terway.

How do I plan the network of a cluster?

When you create an ACK cluster, you must specify a VPC, vSwitches, the pod CIDR block, and Service CIDR blocks. We recommend that you plan the CIDR block of Elastic Compute Service (ECS) instances in the cluster, pod CIDR block, and Service CIDR block before you create an ACK cluster. For more information, see Plan the network of an ACK cluster.

Can I use the hostPort feature to create port mappings in an ACK cluster?

Only Flannel allows you to use the hostPort feature to create port mappings in an ACK cluster.
A pod in a VPC can be accessed by other cloud resources that are deployed in the same VPC by using the endpoint of the pod in the VPC. Therefore, port mapping is not required.
To expose applications to the Internet, you can use NodePort Services or LoadBalancer Services.

How do I check the network type and vSwitches of a cluster?

ACK supports two types of container networks: Flannel and Terway.

To check the network type of the cluster, perform the following steps:

Log on to the ACK console. In the left-side navigation pane, click Clusters.
On the Clusters page, find the cluster that you want to manage and click its name. You can also click Details in the Actions column to go to the cluster details page.
On the Basic Information tab, check the value of the Network Plug-in parameter in the Cluster Information section.
- If the value of the Network Plug-in parameter is terway-eniip, Terway is used.
- If the value of the Network Plug-in parameter is Flannel, Flannel is used.

To check the vSwitch to which the nodes in the network belong, perform the following steps:

Log on to the ACK console. In the left-side navigation pane, click Clusters.
On the Clusters page, find the cluster that you want to manage and click its name. In the left-side pane, choose Nodes > Node Pools.
On the Node Pools page, find the node pool that you want to manage and click Details in the Actions column.
In the Node Configurations section of the Overview tab, check the value of the Node vSwitch parameter.

To check the vSwitch to which the pods in the Terway network belong, perform the following steps:

Note

Only pods in the Terway network require a vSwitch. Pods in the Flannel network do not require a vSwitch.

Log on to the ACK console. In the left-side navigation pane, click Clusters.
On the Clusters page, find the cluster that you want to manage and click its name. You can also click Details in the Actions column to go to the details page of the cluster.
On the details page of the cluster, click the Basic Information tab and check the value of the Pod vSwitch parameter.

How do I check the cloud resources used in an ACK cluster?

Perform the following steps to check the cloud resources used in an ACK cluster, such as vSwitches, VPCs, and Resource Access Management (RAM) roles.

Log on to the ACK console. In the left-side navigation pane, click Clusters.
On the Clusters page, find the cluster that you want to manage and click its name. You can also click Details in the Actions column to go to the details page of the cluster.
On the Basic Information tab, view the cloud resources that are used in the cluster.

How do I modify the configurations of kube-proxy?

By default, a DaemonSet named kube-proxy-worker is deployed in an ACK managed cluster for load balancing. You can modify the ConfigMap named kube-proxy-worker to change the parameters of the kube-proxy-worker DaemonSet. If you use an ACK dedicated cluster, a DaemonSet and a ConfigMap both named kube-proxy-master are deployed on each master node.

The kube-proxy configuration items in ACK are fully compatible with the open source KubeProxyConfiguration. You can refer to the open source version when you customize configurations. For more information, see kube-proxy Configuration (v1alpha1). The kube-proxy configurations must conform to specific formats. Do not omit colons (:) or space characters. Perform the following steps to modify the configurations of kube-proxy:

If you use an ACK managed cluster, perform the following steps to modify the kube-proxy-worker ConfigMap.
1. Log on to the ACK console. In the left-side navigation pane, click Clusters.
2. On the Clusters page, find the cluster that you want to manage and click its name. In the left-side pane, choose Configurations > ConfigMaps.
3. In the upper part of the ConfigMap page, select kube-system from the Namespace drop-down list. Find the kube-proxy-worker ConfigMap and click Edit YAML in the Actions column.
4. In the View in YAML panel, modify the parameters and click OK.
5. Recreate all kube-proxy-worker pods for the configuration to take effect.
  Important
  Your workloads are not interrupted when kube-proxy is restarted. However, new releases are postponed because the system must wait until kube-proxy is restarted. We recommend that you restart kube-proxy during off-peak hours.
  1. In the left-side pane of the cluster details page, choose Workloads > DaemonSets.
  2. On the DaemonSets page, find kube-proxy-worker and click its name.
  3. On the Pods tab of the kube-proxy-worker details page, select a pod and choose More > Delete in the Actions column. In the message that appears, click OK.
    Repeat the preceding steps to delete all of the pods. After you delete the pods, the system automatically recreates the pods.
If you use an ACK dedicated cluster, modify the kube-proxy-worker and kube-proxy-master Configmaps, and then delete the kube-proxy-worker and kube-proxy-master pods. The system automatically recreates them. For more information, see the preceding steps.

How do I increase the maximum number of tracked connections in the conntrack table of the Linux kernel?

If the conntrack full error message is returned after you run the dmesg command, the number of tracked connections in the conntrack table has exceeded the limit specified by the conntrack_max parameter. In this case, you may need to increase the maximum number of tracked connections in the conntrack table.

Run the conntrack -L command to check the proportions of protocols used by the connections in the conntrack table.
- If a large number of TCP connections are found, you must check the application type and consider using persistent connections to replace short-lived connections.
- If a large number of DNS connections are found, you must use NodeLocal DNSCache to improve DNS performance for your cluster. For more information, see Configure NodeLocal DNSCache.
If the proportions of connections in the conntrack table are proper or you do not want to modify the application, you can add the maxPerCore parameter to the kube-proxy configurations to adjust the maximum number of tracked connections.
- If you use an ACK managed cluster, add the maxPerCore parameter to the kube-proxy-worker ConfigMap and set this parameter to 65536 or greater. Then, delete the kube-proxy-worker pods. The system automatically recreates the pods for the configuration to take effect. For more information about how to modify the kube-proxy-worker ConfigMap and delete its pods, see How do I modify the configurations of kube-proxy?
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: kube-proxy-worker
  namespace: kube-system
data:
  config.conf: |
    apiVersion: kubeproxy.config.k8s.io/v1alpha1
    kind: KubeProxyConfiguration
    featureGates:
      IPv6DualStack: true
    clusterCIDR: 172.20.0.0/16
    clientConnection:
      kubeconfig: /var/lib/kube-proxy/kubeconfig.conf
    conntrack:
      maxPerCore: 65536 // Set the maxPerCore parameter to a proper value. Default value: 65536. 
    mode: ipvs
# Irrelevant fields are not shown.
```
- If you use an ACK dedicated cluster, add the maxPerCore parameter to the kube-proxy-worker and kube-proxy-master ConfigMaps and set this parameter to 65536 or greater. Then, delete the kube-proxy-worker and kube-proxy-master pods. The system automatically recreates the pods for the configurations to take effect. For more information about how to modify the kube-proxy-worker and kube-proxy-master ConfigMaps and delete their pods, see How do I modify the configuration of kube-proxy?

How do I modify the IPVS load balancing algorithm in the configurations of kube-proxy?

Perform the following steps to modify the IPVS load balancing algorithm in the kube-proxy configurations to resolve the issue that a large number of persistent connections are not evenly distributed:

Select a proper scheduling algorithm. For more information about how to select scheduling algorithms, see Parameter Changes in Kubernetes documentation.
By default, cluster nodes that were created before October 2022 may not have all IPVS scheduling algorithms enabled. You need to manually enable the IPVS kernel modules on all cluster nodes. In this example, the least connections algorithm is used. If you want to use other scheduling algorithms, replace the lc keyword. Log on to each node, run the lsmod | grep ip_vs_lc command, and check the output.
- If the output contains ip_vs_lc, the kernel modules are loaded. You can skip this step.
- If the kernel modules are not loaded, run the modprobe ip_vs_lc command for the node to immediately take effect. Then, run the echo "ip_vs_lc" >> /etc/modules-load.d/ack-ipvs-modules.conf command to restart the node.
Set the ipvs scheduler parameter to the proper scheduling algorithm.
- If you use an ACK managed cluster, set the ipvs scheduler parameter to the proper scheduling algorithm in the kube-proxy-worker ConfigMap. Then, delete the kube-proxy-worker pods. The system automatically recreates the pods for the configuration to take effect. For more information about how to modify the kube-proxy-worker ConfigMap and delete its pods, see How do I modify the configurations of kube-proxy?
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: kube-proxy-worker
  namespace: kube-system
data:
  config.conf: |
    apiVersion: kubeproxy.config.k8s.io/v1alpha1
    kind: KubeProxyConfiguration
    featureGates:
      IPv6DualStack: true
    clusterCIDR: 172.20.0.0/16
    clientConnection:
      kubeconfig: /var/lib/kube-proxy/kubeconfig.conf
    conntrack:
      maxPerCore: 65536
    mode: ipvs
    ipvs:
      scheduler: lc // Set scheduler to a proper scheduling algorithm. 
# Irrelevant fields are not shown.
```
- If you use an ACK dedicated cluster, set the ipvs scheduler parameter to the proper scheduling algorithm in the kube-proxy-worker and kube-proxy-master ConfigMaps. Then, delete the kube-proxy-worker and kube-proxy-master pods. The system automatically recreates the pods for the configurations to take effect. For more information about how to modify the kube-proxy-worker and kube-proxy-master ConfigMaps and delete their pods, see How do I modify the configurations of kube-proxy?
View the kube-proxy log.
- Run the kubectl get pods command to check whether the status of the kube-proxy-worker container in the kube-system namespace is Running. If your cluster is an ACK dedicated cluster, you also need to check the status of the kube-proxy-master container.
- Run the kubectl logs command to view the log of the container.
  - If the log contains Can't use the IPVS proxier: IPVS proxier will not be used because the following required kernel modules are not loaded: [ip_vs_lc], the IPVS kernel modules fail to be loaded. You need to check whether the preceding steps are performed without errors and then query the log again.
  - If the log contains Using iptables Proxier., kube-proxy fails to enable the IPVS kernel modules and switches back to the iptables mode. In this case, we recommend that you roll back the kube-proxy configurations and then restart the node.
  - If the log does not contain the preceding messages and contains Using ipvs Proxier., the IPVS kernel modules are enabled.
- If kube-proxy passes the preceding checks, the load balancing algorithm is modified.

How do I modify the timeout period for IPVS UDP sessions in the configurations of kube-proxy?

If the kube-proxy mode is set to IPVS in your cluster, the default session persistence policy of IPVS may cause packet loss five minutes after the UDP connection is closed. If your application is dependent on CoreDNS, issues such as API latency and request timeouts may occur five minutes after CoreDNS is updated or its host is restarted.

If your applications in the cluster do not use the UDP protocol, you can reduce the timeout period for IPVS UDP sessions to minimize the effect of DNS resolution latency or failures. To do this, perform the following operations:

Note

If your applications use UDP, submit a ticket.

If your ACK cluster runs Kubernetes 1.18 or later:
- If you use an ACK managed cluster, modify the udpTimeout parameter in the kube-proxy-worker ConfigMap. Then, delete the kube-proxy-worker pods. The system automatically recreates the pods for the configuration to take effect. For more information about how to modify the kube-proxy-worker ConfigMap and delete its pods, see How do I modify the configurations of kube-proxy?
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: kube-proxy-worker
  namespace: kube-system
data:
  config.conf: |
    apiVersion: kubeproxy.config.k8s.io/v1alpha1
    kind: KubeProxyConfiguration
    # Irrelevant fields are not shown. 
    mode: ipvs
    // If the ipvs field does not exist, you must add the field. 
    ipvs:
      udpTimeout: 10s // The default timeout period is 300 seconds. In this example, the timeout period is set to 10 seconds. This way, the time period during which packet loss may occur is reduced to 10 seconds after a UDP connection is closed.
```
- If you use an ACK dedicated cluster, modify the udpTimeout parameter in the kube-proxy-worker and kube-proxy-master ConfigMaps. Then, delete the kube-proxy-worker and kube-proxy-master pods. The system automatically recreates the pods for the configurations to take effect. For more information about how to modify the kube-proxy-worker ConfigMap and delete its pods, see How do I modify the configurations of kube-proxy?
If your ACK cluster runs Kubernetes 1.16 or earlier:
kube-proxy in an ACK cluster that runs Kubernetes 1.16 or earlier does not support the udpTimeout parameter. To change the timeout period of UDP sessions, we recommend that you use CloudOps Orchestration Service (OOS) to run the following ipvsadm commands on all ECS instances in the cluster at the same time: Run the following commands:
```
yum install -y ipvsadm
ipvsadm -L --timeout > /tmp/ipvsadm_timeout_old
ipvsadm --set 900 120 10
ipvsadm -L --timeout > /tmp/ipvsadm_timeout_new
diff /tmp/ipvsadm_timeout_old /tmp/ipvsadm_timeout_new
```
For more information about how to use OOS to manage multiple ECS instances at the same time, see Manage multiple instances at a time.

How do I fix common issues related to IPv4/IPv6 dual stack?

Issue: The pod IP addresses displayed in kubectl are still IPv4 addresses.
Solution: Run the following command to display pod IPv6 addresses:
```
kubectl get pods -A -o jsonpath='{range .items[*]}{@.metadata.namespace} {@.metadata.name} {@.status.podIPs[*].ip} {"\n"}{end}'
```
Issue: The cluster IP addresses displayed in kubectl are still IPv4 addresses.
Solution:
1. Confirm that the spec.ipFamilyPolicy field is not set to SingleStack.
2. Run the following command to display cluster IPv6 addresses:
```
kubectl get svc -A -o jsonpath='{range .items[*]}{@.metadata.namespace} {@.metadata.name} {@.spec.ipFamilyPolicy} {@.spec.clusterIPs[*]} {"\n"}{end}'
```

Issue: You cannot access a pod by using its IPv6 address.

Cause: By default, some applications do not listen on IPv6 addresses, such as NGINX containers.

Solution: Run the netstat -anp command to check whether the pod listens on IPv6 addresses.

Expected output:

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.XX.XX:10248         0.0.0.0:*               LISTEN      8196/kubelet
tcp        0      0 127.0.XX.XX:41935         0.0.0.0:*               LISTEN      8196/kubelet
tcp        0      0 0.0.XX.XX:111             0.0.0.0:*               LISTEN      598/rpcbind
tcp        0      0 0.0.XX.XX:22              0.0.0.0:*               LISTEN      3577/sshd
tcp6       0      0 :::30500                :::*                    LISTEN      1916680/kube-proxy
tcp6       0      0 :::10250                :::*                    LISTEN      8196/kubelet
tcp6       0      0 :::31183                :::*                    LISTEN      1916680/kube-proxy
tcp6       0      0 :::10255                :::*                    LISTEN      8196/kubelet
tcp6       0      0 :::111                  :::*                    LISTEN      598/rpcbind
tcp6       0      0 :::10256                :::*                    LISTEN      1916680/kube-proxy
tcp6       0      0 :::31641                :::*                    LISTEN      1916680/kube-proxy
udp        0      0 0.0.0.0:68              0.0.0.0:*                           4892/dhclient
udp        0      0 0.0.0.0:111             0.0.0.0:*                           598/rpcbind
udp        0      0 47.100.XX.XX:323           0.0.0.0:*                           6750/chronyd
udp        0      0 0.0.0.0:720             0.0.0.0:*                           598/rpcbind
udp6       0      0 :::111                  :::*                                598/rpcbind
udp6       0      0 ::1:323                 :::*                                6750/chronyd
udp6       0      0 fe80::216:XXXX:fe03:546 :::*                                6673/dhclient
udp6       0      0 :::720                  :::*                                598/rpcbind

If the value in the Proto column is tcp, the pod listens on IPv4 addresses. If the value is tcp6, the pod listens on IPv6 addresses.

Issue: You can access a pod by using its IPv6 address within the cluster but not from the Internet.
Cause: No public bandwidth is configured for the IPv6 address.
Solution: Configure public bandwidth for the IPv6 address. For more information, see Enable and manage IPv6 Internet bandwidth.

Issue: You cannot access a pod by using the cluster IPv6 address.

Solution:

Confirm that the spec.ipFamilyPolicy field is not set to SingleStack.

Run the netstat -anp command to check whether the pod listens on IPv6 addresses.

Expected output:

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.XX.XX:10248         0.0.0.0:*               LISTEN      8196/kubelet
tcp        0      0 127.0.XX.XX:41935         0.0.0.0:*               LISTEN      8196/kubelet
tcp        0      0 0.0.XX.XX:111             0.0.0.0:*               LISTEN      598/rpcbind
tcp        0      0 0.0.XX.XX:22              0.0.0.0:*               LISTEN      3577/sshd
tcp6       0      0 :::30500                :::*                    LISTEN      1916680/kube-proxy
tcp6       0      0 :::10250                :::*                    LISTEN      8196/kubelet
tcp6       0      0 :::31183                :::*                    LISTEN      1916680/kube-proxy
tcp6       0      0 :::10255                :::*                    LISTEN      8196/kubelet
tcp6       0      0 :::111                  :::*                    LISTEN      598/rpcbind
tcp6       0      0 :::10256                :::*                    LISTEN      1916680/kube-proxy
tcp6       0      0 :::31641                :::*                    LISTEN      1916680/kube-proxy
udp        0      0 0.0.0.0:68              0.0.0.0:*                           4892/dhclient
udp        0      0 0.0.0.0:111             0.0.0.0:*                           598/rpcbind
udp        0      0 47.100.XX.XX:323           0.0.0.0:*                           6750/chronyd
udp        0      0 0.0.0.0:720             0.0.0.0:*                           598/rpcbind
udp6       0      0 :::111                  :::*                                598/rpcbind
udp6       0      0 ::1:323                 :::*                                6750/chronyd
udp6       0      0 fe80::216:XXXX:fe03:546 :::*                                6673/dhclient
udp6       0      0 :::720                  :::*                                598/rpcbind

If the value in the Proto column is tcp, the pod listens on IPv4 addresses. If the value is tcp6, the pod listens on IPv6 addresses.

Issue: You cannot access the Internet from a pod by using an IPv6 address.
Solution: Create an IPv6 gateway for the VPC in which the pod resides and configure public bandwidth for the IPv6 address that you use. For more information, see Create and manage an IPv6 gateway and Enable and manage IPv6 Internet bandwidth.

How do I resolve the issue that the IP addresses provided by vSwitches are insufficient when my cluster uses the Terway network plug-in?

Issue

A pod fails to be created. After you log on to the VPC console, select the region in which you want to create the pod, and then click vSwitch in the left-side navigation pane to go to the vSwitch page, you find that the number of available IP addresses of the vSwitch is 0. For more information about how to troubleshoot this issue, see What to do next.

Cause

The vSwitch used by the Terway network of the node does not have sufficient idle IP addresses. Consequently, no IP address is assigned to the pod that you want to create and the pod remains in the ContainerCreating state.

Solution

Perform the following steps to add another vSwitch:

Log on to the VPC console, select a region in the top navigation bar, and then create a vSwitch.
Note
The vSwitch that you create must reside in the region and zone of the vSwitch that does not have sufficient idle IP addresses. If the number of pods continuously grows, we recommend that you set the mask length of the vSwitch CIDR block for pods to a value that is smaller than or equal to 19. This ensures that the CIDR block contains at least 8,192 IP addresses.
Run one of the following commands to delete all Terway pods. The system then recreates the Terway pods.
Note
If you choose Terway when you create the cluster and have selected Assign One ENI to Each Pod, your ENI has only one IP address. If you do not select this option, your ENI has multiple IP addresses. For more information, see Work with Terway.
- If the ENI uses multiple IP addresses, run the following command: kubectl delete -n kube-system pod -l app=terway-eniip.
- If the ENI uses only one IP address, run the following command: kubectl delete -n kube-system pod -l app=terway-eni.
Run the kubectl get pod command to verify that all Terway pods are recreated.
Create a pod. Verify that the pod is created and an IP address is assigned from the vSwitch to the pod.

What to do next

Connect to your ACK cluster and run the kubectl get pod command. The output indicates that the pod is in the ContainerCreating state. For more information about how to connect to an ACK cluster, see Obtain the kubeconfig file of a cluster and use kubectl to connect to the cluster. Run the following command to print the Terway container log of the node that hosts the pod:

kubectl get pod -l app=terway-eniip -n kube-system | grep [$Node_Name] # [$Node_Name] indicates the name of the node that hosts the pod. You can use the node name to identify the Terway pod on the node.
kubectl logs --tail=100 -f [$Pod_Name] -n kube-system -c terway # [$Pod_Name] indicates the name of the Terway pod on the node.

If the InvalidVSwitchId.IpNotEnough error message appears, the vSwitch does not have sufficient idle IP addresses.

time="2020-03-17T07:03:40Z" level=warning msg="Assign private ip address failed: Aliyun API Error: RequestId: 2095E971-E473-4BA0-853F-0C41CF52651D Status Code: 403 Code: InvalidVSwitchId.IpNotEnough Message: The specified VSwitch \"vsw-AAA\" has not enough IpAddress., retrying"

What do I do if the IP address of a newly created pod does not fall within the vSwitch CIDR block in Terway mode?

Issue

In Terway mode, the IP address of a newly created pod does not fall within the vSwitch CIDR block.

Cause

This issue may occur in the following scenarios:

You add a node that is removed from another cluster to your cluster. The node was not drained before it was removed. In this case, the node uses the ENI that was attached by the cluster to which the node previously belonged.
You manually add or modify the vSwitches used by Terway. However, a node may still be attached to the original ENI. In this case, the ENI assigns IP addresses to newly created pods on the node from the vSwitch to which the ENI belongs.

Solution

You can create new nodes. You can also remove nodes from the cluster and then add the removed nodes to the cluster.

To remove nodes and then add the removed nodes, perform the following steps:

Drain and remove nodes. For more information, see Remove nodes.
Disassociate the ENIs from the removed nodes. For more information, see Unbind a secondary ENI.
Add the removed nodes back to the ACK cluster. For more information, see Add existing ECS instances to an ACK cluster.

What do I do if the IP address of a newly created pod does not fall within the vSwitch CIDR block after I add a vSwitch in Terway mode?

Issue

In Terway mode, the IP address of a newly created pod does not fall within the vSwitch CIDR block after you add a vSwitch.

Cause

After the pod is created, the ENI of the ECS instance assigns an IP address from the VPC CIDR block to the pod. You can configure vSwitches only if a newly created ENI is attached to the node. If an ENI is attached to the node before you add the node to the cluster or modify vSwitches used by Terway, the ENI assigns IP addresses to newly created pods on the node from the vSwitch to which the ENI belongs. However, the number of ENIs that are attached to the node reaches the upper limit and new ENIs cannot be created. As a result, this error occurs. For more information about the ENI quota, see Overview.

Solution

You can create new nodes. You can also remove nodes from the cluster and then add the removed nodes to the cluster.

To remove nodes and then add the removed nodes, perform the following steps:

Drain and remove nodes. For more information, see Remove nodes.
Disassociate the ENIs from the removed nodes. For more information, see Unbind a secondary ENI.
Add the removed nodes back to the ACK cluster. For more information, see Add existing ECS instances to an ACK cluster.

How do I enable load balancing within a cluster in Terway IPVLAN mode?

Issue

In Terway IPVLAN mode, when you create a cluster that uses Terway 1.2.0 or later, load balancing is automatically enabled within the cluster. If you access an external IP address or a Server Load Balancer (SLB) instance from within a cluster, the traffic is routed to the backend Service. How do I enable load balancing within an existing cluster that uses the Terway IPVLAN mode?

Cause

If you access an external IP address or an SLB instance from within a cluster, kube-proxy directly routes the traffic to the endpoint of the backend Service. In Terway IPVLAN mode, the traffic is handled by Cilium instead of kube-proxy. This feature is not supported in Terway versions earlier than 1.2.0. This feature is automatically enabled for clusters that use Terway 1.2.0 or later versions. You must manually enable this feature for clusters that use Terway versions earlier than 1.2.0.

Solution

Note

Update Terway to 1.2.0 or later and enable the IPVLAN mode.
If the IPVLAN mode is not enabled, the following configurations do not take effect.
This feature is automatically enabled for newly created clusters that use Terway 1.2.0 or later versions.

Run the following command to modify the eni_conf ConfigMap of the Terway configurations:
```
kubectl edit cm eni-config -n kube-system
```
Add the following content to the eni_conf ConfigMap:
```
in_cluster_loadbalance: "true"
```
Note
Make sure that in_cluster_loadbalance is aligned with eni_conf.
Run the following command to enable load balancing within the cluster by recreating the Terway pod:
```
kubectl delete pod -n kube-system -l app=terway-eniip
```
Verify the configurations
Run the following command to print the policy log in terway-ennip. If enable-in-cluster-loadbalance=true is displayed in the log, the modification is in effect.
```
kubectl logs -n kube-system <terway pod name> policy | grep enable-in-cluster-loadbalance
```

How do I add the pod CIDR block to a whitelist if my cluster uses Terway?

Issue

You want to enforce access control on services such as database services by using whitelists. To configure access control in container networks, you must add pod IP addresses to a whitelist. However, pod IP addresses dynamically change.

Cause

ACK provides the Flannel and Terway network plug-ins to set up the container network:

If your cluster uses Flannel, pods in the cluster use the IP addresses of the nodes that host the pods to access services such as database services. You can schedule client pods to a small number of nodes and then add the IP addresses of these nodes to the whitelist of a database service.
If your cluster uses Terway, ENIs assign IP addresses to pods in the cluster. Pods use the IP addresses assigned by ENIs to access external services. Therefore, client pods do not use the IP addresses of nodes to access external services even if you schedule the client pods to specific nodes based on affinity settings. Random IP addresses are allocated to pods from the vSwitch that is specified by Terway. In most cases, auto scaling is required for pods. Therefore, static IP addresses are not suitable for pods. To meet the requirement of auto scaling, we recommend that you specify a CIDR block for pods and then add the CIDR block to the whitelist of a database service that you want to access.

Solution

Add a label to a node to specify the vSwitch that is used to allocate IP addresses to pods. This way, the system uses the vSwitch to allocate IP addresses to pods when the pods are scheduled to the node with the specified label.

Create a ConfigMap named eni-config-fixed in the kube-system namespace. Specify the vSwitch that you want to use in the ConfigMap.

In this example, the vsw-2zem796p76viir02c**** vSwitch is used. The CIDR block of the vSwitch is 10.2.1.0/24.

apiVersion: v1
data:
  eni_conf: |
    {
       "vswitches": {"cn-beijing-h":["vsw-2zem796p76viir02c****"]},
       "security_group": "sg-bp19k3sj8dk3dcd7****",
       "security_groups": ["sg-bp1b39sjf3v49c33****","sg-bp1bpdfg35tg****"]
    }
kind: ConfigMap
metadata:
  name: eni-config-fixed
  namespace: kube-system

Create a node pool and add the terway-config: eni-config-fixed label to nodes in the node pool. For more information about how to create a node pool, see Procedure.
To ensure that irrelevant pods are not scheduled to the nodes in the node pool, add specific taints. For example, you can add the fixed=true:NoSchedule taint to the nodes.
Scale out the node pool. For more information, see Increase the number of nodes in an ACK cluster.
The label and taint that you added in the previous step are automatically added to the nodes that are newly added to the node pool.

Create pods. To ensure that the pods are scheduled to nodes with the terway-config: eni-config-fixed label, you must add a specific toleration rule to the pod configuration.

apiVersion: apps/v1 # Use apps/v1beta1 in clusters that run Kubernetes 1.8.0 or earlier. 
kind: Deployment
metadata:
  name: nginx-fixed
  labels:
    app: nginx-fixed
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-fixed
  template:
    metadata:
      labels:
        app: nginx-fixed
    spec:
      tolerations:        # Add a toleration rule. 
      - key: "fixed"
        operator: "Equal"
        value: "true"
        effect: "NoSchedule"
      nodeSelector:
        terway-config: eni-config-fixed
      containers:
      - name: nginx
        image: nginx:1.9.0 # Replace the value with the actual image that you use. Format: <image_name:tags>. 
        ports:
        - containerPort: 80

Verify scheduled scaling

Run the following command to query the IP addresses of the pods that you created:

kubectl get po -o wide | grep fixed

Expected output:

nginx-fixed-57d4c9bd97-l****                   1/1     Running             0          39s    10.2.1.124    bj-tw.062149.aliyun.com   <none>           <none>
nginx-fixed-57d4c9bd97-t****                   1/1     Running             0          39s    10.2.1.125    bj-tw.062148.aliyun.com   <none>           <none>

The output indicates that the IP addresses of the pods are allocated from the vSwitch that you specified.

Run the following command to increase the number of pods to 30:

kubectl scale deployment nginx-fixed --replicas=30

Expected output:

nginx-fixed-57d4c9bd97-2****                   1/1     Running     0          60s     10.2.1.132    bj-tw.062148.aliyun.com   <none>           <none>
nginx-fixed-57d4c9bd97-4****                   1/1     Running     0          60s     10.2.1.144    bj-tw.062149.aliyun.com   <none>           <none>
nginx-fixed-57d4c9bd97-5****                   1/1     Running     0          60s     10.2.1.143    bj-tw.062148.aliyun.com   <none>           <none>
...

The output indicates that the IP addresses of the pods are allocated from the vSwitch that you specified. You can add the CIDR block of the vSwitch to the whitelist of a database service that you want to access. This way, access control is enforced for pods that use dynamic IP addresses.

Note

We recommend that you create new nodes. If you use existing nodes, you must disassociate ENIs from the ECS instances before you can add the ECS instances to the cluster. You must add existing nodes in Auto mode. In Auto mode, the system disks of the nodes are replaced. For more information, see Unbind a secondary ENI and Automatically add nodes.
You must add specific labels and taints to the nodes in the node pools that you want to use to host client pods. This ensures that irrelevant pods are not scheduled to the node pools.
After you create the eni-config-fixed ConfigMap, it overwrites the eni-config ConfigMap. For more information about how to configure the eni-config ConfigMap, see terway.
We recommend that you specify a vSwitch that can provide at least twice as many IP addresses as the client pods. This ensures sufficient IP addresses when pods are scaled out or IP addresses cannot be reclaimed.

What do I do if I fail to ping ECS nodes from a pod?

Issue

Your cluster uses Flannel and the VPN gateway works as expected. After you log on to a pod, you fail to ping specific ECS nodes.

Cause

You may fail to ping specific ECS nodes due to the following causes:

Cause 1: The ECS instances that you access from the pod are deployed in the same VPC as the cluster in which the pod is deployed but do not belong to the same security group as the cluster.
Cause 2: The ECS instances that you access from the pod are not deployed in the same VPC as the cluster in which the pod is deployed.

Solution

Resolve the issue based on the cause.

If the issue is caused by Cause 1, you must add the ECS instances to the security group to which the cluster belongs. For more information, see Configure a security group.
If the issue is caused by Cause 2, you must add the public IP address of the cluster in which the pod is deployed to the inbound rules of the security group to which the ECS instances belong.

What do I do if a node has the NodeNetworkUnavailable taint?

Issue

In a cluster that uses Flannel, a newly added node has the NodeNetworkUnavailable taint and pods cannot be scheduled to the node.

Cause

The NodeNetworkUnavailable taint is not deleted by the cloud controller manager (CCM) for reasons such as the route table being full or the VPC having multiple route tables.

Solution

Run the kubectl describe node command to check the node events and fix the issue based on the returned error message. For more information about how to configure multiple route tables using the CCM, see Configure multiple route tables for a VPC.

What do I do if a pod fails to be started and the "no IP addresses available in range" error message appears?

Issue

You fail to start a pod in the Flannel network and the failed to allocate for range 0: no IP addresses available in range set: 172.30.34.129-172.30.34.190 error message is displayed in the relevant pod event.

Cause

In the Flannel network, a CIDR block is allocated to each node in the cluster. When the system schedules a pod to a node, Flannel allocates an idle IP address from the pod CIDR block of the node to the pod. If the failed to allocate for range 0: no IP addresses available in range set: 172.30.34.129-172.30.34.190 error message is returned during pod scheduling, no idle IP address can be allocated. This error may be caused by IP leaks in the following cases:

In ACK clusters that run Kubernetes versions earlier than 1.20, pod IP addresses may be leaked if the pods are repeatedly restarted or the pods created by CronJobs exit within a short period of time. For more information, see Issues 75665 and Issues 92614.
If a Flannel version earlier than 0.15.1.11-7e95fe23-aliyun is used, pods may be destroyed when the host is restarted or accidentally shut down. In this case, the IP addresses of the pods are leaked. For more information, see Issues 332.

Solution

If the Kubernetes version of your cluster is earlier than 1.20, update the Kubernetes version to 1.20 or later. For more information, see Manually update a cluster.
If the version of the Flannel plug-in used by your cluster is earlier than 0.15.1.11-7e95fe23-aliyun, perform the following steps to update the Flannel plug-in to 0.15.1.11-7e95fe23-aliyun or later. To do this, perform the following steps:
If your cluster uses Flannel 0.15.1.11-7e95fe23-aliyun or later, ACK migrates the database that stores the default CIDR block to the temporary directory /var/run. If a node is restarted, the system automatically deletes the data in the temporary directory to prevent leaking the IP addresses in the temporary directory.
1. Update Flannel to 0.15.1.11-7e95fe23-aliyun or later. For more information, see Manage components.
2. Run the following command to modify the kube-flannel-cfg file. Add the dataDir and ipam parameters to the kube-flannel-cfg file.
```
kubectl -n kube-system edit cm kube-flannel-cfg
```
  Sample kube-flannel-cfg file:
```
# The original settings
    {
      "name": "cb0",
      "cniVersion":"0.3.1",
      "plugins": [
        {
          "type": "flannel",
          "delegate": {
            "isDefaultGateway": true,
            "hairpinMode": true
           },
        },
        // portmap # This configuration may not be used in earlier versions of Flannel. You ignore this configuration if it is not required. 
        {
          "type": "portmap",
          "capabilities": {
            "portMappings": true
          },
          "externalSetMarkChain": "KUBE-MARK-MASQ"
        }
      ]
    }

# The modified settings
    {
      "name": "cb0",
      "cniVersion":"0.3.1",
      "plugins": [
        {
          "type": "flannel",
          "delegate": {
            "isDefaultGateway": true,
            "hairpinMode": true
           },
          // Add a comma (,) to the end of each parameter. 
          "dataDir": "/var/run/cni/flannel",
          "ipam": {
            "type": "host-local",
            "dataDir": "/var/run/cni/networks"
           }
        },
        {
          "type": "portmap",
          "capabilities": {
            "portMappings": true
          },
          "externalSetMarkChain": "KUBE-MARK-MASQ"
        }
      ]
    }
```
3. Run the following command to restart Flannel pods:
  The restart operation does not interrupt workloads that are running.
```
kubectl -n kube-system delete pod -l app=flannel
```
4. Delete the directories that store CIDR blocks on nodes and then restart the nodes.
  1. Drain nodes. For more information, see Set node schedulability.
  2. Log on to each node and run the following command to delete the directory that stores the CIDR block:
```
rm -rf /etc/cni/
rm -rf /var/lib/cni/
```
  3. Restart nodes. For more information, see Restart an instance.
  4. Repeat the preceding steps to delete the directories that store CIDR blocks on all nodes in your cluster.
5. Run the following command to check whether a temporary directory is created on the node to store the CIDR block:
```
if [ -d /var/lib/cni/networks/cb0 ]; then echo "not using tmpfs"; fi
if [ -d /var/run/cni/networks/cb0 ]; then echo "using tmpfs"; fi
cat /etc/cni/net.d/10-flannel.conf*
```
  If using tmpfs is returned, the current node has migrated the database that stores the default CIDR block to the temporary directory /var/run.

If you cannot update the Kubernetes version of your cluster or the Flannel plug-in used by your cluster within a short period of time, you can use the following method as a temporary solution. The following method applies only to pod IP address leaks that occur for the preceding reasons.

This method is used to delete the leaked pod IP addresses. You cannot use this method to prevent pod IP address leaks. Therefore, you still need to update the Kubernetes version of your cluster or the Flannel plug-in used by your cluster at the earliest opportunity.

Note

The following commands are not applicable to nodes that use Flannel 0.15.1.11-7e95fe23-aliyun or later and have stored CIDR blocks in the /var/run directory.
The following script is for reference only. If you have configured custom node configurations, you may fail to execute the script.

Set the node on which pod IP addresses are leaked as Unschedulable. For more information, see Set node schedulability.

Select a script based on the container runtime used by the node and execute the script on the node to delete the leaked pod IP addresses.

If the node uses Docker, execute the following script on the node to delete the leaked pod IP addresses:

#!/bin/bash
cd /var/lib/cni/networks/cb0;
docker ps -q > /tmp/running_container_ids
find /var/lib/cni/networks/cb0 -regex ".*/[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+" -printf '%f\n' > /tmp/allocated_ips
for ip in $(cat /tmp/allocated_ips); do
  cid=$(head -1 $ip | sed 's/\r#g' | cut -c-12)
  grep $cid /tmp/running_container_ids > /dev/null || (echo removing leaked ip $ip && rm $ip)
done

If the node uses containerd, execute the following script on the node to delete the leaked pod IP addresses:

#!/bin/bash
# install jq
yum install -y jq

# export all running pod's configs
crictl -r /run/containerd/containerd.sock pods -s ready -q | xargs -n1 crictl -r /run/containerd/containerd.sock inspectp > /tmp/flannel_ip_gc_all_pods

# export and sort pod ip
cat /tmp/flannel_ip_gc_all_pods | jq -r '.info.cniResult.Interfaces.eth0.IPConfigs[0].IP' | sort > /tmp/flannel_ip_gc_all_pods_ips

# export flannel's all allocated pod ip
ls -alh /var/lib/cni/networks/cb0/1* | cut -f7 -d"/" | sort > /tmp/flannel_ip_gc_all_allocated_pod_ips

# print leaked pod ip
comm -13 /tmp/flannel_ip_gc_all_pods_ips /tmp/flannel_ip_gc_all_allocated_pod_ips > /tmp/flannel_ip_gc_leaked_pod_ip

# clean leaked pod ip
echo "Found $(cat /tmp/flannel_ip_gc_leaked_pod_ip | wc -l) leaked Pod IP, press <Enter> to clean."
read sure

# delete leaked pod ip
for pod_ip in $(cat /tmp/flannel_ip_gc_leaked_pod_ip); do
    rm /var/lib/cni/networks/cb0/${pod_ip}
done

echo "Leaked Pod IP cleaned, removing temp file."
rm /tmp/flannel_ip_gc_all_pods_ips /tmp/flannel_ip_gc_all_pods /tmp/flannel_ip_gc_leaked_pod_ip /tmp/flannel_ip_gc_all_allocated_pod_ips

Set the node as Schedulable. For more information, see Set node schedulability.

How do I modify the number of node IP addresses, the pod CIDR block, and the Service IP block?

The number of node IP addresses, the pod CIDR block, and the Service IP block of a cluster cannot be modified after the cluster is created. We recommend that you properly configure these items when you create a cluster.

In what scenarios do I need to configure multiple route tables for a cluster?

In a cluster that uses Flannel, you need to use the cloud-controller-manager component to configure multiple route tables in the following scenarios. For more information, see Configure multiple route tables for a VPC.

Scenarios

Scenario 1:
The system diagnostic information indicates that the pod CIDR block is specified in the route table of the VPC and suggests that you add a custom route to add the next hop of the pod CIDR block to the current node.
Cause: When you create a custom route table in the cluster, you need to configure the CCM to support multiple route tables.
Scenario 2:
The cloud-controller-manager component reports the multiple route tables found error, which indicates that network errors occur.
Cause: If the cluster has multiple route tables, you need to configure the CCM to support multiple route tables.
Scenario 3:
In a cluster that uses Flannel, a newly added node has the NodeNetworkUnavailable taint, which is not deleted by the cloud-controller-manager component. As a result, pods cannot be scheduled to the node. For more information, see What do I do if a node has the NodeNetworkUnavailable taint?

Can I install and configure third-party network plug-ins for a cluster?

No, you cannot install or configure third-party network plug-ins for ACK clusters. If a third-party network plug-in is installed for an ACK cluster, the cluster network may become unavailable.

What do I do if a pod fails to be started and the `no IP addresses available in range` error message appears?

This issue occurs because the cluster uses the Flannel network plug-in. In the Flannel network, a CIDR block is allocated to each node in the cluster. The CIDR block cannot be changed. When the IP addresses in the CIDR block allocated to a node are exhausted, pods are no longer scheduled to the node. To resolve this issue, release some IP addresses or modify the network configurations of the cluster. For more information, see Plan the network of an ACK cluster.

What is the number of pods that can be created on a node in Terway mode?

In Terway mode, the number of pods that can be created on a node depends on the number of available IP addresses based on the ECS instance type. For more information, see Work with Terway.

What is the Terway DataPath V2 data plane mode?

When you create a cluster, if you select Terway 1.8.0 or later and DataPath V2, the DataPath V2 mode is enabled for the cluster by default. For existing clusters that have enabled the IPVLAN feature, the original IPVLAN mode is used on the data plane.
DataPath V2 is a next-generation data plane path. Compared with the IPVLAN mode, the DataPath V2 mode provides better compatibility. For more information, see Work with Terway.

How do I view the lifecycle of a pod in Terway mode?

Log on to the ACK console. In the left-side navigation pane, click Clusters.
On the Clusters page, find the cluster that you want to manage and click its name. In the left-side pane, choose Workloads > DaemonSets.
In the upper part of the DaemonSets page, click the icon to select kube-system from the Namespace drop-down list.

On the DaemonSets page, search for terway-eniip and click terway-eniip in the Name column.

The following table describes the status of pods.

Status	Description
Ready	All containers in the pod are started and are running as expected.
Pending	The pod is waiting for Terway to configure network resources. The pod cannot be scheduled to a specific node due to insufficient resources. For more information, see Pod troubleshooting.
ContainerCreating	The pod is scheduled to a specific node. This indicates that the pod is waiting for the network initialization to be complete.

For more information, see Pod lifecycle.

How do I troubleshoot Terway update failures?

Issue	Solution
The `eip pool is not supported` error occurs during the update.	This issue occurs because elastic IP addresses (EIPs) are no longer supported by Terway. If you want to use EIPs in the Terway network, see Migrate EIPs from Terway to ack-extend-network-controller.

What do I do if the MAC address of the ECS instance cannot be found during pod creation in Terway mode?

Issue

The pod fails to be created due to an error indicating that the MAC address of the ECS instance cannot be found.

 failed to do add; error parse config, can't found dev by mac 00:16:3e:xx:xx:xx: not found

Solution

ENIs are loaded asynchronously in the system and may not be completely loaded when you configure the CNI. In this case, the CNI automatically retries the ENI reload operation. The retry does not impact the system. You can check whether the pod is created based on the final state of the pod.
If this issue persists for a long period of time, the reason may be that high-order memory is insufficient, causing the failure of driver loading during the attachment process of an ENI. In this case, you can restart the ECS instance to resolve this issue.

Table of contents

Issues related to Terway

Issues related to Flannel

Issues related to kube-proxy

Issues related to IPv6

Other issues

Can I switch the network plug-in for an existing ACK cluster?

What do I do if a cluster installed with Terway cannot access the Internet after I create a vSwitch for the cluster?

What do I do if Flannel becomes incompatible with clusters of Kubernetes 1.16 or later after I manually update Flannel?

What do I do if a pod is not immediately ready for communication after it is started?

How do I enable a pod to access a Service that is used to expose the pod?

How do I choose between Terway and Flannel for an ACK cluster?

How do I plan the network of a cluster?

Can I use the hostPort feature to create port mappings in an ACK cluster?

How do I check the network type and vSwitches of a cluster?

How do I check the cloud resources used in an ACK cluster?

How do I modify the configurations of kube-proxy?

How do I increase the maximum number of tracked connections in the conntrack table of the Linux kernel?

How do I modify the IPVS load balancing algorithm in the configurations of kube-proxy?

How do I modify the timeout period for IPVS UDP sessions in the configurations of kube-proxy?

How do I fix common issues related to IPv4/IPv6 dual stack?

How do I resolve the issue that the IP addresses provided by vSwitches are insufficient when my cluster uses the Terway network plug-in?

What do I do if the IP address of a newly created pod does not fall within the vSwitch CIDR block in Terway mode?

What do I do if the IP address of a newly created pod does not fall within the vSwitch CIDR block after I add a vSwitch in Terway mode?

How do I enable load balancing within a cluster in Terway IPVLAN mode?

How do I add the pod CIDR block to a whitelist if my cluster uses Terway?

What do I do if I fail to ping ECS nodes from a pod?

What do I do if a node has the NodeNetworkUnavailable taint?

What do I do if a pod fails to be started and the "no IP addresses available in range" error message appears?

How do I modify the number of node IP addresses, the pod CIDR block, and the Service IP block?

In what scenarios do I need to configure multiple route tables for a cluster?

Scenarios

Can I install and configure third-party network plug-ins for a cluster?

What do I do if a pod fails to be started and the no IP addresses available in range error message appears?

What is the number of pods that can be created on a node in Terway mode?

What is the Terway DataPath V2 data plane mode?

How do I view the lifecycle of a pod in Terway mode?

How do I troubleshoot Terway update failures?

What do I do if the MAC address of the ECS instance cannot be found during pod creation in Terway mode?

Issue

Solution

What do I do if a pod fails to be started and the `no IP addresses available in range` error message appears?