We're in the process of standardizing our container security and monitoring on Sysdig across a mixed estate of Linux and Windows Server containers (mostly Windows Server 2019 LTSC). Our Linux agent rollout was straightforward, but we're hitting consistent, repeated failures with the Sysdig agent on our Windows container hosts. The pods enter a `CrashLoopBackOff` and the agent never becomes functional.
Our environment is AKS on Azure, with Windows nodes running the `aks-windows` CBL-Mariner-based image (Windows Server 2022 with containerd). We're deploying the agent via the official Helm chart (`sysdig/sysdig`) with the `nodeAnalyzer` and `global.sysdig.region` configured appropriately. The failure appears to be at the kernel module level, but the Windows driver story seems less clear than the Linux eBPF approach.
From the agent pod logs, we repeatedly see entries related to driver installation and then a fatal error:
```
time="2023-xx-xxTxx:xx:xxZ" level=info msg="Loading driver"
time="2023-xx-xxTxx:xx:xxZ" level=error msg="An error occurred while loading the driver: The system cannot find the file specified."
```
Followed by a restart.
Our current Helm values relevant to Windows are:
```yaml
sysdig:
secure:
enabled: true
agent:
os: "windows"
windows:
enabled: true
nodeSelector:
kubernetes.io/os: windows
tolerations:
- key: "os"
value: "windows"
Effect: "NoSchedule"
```
We've verified that the nodes have the necessary kernel headers, and we're running with privileged: true. The Sysdig documentation for Windows is notably sparser. Has anyone successfully deployed the Sysdig agent on Windows Server containers in a production Kubernetes environment, particularly on AKS?
Specific questions:
1. **Driver Signing:** Are there known issues with driver signing enforcement on newer Windows Server container hosts that would prevent the `sysdig-probe` kernel module from loading?
2. **Container Runtime:** Does the agent fully support `containerd` on Windows, or is there an implicit dependency on `dockershim` that we're missing?
3. **Image Version:** Is there a specific Windows base image version that is known to be compatible? Must we use a specific `sysdig/agent` image tag?
4. **Alternative Deployment:** Would we be better off installing the agent directly on the Windows host VM (outside of Kubernetes) for these nodes, and if so, how do we then integrate that data with our Kubernetes-centric Sysdig deployment?
Any insights into the exact failure path, required host configurations, or even a working example of your values.yaml would be immensely helpful. We're trying to avoid a scenario where we have a fragmented monitoring strategy simply because of the Windows container component.
- Mike
Mike
Windows containers with Sysdig are a different beast, especially on AKS. That driver error is classic.
Had a similar fight last year. The official Helm chart, for a long time, didn't have proper Windows support baked in. Even with the right node selector, the DaemonSet might be trying to load the Linux agent image on your Windows nodes.
A couple quick things to check:
* Are you overriding `image` and `imageTag` for the agent container to the *Windows* specific versions in your values? The default is Linux.
* Make sure `osType` is explicitly set to `windows` under `agent` in your Helm values. It sometimes guesses wrong.
* Double-check that the Windows kernel driver version matches your host OS build. That "cannot find the file" often means the driver isn't there or is for the wrong Windows version.
The logs from the node itself (kubectl describe pod on the Windows node) might show a pull error for the image if it's the wrong one. Good luck, this is finicky stuff!
Trial first, ask later.