This page describes the advanced networking features of Google Distributed Cloud Edge.
Distributed Cloud Edge ships with a bundled network load balancing solution based on MetalLB in Layer 2 mode. You can use this solution to expose services running in your Distributed Cloud Edge Zone to the outside world using virtual IPs as follows:
- Your network administrator plans the network topology and specifies the
required virtual IPv4 address subnetwork when ordering
Distributed Cloud Edge. Google configures your
Distributed Cloud Edge hardware accordingly before delivery.
Keep the following in mind:
- This virtual IP address subnetwork is shared among all Kubernetes Clusters running within your Distributed Cloud Edge Zone.
- A route for the requested virtual IP address subnetwork is advertised through the BGP sessions between the Distributed Cloud Edge Zone and your local network.
- The first (network ID), second (default gateway), and last (broadcast address) addresses in the subnetwork are reserved for core system functionality. Do not assign those addresses to your MetalLB configurations' address pools.
- Each Cluster must use a separate virtual IP address range that falls within the configured virtual IP address subnetwork.
- When creating a Cluster in your Distributed Cloud Edge Zone, your Cluster administrator specifies the Pod and ClusterIP Service address pools using CIDR notation. Your network administrator provides the appropriate LoadBalancer virtual IP address subnetwork to your Cluster administrator.
After the Cluster has been created, the Cluster administrator configures the virtual IP address pools, using the
kubectltool, to edit the
metallb-configConfigMap in the
metallb-systemnamespace, and applies the configuration to the Cluster. The following example illustrates such a configuration:
# metallb-config.yaml apiVersion: v1 kind: ConfigMap metadata: namespace: metallb-system name: metallb-config data: config: | address-pools: - name: default protocol: layer2 addresses: - 192.168.1.2-192.168.1.254
The Cluster administrator creates the appropriate Kubernetes
Distributed Cloud Edge Nodes in a single NodePool share a common Layer 2 domain and are therefore also MetalLB load balancer nodes. Distributed Cloud Edge control plane nodes running on Google Cloud do not function as load balancer nodes.
Distributed Cloud Edge ingress
In addition to load balancing, Distributed Cloud Edge also supports
Ingress resources. A Kubernetes ingress controls the flow of
HTTP(S) traffic to Kubernetes services running on your Distributed Cloud Edge
Clusters. The example below illustrates a typical
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress spec: rules: - http: paths: - backend: service: name: my-service port: number: 80 path: /foo pathType: Prefix
When configured, network traffic flows through the
istio-ingress service, which by
default is assigned a random IP address from the virtual IP address pools specified
in your MetalLB configuration. You can select a specific IP or virtual IP address from the MetalLB
configuration using the
loadBalancerIP field in the
istio-ingress service definition. For example:
apiVersion: v1 kind: Service metadata: labels: istio: ingress-gke-system release: istio name: istio-ingress namespace: gke-system spec: loadBalancerIP: <targetLoadBalancerIPaddress>