Updated on 2025-07-31 GMT+08:00

Network Overview

You can learn about a cluster network from the following:

  • Cluster network types and their functions. For details, see Cluster Network Structure.
  • Access to a pod or container n a cluster. Kubernetes provides Service and Ingress to enable pod access. This section summarizes common network access scenarios. You can select the proper scenario based on site requirements. For details about the network access scenarios, see Network Access Scenarios.

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 TCP and UDP at Layer 4. Ingresses forward requests using HTTP and HTTPS at Layer 7. Domain names and paths can be used for access of finer granularities.

Figure 2 An ingress and associated Services

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 the Public Network from a Container.
Figure 3 Network access diagram