# Compatibility > What sends a paused workload's traffic to the doorman, and how far each is checked. Source: https://docs.napwake.dev/next/reference/compatibility/ * Kubernetes 1.30 and later * Tested in CI on 1.30 and 1.37 [Wake on request](https://docs.napwake.dev/next/concepts/wake-on-request/) points a paused workload’s Services at the doorman with an EndpointSlice per IP family. Anything that finds backends through EndpointSlices then reaches the doorman, though each project reads them its own way. | Status | Means | | ---------------------- | -------------------------------------------------------------------------- | | Tested | End-to-end tests run it on every change | | Tried by hand | Run once on a test cluster, for the release listed | | Checked against source | Its endpoint code was read for the release listed, and nothing runs it yet | ## Service proxies | Proxy | Status | Notes | | -------------------------------------------------------------------------------- | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | kube-proxy, kind’s default mode | Tested | ClusterIP Services, from pods and through ingress-nginx | | kube-proxy, other modes (ipvs, nftables), and NodePort and LoadBalancer Services | Not tested yet | Same EndpointSlices as ClusterIP. [Admit nodes’ addresses](https://docs.napwake.dev/next/concepts/wake-on-request/#restricting-who-can-reach-the-doorman) in `doorman.networkPolicy.ingressFrom` as an `ipBlock` | | NodePort and LoadBalancer Services with `externalTrafficPolicy: Local` | **Partial** | Routed, but external traffic stays on its node, so at a node with no doorman pod it’s dropped and nothing wakes | | Cilium kube-proxy replacement (v1.20) | Checked against source | | ## Ingress controllers and Gateway API | Controller | Status | Notes | | --------------------------------------------------------- | ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ingress-nginx (v1.15) | Tested | Reads endpoints on a timer, so for a second or two after a pause it can send a request to the removed pod. [Closes upstream requests](https://docs.napwake.dev/next/concepts/wake-on-request/#how-long-a-connection-is-held) after 60 seconds by default | | Traefik (v3.7), for Ingress, IngressRoute and Gateway API | Checked against source | | | Envoy Gateway (v1.9) | Checked against source | | | Contour (v1.33) | Checked against source | | | Kong Ingress Controller (v3.5) | Checked against source | | | HAProxy Kubernetes Ingress (v3.2) | Checked against source | | | Cilium Ingress and Gateway API (v1.20) | Checked against source | | ## Cloud load balancers | Load balancer | Status | Notes | | -------------------------------------------------------------------------------------------------------- | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | AWS Load Balancer Controller, target type `instance` | Checked against source | Through the NodePort | | AWS Load Balancer Controller, target type `ip` | Checked against source | Registers the doorman pods as targets, if it watches the Napwake namespace, as it does without `--watch-namespace` | | GKE Ingress (GKE 1.36) on instance groups, its Service with `cloud.google.com/neg: '{"ingress": false}'` | Tried by hand | Through the NodePort. The doorman [answers Google’s health check](https://docs.napwake.dev/next/concepts/wake-on-request/#on-gke) `200`, so the backend stayed healthy while paused, and a request through the Ingress woke it | | HTTPS health checks on the traffic port, any provider | **Partial** | [Each check wakes the workload.](https://docs.napwake.dev/next/concepts/wake-on-request/#health-checks-the-doorman-cant-recognise) Check over HTTP, or on a port of its own in `napwake.dev/doorman-ignore-ports` | | Services on GKE (1.36) that no GKE Ingress uses | Tried by hand | Routed like any other, since [GKE’s default NEG annotation](https://docs.napwake.dev/next/concepts/wake-on-request/#on-gke) alone makes no NEG. A request through ingress-nginx woke a paused workload | | GKE container-native load balancing (NEGs) | **Not supported** by default | [Not routed](https://docs.napwake.dev/next/concepts/wake-on-request/#on-gke), with a warning event naming the Service. With no other Service routed, the workload reports `WakeOnRequest=False`, reason `UnsupportedLoadBalancer`. The forwarder, next row, routes it | | GKE Ingress with NEGs (GKE 1.36), with `doorman.negForwarder.enabled` | Tried by hand | [Optional](https://docs.napwake.dev/next/concepts/wake-on-request/#gke-container-native-load-balancing-negs), off by default. The NEG kept the forwarder healthy, a request woke the workload and showed a browser the waking-up page, and nothing failed as the forwarder went. For under a minute after a pause, a request can get a `502`. GKE Gateway is checked against ingress-gce’s source only | ## Service meshes | Mesh | Status | Notes | | --------------------------------------------------------------- | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | Linkerd (edge-26.9) | Checked against source | Plain TCP to the doorman, without mTLS | | Istio sidecar mode, PERMISSIVE mTLS (v1.31) | Tried by hand | Istio’s default. Callers in the mesh reach the doorman in plain text, and the woken pod’s sidecar accepts the connection | | Istio sidecar mode, STRICT mTLS (v1.31) | **Partial** | Wakes the workload, but the woken pod’s sidecar refuses the doorman’s plain text, so the caller gets a `503`. Requests once it’s Running succeed | | Istio ambient mode (v1.31) | **Not supported** | ztunnel builds backends from pods and ignores EndpointSlices, so callers in the mesh never reach the doorman. Callers outside the mesh still do | | Istio AuthorizationPolicies that match on the caller’s identity | **Not supported** (not tried) | The doorman’s connections carry no caller identity, so a policy allowing only certain callers denies them | For a workload on a public URL, which crawlers would wake, have the doorman [ask before waking](https://docs.napwake.dev/next/concepts/wake-on-request/#asking-before-waking). To keep the doorman off a port, or the whole cluster, see [Turning it off](https://docs.napwake.dev/next/concepts/wake-on-request/#turning-it-off). To report something, [open an issue](https://github.com/napwake/napwake/issues).