Use when an Alibaba Cloud ACK / Serverless-ACK cluster has problems specific to ACK rather than generic Kubernetes - ECI/virtual-node pods stuck pulling images (cross-border registry timeouts, needing a regional mirro…
---
name: ack-triage
description: Use when an Alibaba Cloud ACK / Serverless-ACK cluster has problems specific to ACK rather than generic Kubernetes — ECI/virtual-node pods stuck pulling images (cross-border registry timeouts, needing a regional mirror), node-pool scaling not firing, Terway CNI ENI/IP issues, CCM-managed SLB with no targets or wrong listeners, ECI cold-start latency, or ACK-vs-upstream behavioral gaps. Read-only `kubectl` + `aliyun` CLI triage that names the Alibaba-Cloud-layer root cause.
---
# ack-triage
ACK (Alibaba Cloud Container Service for Kubernetes) is mostly upstream Kubernetes,
but the things that page you live in the Alibaba-Cloud seam: ECI/Serverless virtual
nodes, the Terway CNI, the Cloud Controller Manager (CCM) wiring Services to SLB, RAM
permissions, and — the single most common one — **cross-border image pulls timing
out** because the manifest points at a registry that's slow or blocked from the
mainland region. Those don't surface in a plain `kubectl describe`; you cross into the
`aliyun` API to see them. This skill drives that crossing read-only and reports the
**Alibaba-Cloud-layer root cause**.
Use `k8s-triage` for pure-Kubernetes symptoms. Use **this** when the problem smells
like Alibaba Cloud underneath: a Serverless pod that never finishes `ContainerCreating`,
an SLB with zero healthy targets, a node pool that won't grow.
## When to use
Reach for this on an ACK cluster when someone reports:
- a **Serverless-ACK / ECI / virtual-node pod stuck `ContainerCreating`** on image… install to load the full skill