Istio — alert on istio-proxy sidecar restart loop
An istio-proxy sidecar in a pod is restarting — the app keeps running, but mesh policy is broken, mTLS goes unchecked, and traffic flows in violation of policy.
Recipe
#!/usr/bin/env bash
# /etc/cron.d/istio-sidecar
# */5 * * * * root /opt/istio-sidecar.sh
CONTEXT=${KUBE_CONTEXT:-prod}
THRESH=${THRESH:-3} # restarts in last hour
# Find pods where the istio-proxy container has restartCount delta > THRESH
HOTSPOTS=$(kubectl --context "$CONTEXT" get pods -A -o json \
| jq --argjson t "$THRESH" '
[.items[] |
. as $p |
.status.containerStatuses[]? |
select(.name=="istio-proxy" and .restartCount >= $t) |
{ns: $p.metadata.namespace, name: $p.metadata.name, restarts: .restartCount}]')
COUNT=$(echo "$HOTSPOTS" | jq 'length')
if [ "${COUNT:-0}" -gt 0 ]; then
SUMMARY=$(echo "$HOTSPOTS" | jq -r '.[] | "\(.ns)/\(.name)=\(.restarts)"' | head -5 | tr '\n' ',')
curl -fsS "$HEARTBEAT_URL" --data "sidecar_loops=$COUNT,examples=$SUMMARY"
exit 2
fi
echo "OK (no sidecar loops)"Same thing in Enterno.io
Wrap in an Enterno heartbeat — learn the sidecar is looping before traffic falls onto a non-mTLS path.
Related recipes
Readiness probes pass inside the pod, but no one sees that the LB refused to route traffic to the new deploy.
A CrashLoopBackOff in one namespace — kubectl shows a restart count of 47, but nobody sees it. Want an endpoint that returns high when the counter jumps.
Inside a K8s cluster etcd re-elects the leader every 30 s — kube-apiserver lags, controller-manager can't keep reconciling. Only visible in etcd metrics.