Support for Istio (Sidecar and Ambient)

[christensenjairus]

Hey, love this project!

Could you could support running in either (preferably both) istio modes?
I've noticed scale-up does not occur when inside the mesh in either istio mode, causing client timeouts.

[ctrox]

I don't have much experience using istio but I quickly tested both modes (latest version 1.28.2) on a local kind cluster together with zeropod (also the latest version) and the nginx from config/examples/nginx.yaml.

In sidecar mode, one issue seems to be the health checks that istio is doing, these seem to fail whenever the application is scaled down. But generally, scaling up and down seems to work through the proxy.

In ambient mode, everything worked at first glance. It scales up on requests (I just used a NodePort service) and I see the request IP as 169.254.7.127 so traffic is being routed through istio. But there seems to be an issue with the last connection detection, so it will always scale down after the configured duration is over, regardless of recent connections.

Both of these issues are probably fixable but I can't really commit to anything right now. Can you maybe describe your setup in more detail so we can figure out why it does not seem to work at all?

[christensenjairus]

I've tried it with your nginx in Kind, as you said, and it seems to be working differently than it did my main dev environment. That's a relief :) I'll poke around more to see if it's a networking issue or something specific to my CNI.

I agree with your diagnosis of what occurs in Kind. 👍

[christensenjairus]

I spoke too soon, I didn't have ambient installed correctly on kind 🤦. W/ ambient mode I get a 503.

Here's my istiooperator config for testing on kind

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  profile: ambient #demo
  meshConfig:
    accessLogFile: /dev/stdout
  components:
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true
    - name: istio-egressgateway
      enabled: false

Then I have port 30000 mapped to a nodeport for the ingressgateway service.

I set up a gateway & virtualservice like so

apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: gateway
  namespace: istio-system
spec:
  selector:
    istio: ingressgateway
  servers:
  - hosts:
    - '*'
    port:
      name: http
      number: 80
      protocol: HTTP
---
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: nginx
  namespace: default
spec:
  gateways:
  - istio-system/gateway
  hosts:
  - '*'
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: nginx
        port:
          number: 80

❯ curl localhost:30000 -I
HTTP/1.1 200 OK
server: istio-envoy
date: Mon, 05 Jan 2026 03:23:55 GMT
content-type: text/html
content-length: 615
last-modified: Tue, 09 Dec 2025 18:28:10 GMT
etag: "69386a3a-267"
accept-ranges: bytes
x-envoy-upstream-service-time: 122

❯ kubectl label ns default istio.io/dataplane-mode=ambient
namespace/default labeled
❯ curl localhost:30000 -I
HTTP/1.1 503 Service Unavailable
content-length: 95
content-type: text/plain
date: Mon, 05 Jan 2026 03:24:12 GMT
server: istio-envoy

Ztunnel has a log that says

2026-01-05T03:24:13.367778Z    error    access    connection complete    src.addr=
10.244.3.11:51754 src.workload="istio-egressgateway-684464ff44-bxk4s" src.namespac
e="istio-system" src.identity="spiffe://cluster.local/ns/istio-system/sa/istio-egr
essgateway-service-account" dst.addr=10.244.1.10:15008 dst.hbone_addr=10.244.1.10:
80 dst.service="nginx.default.svc.cluster.local" dst.workload="nginx-7c78fb948f-8b
cpd" dst.namespace="default" dst.identity="spiffe://cluster.local/ns/default/sa/de
fault" direction="inbound" bytes_sent=0 bytes_recv=0 duration="10001ms" error="con
nection failed: deadline has elapsed" 

Zeropod doesn't show much on this node to help debug.

[christensenjairus]

Alternatively, with sidecar mode, when targeting only nginx container, something about istio keeps it alive, as you saw. Targeting istio-proxy as well as nginx causes a 503 error as the istio-proxy gets suspended and doesn't get into RUNNING state again, while nginx does keep running, so it's not the sidecar keeping it alive.

Anyway, I'm sure your day job keeps you busy. You can take your time, there's no rush 👍

[myeongseok-rpls]

Hi,
I’m running into a very similar issue and wanted to share some observations.

From what I understand, Zeropod’s restore mechanism appears to rely on the Pod itself receiving the first incoming TCP connection (destination port) in order to trigger a restore.

In an Istio Ambient Mesh environment, inbound (and outbound) traffic is handled by istio-cni and ztunnel. My understanding is that the initial TCP connection is intercepted at ztunnel and a new connection is then established from ztunnel to the Pod. If this interpretation is correct, the zeropod shim inside the Pod would never see the original incoming connection, which could explain why the restore trigger does not fire.

In my setup, restore consistently fails when the zeropod workload participates in ambient mesh, but starts working again once the Pod is explicitly excluded using istio.io/dataplane-mode: none.

This makes me suspect a potential structural mismatch rather than a simple configuration issue. Supporting ambient environments might require moving away from a “first TCP connection to the Pod”–based restore trigger, for example toward an L7/HTTP-based or external trigger model.

Thanks a lot for this great project and for all the work you’ve put into it — zeropod has been really interesting to experiment with.