Help Center/ Cloud Container Engine/ Best Practices/ Networking/ Accessing an External Network from a Pod/ Accessing Cloud Services from a Pod in a Different VPC
Updated on 2024-12-28 GMT+08:00
View PDF
Share

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. In this section, the VPC where the cluster is in is referred to as the cluster VPC, the VPC where the cloud service to be accessed is in is referred to as the destination VPC, and the subnet where the cloud service to be accessed is in is referred to as the destination subnet.

Table 1 Cross-VPC access for clusters of different network types

Network Model

Description

Difference

Tunnel network

Data packets are encapsulated through tunnels in the node network.

To access cloud services from a pod in a different VPC, ensure that the node subnet can communicate with the destination subnet.

After creating a VPC peering connection between the cluster VPC and the destination VPC, you only need to create a route for the node subnet and the destination subnet.

VPC network

Pod traffic is forwarded through VPC routing. The VPC CIDR block of the cluster cannot overlap with the container CIDR block.

When accessing services from a pod in a different VPC, ensure that the node subnet can communicate with the destination subnet and that the container CIDR block can also communicate with the destination subnet.

After creating a VPC peering connection between the cluster VPC and the destination VPC, you need to create a route for the destination subnet, cluster node subnet, and container CIDR block.

Cloud Native Network 2.0

In the Cloud Native 2.0 network model, container IP addresses are directly assigned from the VPC CIDR block.

To access cloud services from a pod in a different VPC, ensure that the container subnet can communicate with the destination subnet.

After creating a VPC peering connection between the cluster VPC and the destination VPC, you only need to create a route for the container subnet and the destination subnet.

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.

This section uses ECS and RDS for MySQL as examples to describe how to implement cross-VPC communication between pods in clusters that use different network models. Table 2 shows the details about the cluster, ECS, and RDS for MySQL network information in the example.

Table 2 Network information

Cloud Service

Container Network Model

Network Information

CCE

Container tunnel network (CCE standard cluster)
  • Cluster VPC
    • Name: vpc-demo1
    • CIDR block: 192.168.0.0/18 (primary) and 172.1.0.0/24 (secondary)
      NOTE:

      After a VPC is created, if the primary CIDR block is not enough, you can add secondary CIDR blocks to the VPC. For details, see Adding a Secondary IPv4 CIDR Block to a VPC. After a secondary CIDR block is added to the VPC, you can create a subnet based on the secondary CIDR block. The subnet can be used in CCE.

    • Subnet: 192.168.0.0/24, 192.168.60.0/28, and 172.1.0.0/26
  • Node subnet: 192.168.0.0/24
  • Container CIDR block: 172.18.1.0/24

VPC network (CCE standard cluster)
  • Cluster VPC
    • Name: vpc-demo1
    • CIDR block: 192.168.0.0/18 (primary) and 172.1.0.0/24 (secondary)
    • Subnet: 192.168.0.0/24, 192.168.60.0/28, and 172.1.0.0/26
  • Node subnet: 192.168.0.0/24
  • Container CIDR block: 172.18.1.0/24

Cloud Native 2.0 network (CCE Turbo cluster)
  • Cluster VPC
    • Name: vpc-demo1
    • CIDR block: 192.168.0.0/18 (primary) and 172.1.0.0/24 (secondary)
    • Subnet: 192.168.0.0/24, 192.168.60.0/28, and 172.1.0.0/26
  • Node subnet: 192.168.0.0/24
  • Container subnet: 192.168.60.0/28

ECS

N/A
  • Destination VPC
    • Name: vpc-demo2
    • CIDR block: 10.1.0.0/16
    • Subnet: 10.1.1.0/24
  • Subnet where the ECS resides (destination subnet): 10.1.1.0/24
  • ECS IP address: 10.1.1.24

RDS for MySQL

N/A
  • Destination VPC
    • Name: vpc-373896-1
    • CIDR block: 172.16.0.0/16
    • Subnet: 172.16.0.0/24
  • Subnet where RDS for MySQL resides (destination subnet): 172.16.0.0/24
  • IP address of RDS for MySQL: 172.16.0.167

Prerequisites

Accessing Cloud Services from a Pod in a Different VPC

This part describes how to access an ECS or an RDS for MySQL DB instance from a pod in a different VPC.

The following describes how to access an ECS from pods that run in clusters that use the tunnel network model, VPC network model, and Cloud Native 2.0 network model, respectively. You can select a method based on your cluster types.

Accessing an ECS from a pod in a CCE standard cluster that uses the tunnel network model

  1. Create a VPC peering connection between the cluster VPC and the destination VPC.
    1. Switch to the console, click in the upper left corner, and choose Networking > Virtual Private Cloud in the expanded list.
    2. In the navigation pane, choose VPC Peering Connections. In the upper right corner of the displayed page, click Create VPC Peering Connection.
    3. Configure parameters following instructions. For details about the parameters, see Table 3.
      Figure 1 Creating a VPC peering connection

      Table 3 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
    4. After configuring the parameters, click Create Now.
  2. In the displayed VPC Peering Connection Created dialog box, click Add Now and add a route for the node subnet and destination subnet. In the Add Route dialog box, configure the parameters following instructions. For details about the parameters, see Table 4.
    Figure 2 Adding a route for the node subnet and destination subnet

    Table 4 Parameters for adding a route for the node subnet and destination subnet

    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.1.0/24

    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/24
  3. Log in to the pod and enter the following code on the CloudShell page of the pod again, where 10.1.1.24 indicates the IP address of the ECS to be accessed: (For details about how to log in to a container, see Logging In to a Container.) 
    ping 10.1.1.24

    If the access fails, check whether the traffic from the cluster node subnet is allowed in the inbound rules of the ECS security group. If it is not allowed, you need to add a security group rule and allow the corresponding traffic. For details, see Adding a Security Group Rule.

    • If a ping command is available and 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
    • If no ping command is available, add it. 
      ping: command not found

      The following uses the Nginx:latest container as an example to describe how to add a ping command. If the ping command is already available, skip this step.

      1. Ensure that the pod can access the Internet. For details, see Accessing the Internet from a Pod.
      2. Update the local software package index and install the iputils-ping software package that provides the ping command. 
        apt-get update
apt-get install iputils-ping
      3. Access the ECS again. 
        ping 10.1.1.24

        If information similar to the following is displayed, the ping command has been added and the 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

Accessing an ECS from a pod in a CCE standard cluster that uses the VPC network model

  1. Create a VPC peering connection between the cluster VPC and the destination VPC.
    1. Switch to the console, click in the upper left corner, and choose Networking > Virtual Private Cloud in the expanded list.
    2. In the navigation pane, choose VPC Peering Connections. In the upper right corner of the displayed page, click Create VPC Peering Connection.
    3. Configure parameters following instructions. For details about the parameters, see Table 5.
      Figure 3 Creating a VPC peering connection

      Table 5 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
    4. After configuring the parameters, click Create Now.
  2. In the displayed VPC Peering Connection Created dialog box, click Add Now and add a route for the node subnet and destination subnet. In the Add Route dialog box, configure the parameters following instructions. For details about the parameters, see Table 6.
    Figure 4 Adding a route for the node subnet and destination subnet

    Table 6 Parameters for adding a route for the node subnet and destination subnet

    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.1.0/24

    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/24
  3. On the current page, click Add Route and add a route for the destination VPC and the container CIDR block of the cluster. In the Add Route dialog box, set VPC to vpc-demo2 and Destination to 172.18.1.0/24. For details, see Figure 5.
    Figure 5 Adding a route to the container CIDR block

  4. Log in to the pod and enter the following code on the CloudShell page of the pod again, where 10.1.1.24 indicates the IP address of the ECS to be accessed: (For details about how to log in to a container, see Logging In to a Container.) 
    ping 10.1.1.24

    If the access fails, check whether the traffic from the cluster node subnet and container CIDR block is allowed in the inbound rules of the ECS security group. If it is not allowed, you need to add a security group rule and allow the corresponding traffic. For details, see Adding a Security Group Rule.

    • If a ping command is available and 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
    • If no ping command is available, add it. 
      ping: command not found

      The following uses the Nginx:latest container as an example to describe how to add a ping command. If the ping command is already available, skip this step.

      1. Ensure that the pod can access the Internet. For details, see Accessing the Internet from a Pod.
      2. Update the local software package index and install the iputils-ping software package that provides the ping command. 
        apt-get update
apt-get install iputils-ping
      3. Access the ECS again. 
        ping 10.1.1.24

        If information similar to the following is displayed, the ping command has been added and the 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

Accessing an ECS from a pod in a CCE Turbo cluster that uses the Cloud Native 2.0 network model

  1. Create a VPC peering connection between the cluster VPC and the destination VPC.
    1. Switch to the console, click in the upper left corner, and choose Networking > Virtual Private Cloud in the expanded list.
    2. In the navigation pane, choose VPC Peering Connections. In the upper right corner of the displayed page, click Create VPC Peering Connection.
    3. Configure parameters following instructions. For details about the parameters, see Table 7.
      Figure 6 Creating a VPC peering connection

      Table 7 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
  2. In the displayed VPC Peering Connection Created dialog box, click Add Now and add a route for the container subnet and destination subnet. In the Add Route dialog box, configure the parameters following instructions. For details about the parameters, see Table 8.
    Figure 7 Adding a route for the container subnet and the destination subnet

    Table 8 Parameters for adding a route for the container subnet and destination subnet

    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.1.0/24

    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.60.0/28
  3. Log in to the pod and enter the following code on the CloudShell page of the pod again, where 10.1.1.24 indicates the IP address of the ECS to be accessed: (For details about how to log in to a container, see Logging In to a Container.) 
    ping 10.1.1.24

    If the access fails, check whether the traffic from the cluster container subnet is allowed in the inbound rules of the ECS security group. If it is not allowed, you need to add a security group rule and allow the corresponding traffic. For details, see Adding a Security Group Rule.

    • If a ping command is available and 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
    • If no ping command is available, add it. 
      ping: command not found

      The following uses the Nginx:latest container as an example to describe how to add a ping command. If the ping command is already available, skip this step.

      1. Ensure that the pod can access the Internet. For details, see Accessing the Internet from a Pod.
      2. Update the local software package index and install the iputils-ping software package that provides the ping command. 
        apt-get update
apt-get install iputils-ping
      3. Access the ECS again. 
        ping 10.1.1.24

        If information similar to the following is displayed, the ping command has been added and the 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

The following describes how to access an RDS for MySQL DB instance from pods that run in clusters that use the tunnel network model, VPC network model, and Cloud Native 2.0 network model, respectively. You can select a method based on your cluster types.

Accessing an RDS for MySQL DB instance from a pod in a CCE standard cluster that uses the tunnel network model

  1. Create a VPC peering connection between the cluster VPC and the destination VPC.
    1. Switch to the console, click in the upper left corner, and choose Networking > Virtual Private Cloud in the expanded list.
    2. In the navigation pane, choose VPC Peering Connections. In the upper right corner of the displayed page, click Create VPC Peering Connection.
    3. Configure parameters following instructions. For details about some of the parameters, see Table 9.
      Figure 8 Creating a VPC peering connection

      Table 9 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
    4. After configuring the parameters, click Create Now.
  2. In the displayed VPC Peering Connection Created dialog box, click Add Now and add a route for the node subnet and destination subnet. In the Add Route dialog box, configure the parameters following instructions. For details about the parameters, see Table 10.
    Figure 9 Adding a route for the node subnet and destination subnet

    Table 10 Parameters for adding a route for the node subnet and destination subnet

    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/24

    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/24
  3. Log in to the pod and enter the following code on the CloudShell page of the pod again, where 172.16.0.167 indicates the IP address of the RDS for MySQL DB instance to be accessed: (For details about how to log in to a container, see Logging In to a Container.) 
    ping 172.16.0.167

    If the access fails, check whether the traffic from the cluster node subnet is allowed in the inbound rules of the DB instance security group. If it is not allowed, you need to add a security group rule and allow the corresponding traffic. For details, see Adding a Security Group Rule.

    • If a ping command is available and 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
    • If no ping command is available, add it. 
      ping: command not found

      The following uses the Nginx:latest container as an example to describe how to add a ping command. If the ping command is already available, skip this step.

      1. Ensure that the pod can access the Internet. For details, see Accessing the Internet from a Pod.
      2. Update the local software package index and install the iputils-ping software package that provides the ping command. 
        apt-get update
apt-get install iputils-ping
      3. Access the RDS for MySQL DB instance again. 
        ping 172.16.0.167

        If information similar to the following is displayed, the ping command has been added and the 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

Accessing an RDS for MySQL DB instance from a pod in a CCE standard cluster that uses the VPC network model

  1. Create a VPC peering connection between the cluster VPC and the destination VPC.
    1. Switch to the console, click in the upper left corner, and choose Networking > Virtual Private Cloud in the expanded list.
    2. In the navigation pane, choose VPC Peering Connections. In the upper right corner of the displayed page, click Create VPC Peering Connection.
    3. Configure parameters following instructions. For details about some of the parameters, see Table 11.
      Figure 10 Creating a VPC peering connection

      Table 11 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
    4. After configuring the parameters, click Create Now.
  2. In the displayed VPC Peering Connection Created dialog box, click Add Now and add a route for the node subnet and destination subnet. In the Add Route dialog box, configure the parameters following instructions. For details about the parameters, see Table 12.
    Figure 11 Adding a route for the node subnet and destination subnet

    Table 12 Parameters for adding a route for the node subnet and destination subnet

    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/24

    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/24
  3. On the current page, click Add Route. In the displayed dialog box, set VPC to vpc-373896-1 and Destination to 172.18.1.0/24 and add a route for the destination VPC and the container CIDR block of the cluster. For details, see Figure 12.
    Figure 12 Adding a route to the container CIDR block

  4. Log in to the pod and enter the following code on the CloudShell page of the pod again, where 172.16.0.167 indicates the IP address of the RDS for MySQL DB instance to be accessed: (For details about how to log in to a container, see Logging In to a Container.) 
    ping 172.16.0.167

    If the access fails, check whether the traffic from the cluster node subnet and container CIDR block is allowed in the inbound rules of the DB instance security group. If it is not allowed, you need to add a security group rule and allow the corresponding traffic. For details, see Adding a Security Group Rule.

    • If a ping command is available and 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
    • If no ping command is available, add it. 
      ping: command not found

      The following uses the Nginx:latest container as an example to describe how to add a ping command. If the ping command is already available, skip this step.

      1. Ensure that the pod can access the Internet. For details, see Accessing the Internet from a Pod.
      2. Update the local software package index and install the iputils-ping software package that provides the ping command. 
        apt-get update
apt-get install iputils-ping
      3. Access the RDS for MySQL DB instance again. 
        ping 172.16.0.167

        If information similar to the following is displayed, the ping command has been added and the 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

Accessing an RDS for MySQL DB instance from a pod in a CCE Turbo cluster that uses the Cloud Native 2.0 network model

  1. Create a VPC peering connection between the cluster VPC and the destination VPC.
    1. Switch to the console, click in the upper left corner, and choose Networking > Virtual Private Cloud in the expanded list.
    2. In the navigation pane, choose VPC Peering Connections. In the upper right corner of the displayed page, click Create VPC Peering Connection.
    3. Configure parameters following instructions. For details about some of the parameters, see Table 13.
      Figure 13 Creating a VPC peering connection

      Table 13 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
    4. After configuring the parameters, click Create Now.
  2. In the displayed VPC Peering Connection Created dialog box, click Add Now and add a route for the container subnet and destination subnet. In the Add Route dialog box, configure the parameters following instructions. For details about the parameters, see Table 14.
    Figure 14 Adding a route to the container CIDR block

    Table 14 Parameters for adding a route for the container subnet and destination subnet

    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.60.0/28

    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/24
  3. Log in to the pod and enter the following code on the CloudShell page of the pod again, where 172.16.0.167 indicates the IP address of the RDS for MySQL DB instance to be accessed: (For details about how to log in to a container, see Logging In to a Container.) 
    ping 172.16.0.167

    If the access fails, check whether the traffic from the cluster container subnet is allowed in the inbound rules of the DB instance security group. If it is not allowed, you need to add a security group rule and allow the corresponding traffic. For details, see Adding a Security Group Rule.

    • If a ping command is available and 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
    • If no ping command is available, add it. 
      ping: command not found

      The following uses the Nginx:latest container as an example to describe how to add a ping command. If the ping command is already available, skip this step.

      1. Ensure that the pod can access the Internet. For details, see Accessing the Internet from a Pod.
      2. Update the local software package index and install the iputils-ping software package that provides the ping command. 
        apt-get update
apt-get install iputils-ping
      3. Access the RDS for MySQL DB instance again. 
        ping 172.16.0.167

        If information similar to the following is displayed, the ping command has been added and the 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 15. 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 15 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.

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 destination 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 problem 2, add a route for the destination service subnet and the container CIDR block.

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.
Parent Topic: Accessing an External Network from a Pod