/kubesphere-openkruise

name: kubesphere-openkruise
description: KubeSphere OpenKruise management Skill. Use when user asks to install or enable OpenKruise, check OpenKruise status, view kruise pods/logs/CRDs, create or update SidecarSet, manage sidecar injection, create or update CloneSet, perform in-place update or batch rollout, uninstall or remove OpenKruise, or troubleshoot Kruise Pod, CRD, and webhook issues in KubeSphere.

Skill: kubesphere-openkruise

KubeSphere OpenKruise Management

Use this skill for the full OpenKruise lifecycle in KubeSphere:

• Install or upgrade the OpenKruise extension through `InstallPlan`
• Query extension status, CRDs, Pods, and logs
• Generate `SidecarSet` manifests for sidecar injection and rolling updates
• Generate `CloneSet` manifests for advanced stateless workloads, in-place updates, and batch rollout
• Uninstall the OpenKruise extension
• Troubleshoot failed Pods, missing CRDs, and webhook problems

Out of scope by default:

• Advanced OpenKruise CRDs not requested by the user, such as `BroadcastJob`, `NodeImage`, `UnitedDeployment`, or `AdvancedPodAutoscaler`
• Deep chart-value design without cluster evidence

If the user explicitly asks for those CRDs, acknowledge that they are OpenKruise capabilities but treat them as a follow-up task instead of assuming they belong in the default workflow.

Response Rules

• Prefer executable output: `InstallPlan` YAML, `SidecarSet` YAML, `CloneSet` YAML, `kubectl` commands, or a short ordered procedure.
• Verify the extension name and exact version before generating a final `InstallPlan`.
• Default the extension name to `openkruise` only if the user context or cluster output does not expose a different resource name.
• In this KubeSphere environment, the observed mapping is:
• KubeSphere extension version `1.0.3`
• OpenKruise runtime version `1.4.0`
• Distinguish two version concepts before generating `InstallPlan`:
• KubeSphere extension version: used by `spec.extension.version`
• OpenKruise runtime version: the controller or component version seen in Pods or docs
• For this environment, if the user asks to install the current OpenKruise plugin and does not provide another extension version, prefer `spec.extension.version: 1.0.3`.
• If the user only provides the OpenKruise runtime version, first ask them to confirm the matching KubeSphere extension version.
• Never invent a version. If the version is missing, first show how to list versions and ask the user to confirm one.
• `InstallPlan.metadata.name` MUST equal `InstallPlan.spec.extension.name`.
• `InstallPlan` is cluster-scoped in KubeSphere. Do not add a namespace to `kubectl get|describe|delete installplan`.
• Use `upgradeStrategy: Manual` unless the user explicitly asks for something else.
• Omit optional fields instead of guessing values.
• Before generating `SidecarSet` or `CloneSet`, prefer checking the installed API versions:

kubectl api-resources --api-group apps.kruise.io

• If the cluster version is unknown and the user only wants an example, prefer:
• `SidecarSet`: `apps.kruise.io/v1alpha1`
• `CloneSet`: `apps.kruise.io/v1alpha1`
• For uninstall requests, warn that deleting CRDs or CR instances can remove application configuration. Do not suggest deleting CRDs unless the user explicitly asks for full cleanup.

Version Mapping Discovery

Treat the `1.0.3 -> 1.4.0` mapping as environment evidence, not a universal rule. When the user asks for precision, prove it first:

# Discover KubeSphere extension version
kubectl get extensionversions.kubesphere.io -l kubesphere.io/extension-ref=openkruise
kubectl get extensionversion openkruise-1.0.3 -o yaml

# Discover deployed runtime image or controller version
kubectl get pods -n kruise-system -o wide
kubectl get deploy -n kruise-system kruise-manager -o jsonpath='{.spec.template.spec.containers[*].image}'
kubectl describe pod -n kruise-system <kruise-manager-pod>

If these commands disagree with the assumed mapping, prefer cluster output over the baked-in default.

Discovery Commands

This section provides two approaches for querying OpenKruise status: 1. **KubeSphere API (curl)** - for extension management and multi-cluster queries 2. **kubectl** - for direct Kubernetes resource operations

Option 1: Using KubeSphere API (curl)

Use curl with environment variables for querying KubeSphere extension status and multi-cluster resources.

**Environment Variables:**

export KS_HOST="http://<kubesphere-host>"     # KubeSphere console URL (required)
export KS_USERNAME="admin"                     # Username (default: admin)
export KS_PASSWORD="<password>"                # Password (required)

**Helper Functions (add to ~/.bashrc or use directly):**

# Get OAuth token
ks_token() {
  curl -s -X POST "$KS_HOST/oauth/token" \
    -H "Content-Type: application/x-www-form-urlencoded" \
    -d "grant_type=password&username=${KS_USERNAME:-admin}&password=$KS_PASSWORD&client_id=kubesphere&client_secret=kubesphere" | jq -r '.access_token'
}

# Make API call: ks_api GET/POST/PUT/DELETE <path> [body]
ks_api() {
  local method=${1:-GET}
  local path=$2
  local body=$3
  local token=$(ks_token)
  
  curl -s -X "$method" \
    -H "Authorization: Bearer $token" \
    -H "Content-Type: application/json" \
    ${body:+-d "$body"} \
    "$KS_HOST$path"
}

**Query Commands:**

# List all clusters (host + member clusters)
ks_api GET /kapis/cluster.kubesphere.io/v1alpha1/clusters | jq -r '.items[].metadata.name'

# List installed extensions
ks_api GET /kapis/kubesphere.io/v1alpha1/extensions | jq -r '.items[].metadata.name' | grep -i kruise

# List available extension versions
ks_api GET /kapis/kubesphere.io/v1alpha1/extensionversions | jq -r '.items[].metadata.name' | grep -i kruise

# Get OpenKruise extension details
ks_api GET /kapis/kubesphere.io/v1alpha1/extensions/openkruise | jq

# Get cluster connection status (for member clusters)
ks_api GET /kapis/cluste