This section describes how to access an intranet from a container (outside the cluster in a VPC), including intra-VPC access and cross-VPC access.
The performance of accessing an intranet from a container varies depending on the container network models of a cluster.
The container tunnel network encapsulates network data packets through tunnels based on the node network. A container can access other resources in the same VPC as long as the node can access the resources. If the access fails, check whether the security group of the peer resource allows access from the node where the container is located.
In the Cloud Native Network 2.0 model, a container is assigned an IP address from the CIDR block of a VPC. The container CIDR block is the subnet of the VPC where the node is located. The container can naturally communicate with other addresses in the VPC. If the access fails, check whether the security group of peer resources allows the access from the container CIDR block.
The VPC network model uses VPC routes to forward container traffic. The container CIDR block and the node VPC are not in the same CIDR block. When a container accesses other resources in the same VPC, the security group of the peer resource must allow access of the container CIDR block.
For example, the CIDR block where the cluster node resides is 192.168.10.0/24, and the container CIDR block is 172.16.0.0/16.
There is an ECS whose IP address is 192.168.10.52 in the VPC (outside the cluster). The security group of the ECS allows access of only the CIDR block of the cluster node.
In this case, if you ping 192.168.10.52 from the container, the ping operation fails.
kubectl exec test01-6cbbf97b78-krj6h -it -- /bin/sh / # ping 192.168.10.25 PING 192.168.10.25 (192.168.10.25): 56 data bytes ^C --- 192.168.10.25 ping statistics --- 104 packets transmitted, 0 packets received, 100% packet loss
Configure the security group to allow access from the container CIDR block 172.16.0.0/16.
In this case, 192.168.10.52 can be pinged from the container.
$ kubectl exec test01-6cbbf97b78-krj6h -it -- /bin/sh / # ping 192.168.10.25 PING 192.168.10.25 (192.168.10.25): 56 data bytes 64 bytes from 192.168.10.25: seq=0 ttl=64 time=1.412 ms 64 bytes from 192.168.10.25: seq=1 ttl=64 time=1.400 ms 64 bytes from 192.168.10.25: seq=2 ttl=64 time=1.299 ms 64 bytes from 192.168.10.25: seq=3 ttl=64 time=1.283 ms ^C --- 192.168.10.25 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss
Cross-VPC access is implemented by establishing a peering connection between VPCs.
Create a peering connection named peering-demo (the local VPC is vpc-demo and the peer VPC is vpc-demo2). Add the container CIDR block to the route of the peer VPC.
After this configuration, you can access the container CIDR block 10.0.0.0/16 in vpc-demo2. During the access, pay attention to the security group configuration and enable the port configuration.
Common services that communicate with CCE through an intranet include RDS, DCS, Kafka, RabbitMQ, and ModelArts.
In addition to the network configurations described in Intra-VPC Access and Cross-VPC Access, you also need to check whether these cloud services allow external access. For example, the DCS Redis instance can be accessed only by the IP addresses in its whitelist. Generally, these cloud services can be accessed by IP addresses in the same VPC. However, the container CIDR block in the VPC network model is different from the CIDR block of the VPC. Therefore, you must add the container CIDR block to the whitelist.
If an intranet cannot be accessed from a container, perform the following operations: