Este conteúdo foi traduzido por máquina para sua conveniência e a Huawei Cloud não pode garantir que o conteúdo foi traduzido com precisão. Para exibir o conteúdo original, use o link no canto superior direito para mudar para a página em inglês.
Computação
Elastic Cloud Server
Bare Metal Server
Auto Scaling
Image Management Service
Dedicated Host
FunctionGraph
Cloud Phone Host
Huawei Cloud EulerOS
Redes
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
Gerenciamento e governança
Cloud Eye
Identity and Access Management
Cloud Trace Service
Resource Formation Service
Tag Management Service
Log Tank Service
Config
Resource Access Manager
Simple Message Notification
Application Performance Management
Application Operations Management
Organizations
Optimization Advisor
Cloud Operations Center
Resource Governance Center
Migração
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
Análises
MapReduce Service
Data Lake Insight
CloudTable Service
Cloud Search Service
Data Lake Visualization
Data Ingestion Service
GaussDB(DWS)
DataArts Studio
IoT
IoT Device Access
Outros
Product Pricing Details
System Permissions
Console Quick Start
Common FAQs
Instructions for Associating with a HUAWEI CLOUD Partner
Message Center
Segurança e conformidade
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
Situation Awareness
Managed Threat Detection
Blockchain
Blockchain Service
Serviços de mídia
Media Processing Center
Video On Demand
Live
SparkRTC
Armazenamento
Object Storage Service
Elastic Volume Service
Cloud Backup and Recovery
Cloud Server Backup Service
Storage Disaster Recovery Service
Scalable File Service
Volume 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
Bancos de dados
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
EventGrid
Dedicated Cloud
Dedicated Computing Cluster
Aplicações de negócios
ROMA Connect
Message & SMS
Domain Name Service
Edge Data Center Management
Meeting
AI
Face Recognition Service
Graph Engine Service
Content Moderation
Image Recognition
Data Lake Factory
Optical Character Recognition
ModelArts
ImageSearch
Conversational Bot Service
Speech Interaction Service
Huawei HiLens
Developer Tools
SDK Developer Guide
API Request Signing Guide
Terraform
Koo Command Line Interface
Distribuição de conteúdo e computação de borda
Content Delivery Network
Intelligent EdgeFabric
CloudPond
Soluções
SAP Cloud
High Performance Computing
Serviços para desenvolvedore
ServiceStage
CodeArts
CodeArts PerfTest
CodeArts Req
CodeArts Pipeline
CodeArts Build
CodeArts Deploy
CodeArts Artifact
CodeArts TestPlan
CodeArts Check
Cloud Application Engine
MacroVerse aPaaS
KooPhone
KooDrive
Central de ajuda/ Virtual Private Cloud/ Melhores práticas/ Implementação de contêineres que podem se comunicar uns com os outros em ECSs

Implementação de contêineres que podem se comunicar uns com os outros em ECSs

Atualizado em 2024-09-20 GMT+08:00

Cenários

Você pode implantar contêineres que não são da Huawei Cloud em ECSs da Huawei Cloud e permitir que os contêineres em ECSs diferentes, mas na mesma sub-rede, se comuniquem entre si.

Vantagens

  • Os contêineres implementados em ECSs podem usar blocos CIDR que não são daqueles das VPCs às quais os ECSs pertencem, mas usam rotas adicionadas a tabelas de rotas da VPC para encaminhamento de dados.
  • Você só precisa adicionar rotas às tabelas de rotas para permitir comunicações entre os contêineres, o que é flexível e conveniente.

Topologia típica

Os requisitos de topologia de rede são os seguintes:

  • Os ECSs estão na mesma sub-rede. Conforme mostrado na figura a seguir, a sub-rede da VPC é 192.168.0.0/24, e os endereços IP do ECS 1 e do ECS 2 são 192.168.0.2 e 192.168.0.3, respectivamente.
  • Os contêineres estão em blocos CIDR que não pertencem às sub-redes da VPC às quais os ECSs pertencem. Os contêineres no mesmo ECS estão no mesmo bloco CIDR, mas os contêineres em ECSs diferentes usam blocos CIDR diferentes. Conforme mostrado na figura a seguir, o bloco CIDR de contêineres no ECS 1 é 10.0.2.0/24 e o bloco no ECS 2 é 10.0.3.0/24.
  • O próximo salto dos pacotes de dados enviados para um contêiner é o ECS onde o contêiner está localizado. Conforme mostrado na figura a seguir, o próximo salto dos pacotes enviados ao bloco CIDR 10.0.2.0/24 é 192.168.0.2, e o dos pacotes enviados ao bloco CIDR 10.0.3.0/24 é 192.168.0.3.
Figura 1 Topologia de rede

Procedimento

  1. Crie VPCs.

    Para obter detalhes, consulte Criação de uma VPC.

  2. Crie ECSs.

    Para obter detalhes, consulte Compra de um ECS.

    Depois que o ECS for criado, desative a verificação de origem/destino na NIC do ECS, conforme mostrado na Figura 2.

    Figura 2 Desativar a verificação de origem/destino

  3. Implemente contêineres em ECSs.

    Você pode usar o Docker CE para implementar contêineres. Para obter detalhes, consulte a documentação do Docker CE.

    Os contêineres no mesmo ECS devem estar no mesmo bloco CIDR e os blocos CIDR de contêineres em ECSs diferentes não podem se sobrepor.

  4. Adicione rotas à tabela de rotas da VPC.

    Defina o próximo salto dos pacotes enviados para o bloco CIDR 10.0.2.0/24 para 192.168.0.2, e defina o próximo salto dos pacotes enviados para o bloco CIDR 10.0.3.0/24 para 192.168.0.3.

    Figura 3 Adicionar rotas
    • Por padrão, uma VPC suporta contêineres de no máximo 50 blocos CIDR diferentes. Se contêineres de mais blocos CIDR diferentes precisarem ser implantados em uma VPC, solicite mais tabelas de rotas para a VPC.
    • Depois que um contêiner é migrado para outro ECS, você precisa adicionar rotas à tabela de rotas do ECS da VPC.

  5. Adicione regras ao grupo de segurança.

    Para usar os comandos ping e traceroute para verificar as comunicações entre contêineres, adicione as regras mostradas em Tabela 1 ao grupo de segurança dos ECSs para permitir o tráfego ICMP e UDP.

    Para obter detalhes, consulte Adição de uma regra de grupo de segurança.

    Tabela 1 Regras de grupos de segurança

    Direção

    Protocolo

    Porta

    Origem

    Entrada

    ICMP

    Todas

    0.0.0.0/0

    Entrada

    UDP

    Todas

    0.0.0.0/0

Verificação

Use o comando ping para verificar se os contêineres implantados em dois ECSs diferentes podem se comunicar entre si.

Execute os comandos a seguir para criar uma conexão de rede my-net no ECS 1, defina o bloco CIDR a ser usado por um contêiner no ECS 1 como 10.0.2.0/24 e crie o contêiner que usa my-net.

$ docker network create  --subnet 10.0.2.0/24 my-net
$ docker run -d --name nginx --net my-net -p 8080:80  nginx:alpine

Execute os comandos a seguir para criar uma conexão de rede e um contêiner no ECS 2 e defina o bloco CIDR a ser usado pelo contêiner como 10.0.3.0/24.

$ docker network create  --subnet 10.0.3.0/24 my-net
$ docker run -d --name nginx --net my-net -p 8080:80  nginx:alpine

Execute o seguinte comando para definir a política padrão da cadeia FORWARD na tabela de filtros do iptables no ECS para ACCEPT.

Essa operação é necessária porque o Docker define a política padrão da cadeia FORWARD na tabela de filtros do iptables para DROP para fins de segurança.

$ iptables -P FORWARD ACCEPT

Faça ping e traceroute de 10.0.3.2 de 10.0.2.2. As operações de ping e traceroute são bem sucedidas, e o pacote é rastreado na seguinte sequência: 10.0.2.2 -> 10.0.2.1 -> 192.168.0.3 -> 10.0.3.2, que é consistente com as regras de encaminhamento de rota configuradas.

[root@ecs1 ~]# docker exec -it nginx /bin/sh
/ # traceroute -d 10.0.3.2
traceroute to 10.0.3.2 (10.0.3.2), 30 hops max, 46 byte packets
 1  10.0.2.1 (10.0.2.1)  0.007 ms  0.004 ms  0.007 ms
 2  192.168.0.3 (192.168.0.3)  0.232 ms  0.165 ms  0.248 ms
 3  10.0.3.2 (10.0.3.2)  0.366 ms  0.308 ms  0.158 ms
/ # ping 10.0.3.2
PING 10.0.3.2 (10.0.3.2): 56 data bytes
64 bytes from 10.0.3.2: seq=0 ttl=62 time=0.570 ms
64 bytes from 10.0.3.2: seq=1 ttl=62 time=0.343 ms
64 bytes from 10.0.3.2: seq=2 ttl=62 time=0.304 ms
64 bytes from 10.0.3.2: seq=3 ttl=62 time=0.319 ms

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

Conteúdo selecionado

Envie o conteúdo selecionado com o feedback