Install any skill in seconds. Free to start, no credit card required.
Get Started Free →KubeSphere Gateway extension management Skill (ingress-nginx based, uses Kubernetes Ingress API + Gateway CRD gateway.kubesphere.io/v2alpha2). For the newer Kubernetes Gateway API (Traefik + GatewayProxy CRD), see the kubesphere-gateway-api skill instead. Covers installation, uninstallation, status checks, gateway status inspection, and troubleshooting (gateway stuck states, Helm failures, pod issues).
.claude/skills/kubesphere-kubesphere-gateway/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-04 | ✗→✓ | ▲ Improved | 335% | 0% |
| case-05 | ✗→✓ | ▲ Improved | 245% | 0% |
| case-06 | ✗→✓ | ▲ Improved | 89% | 0% |
| case-07 | ✗→✓ | ▲ Improved | 47% | 0% |
| case-12 | ✗→✓ | ▲ Improved | 161% | 0% |
Provides external access management (ingress) for KubeSphere using ingress-nginx. Supports three-tier gateway management:
| Tier | Scope | Name Pattern | Namespace | Label | |---|---|---|---| | Cluster | Entire cluster | kubesphere-router-cluster | kubesphere-controls-system | kubesphere.io/gateway-type=cluster | | Workspace | Single workspace | kubesphere-router-workspace-{workspace} | kubesphere-controls-system | kubesphere.io/gateway-type=workspace | | Project | Single project/namespace | kubesphere-router-{namespace} | kubesphere-controls-system | kubesphere.io/gateway-type=project |
Each gateway is a standalone Helm release of ingress-nginx. The gateway-controller-manager manages the lifecycle (install/upgrade/uninstall) via Helm.
Gateway (gateway.kubesphere.io/v2alpha2) — represents a single ingress-nginx deployment. Key fields:spec.appVersion — the Helm chart version (e.g. kubesphere-nginx-ingress-<version>)spec.values — Helm values for ingress-nginx (controller config, service type, resources, etc.)status.state — Creating, Updating, Running, Faulted, Stoppedstatus.conditions[].type=GatewayReady — True when fully operationalstatus.loadBalancer — LB ingress IPs/hostnamesstatus.service — Service type, ports, external IPsUpgradePlan (gateway.kubesphere.io/v2alpha2) — batch gateway upgrade job. Key fields:spec.gatewayReferences — list of {name, namespace} to upgradespec.targetAppVersion — target versionstatus.state — Pending, Running, Succeeded, FailedGateway exposes NGINX metrics (requests, 4xx/5xx, latency P50/P90/P99) via Prometheus. Requires the whizard-monitoring extension (optional dependency).
Check if Gateway extension is already installed:
bashkubectl get installplans.kubesphere.io gateway --ignore-not-found
If found, upgrading is supported — just select a newer version in Step 1.
bashALL_VERSIONS=$(kubectl get extensionversions.kubesphere.io \ -l kubesphere.io/extension-ref=gateway \ -o jsonpath='{range .items[*]}{.spec.version}{"\n"}{end}' | sort -V) LATEST_STABLE=$(echo "$ALL_VERSIONS" | grep -v -E 'alpha|beta|rc' | tail -1) if [ -z "$LATEST_STABLE" ]; then LATEST_STABLE=$(echo "$ALL_VERSIONS" | tail -1) fi echo "Available versions:" echo "$ALL_VERSIONS" echo "" echo "Latest stable: $LATEST_STABLE"
This sets ALL_VERSIONS and LATEST_STABLE. Use SELECTED_VERSION for the version chosen.
Use the question tool:
$LATEST_STABLE (Recommended) — accept the auto-detected versionbashCLUSTER_DATA=$(kubectl get clusters.cluster.kubesphere.io \ -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.conditions[?(@.type=="Ready")].status}{"\n"}{end}') READY_CLUSTERS=$(echo "$CLUSTER_DATA" | awk -F'\t' '$2 == "True" {print $1}') CLUSTER_COUNT=$(echo "$READY_CLUSTERS" | wc -l) HOST_CLUSTER=$(kubectl get clusters.cluster.kubesphere.io \ -l 'cluster-role.kubesphere.io/host' \ -o jsonpath='{.items[0].metadata.name}' || echo "") echo "Ready clusters:" echo "$READY_CLUSTERS" echo "" echo "Cluster count: $CLUSTER_COUNT" echo "Host cluster: $HOST_CLUSTER"
This sets READY_CLUSTERS, CLUSTER_COUNT, HOST_CLUSTER.
TARGET_CLUSTERS="$HOST_CLUSTER"question with multiple: true:TARGET_CLUSTERS="$READY_CLUSTERS"TARGET_CLUSTERS="$HOST_CLUSTER"$READY_CLUSTERSbash./scripts/generate-installplan.sh "$SELECTED_VERSION" "$TARGET_CLUSTERS"
This generates the YAML to /tmp/gateway-installplan.yaml, runs --dry-run=server, then prints the apply command.
> For configurable extension values (ingress-nginx default settings, image registry, upgrade tool config, etc.), see references/extension-values.md.
Apply it:
bashkubectl apply -f /tmp/gateway-installplan.yaml
Tell the user "Installing". Then ask if they want to check status. If yes:
bash./scripts/check-status.sh poll
| Purpose | Command | |---|---| | Single snapshot | ./scripts/check-status.sh quick | | Wait until complete (5min timeout) | ./scripts/check-status.sh poll |
Logic:
Installed → ✓ successFailed → ✗ prints full status> ⚠ Always confirm with the user before proceeding.
bashif ! kubectl get installplans.kubesphere.io gateway &>/dev/null; then echo "Gateway is not installed." exit 0 fi
Confirm with the user, then delete:
bashkubectl delete installplans.kubesphere.io gateway --ignore-not-found
Verify cleanup:
bash./scripts/verify-uninstall.sh
Success criteria:
extension-gateway namespace> WARNING: Do NOT delete the InstallPlan. Only remove target clusters from the placement list.
Confirm which clusters to remove, compute remaining clusters, then patch:
bashkubectl patch installplans.kubesphere.io gateway --type='json' \ -p='[{"op": "replace", "path": "/spec/clusterScheduling/placement/clusters", "value": ["<REMAINING_CLUSTER_1>", "<REMAINING_CLUSTER_2>"]}]'
Success: patch returns OK + removed clusters no longer in .status.clusterSchedulingStatuses.
Gateways are organized by tier (see Overview), with each tier identified by the label kubesphere.io/gateway-type. List them grouped by tier:
bashecho "=== Cluster Gateway ===" kubectl get gateways.gateway.kubesphere.io -n kubesphere-controls-system \ -l kubesphere.io/gateway-type=cluster echo -e "\n=== Workspace Gateways ===" kubectl get gateways.gateway.kubesphere.io -n kubesphere-controls-system \ -l kubesphere.io/gateway-type=workspace echo -e "\n=== Project Gateways ===" kubectl get gateways.gateway.kubesphere.io -n kubesphere-controls-system \ -l kubesphere.io/gateway-type=project
Pick a gateway name from the List Gateways output and run:
bashGW_NS="kubesphere-controls-system" GW_NAME="<gateway-name-from-list>" # app.kubernetes.io/instance uses the Helm release name if available, otherwise the Gateway name GW_INSTANCE=$(kubectl get gateways.gateway.kubesphere.io -n $GW_NS $GW_NAME -o jsonpath='{.status.helmRelease.name}' 2>/dev/null) if [ -z "$GW_INSTANCE" ]; then GW_INSTANCE="$GW_NAME" fi kubectl get gateways.gateway.kubesphere.io -n $GW_NS $GW_NAME -o wide kubectl describe gateways.gateway.kubesphere.io -n $GW_NS $GW_NAME kubectl get gateways.gateway.kubesphere.io -n $GW_NS $GW_NAME -o yaml kubectl get pods -n $GW_NS -l "app.kubernetes.io/instance=$GW_INSTANCE"
Gateway states: | State | Meaning | |---|---| | Creating | First-time Helm install in progress | | Updating | Helm upgrade in progress (spec changed) | | Running | Fully operational (all replicas available) | | Faulted | Deployment missing, stopped unexpectedly, or health probe timeout | | Stopped | Scaled to zero replicas intentionally |
> Set $GW_NAME according to the gateway tier being troubleshot (see naming rules in Overview): > - Cluster → GW_NAME=kubesphere-router-cluster > - Workspace → GW_NAME=kubesphere-router-workspace-${WORKSPACE} > - Project → GW_NAME=kubesphere-router-${NAMESPACE} > > Common namespace: GW_NS=kubesphere-controls-system > > $GW_INSTANCE is auto-resolved from status.helmRelease.name (falls back to $GW_NAME). If not yet set, run: > bash > GW_INSTANCE=$(kubectl get gateways.gateway.kubesphere.io -n $GW_NS $GW_NAME -o jsonpath='{.status.helmRelease.name}' 2>/dev/null) > if [ -z "$GW_INSTANCE" ]; then > GW_INSTANCE="$GW_NAME" > fi >
Creating or Updating statebashkubectl describe gateways.gateway.kubesphere.io -n $GW_NS $GW_NAME kubectl logs -n extension-gateway -l app=gateway-controller-manager --tail=200 | grep -iE "(error|helm|install|upgrade|reconcile)" kubectl get deployment -n $GW_NS -l "app.kubernetes.io/instance=$GW_INSTANCE,app.kubernetes.io/component=controller" kubectl get configmap -n $GW_NS $GW_NAME -o yaml
Common causes: Chart ConfigMap missing/corrupted, Helm wrapper timeout, invalid spec.values.
Faulted statebashkubectl get deployment -n $GW_NS $GW_NAME -o wide kubectl describe deployment -n $GW_NS $GW_NAME kubectl get pods -n $GW_NS -l "app.kubernetes.io/instance=$GW_INSTANCE" -o wide POD_NAME=$(kubectl get pods -n $GW_NS -l "app.kubernetes.io/instance=$GW_INSTANCE" -o jsonpath='{.items[0].metadata.name}') kubectl describe pod -n $GW_NS $POD_NAME kubectl logs -n $GW_NS $POD_NAME --tail=100
Common causes: Image pull failure, resource constraints, port conflicts, missing ConfigMap/Secret.
bashkubectl logs -n $GW_NS -l "app.kubernetes.io/instance=$GW_INSTANCE" --tail=100 --previous kubectl get events -n $GW_NS --sort-by='.lastTimestamp' | tail -20 kubectl exec -n $GW_NS -l "app.kubernetes.io/instance=$GW_INSTANCE" -- cat /etc/nginx/nginx.conf 2>/dev/null | head -50 kubectl get configmap -n $GW_NS -l "app.kubernetes.io/instance=$GW_INSTANCE" -o yaml
Common causes: Misconfigured nginx config, port conflicts, resource limits (OOMKilled), missing dependencies (ConfigMap/Secret).
Gateway log search proxies to whizard-telemetry-apiserver:
bashkubectl get configmap -n extension-gateway gateway-agent-backend-config -o yaml kubectl get pods -n extension-whizard-telemetry kubectl get svc -n extension-whizard-telemetry whizard-telemetry-apiserver kubectl logs -n extension-gateway -l app=gateway-apiserver --tail=100 | grep -iE "(log|search|whizard|proxy)"
Common causes: Whizard-telemetry not installed or not running, misconfigured gateway-agent-backend-config, network policy blocking cross-namespace traffic.
bashkubectl get pods -n extension-gateway -l app=gateway-controller-manager kubectl logs -n extension-gateway -l app=gateway-controller-manager --tail=200 kubectl get validatingwebhookconfiguration -l "app.kubernetes.io/managed-by=Helm,kubesphere.io/extension-ref=gateway" kubectl get deployment -n extension-gateway -l app=gateway-controller-manager -o yaml
Common causes: Controller pod not running, webhook configuration blocking updates, Helm release state mismatch, RBAC permission issues.
| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-01 | fail→fail | 4,781 | 5,740 | +20% | 1 | 1 | 0% | 250 | 4,058 | +1523% | 0 | 0 | — |
case-02 | fail→fail | 4,868 | 3,057 | -37% | 1 | 1 | 0% | 912 | 3,573 | +292% | 0 | 0 | — |
case-03 | fail→fail | 16,311 | 4,331 | -73% | 1 | 1 | 0% | 1,863 | 3,762 | +102% | 0 | 0 | — |
case-04 | fail→pass | 4,655 | 2,425 | -48% | 1 | 1 | 0% | 805 | 3,503 | +335% | 0 | 0 | — |
case-05 | fail→pass | 5,894 | 2,422 | -59% | 1 | 1 | 0% | 1,057 | 3,647 | +245% | 0 | 0 | — |
case-06 | fail→pass | 12,765 | 3,452 | -73% | 1 | 1 | 0% | 2,098 | 3,967 | +89% | 0 | 0 | — |
case-07 | fail→pass | 14,004 | 2,644 | -81% | 1 | 1 | 0% | 2,534 | 3,718 | +47% | 0 | 0 | — |
case-12 | fail→pass | 9,382 | 5,398 | -42% | 1 | 1 | 0% | 1,476 | 3,851 | +161% | 0 | 0 | — |
case-08 | fail→pass | 10,514 | 4,385 | -58% | 1 | 1 | 0% | 1,645 | 3,956 | +140% | 0 | 0 | — |
case-09 | fail→pass | 11,490 | 19,849 | +73% | 1 | 1 | 0% | 1,995 | 3,972 | +99% | 0 | 0 | — |
case-10 | fail→pass | 14,768 | 2,010 | -86% | 1 | 1 | 0% | 1,169 | 3,637 | +211% | 0 | 0 | — |
case-11 | fail→pass | 10,468 | 4,085 | -61% | 1 | 1 | 0% | 1,218 | 4,012 | +229% | 0 | 0 | — |
case-13 | fail→pass | 8,977 | 3,688 | -59% | 1 | 1 | 0% | 1,556 | 3,886 | +150% | 0 | 0 | — |
case-14 | fail→pass | 6,691 | 2,187 | -67% | 1 | 1 | 0% | 1,295 | 3,669 | +183% | 0 | 0 | — |
case-15 | fail→pass | 7,907 | 2,737 | -65% | 1 | 1 | 0% | 1,258 | 3,682 | +193% | 0 | 0 | — |
case-16 | fail→pass | 7,961 | 3,480 | -56% | 1 | 1 | 0% | 1,271 | 3,796 | +199% | 0 | 0 | — |
case-17 | fail→pass | 10,357 | 2,287 | -78% | 1 | 1 | 0% | 1,618 | 3,597 | +122% | 0 | 0 | — |
case-18 | fail→pass | 13,410 | 1,986 | -85% | 1 | 1 | 0% | 2,118 | 3,650 | +72% | 0 | 0 | — |
case-19 | fail→pass | 8,564 | 2,192 | -74% | 1 | 1 | 0% | 1,438 | 3,555 | +147% | 0 | 0 | — |
case-20 | pass→pass | 12,142 | 6,244 | -49% | 1 | 1 | 0% | 2,081 | 4,382 | +111% | 0 | 0 | — |
case-21 | pass→pass | 38,335 | 13,206 | -66% | 1 | 1 | 0% | 3,557 | 5,584 | +57% | 0 | 0 | — |
case-22 | pass→fail | 16,660 | 6,590 | -60% | 1 | 1 | 0% | 2,787 | 3,540 | +27% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 22 cases were attempted, and 19 counted toward the lift figure. The other 3 produced results that are not comparable between the two arms, so they are excluded from the headline rather than averaged into it. The headline lift of +68 percentage points is the difference between those two pass rates over the 19 comparable cases. 1 case got worse with the skill loaded, and it is included in that figure.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.