Pod-to-pod communication
Advantages
Disadvantages
The VPC network allocates container IP addresses according to the following rules:
Maximum number of nodes that can be created in the cluster using the VPC network = Number of IP addresses in the container CIDR block /Number of IP addresses in the CIDR block allocated to the node by the container CIDR block
For example, if the container CIDR block is 172.16.0.0/16, the number of IP addresses is 65536. The mask of the container CIDR block allocated to the node is 25. That is, the number of container IP addresses on each node is 128. Therefore, a maximum of 512 (65536/128) nodes can be created. In addition, the number of nodes that can be created in a cluster also depends on the node network and cluster scale.
As described in Cluster Network Structure, network addresses in a cluster can be divided into three parts: node network, container network, and service network. When planning network addresses, consider the following aspects:
Assume that a cluster contains 200 nodes and the network model is VPC network.
In this case, the number of available IP addresses in the selected node subnet must be greater than 200. Otherwise, nodes cannot be created due to insufficient IP addresses.
The container CIDR block is 10.0.0.0/16, and the number of available IP addresses is 65536. As described in Container IP Address Management, the VPC network is allocated a CIDR block with the fixed size (using the mask to determine the maximum number of container IP addresses allocated to each node). For example, if the upper limit is 128, the cluster supports a maximum of 512 (65536/128) nodes, including the three master nodes.
Create a cluster using the VPC network model. The cluster contains one node.
$ kubectl get node NAME STATUS ROLES AGE VERSION 192.168.0.99 Ready <none> 9d v1.17.17-r0-CCE21.6.1.B004-17.37.5
Check the VPC routing table. The destination address 172.16.0.0/25 is the container CIDR block allocated to the node, and the next hop is the corresponding node. When the container IP address is accessed, the VPC route forwards the access request to the next-hop node. This indicates that the VPC network model uses VPC routes.
Create a Deployment in the cluster.
kind: Deployment apiVersion: apps/v1 metadata: name: example namespace: default spec: replicas: 4 selector: matchLabels: app: example template: metadata: labels: app: example spec: containers: - name: container-0 image: 'nginx:perl' imagePullSecrets: - name: default-secret
Check the pod.
$ kubectl get pod -owide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES example-86b9779494-l8qrw 1/1 Running 0 14s 172.16.0.6 192.168.0.99 <none> <none> example-86b9779494-svs8t 1/1 Running 0 14s 172.16.0.7 192.168.0.99 <none> <none> example-86b9779494-x8kl5 1/1 Running 0 14s 172.16.0.5 192.168.0.99 <none> <none> example-86b9779494-zt627 1/1 Running 0 14s 172.16.0.8 192.168.0.99 <none> <none>
In this case, if you access the IP address of the pod from an ECS (outside the cluster) in the same VPC, the access is successful. This is a feature of VPC networking. Pods can be directly accessed from any node locating outside of the cluster and in the same VPC as that of the pods using the pods' IP addresses.
Pods can be accessed from nodes or pods in the same cluster. In the following example, you can directly access the pods in the container.
$ kubectl exec -it example-86b9779494-l8qrw -- curl 172.16.0.7 <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html>