Esta página ainda não está disponível no idioma selecionado. Estamos trabalhando para adicionar mais opções de idiomas. Agradecemos sua compreensão.

Compute
Elastic Cloud Server
Huawei Cloud Flexus
Bare Metal Server
Auto Scaling
Image Management Service
Dedicated Host
FunctionGraph
Cloud Phone Host
Huawei Cloud EulerOS
Networking
Virtual Private Cloud
Elastic IP
Elastic Load Balance
NAT Gateway
Direct Connect
Virtual Private Network
VPC Endpoint
Cloud Connect
Enterprise Router
Enterprise Switch
Global Accelerator
Management & Governance
Cloud Eye
Identity and Access Management
Cloud Trace Service
Resource Formation Service
Tag Management Service
Log Tank Service
Config
OneAccess
Resource Access Manager
Simple Message Notification
Application Performance Management
Application Operations Management
Organizations
Optimization Advisor
IAM Identity Center
Cloud Operations Center
Resource Governance Center
Migration
Server Migration Service
Object Storage Migration Service
Cloud Data Migration
Migration Center
Cloud Ecosystem
KooGallery
Partner Center
User Support
My Account
Billing Center
Cost Center
Resource Center
Enterprise Management
Service Tickets
HUAWEI CLOUD (International) FAQs
ICP Filing
Support Plans
My Credentials
Customer Operation Capabilities
Partner Support Plans
Professional Services
Analytics
MapReduce Service
Data Lake Insight
CloudTable Service
Cloud Search Service
Data Lake Visualization
Data Ingestion Service
GaussDB(DWS)
DataArts Studio
Data Lake Factory
DataArts Lake Formation
IoT
IoT Device Access
Others
Product Pricing Details
System Permissions
Console Quick Start
Common FAQs
Instructions for Associating with a HUAWEI CLOUD Partner
Message Center
Security & Compliance
Security Technologies and Applications
Web Application Firewall
Host Security Service
Cloud Firewall
SecMaster
Anti-DDoS Service
Data Encryption Workshop
Database Security Service
Cloud Bastion Host
Data Security Center
Cloud Certificate Manager
Edge Security
Situation Awareness
Managed Threat Detection
Blockchain
Blockchain Service
Web3 Node Engine Service
Media Services
Media Processing Center
Video On Demand
Live
SparkRTC
MetaStudio
Storage
Object Storage Service
Elastic Volume Service
Cloud Backup and Recovery
Storage Disaster Recovery Service
Scalable File Service Turbo
Scalable File Service
Volume Backup Service
Cloud Server Backup Service
Data Express Service
Dedicated Distributed Storage Service
Containers
Cloud Container Engine
SoftWare Repository for Container
Application Service Mesh
Ubiquitous Cloud Native Service
Cloud Container Instance
Databases
Relational Database Service
Document Database Service
Data Admin Service
Data Replication Service
GeminiDB
GaussDB
Distributed Database Middleware
Database and Application Migration UGO
TaurusDB
Middleware
Distributed Cache Service
API Gateway
Distributed Message Service for Kafka
Distributed Message Service for RabbitMQ
Distributed Message Service for RocketMQ
Cloud Service Engine
Multi-Site High Availability Service
EventGrid
Dedicated Cloud
Dedicated Computing Cluster
Business Applications
Workspace
ROMA Connect
Message & SMS
Domain Name Service
Edge Data Center Management
Meeting
AI
Face Recognition Service
Graph Engine Service
Content Moderation
Image Recognition
Optical Character Recognition
ModelArts
ImageSearch
Conversational Bot Service
Speech Interaction Service
Huawei HiLens
Video Intelligent Analysis Service
Developer Tools
SDK Developer Guide
API Request Signing Guide
Terraform
Koo Command Line Interface
Content Delivery & Edge Computing
Content Delivery Network
Intelligent EdgeFabric
CloudPond
Intelligent EdgeCloud
Solutions
SAP Cloud
High Performance Computing
Developer Services
ServiceStage
CodeArts
CodeArts PerfTest
CodeArts Req
CodeArts Pipeline
CodeArts Build
CodeArts Deploy
CodeArts Artifact
CodeArts TestPlan
CodeArts Check
CodeArts Repo
Cloud Application Engine
MacroVerse aPaaS
KooMessage
KooPhone
KooDrive

Accessing Cloud Services from a Pod in the Same VPC

Updated on 2024-12-28 GMT+08:00

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

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.

Usamos cookies para aprimorar nosso site e sua experiência. Ao continuar a navegar em nosso site, você aceita nossa política de cookies. Saiba mais

Feedback

Feedback

Feedback

0/500

Selected Content

Submit selected content with the feedback