Accessing Cloud Services from a Pod in a Different VPC

Pods cannot communicate with each other across VPCs. To resolve this issue, you can use VPC peering to connect two VPCs so that pods in one VPC can access services in the other VPC. The method of setting up cross-VPC connectivity varies depending on the clusters' network types. For details, see Table 1.

**Table 1** Cross-VPC access for clusters of different network types
Network Model	Description	Cross-VPC Access Process (Example: Accessing an ECS from a Pod)
Tunnel network	Data packets are encapsulated through tunnels in the node network. To access resources from a pod in a different VPC, ensure that the node CIDR block can communicate with the target VPC.	Create a VPC peering connection between the local and peer VPCs. For details, see Step 2 Create a VPC peering connection. Add a route between the two VPCs based on their CIDR blocks. For details, see Step 3 Add a route between the VPCs. Verify the cross-VPC access. For details, see Step 5 Verify the configuration.
VPC network	Pod traffic is forwarded through VPC routing. The CIDR block of the pod is independent of the CIDR block of the VPC where the node is located. To access services from a pod in a different VPC, ensure the connectivity between the node CIDR block and the target VPC, as well as between the container CIDR block and the target VPC.	Create a VPC peering connection between the local and peer VPCs. For details, see Step 2 Create a VPC peering connection. Add a route between the two VPCs based on their CIDR blocks. For details, see Step 3 Add a route between the VPCs. Add a route based on the CIDR block of local-end containers and the CIDR block of the peer VPC. For details, see Step 4 Add a route between the container CIDR block and the peer VPC. Verify the cross-VPC access. For details, see Step 5 Verify the configuration.
Cloud Native Network 2.0	Containers receive IP addresses from VPC CIDR blocks. Container CIDR blocks are part of the VPC subnet where the node is located. To access resources from a pod in a different VPC, ensure that the VPC subnet where the pod locates can communicate with the target VPC.	Create a VPC peering connection between the local and peer VPCs. For details, see Step 2 Create a VPC peering connection. Add a route between the two VPCs based on their CIDR blocks. For details, see Step 3 Add a route between the VPCs. Verify the cross-VPC access. For details, see Step 5 Verify the configuration.

Cloud services that communicate with CCE include ECS, ELB, RDS, DCS, Kafka, RabbitMQ, ModelArts, and DDS. To ensure successful communication, make sure your network is configured correctly and verify that the cloud service you want to access allows external access. For example, accessing DCS Redis requires being trustlisted. If you cannot configure the trustlist on the service console, create a service ticket in the target service. The following describes the operations and precautions for accessing an ECS from a pod and an RDS MySQL DB instance from a pod.

Prerequisites

A CCE cluster is available. For details, see Buying a CCE Standard/Turbo Cluster.
A pod is available in the cluster. For details, see Creating a Deployment.

For example, the cluster's VPC is vpc-demo1, the CIDR blocks are 192.168.0.0/18 and 172.1.0.0/24, and the subnet where the cluster resides is 192.168.0.0/18. The cluster uses a VPC network, and the container CIDR block is 172.1.1.0/24. The following describes how to set up cross-VPC connectivity.

Purchase an ECS. For details, see Purchasing and Using a Linux ECS. The ECS and the cluster are in the same region but in different VPCs. The ECS's VPC is vpc-demo2, the CIDR block is 10.1.0.0/16, and the IP address of the ECS is 10.1.1.24.

Create a VPC peering connection.

Switch to the console, click in the upper left corner, and choose Networking > Virtual Private Cloud in the expanded list.
In the navigation pane, choose VPC Peering Connections. In the upper right corner of the displayed page, click Create VPC Peering Connection.

Configure parameters as prompted. For details, see Table 2.

Figure 1 Creating a VPC peering connection
Click to enlarge

**Table 2** Parameters for creating a VPC peering connection
Parameter	Description	Example
VPC Peering Connection Name	Mandatory. Enter a name for the VPC peering connection. The name can contain a maximum of 64 characters, including letters, digits, hyphens (-), and underscores (_).	peering-demo
Local VPC	Mandatory. Local-end VPC of the peering connection. You can choose one from the drop-down list.	vpc-demo1
Local VPC CIDR Block	CIDR block of the selected local-end VPC.	192.168.0.0/18 and 172.1.0.0/24
Account	Mandatory. My account: The local and peer VPCs are from the same account. Another account: The local and peer VPCs are from different accounts.	My account
Peer Project	The system fills in the corresponding project by default because Account is set to My account. For example, vpc-demo1 and vpc-demo2 are both under account A in region A. Then, the system fills in the project of account A in region A by default.	None
Peer VPC	This parameter is mandatory if Account is set to My account. VPC at the other end of the peering connection. You can choose one from the drop-down list.	vpc-demo2
Peer VPC CIDR Block	CIDR block of the selected peer VPC. NOTICE: If the local and peer VPCs have overlapping CIDR blocks, the VPC peering connection may not take effect.	10.1.0.0/16

After configuring the parameters, click Create Now.
In the displayed dialog box, click Add Now.

Add a route between the VPCs. Add a route to the VPC route table as prompted. Table 3 describes some parameters.

Figure 2 Adding a route between the VPCs
Click to enlarge

**Table 3** Route parameters
Parameter	Description	Example
VPC	Select a VPC that is connected by the VPC peering connection.	vpc-demo1
Route Table	Select the route table of the VPC. The route will be added to this route table. Each VPC comes with a default route table that manages the flow of outgoing traffic from the subnets in the VPC. In addition to the default route table, you can create a custom route table and associate it with the subnets in the VPC. Then, the custom route table controls outbound traffic of the subnets. If there is only the default route table in the drop-down list, select the default route table. If there are both default and custom route tables in drop-down list, select the route table associated with the subnet connected by the VPC peering connection.	rtb-vpc-demo1 (default route table)
Destination	IP address in the VPC at the other end of the VPC peering connection. The value can be a VPC CIDR block, subnet CIDR block, or ECS IP address.	10.1.0.0/16
Next Hop	The default value is the current VPC peering connection. You do not need to specify this parameter.	peering-demo
Add a route for the other VPC	If you select this option, you can also add a route for the other VPC connected by the VPC peering connection. To allow VPCs connected through VPC peering to communicate, you must include forward and return routes in the VPCs' route tables.	Selected
VPC	By default, the system selects the other VPC connected by the VPC peering connection. You do not need to specify this parameter.	vpc-demo2
Route Table	Select the route table of the VPC. The route will be added to this route table. Each VPC comes with a default route table that manages the flow of outgoing traffic from the subnets in the VPC. In addition to the default route table, you can create a custom route table and associate it with the subnets in the VPC. Then, the custom route table controls outbound traffic of the subnets. If there is only the default route table in the drop-down list, select the default route table. If there are both default and custom route tables in drop-down list, select the route table associated with the subnet connected by the VPC peering connection.	rtb-vpc-demo2 (default route table)
Destination	IP address in the VPC at the other end of the VPC peering connection. The value can be a VPC CIDR block, subnet CIDR block, or ECS IP address.	192.168.0.0/18
Next Hop	The default value is the current VPC peering connection. You do not need to specify this parameter.	peering-demo

Add a route between the peer VPC and the container CIDR block. Click Add Route. In the Add Route dialog box, set VPC to the peer VPC and Destination to the container CIDR block. For details, see Figure 3.

Figure 3 Adding a route to the container CIDR block
Verify the configuration. Check whether the security group inbound rules of the peer service include the CIDR blocks of the local node and container (only necessary if the cluster network model is VPC). If they are not included, add a rule. For details, see Step 3 Add the container CIDR block to the security group inbound rules of the ECS. Log in to the container. For details, see Logging In to a Container. Enter the following code on the CloudShell page of the pod again, where 10.1.1.24 indicates the IP address of the peer service that is accessed.

ping 10.1.1.24

If information similar to the following is displayed, cross-VPC access from the pod is successful:
```
PING 10.1.1.24 (10.1.1.24): 56 data bytes
64 bytes from 10.1.1.24: seq=0 ttl=64 time=1.412 ms
64 bytes from 10.1.1.24: seq=1 ttl=64 time=1.400 ms
64 bytes from 10.1.1.24: seq=2 ttl=64 time=1.299 ms
64 bytes from 10.1.1.24: seq=3 ttl=64 time=1.283 ms
--- 10.1.1.24 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
```

Buy an RDS for MySQL instance. For details, see Buying a DB Instance and Connecting to It Using a MySQL Client. The instance and the cluster are in the same region but in different VPCs. The instance's VPC is vpc-373896-1, the CIDR block is 172.16.0.0/12, and the IP address is 172.16.0.167.

Create a VPC peering connection.

Switch to the console, click in the upper left corner, and choose Networking > Virtual Private Cloud in the expanded list.
In the navigation pane, choose VPC Peering Connections. In the upper right corner of the displayed page, click Create VPC Peering Connection.

Configure parameters as prompted. For details, see Table 4.

Figure 4 Creating a VPC peering connection
Click to enlarge

**Table 4** Parameters for creating a VPC peering connection
Parameter	Description	Example
VPC Peering Connection Name	Mandatory. Enter a name for the VPC peering connection. The name can contain a maximum of 64 characters, including letters, digits, hyphens (-), and underscores (_).	peering-b34b
Local VPC	Mandatory. Local-end VPC of the peering connection. You can choose one from the drop-down list.	vpc-373896-1
Local VPC CIDR Block	CIDR block of the selected local-end VPC.	172.16.0.0/12
Account	Mandatory. My account: The local and peer VPCs are from the same account. Another account: The local and peer VPCs are from different accounts.	My account
Peer Project	The system fills in the corresponding project by default because Account is set to My account. For example, vpc-demo1 and vpc-demo2 are both under account A in region A. Then, the system fills in the project of account A in region A by default.	None
Peer VPC	This parameter is mandatory if Account is set to My account. VPC at the other end of the peering connection. You can choose one from the drop-down list.	vpc-demo1
Peer VPC CIDR Block	CIDR block of the selected peer VPC. NOTICE: If the local and peer VPCs have overlapping CIDR blocks, the VPC peering connection may not take effect.	192.168.0.0/18 and 172.1.0.0/24

After configuring the parameters, click Create Now.
In the displayed dialog box, click Add Now.

Add a route between the VPCs. Add a route to the VPC route table as prompted. Table 5 describes some parameters.

Figure 5 Adding a route between the VPCs
Click to enlarge

**Table 5** Route parameters
Parameter	Description	Example
VPC	Select a VPC that is connected by the VPC peering connection.	vpc-373896-1
Route Table	Select the route table of the VPC. The route will be added to this route table. Each VPC comes with a default route table that manages the flow of outgoing traffic from the subnets in the VPC. In addition to the default route table, you can create a custom route table and associate it with the subnets in the VPC. Then, the custom route table controls outbound traffic of the subnets. If there is only the default route table in the drop-down list, select the default route table. If there are both default and custom route tables in drop-down list, select the route table associated with the subnet connected by the VPC peering connection.	rtb-d43b (custom route table) NOTICE: The custom route table must be associated with the subnet connected by the VPC peering connection.
Destination	IP address in the VPC at the other end of the VPC peering connection. The value can be a VPC CIDR block, subnet CIDR block, or ECS IP address.	192.168.0.0/18
Next Hop	The default value is the current VPC peering connection. You do not need to specify this parameter.	peering-b34b
Add a route for the other VPC	If you select this option, you can also add a route for the other VPC connected by the VPC peering connection. To allow VPCs connected through VPC peering to communicate, you must include forward and return routes in the VPCs' route tables.	Selected
VPC	By default, the system selects the other VPC connected by the VPC peering connection. You do not need to specify this parameter.	vpc-demo1
Route Table	Select the route table of the VPC. The route will be added to this route table. Each VPC comes with a default route table that manages the flow of outgoing traffic from the subnets in the VPC. In addition to the default route table, you can create a custom route table and associate it with the subnets in the VPC. Then, the custom route table controls outbound traffic of the subnets. If there is only the default route table in the drop-down list, select the default route table. If there are both default and custom route tables in drop-down list, select the route table associated with the subnet connected by the VPC peering connection.	rtb-vpc-demo1 (default route table)
Destination	IP address in the VPC at the other end of the VPC peering connection. The value can be a VPC CIDR block, subnet CIDR block, or ECS IP address.	172.16.0.0/12
Next Hop	The default value is the current VPC peering connection. You do not need to specify this parameter.	peering-b34b

Add a route between the VPC containing the RDS for MySQL instance and the container CIDR block. Click Add Route. In the Add Route dialog box, set VPC to vpc-373896-1 and Destination to the container CIDR block. For details, see Figure 6.

Figure 6 Adding a route to the container CIDR block
Verify the configuration. Check whether the security group inbound rules of the RDS for MySQL instance include the CIDR blocks of the cluster node and container (only necessary if the cluster network model is VPC). If they are not included, add a rule. For details, see Step 3 Add the container CIDR block to the security group inbound rules of the accessed service. Log in to the container. For details, see Logging In to a Container. Enter the following code on the CloudShell page of the pod again, where 172.16.0.167 indicates the IP address of the service that is accessed.

ping 172.16.0.167

If information similar to the following is displayed, cross-VPC access from the pod is successful:
```
PING 172.16.0.167 (172.16.0.167) 56(84) bytes of data.
64 bytes from 172.16.0.167: icmp_seq=1 ttl=63 time=0.516 ms
64 bytes from 172.16.0.167: icmp_seq=2 ttl=63 time=0.418 ms
64 bytes from 172.16.0.167: icmp_seq=3 ttl=63 time=0.376 ms
--- 172.16.0.167 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1001ms
```

Troubleshooting a Pod Access Failure

If a pod cannot access the network, rectify the fault by referring to Table 6. If the fault persists, submit a service ticket to contact Huawei Cloud customer service.

The CIDR blocks used for pod access depend on the cluster network model. For details, see Table 1. The container CIDR blocks mentioned in the following section are specific to a cluster that uses the VPC network model.

**Table 6** Troubleshooting methods
Check Item	Possible Fault	Solution
Security group rules of the accessed service	One of the following issues may be the cause of the failure: The security group's inbound rules prevent access to the node CIDR block or container CIDR block. The security group's inbound rules permit access to the node CIDR block and container CIDR block, but the protocol is incorrectly configured. NOTICE: Run the ping command and use ICMP to test network connectivity. Before doing so, enable the ICMP port in the security group rule.	For possible cause 1, add a security group rule. For details, see Adding a Security Group Rule. For possible cause 2, change the protocol port in the security group rules. For details, see Modifying a Security Group Rule.
VPC peering connection	The CIDR blocks of the local and peer VPCs are overlapping.	There are two possible causes for this issue. For details, see Overlapping CIDR Blocks of Local and Peer VPCs. If the subnet where the node CIDR block resides does not overlap with the subnet where the accessed service resides, you can create a VPC peering connection that points to the subnet. If the subnet where the node CIDR block resides overlaps with the subnet where the accessed service resides, you need to replan the network.
Route	One of the following issues may be the cause of the failure: The custom route table used to add routes for the two VPCs is not associated with the target subnet. (The cluster VPC route table must be associated with the node subnet, and the route table of the accessed service must be associated with the subnet where the accessed service is located.) There is no route between the accessed service subnet and the container CIDR block.	For possible cause 1, locate the target route table, click Associate Subnet, and select the correct subnet. For possible cause 2, see Step 4 Add a route between the container CIDR block and the peer VPC.
Trustlist	The trustlist for the accessed service does not have the node CIDR block and container CIDR block configured.	Add the container and node CIDR blocks to the trustlist. Find more information in the help document for the relevant service.
Domain name resolution	When accessing an external domain name, the pod uses its cluster's domain name resolution to resolve the destination address and accesses the address based on the pod's network policy. However, sometimes the domain name cannot be resolved, resulting in errors. The most common errors are listed below: Name or service not known Temporary failure in name resolution Unable to resolve hostname DNS resolution failed Could not resolve MYHOST (nodename nor servname known), where MYHOST indicates the domain name that cannot be resolved	Locate the cause of the DNS exception. For details, see DNS Overview for troubleshooting.
Network policy (applicable only to tunnel networks)	If you have configured a network policy for both your tunnel network cluster and the namespace where the pod is located, the network policy may prevent the pod from accessing the destination address.	If so, modify the network policy. For details, see Configuring Network Policies to Restrict Pod Access.