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

Accessing Cloud Services from a Pod in the Same VPC

The method of accessing cloud services from a pod in the same VPC varies depending on the cluster's network model. For details, see Table 1 Accessing cloud services from a pod in the same VPC.

Table 1 Accessing cloud services from a pod in the same VPC

Network Model

Description

Tunnel network

Data packets are encapsulated through tunnels in the node network. If the node access permission is limited, you will not be able to access resources from a pod in the same VPC. If you encounter an access failure, verify that the security group of the service you are trying to access allows access from the node where the pod is located.

VPC network

Pod traffic is forwarded through VPC routing. If the container CIDR block is different from the VPC CIDR block of the node, the container cannot directly communicate with other IP addresses in the VPC. To access a service outside the cluster from a pod in the same VPC, you must configure the security group of the accessed service.

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. Therefore, the containers can directly communicate with other IP addresses in the VPC. If the access failed, check if the security group of the accessed service permits access from the container CIDR block.

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

The following uses a VPC network cluster as an example to describe how to configure security group rules for seamless access to an ECS in the same VPC. For example, the node CIDR block is 192.168.0.0/24, and the container CIDR block is 172.16.0.0/16.

  1. Purchase an ECS. For details, see Purchasing and Using a Linux ECS. The ECS and the cluster are in the same region and VPC, and the IP address of the ECS is 192.168.0.28.
  2. Log in to the pod. For details, see Logging In to a Container. Try to access the ECS from the pod.

    ping 192.168.0.28

    • If the ping command is available, execute it. If the following information is displayed, the access from the pod to the ECS failed: 
      PING 192.168.0.28 (192.168.0.28): 56 data bytes
--- 192.168.0.28 ping statistics ---
104 packets transmitted, 0 packets received, 100% 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.

        apt-get update

      3. Install the iputils-ping software package, which provides the ping command.

        apt-get install iputils-ping

      4. Access the ECS again.

        ping 192.168.0.28

        If the following information is displayed, the ping command has been added:

        PING 192.168.0.28 (192.168.0.28): 56 data bytes
--- 192.168.0.28 ping statistics ---
104 packets transmitted, 0 packets received, 100% packet loss

  3. Add the container CIDR block of the cluster to the inbound rules of the ECS security group so that all pods in the cluster can access the ECS. If you only want to grant access to the ECS from a specific pod in the cluster, you can add the IP address of that pod to the inbound rules of the ECS security group.

    1. On the console homepage, click in the upper left corner. In the expanded list, choose Compute > Elastic Cloud Server and click the target ECS name.
    2. Click the Security Groups tab. In the left pane of the page, click Manage Rule. On the Inbound Rules tab page, you can find that the source addresses include the CIDR block 192.168.0.0/18. Within this block, the node CIDR block 192.168.0.0/24 is included, but the container CIDR block 172.16.0.0/16 is not. If a cluster uses a VPC network model, you need to allow both the node and container CIDR blocks in the security group rules of the ECS outside the cluster to access the ECS from a pod. However, for other network models, you only need to allow the node CIDR block in the security group rules of the ECS.
      Figure 1 Original inbound rules

    3. Click Add Rule and enter 172.16.0.0/16 in the Source text box. For details, see Figure 2.
      Figure 2 Adding a rule

  4. Check whether the pod can access the ECS outside of the cluster in the same VPC. On the CloudShell page of the pod, run the following command again:

    ping 192.168.0.28

    If information similar to the following is displayed, the pod can access the ECS:

    PING 192.168.0.28 (192.168.0.28): 56 data bytes
64 bytes from 192.168.0.28: seq=0 ttl=64 time=1.412 ms
64 bytes from 192.168.0.28: seq=1 ttl=64 time=1.400 ms
64 bytes from 192.168.0.28: seq=2 ttl=64 time=1.299 ms
64 bytes from 192.168.0.28: seq=3 ttl=64 time=1.283 ms
--- 192.168.0.28 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss

The following uses a VPC network cluster as an example to describe how to configure security group rules for seamless access to an RDS for MySQL instance in the same VPC. For example, the node CIDR block is 192.168.0.0/24, and the container CIDR block is 172.16.0.0/16.

  1. Buy an RDS for MySQL instance. For details, see Buying a DB Instance and Connecting to It Using a MySQL Client. The DB instance and the cluster are in the same region and VPC, and the IP address of the DB instance is 192.168.10.10.
  2. Log in to the pod. For details, see Logging In to a Container. Try to access the RDS for MySQL instance from the pod.

    ping 192.168.10.10

    • If the ping command is available, execute it. If the following information is displayed, the access from the pod to the RDS for MySQL instance failed: 
      PING 192.168.10.10 (192.168.10.10): 56 data bytes
--- 192.168.10.10 ping statistics ---
104 packets transmitted, 0 packets received, 100% 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.

        apt-get update

      3. Install the iputils-ping software package, which provides the ping command.

        apt-get install iputils-ping

      4. Access the RDS for MySQL instance again.

        ping 192.168.10.10

        If the following information is displayed, the ping command has been added:

        PING 192.168.10.10 (192.168.10.10): 56 data bytes
--- 192.168.10.10 ping statistics ---
104 packets transmitted, 0 packets received, 100% packet loss

  3. Add the container CIDR block of the cluster to the inbound rules of the DB instance security group so that all pods in the cluster can access the RDS for MySQL instance. If you only want to grant access to the RDS for MySQL instance from a specific pod in the cluster, you can add the IP address of that pod to the inbound rules of the DB instance security group.

    1. On the console homepage, click in the upper left corner. In the expanded list, choose Databases > Relational Database Service. On the Instances page, click the DB instance name.
    2. In the navigation pane, choose Connectivity & Security. In the Security Group Rules area, click the target security group rule. On the Inbound Rules tab page, you can find that the source addresses include the CIDR block 192.168.0.0/18. Within this block, the node CIDR block 192.168.0.0/24 is included, but the container CIDR block 172.16.0.0/16 is not. If a cluster uses a VPC network model, you need to allow both the node and container CIDR blocks in the security group rules of the RDS for MySQL instance outside the cluster to access the DB instance from a pod. However, for other network models, you only need to allow the node CIDR block in the security group rules of the DB instance.
      Figure 3 Original inbound rules

    3. Click Add Rule and enter 172.16.0.0/16 in the Source text box. For details, see Figure 4.
      Figure 4 Adding a rule

  4. Check whether the pod can access the RDS for MySQL instance. On the CloudShell page of the pod, run the following command again:

    ping 192.168.10.10

    If information similar to the following is displayed, the pod can access the DB instance:

    PING 192.168.10.10 (192.168.10.10): 56 data bytes
64 bytes from 192.168.10.10: seq=0 ttl=64 time=1.412 ms
64 bytes from 192.168.10.10: seq=1 ttl=64 time=1.400 ms
64 bytes from 192.168.10.10: seq=2 ttl=64 time=1.299 ms
64 bytes from 192.168.10.10: seq=3 ttl=64 time=1.283 ms
--- 192.168.10.10 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss

Troubleshooting a Pod Access Failure

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

Table 2 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.

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