Network Overview

Cluster Network Structure

A cluster network can be divided into two parts:

• Container Network

  A container network assigns IP addresses to pods in a cluster. CCE Autopilot inherits the IP-Per-Pod-Per-Network network model of Kubernetes. That means each pod has an independent IP address on a network plane and all containers in a pod share the same network namespace. All pods in a cluster are running in a directly connected flat network. They can access each other through their IP addresses without using NAT. Kubernetes only provides a network mechanism for pods, but does not directly configure pod networks. You can use specific container network add-ons to configure networks for pods and manages container IP addresses.

  CCE Autopilot supports only the Cloud Native 2.0 model. Cloud Native 2.0, built on CCE, is a next-generation container network. It integrates network interfaces and supplementary network interfaces of Virtual Private Cloud (VPC).IP addresses can be assigned to containers from a VPC CIDR block. Load balancers, security groups, and EIPs can be used in a container network to deliver high performance.

• Service Network

  Service is a Kubernetes concept. Each Service has an IP address. When creating a cluster on CCE, you can specify a CIDR block for ClusterIP Service. The Service CIDR block cannot overlap with the container subnet CIDR block. IP addresses in the Service CIDR block can only be assigned to the containers in the cluster.

Service

Each Service has a fixed IP address and routes traffic across the pods.

Figure 1 Accessing pods through a Service

You can configure the following types of Services:

• ClusterIP: used to make the Service only reachable from within a cluster.
• LoadBalancer: used for access from outside a cluster. A load balancer distributes external requests across the supplementary network interfaces of nodes.

Ingress

Services forward requests using layer-4 TCP and UDP protocols. Ingresses forward requests using layer-7 HTTP and HTTPS protocols. Domain names and paths can be used to achieve finer granularities.

Figure 2 Ingress and Service

Network Access Scenarios

Workload access scenarios can be categorized as follows:

• Intra-cluster access: A ClusterIP Service is used for workloads in the same cluster to access each other.
• Access from outside a cluster: A Service (LoadBalancer) or an Ingress is recommended for a workload outside a cluster to access workloads in a cluster.
  • Access through a public network requires an EIP to be bound to the load balancer.
  • Access through an intranet requires the workload to be accessed through the internal IP address of the load balancer. If workloads are located in different VPCs, a peering connection is required to enable communication between different VPCs.
• The workload can access the external network as follows:
  • Accessing an intranet: How workloads access an intranet address varies depending on container network models. Ensure that the peer security group rules allow the access from the container CIDR block.
  • Accessing the internet: You can bind an EIP to the pod by referring to Configuring an EIP for a Pod, or configure SNAT rules for NAT gateway by referring to Accessing Public Networks from a Container.

Figure 3 Network access diagram