Before you create an ACS cluster, you need to design the VPC, vSwitches, and Service CIDR block of the cluster to ensure that all network resources are efficiently used and reserve sufficient address space for further business expansion. This topic describes how to design the network of an ACS cluster in a VPC.
Network scale
Regions and zones
Number of VPCs
Number of vSwitches
Number of pods
Network design
The VPC CIDR block contains the vSwitch CIDR block. The ACS network CIDR block consists of the pod CIDR block and Service CIDR block.
When you configure an ACS cluster network, you need to set the following parameters and pay attention to the CIDR blocks:
VPC
You can specify one of the following CIDR blocks or their subsets as the primary IPv4 CIDR block of the VPC: 192.168.0.0/16, 172.16.0.0/12, and 10.0.0.0/8. These CIDR blocks are standard private CIDR blocks as defined by RFC. The subnet mask must be 8 to 28 bits in length. Example: 192.168.0.0/16.
You can also use a custom CIDR block other than 100.64.0.0/10, 224.0.0.0/4, 127.0.0.0/8, 169.254.0.0/16, and their subnets as the primary IPv4 CIDR block of the VPC.
In scenarios where multiple VPCs are used or in hybrid cloud scenarios where data centers and VPCs are co-located, we recommend that you use subsets of standard RFC CIDR blocks as VPC CIDR blocks with subnet masks no more than 16 bits in length. Make sure that the CIDR blocks of the VPCs and data centers do not overlap with each other.
IPv6 CIDR blocks are assigned to pods by VPC after IPv6 is enabled in the VPC. For more information, see Assign IPv6 addresses to pods.
vSwitch
The IP addresses of pods are assigned from the CIDR blocks of pod vSwitches. This allows pods to communicate with each other. A pod is a group of containers in a Kubernetes cluster. Each pod has an IP address. The CIDR blocks of vSwitches in the VPC must be subsets of the VPC CIDR block. When you specify the CIDR blocks of vSwitches, take note of the following items:
You must select vSwitches that belong to the VPC where the cluster resides.
In an ACS network, the IP addresses of pods are assigned by pod vSwitches.
The CIDR block cannot overlap with the Service CIDR block.
Service CIDR block
ImportantThe Service CIDR block cannot be modified after it is created.
The CIDR block of Services. The Service CIDR block provides IP addresses for ClusterIP type Services. Service is a Kubernetes concept. Each Service has an IP address. When you specify the Service CIDR block, take note of the following items:
The IP address of a Service is effective only within the ACS cluster.
The Service CIDR block cannot overlap with the vSwitch CIDR block.
The following table provides an example of multi-zone configuration for container networks in ACS scenarios:
VPC CIDR block | vSwitch CIDR block | Service CIDR block | Maximum number of assignable pod IP addresses |
192.168.0.0/16 | Zone I 192.168.0.0/19 | 172.21.0.0/20 | 8,192 |
Zone J 192.168.32.0/19 | 8,192 |
Network communication design
A single cluster in a single VPC
When you create a VPC, the VPC CIDR block is specified. When you create an ACS cluster, you need to specify a Service CIDR block that does not overlap with the VPC CIDR block. This ensures the network communication within the cluster and prevents conflicts with external VPCs.
Multiple clusters in a single VPC
Create multiple clusters in a VPC.
The CIDR block of the VPC is specified when you create the VPC. When you create a cluster, the VPC CIDR block and Service CIDR block of each cluster cannot overlap with each other.
The Service CIDR blocks of all clusters can overlap, and pod vSwitches can be reused.
In this case, clusters are partially interconnected. Pods in one cluster can directly access pods in another cluster, but cannot access Services in another cluster (such as ClusterIP type Services that can only be accessed within the cluster. To expose Services, you can use LoadBalancer Services or Ingress).
Multiple clusters across VPCs
We recommend that you plan the connection of multiple clusters across VPCs in the following scenarios:
Inter-region deployment
A VPC cannot be deployed across regions. If you want to deploy your services in different regions, you must create multiple VPCs and multiple clusters. You can enable communication between VPCs across regions by using VPC peering connection, VPN Gateway, Cloud Enterprise Network, and other products.
Business system isolation
If multiple business systems in a region require strict isolation by using VPCs, such as isolation between the production environment and the staging environment, you can deploy the production cluster and the test cluster in different VPCs to provide better logical isolation and security. You can also enable communication between VPCs in the same region by using VPC peering connection, VPN Gateway, Cloud Enterprise Network, and other products.
Large-scale business system
If your business architecture is complex and each service and department require an independent VPC to manage their clusters and resources, we recommend that you configure multiple VPCs and multiple clusters.
To avoid issues such as routing errors caused by IP conflicts in multi-cluster interconnection across VPC scenarios, you must follow the following network planning requirements for newly created clusters:
The CIDR block of the new cluster does not overlap with the VPC CIDR block.
The CIDR block of the new cluster does not overlap with the CIDR block of other clusters.
The CIDR block of the new cluster does not overlap with the Service CIDR block of other clusters.
Communication between clusters and data centers
Similar to the Multiple clusters across VPCs scenario, some CIDR blocks in the VPC are routed to the data center, and the Service CIDR block of the cluster cannot overlap with these CIDR blocks. To access pods in the VPC from the data center, you must configure a routing table for the VBR in the data center.
