Istio — алерт при restart-loop у istio-proxy sidecar
istio-proxy sidecar в pod рестартует — приложение работает, но mesh-policy ломается, mTLS не проверяется, traffic идёт с нарушением политики безопасности.
Рецепт
#!/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)"
То же самое в Enterno.io
Заверните в Enterno heartbeat — узнаете когда sidecar начал loop-ать раньше, чем traffic ляжет на нелегитимный путь без mTLS.
Похожие рецепты
Readiness-probe внутри пода есть, но никто не видит, что LB отказался роутить трафик на новый deploy.
CrashLoopBackOff в одном пространстве имён — kubectl показывает restart-count = 47, но никто не видит. Хочется endpoint, который вернёт high когда счётчик прыгает.
etcd в кластере K8s переизбирает лидера каждые 30 сек — kube-apiserver лагает, controller-manager не успевает применять reconcile. Это видно только в etcd-метриках.