A pod can access resources deployed in virtual private clouds (VPCs) as a client, including Elastic Compute Service (ECS) instances, Server Load Balancer (SLB) instances, and Object Storage Service (OSS) buckets. It can also access the Internet after configuration. This topic describes the notes when configuring a pod to access an external network.
Precautions for configuring a pod
Configure domain name resolution
When a pod accesses an external network, the pod uses the domain name resolution feature provided by the cluster to resolve the destination address. Then, it accesses the destination through the network policy on the pod side. If the domain name cannot be resolved, you need to troubleshoot DNS resolution errors. For more information, see DNS troubleshooting.
Configure network policies
Check whether a network policy is configured for the namespace to which the pod belongs, and whether the network policy forbids the pod from accessing the destination. If the preceding network policy exists, modify the policy. For more information, see Use network policies in ACK clusters.
Configure security groups
Check whether the security group of the cluster and the security group of the ECS instance that hosts the pod forbid the pod from accessing the destination. Ensure that the security group meets the following rules:
A security group rule is created to allow the pod to access the destination address and port in the outbound direction.
No security group rules are created to forbid the pod from accessing the destination address and port in the outbound direction.
For more information about how to manage security groups for clusters, see Configure security groups for clusters.
Precautions for configuring the destination
Pods in a cluster can access the Internet or resources deployed in VPCs, including existing resources such as ECS instances and SLB instances, cloud services such as ApsaraDB RDS and OSS, and LoadBalancer Services that are exposed by the cluster. The pod configuration varies based on the destination.
Access the Internet
In an IPv4 single-stack cluster, a pod uses only IPv4 addresses and can access only public IPv4 addresses. It cannot access IPv6 addresses.
After enabling dual-stack in the cluster, a pod uses both IPv4 addresses and IPv6 addresses. IPv4 addresses used by the pod are private IP addresses, while IPv6 addresses are public addresses.
The pod configuration varies based on the IP addresses that the pod needs to access.:
IPv4 single-stack cluster:
To enable the pod to access the Internet, you need to associate an elastic IP address (EIP) to the pod or use a NAT gateway. The following table describes the methods that you can use to configure the pod to access public IPv4 addresses:
Internet access method
Terway network plug-in
Flannel network plug-in
Use a NAT gateway
The SNAT rule needs to include the SNAT entry of the pod. For more information about how to configure the NAT gateway, see Enable an existing ACK cluster to access the Internet.
The public IP address used to access the external network is the EIP associated with the NAT gateway.
The SNAT rule needs to include the SNAT entry of the node where the pod resides. For more information about how to configure the NAT gateway, see Enable an existing ACK cluster to access the Internet.
The public IP address used to access the external network is the EIP associated with the NAT gateway.
Associate with an EIP
You can associate an EIP with the pod. For more information, see Associate an exclusive EIP with a pod.
The public IP address used to access the external network is the EIP associated with the pod.
The pod can only access the Internet using the EIP associated to the node. For more information, see Associate or disassociate an EIP.
The public IP address used to access the external network is the EIP associated with the node.
Method
Precaution
Public IP address used to access the external network
Use a NAT gateway
For clusters using Terway: The SNAT rule needs to include the SNAT entry of the pod.
For clusters using Flannel: The SNAT rule needs to include the SNAT entry of the node where the pod is located.
To configure the NAT gateway, see Enable public network access for an existing cluster.
The EIP associated with the NAT gateway.
Use the EIP that is associated with the node of the pod (only when Flannel is used)
Associate an EIP with the node (ECS instance) that hosts the pod. For more information, see Associate or disassociate an EIP.
The EIP associated with the node.
Use the EIP that is associated with the pod (only when Terway is used)
Associate an EIP with the pod. For more information, see Mount an independent public EIP to a pod.
The EIP associated with the pod.
Dual-stack cluster:
In a dual-stack cluster, the pod uses public IPv6 addresses, but no public bandwidth is allocated to the IPv6 addresses by default. For more information about how to allocate public bandwidth to the pod, see Allocate IPv6 Internet bandwidth to a pod.
Access resources in the VPC
When a pod accesses other resources in the cluster, such as ECS, RDS, and OSS, the destination may have some access control rules that block the source of accesses, such as security groups, Access Control List (ACL) rules, or whitelist mechanisms. If the source IP address used by the pod is blocked, you need to unblock it in the access control rules:
In Terway mode, the pod IP address is used. You need to modify the security group rules, ACL rules, and whitelists used by other resources in the VPC to accept accesses from the pod IP address.
In Flannel mode, the IP address of the node on which the pod resides is used. You need to modify the security group rules, ACL rules, and whitelists used by other resources in the VPC to accept accesses from the IP address of the ECS on which the pod resides..
You can also use ack-kubernetes-webhook-injector to automatically configure the whitelist. For more information, see Dynamically configure a pod whitelist for an Alibaba Cloud service.
Access the SLB instance used by the cluster
When a pod accesses the SLB instance used by the Service in the cluster, it uses a mechanism where the traffic is routed to the backend pod for direct access, and the actual traffic does not leave the cluster. In Terway 1.1.0 or earlier versions, clusters using IPVLAN + eBPF acceleration mode do not support this mechanism and uses the IP address of the SLB instance for access. In Terway 1.2.0 or later versions, newly created clusters support this feature, while existing clusters do not. For more information about this mechanism, see How do I enable load balancing within a cluster in Terway IPVLAN mode?.