Install eBPF-based sidecar acceleration

Use eBPF sidecar acceleration to reduce network latency in your service mesh.

About sidecar acceleration

Gloo Mesh Enterprise ships with an optional component that enables eBPF-based sidecar acceleration.

Instead of using iptables rules to redirect ingress and egress traffic from an app container to the injected Istio sidecar proxy and vice versa, eBPF is used to intercept the traffic and shorten the data path in a service mesh. With eBPF, packets to and from apps can be directly forwarded from one socket to the other. This setup reduces network latency and the necessary packet processing in the kernel.

The Istio architecture is not changed. When you remove the Gloo Mesh add-on, Istio's iptables rules are again used to redirect network traffic to and from the sidecars, just as they were before you applied the add-on.

This is an experimental feature. If you are interested in using this feature in production, contact the Solo team so that we can understand your environment and needs.

Version support

Because this Gloo Mesh add-on uses eBPF, all nodes in the cluster must run the Linux kernel version 5.7 or higher.

The following public Kubernetes distributions have been tested:

Before you begin


The sidecar acceleration component can be deployed in one or all of your workload clusters that have Istio installed.

  1. Install the sidecar-accel add-on by upgrading your Helm release in each workload cluster. Note that the sidecarAccel.debug value is set to true to enable detailed eBPF logs. These logs are later used to verify that the sidecar acceleration works as expected. Be sure to change the $REMOTE_CONTEXT each time you repeat this command.

    helm upgrade --install gloo-platform gloo-platform/gloo-platform \
       --kube-context $REMOTE_CONTEXT \
       --namespace gloo-mesh \
       --version $GLOO_VERSION \
       --values agent.yaml \
       --set common.cluster=$REMOTE_CLUSTER \
       --set licensing.glooMeshLicenseKey=$GLOO_MESH_LICENSE_KEY \
       --set sidecarAccel.enabled=true \
       --set sidecarAccel.debug=true

    Make sure to include your Helm values when you upgrade either as a configuration file in the –values flag or with –set flags. Otherwise, any previous custom values that you set might be overwritten. In single cluster setups, this might mean that your Gloo agent and ingress gateways are removed. To get your current values, such as for a release named gloo-platform, you can run helm get values gloo-platform -n gloo-mesh > gloo-gateway-single.yaml. For more information, see Get your Helm chart values in the upgrade guide.

  2. Verify that the sidecar-accel pods run successfully. Because the add-on is deployed as a daemon set, the number of sidecar-accel pods equals the number of nodes in your cluster.

    kubectl get pod -n istio-system --kube-context=$REMOTE_CONTEXT

    Example output:

    NAME                                   READY   STATUS    RESTARTS   AGE
    istio-ingressgateway-778f44479-sxssj   1/1     Running   0          12m
    istiod-6d67d84bc7-jq2wl                1/1     Running   0          12m
    sidecar-accel-hd6cg                    1/1     Running   0          9m28s
    sidecar-accel-hz7cv                    1/1     Running   0          9m28s
    sidecar-accel-mzspz                    1/1     Running   0          9m28s
  3. Generate traffic for your app. For example, if you deployed the Bookinfo app, you can log in to the product page pod and then curl the product page to generate network traffic.

    kubectl exec $(kubectl get pod -l app=productpage -A --context ${REMOTE_CONTEXT}  -o jsonpath='{.items[0]}') -n bookinfo -c curl --context ${REMOTE_CONTEXT} -- curl -v http://productpage:9080
  4. Verify that the sidecar acceleration works correctly by checking the eBPF debug logs.

    1. Log in to a cluster node. For example, you can use ssh to log in the node directly or use the options that your cloud provider offers, such as opening SSH sessions to a node from the web console.

      ssh root@<node-IP-address>
    2. Review the eBPF kernel logs. The sidecar acceleration works correctly if connections and data are successfully redirected by eBPF.

      sudo cat /sys/kernel/debug/tracing/trace_pipe

      Example output:

      curl-57979   [000] d... 11100.185999: bpf_trace_printk: [debug] outbound connect from app container: cookie: 16445, ip: 0x380fc40a, port: 9080
      curl-57979   [000] d... 11100.186128: bpf_trace_printk: [debug] redirect 88 bytes with eBPF successfully
      wrk:worker_1-28489   [000] d... 11100.363604: bpf_trace_printk: [debug] redirect 227 bytes with eBPF successfully


Aside from the kernel version requirements, certain Istio functionality, such as the outbound exclusion of IP addresses and port ranges from the sidecar proxy, does not work as expected when the sidecar acceleration add-on is enabled. Contact the Solo team if you plan to use this Istio feature with sidecar acceleration.