Google Distributed Cloud Edge networking features

This page describes the advanced networking features of Google Distributed Cloud Edge.

Load balancing

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:

  1. 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.
  2. 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.
  3. After the Cluster has been created, the Cluster administrator configures the virtual IP address pools, using the kubectl tool, to edit the metallb-config ConfigMap in the metallb-system namespace, and applies the configuration to the Cluster. The following example illustrates such a configuration:

    # metallb-config.yaml
    apiVersion: v1
    kind: ConfigMap
      namespace: metallb-system
      name: metallb-config
      config: |
        - name: default
          protocol: layer2
  4. The Cluster administrator creates the appropriate Kubernetes LoadBalancer services.

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 Kubernetes 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 Ingress resource:

kind: Ingress
  name: my-ingress
  - http:
      - backend:
            name: my-service
              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
    istio: ingress-gke-system
    release: istio
  name: istio-ingress
  namespace: gke-system
  loadBalancerIP: <targetLoadBalancerIPaddress>