---
title: "Speedscale with Argo Rollouts | Speedscale Docs"
description: "Capture traffic from Argo Rollouts with the Speedscale eBPF collector and account for Java agent rollout changes."
canonical: "https://docs.speedscale.com/guides/argo/"
---

[Documentation index](https://docs.speedscale.com/guides/llms.txt) | [Markdown](https://docs.speedscale.com/guides/argo/index.md) | [Canonical page](https://docs.speedscale.com/guides/argo/)

# Speedscale with Argo Rollouts

[Argo Rollouts](https://argoproj.github.io/argo-rollouts/) are a popular way to gain more control over application deployment in Kubernetes but their design requires special consideration when used in conjunction with Speedscale.

<a id="installation"></a>

## Installation

Please ensure the [Kubernetes Operator](https://docs.speedscale.com/getting-started/installation/install/kubernetes-operator/) is running in your cluster before moving on.

Inspector Restart Required

If you install Argo Rollouts after Speedscale is already running in your cluster, you must restart the Speedscale inspector pod for it to detect and watch Argo Rollouts resources:

```bash
kubectl rollout restart deployment/speedscale-inspector -n speedscale
```

This restart is necessary because the inspector only creates watchers for Argo Rollouts if they're detected at startup.

<a id="capture-rollout-traffic-with-ebpf"></a>

## Capture rollout traffic with eBPF

The eBPF collector observes traffic from the node and does not inject a container into rollout pods. Enabling capture for a non-Java workload therefore does not create a new ReplicaSet, pause a rollout, or require promotion.

Java TLS capture is an exception. The required `capture.speedscale.com/java-agent: "true"` annotation changes the pod template so the Operator can load the JVMTI agent. Treat that annotation change like any other Argo Rollouts pod template change and promote the resulting ReplicaSet.

Enable eBPF in the Operator Helm values and target the stable label shared by the rollout pods:

ebpf-values.yaml

```yaml
ebpf:
  enabled: true
  configuration:
    capture:
      targets:
        - name: rollouts-demo
          namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: my-namespace
          podSelector:
            matchLabels:
              app: rollouts-demo
```

Apply the values:

```bash
helm upgrade speedscale-operator speedscale/speedscale-operator \
  --namespace speedscale \
  --reuse-values \
  -f ebpf-values.yaml
```

Use an application label that remains stable across canary and stable ReplicaSets. Do not target `rollouts-pod-template-hash`, because that value changes with each rollout revision.

Verify that nettap is running and both rollout revisions match the target:

```bash
kubectl -n speedscale get daemonset nettap
kubectl -n my-namespace get pods -l app=rollouts-demo
```

See [eBPF Traffic Collection](https://docs.speedscale.com/reference/ebpf-traffic-collection/) for TLS support, system requirements, and additional target options.

Legacy sidecar deployments

Existing deployments that intentionally use sidecar capture can continue to use `speedctl infra sidecar` and `sidecar.speedscale.com/inject`. Sidecar injection changes the rollout pod template and must be promoted through Argo Rollouts. New deployments should use eBPF capture.

<a id="remove-a-sidecar-from-a-rollout"></a>

## Remove a sidecar from a rollout

To remove a sidecar from an existing rollout, set the inject annotation to `false`:

```yaml
annotations:
  sidecar.speedscale.com/inject: "false"
```

Depending on how the rollout is configured it may not cycle right away. Patch the pod template to force it:

```bash
now=$(date) && kubectl patch rollout rollouts-demo -p '{"spec": {"template": {"metadata": {"annotations": {"speedscale.com/restartedAt": "'$now'"}}}}}' --type merge
```

The rollout cycles and the sidecar is removed. This does not affect eBPF capture, which is controlled separately by the capture targets.