一键导入
troubleshoot-ml-k8s
Help pinpoint why a Wikimedia ML KServe/Knative InferenceService deployment is not working on ml-serve or ml-staging Kubernetes clusters.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Help pinpoint why a Wikimedia ML KServe/Knative InferenceService deployment is not working on ml-serve or ml-staging Kubernetes clusters.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Triage Wikimedia ML inference-services incidents at a time T (now or past). TRIGGER on "investigate / triage / debug / post-mortem / what happened" when the subject is a LiftWing alert, ML-serve namespace, error spike, latency regression, or pod crash — including generic phrasing ("investigate this issue") when context (Phabricator task, pasted alert, log snippet) points at LiftWing, even with no alert string. Always trigger on: LiftWingServiceErrorRate, KubernetesDeploymentUnavailableReplicas, KubernetesPodCrashLooping; any namespace under revscoring*, revertrisk*, articletopic-outlink, or other ML-serve; clusters ml-serve-eqiad, ml-serve-codfw, ml-staging-codfw. SKIP only when modifying code without diagnosing a runtime incident. Pulls Prometheus via Grafana's anonymous datasource proxy; correlates with Gerrit merges in `inference-services` and `deployment-charts` (Phab IDs from `Bug:` footers). Read-only.
Analyze a model server's Python code and its deployment chart to identify performance bottlenecks and optimization opportunities for CPU and GPU (AMD MI300X, ROCm, vLLM) inference services on KServe. Use when you want to improve inference throughput or latency for a model.
Scaffold a new LiftWing ML service in operations/deployment-charts. Handles both adding to an existing namespace (append inference_services entry) and creating a brand-new namespace (full helmfile scaffold). Use when an engineer wants to deploy a new inference service for the first time.
Bump the Docker image tag for one or more LiftWing inference services in operations/deployment-charts after a new image is published by Jenkins. Use when a patch has merged in inference-services, PipelineBot has posted a new image tag on the Gerrit CL, and you need to update the corresponding values.yaml file(s) to deploy it.
Build and run a model server locally via Docker Compose, then test it with curl. Use when the engineer wants to test a model server locally before committing.
Scaffold a new KServe model server from scratch — create the model.py, Blubber config, Docker Compose service, pipeline config, and CI wiring. Use when the engineer wants to add a new inference service model to this repo.
| name | troubleshoot-ml-k8s |
| description | Help pinpoint why a Wikimedia ML KServe/Knative InferenceService deployment is not working on ml-serve or ml-staging Kubernetes clusters. |
| disable-model-invocation | false |
| argument-hint | <cluster> <namespace> <inferenceservice> |
| context | |
| agent |
Use this skill when an InferenceService deployment is failing, stuck, unreachable, not scaling, or returning bad responses. The goal is not to collect every possible Kubernetes fact; it is to narrow the failure to the responsible layer and state the most likely cause with the evidence that supports it.
Important constraints
deployment.eqiad.wmnet after entering the cluster context (sudo users: sudo -i + kube-env admin <cluster>; non-sudo users: kube-env <your-username> <cluster>).kubectl get pods -A sweeps.Collect information one prompt at a time. Do not dump all questions at once.
Step 0 — Access check
Prompt: "Do you have sudo access on deployment.eqiad.wmnet? If yes, you will run sudo -i and kube-env admin <cluster>. If not, you will run kube-env <your-username> <cluster> instead."
Wait for the user's reply before proceeding.
Step 1 — Cluster
Prompt: "Which cluster is the InferenceService deployed to? (ml-serve-eqiad, ml-serve-codfw, or ml-staging-codfw)"
Wait for the user's reply before proceeding.
Step 2 — Namespace
Prompt: "What namespace is it in?"
Wait for the user's reply before proceeding.
Step 3 — InferenceService name
Prompt: "What is the InferenceService name?"
After collecting all three inputs, have the user enter the cluster context:
ssh deployment.eqiad.wmnet
# If you have sudo access:
sudo -i
KUBE_USER=admin
kube-env "$KUBE_USER" <cluster>
# If you do not have sudo access:
KUBE_USER=<your-username>
kube-env "$KUBE_USER" <cluster>
Then ask them to run the initial diagnostic bundle:
NS=<namespace>
ISVC=<inferenceservice>
kubectl get inferenceservice "$ISVC" -n "$NS" -o wide
kubectl get inferenceservice "$ISVC" -n "$NS" -o yaml
kubectl describe inferenceservice "$ISVC" -n "$NS"
kubectl get events -n "$NS" --sort-by='.lastTimestamp' | tail -80
kubectl get ksvc,revision,route,configuration -n "$NS" -l serving.kserve.io/inferenceservice="$ISVC"
kubectl get pods -n "$NS" -l serving.kserve.io/inferenceservice="$ISVC" -o wide
Read the output in this order:
status.conditions: identify the first False or Unknown condition and its reason/message.Use when kubectl get inferenceservice returns NotFound, or describe/events show admission, webhook, validation, or reconciliation errors.
kubectl get inferenceservices -n "$NS"
kubectl get pods -n kserve
kubectl logs -n kserve deploy/kserve-controller-manager --tail=200
Likely causes:
Conclude with the exact rejected field or controller error if present.
Use when the InferenceService exists but no ready Knative revision is created.
kubectl describe ksvc "$ISVC-predictor" -n "$NS"
kubectl get revisions -n "$NS" -l serving.kserve.io/inferenceservice="$ISVC" -o wide
kubectl describe revision -n "$NS" -l serving.kserve.io/inferenceservice="$ISVC"
kubectl logs -n knative-serving deploy/controller --tail=200
Likely causes:
Name the failing revision and condition.
Use when pod status is Pending, Unschedulable, or stuck creating.
POD=<pod>
kubectl describe pod "$POD" -n "$NS"
kubectl get nodes -o wide
kubectl get pvc -n "$NS"
kubectl get nodes -o json | jq -r '.items[] | {name: .metadata.name, capacity_gpu: .status.capacity."amd.com/gpu", allocatable_gpu: .status.allocatable."amd.com/gpu"}'
Likely causes:
amd.com/gpuUse the pod events as the source of truth. Quote the scheduler or kubelet reason in the final diagnosis.
Use when pod status is CrashLoopBackOff, Error, RunContainerError, or restarts keep increasing.
POD=<pod>
kubectl describe pod "$POD" -n "$NS"
kubectl logs "$POD" -n "$NS" --all-containers --tail=200
kubectl logs "$POD" -n "$NS" --all-containers --previous --tail=200
Likely causes:
storageUriDifferentiate app failure from platform failure:
Use when the predictor pod is Running but the InferenceService/Revision remains not ready.
POD=<pod>
kubectl describe pod "$POD" -n "$NS"
kubectl logs "$POD" -n "$NS" --all-containers --tail=200
kubectl get revision -n "$NS" -l serving.kserve.io/inferenceservice="$ISVC" -o yaml
kubectl describe ksvc "$ISVC-predictor" -n "$NS"
Likely causes:
Look for readiness probe failures, queue-proxy errors, and the actual listening port in logs.
Use when resources are ready but HTTP requests fail.
kubectl get inferenceservice "$ISVC" -n "$NS" -o jsonpath='{.status.url}{"\n"}'
kubectl get route "$ISVC-predictor" -n "$NS" -o yaml
kubectl describe route "$ISVC-predictor" -n "$NS"
kubectl get virtualservice -A | grep "$ISVC"
kubectl get pods -n istio-system
kubectl logs -n knative-serving deploy/activator --tail=200
Likely causes:
If the service is ready, make the diagnosis from route status, ingress/activator logs, and the exact HTTP status.
Use when requests eventually work but latency, timeouts, or scale behavior is wrong.
kubectl get revision -n "$NS" -l serving.kserve.io/inferenceservice="$ISVC" -o yaml
kubectl describe ksvc "$ISVC-predictor" -n "$NS"
kubectl logs -n knative-serving deploy/autoscaler --tail=200
kubectl logs -n knative-serving deploy/activator --tail=200
kubectl top pods -n "$NS"
kubectl top nodes
Likely causes:
Separate cold-start problems from steady-state performance problems.
Use when the service is reachable but returns 4xx, 5xx, malformed output, or wrong predictions.
POD=<pod>
kubectl logs "$POD" -n "$NS" --all-containers --tail=300
kubectl get inferenceservice "$ISVC" -n "$NS" -o yaml
kubectl describe pod "$POD" -n "$NS"
Likely causes:
Treat this as an application/model issue unless Kubernetes events or readiness conditions show platform failure.
When responding to the user, be concise and diagnostic:
If evidence is contradictory, say what conflicts and ask for the smallest missing command output. Avoid asking for full cluster dumps unless the current branch gives no signal.
ml-serve-eqiad: production eqiad, workers ml-serve1001 through ml-serve1015ml-serve-codfw: production codfw, workers ml-serve2001 through ml-serve2011ml-staging-codfw: staging codfw, workers ml-staging2001 through ml-staging2003amd.com/gpu