Agent skill

Diagnosing Cockroachdb Helm Deployments

by cockroachdb in cockroachdb/helm-charts

Diagnoses failed or unhealthy CockroachDB Helm chart deployments by checking Helm release state, operator health, CrdbCluster and CrdbNode status, pod readiness, RBAC, webhooks, TLS, upgrades…

Apache-2.0Auto-check passedDevOps & Cloud

Install Diagnosing Cockroachdb Helm Deployments

skills CLI
$ npx skills add cockroachdb/helm-charts --skill diagnosing-cockroachdb-helm-deployments -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install cockroachdb/helm-charts diagnosing-cockroachdb-helm-deployments --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/cockroachdb/helm-charts.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/cockroachdb-observability-and-diagnostics/diagnosing-cockroachdb-helm-deployments .claude/skills/diagnosing-cockroachdb-helm-deployments && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
diagnosing-cockroachdb-helm-deployments
GitHub stars
105
Token cost
~6.8k tokens
SKILL.md length
1,621 words
Files
1
Skills in repo
6
Repo updated
First seen
Licence
Apache-2.0

At a glance

Diagnoses failed or unhealthy CockroachDB Helm chart deployments by checking Helm release state, operator health, CrdbCluster and CrdbNode status, pod readiness, RBAC, webhooks, TLS, upgrades…

  • Works in 2 steps: Collect Baseline State → Classify the Failure
  • Pods are not Ready
  • SKILL.md covers When to Use This Skill, Related Skills, Inputs and Safety Considerations, plus 17 more sections
  • Calls kubectl, helm and jq

What it does

Diagnosing Cockroachdb Helm Deployments is an agent skill from cockroachdb/helm-charts. Diagnoses failed or unhealthy CockroachDB Helm chart deployments by checking Helm release state, operator health, CrdbCluster and CrdbNode status, pod readiness, RBAC, webhooks, TLS, upgrades, scaling, PVCs, DNS, and multi-region assumptions. Use when Helm install or upgrade fails, pods are not Ready, or the operator is not reconciling.

Its SKILL.md is about 6.8k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts. Compatibility notes: CockroachDB Helm v2 charts and operator-managed crdb.cockroachlabs.com/v1beta1 resources. Requires Kubernetes read access to the operator namespace and…

It sits in DevOps & Cloud, covering Container orchestration and Deployment. It works with Helm. The repository describes itself as: Helm charts for cockroachdb. The licence is Apache-2.0.

When your agent uses it

  • Pods are not Ready
  • The operator is not reconciling

Example prompts

  • “Use the diagnosing-cockroachdb-helm-deployments skill to diagnose failed or unhealthy CockroachDB Helm chart deployments by checking Helm release…”
  • “/diagnosing-cockroachdb-helm-deployments”

Requirements

  • Compatibility (from SKILL.md): CockroachDB Helm v2 charts and operator-managed crdb.cockroachlabs.com/v1beta1 resources. Requires Kubernetes read access to the operator namespace and CockroachDB namespace; some remediation requires cluster-admin or platform-team action.

Workflow steps

2 steps, taken from the step headings in SKILL.md.

  1. Collect Baseline State
  2. Classify the Failure

What it can do on your machine

Read from SKILL.md and the folder at commit 26e44ff. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • kubectl
    • helm
    • jq
    • openssl

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Links to these hosts (documentation or services it may open):

    • cockroachlabs.com

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

  • Compatibility

    CockroachDB Helm v2 charts and operator-managed crdb.cockroachlabs.com/v1beta1 resources. Requires Kubernetes read access to the operator namespace and CockroachDB namespace; some remediation requires cluster-admin or platform-team action.

    From compatibility in the SKILL.md frontmatter.

Context cost

Diagnosing Cockroachdb Helm Deployments loads about 6.8k tokens when it runs. Until then it costs about 95 tokens; SKILL.md has 1,621 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~95
When it runs · the whole SKILL.md, loaded when a task matches
~6.8k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from cockroachdb/helm-charts at commit 26e44ff, republished under its Apache-2.0 licence (© cockroachdb). 1,621 words, ~6,774 tokens.

Download SKILL.mdSave it as .claude/skills/diagnosing-cockroachdb-helm-deployments/SKILL.md (or your agent's skills folder).
name
diagnosing-cockroachdb-helm-deployments
description
Diagnoses failed or unhealthy CockroachDB Helm chart deployments by checking Helm release state, operator health, CrdbCluster and CrdbNode status, pod readiness, RBAC, webhooks, TLS, upgrades, scaling, PVCs, DNS, and multi-region assumptions. Use when Helm install or upgrade fails, pods are not Ready, or the operator is not reconciling.
compatibility
CockroachDB Helm v2 charts and operator-managed crdb.cockroachlabs.com/v1beta1 resources. Requires Kubernetes read access to the operator namespace and CockroachDB namespace; some remediation requires cluster-admin or platform-team action.
metadata.author
cockroachdb
metadata.version
1.1

Diagnosing CockroachDB Helm Deployments

Diagnoses CockroachDB Helm install, upgrade, and readiness failures for operator-managed clusters. Keep the flow customer-facing: collect read-only evidence, classify the failure, and propose the smallest safe remediation. If the issue needs TSC escalation or deep operator forensics, use collecting-cockroachdb-operator-escalation-packet.

When to Use This Skill

  • helm install or helm upgrade fails
  • CrdbCluster.status.observedGeneration is behind metadata.generation
  • CrdbCluster.status.reconciled is false or missing
  • CockroachDB pods are Pending, Init, CrashLoopBackOff, Running but not Ready, or stuck on an old image
  • The operator Deployment is unavailable, silent, or not reconciling
  • Errors mention RBAC, CRDs, TLS, certificates, webhooks, node locality, PVCs, DNS, upgrades, scale operations, decommissioning, or multi-region networking

Inputs

  • Exact failed command and stderr
  • Operator namespace, operator Helm release name, and operator chart version
  • CockroachDB namespace, CockroachDB Helm release name, and CockroachDB chart version
  • Values file or --set values used
  • Kubernetes context and Kubernetes version
  • CockroachDB image/version and operator image/version
  • Whether this is install, upgrade, scale up/down, certificate rotation, migration, maintenance, or recovery
  • What the customer already tried, in order

Safety Considerations

  • Collect evidence before retrying. Repeated Helm or kubectl attempts can obscure the original failure.
  • Do not delete PVCs, Secrets, CrdbCluster, or CrdbNode resources unless the user explicitly asks for teardown and understands data impact.
  • Do not manually edit CrdbCluster.status; the operator owns status.
  • Do not run cockroach init on an existing cluster.
  • Do not change service settings such as publishNotReadyAddresses without operator-team guidance.
  • Do not delete version checker jobs or pods during an upgrade until their status and logs are collected.
  • Do not restart or scale down the operator during an active rollout, decommission, or migration unless basic evidence has already been collected.
  • Do not uninstall the operator before checking whether it manages other namespaces or clusters.

Execution Discipline

  • Execute one step at a time and inspect the output before moving on. Do not run whole sections, unrelated command groups, or later diagnostic branches in parallel; earlier output determines which later checks are relevant.
  • Run every step in the same shell session. The commands rely on OPERATOR_NAMESPACE, CRDB_NAMESPACE, CRDBCLUSTER, CRDB_DIAG_DIR, and the CRDB_*_PATH exports set in Step 1; opening a new shell drops those variables and later steps will hit unresolved names or read the wrong object.
  • Treat commands as templates. Substitute namespaces, release names, chart names, and pod names deliberately before running anything.
  • Never infer a CrdbCluster object name from a Helm release, service name, or CockroachDB image/version string. List CrdbCluster objects and use the exact metadata.name.
  • Before reading version-sensitive CrdbCluster fields, save the live CRD YAML and derive field paths from the served CRD schema for the object's apiVersion.
  • Do not run any mutating command unless the user explicitly approves it for the target cluster. This includes kubectl patch, kubectl annotate, kubectl delete, kubectl scale, kubectl rollout restart, helm upgrade, drain/decommission commands, and interactive kubectl exec or kubectl debug shells.
  • In production or whenever the impact is unclear, stop and escalate to TSE or the operator team before pprof/metrics collection, debug containers, timestamp-based rolling restarts, mode changes, operator restarts, scale changes, or decommission actions.

Step 1: Collect Baseline State

bash
export OPERATOR_NAMESPACE="<operator-namespace>"
export OPERATOR_RELEASE="<operator-release>"
export CRDB_NAMESPACE="<cockroachdb-namespace>"
export CRDB_HELM_RELEASE="<cockroachdb-release>"
export CRDB_DIAG_DIR="${CRDB_DIAG_DIR:-$(mktemp -d)}"

# Helm release state
helm -n "$OPERATOR_NAMESPACE" status "$OPERATOR_RELEASE" || true
helm -n "$CRDB_NAMESPACE" status "$CRDB_HELM_RELEASE" || true
helm -n "$OPERATOR_NAMESPACE" history "$OPERATOR_RELEASE" || true
helm -n "$CRDB_NAMESPACE" history "$CRDB_HELM_RELEASE" || true

# Operator state
kubectl -n "$OPERATOR_NAMESPACE" get deploy,pod,svc -o wide | grep -E 'cockroach-operator|NAME'
kubectl -n "$OPERATOR_NAMESPACE" logs -l app=cockroach-operator --tail=200 || true

# CRD and CockroachDB resources
kubectl get crd crdbclusters.crdb.cockroachlabs.com crdbnodes.crdb.cockroachlabs.com
kubectl get crd crdbclusters.crdb.cockroachlabs.com -o yaml > "$CRDB_DIAG_DIR/crdbclusters-crd.yaml"
kubectl get crd crdbclusters.crdb.cockroachlabs.com -o json > "$CRDB_DIAG_DIR/crdbclusters-crd.json"
kubectl -n "$CRDB_NAMESPACE" get crdbcluster,crdbnode,pod,svc,endpoints,pvc,pdb -o wide

kubectl -n "$CRDB_NAMESPACE" get crdbcluster -o json | jq -r '
  .items[]
  | [.metadata.name, .apiVersion, (.metadata.labels["app.kubernetes.io/instance"] // ""), (.metadata.generation | tostring)]
  | @tsv
'

If no CrdbCluster rows are returned, stop the object-specific diagnosis and report that no live CrdbCluster exists in the namespace. You may collect CrdbNode owner references and labels as teardown evidence, but do not treat those values as a replacement for a discovered CrdbCluster.

If multiple CrdbCluster rows are returned, choose the target by metadata.name. Do not use the Helm release or a CockroachDB version as a substitute.

bash
export CRDBCLUSTER="<metadata.name-from-crdbcluster-list>"
test -n "$CRDBCLUSTER"

kubectl -n "$CRDB_NAMESPACE" get crdbcluster "$CRDBCLUSTER" -o yaml > "$CRDB_DIAG_DIR/crdbcluster.yaml"
kubectl -n "$CRDB_NAMESPACE" get crdbcluster "$CRDBCLUSTER" -o json > "$CRDB_DIAG_DIR/crdbcluster.json"
kubectl -n "$CRDB_NAMESPACE" describe crdbcluster "$CRDBCLUSTER" || true
kubectl -n "$CRDB_NAMESPACE" get events --sort-by=.lastTimestamp | tail -50

export CRDBCLUSTER_API_VERSION="$(jq -r '.apiVersion | split("/")[-1]' "$CRDB_DIAG_DIR/crdbcluster.json")"
export CRDBCLUSTER_SCHEMA_JSON="$CRDB_DIAG_DIR/crdbcluster-schema.json"
jq -e --arg version "$CRDBCLUSTER_API_VERSION" '
  .spec.versions[] | select(.name == $version) | .schema.openAPIV3Schema
' "$CRDB_DIAG_DIR/crdbclusters-crd.json" > "$CRDBCLUSTER_SCHEMA_JSON"

crdb_schema_has() {
  jq -e --arg path "$1" '
    def has_schema_path($schema; $parts):
      if ($parts | length) == 0 then true
      elif (($schema.properties? // {}) | has($parts[0])) then
        has_schema_path($schema.properties[$parts[0]]; $parts[1:])
      else false
      end;
    has_schema_path(.; $path | split("."))
  ' "$CRDBCLUSTER_SCHEMA_JSON" >/dev/null
}

crdb_first_schema_path() {
  for schema_path in "$@"; do
    if crdb_schema_has "$schema_path"; then
      printf '%s\n' "$schema_path"
      return 0
    fi
  done
  printf '\n'
}

export CRDB_MODE_PATH="$(crdb_first_schema_path spec.mode)"
export CRDB_REGIONS_PATH="$(crdb_first_schema_path spec.regions)"
export CRDB_DESIRED_IMAGE_PATH="$(crdb_first_schema_path spec.template.spec.image spec.image.name spec.image)"
export CRDB_OBSERVED_GENERATION_PATH="$(crdb_first_schema_path status.observedGeneration)"
export CRDB_RECONCILED_PATH="$(crdb_first_schema_path status.reconciled)"
export CRDB_READY_NODES_PATH="$(crdb_first_schema_path status.readyNodes)"
export CRDB_STATUS_IMAGE_PATH="$(crdb_first_schema_path status.image status.crdbcontainerimage)"
export CRDB_STATUS_VERSION_PATH="$(crdb_first_schema_path status.version)"
export CRDB_ACTIONS_PATH="$(crdb_first_schema_path status.actions status.operatorActions)"
export CRDB_CONDITIONS_PATH="$(crdb_first_schema_path status.conditions)"
export CRDB_CERTIFICATES_PATH="$(crdb_first_schema_path spec.template.spec.certificates spec.certificates)"

printf '%s\n' \
  "apiVersion=$CRDBCLUSTER_API_VERSION" \
  "mode=$CRDB_MODE_PATH" \
  "regions=$CRDB_REGIONS_PATH" \
  "desiredImage=$CRDB_DESIRED_IMAGE_PATH" \
  "observedGeneration=$CRDB_OBSERVED_GENERATION_PATH" \
  "reconciled=$CRDB_RECONCILED_PATH" \
  "readyNodes=$CRDB_READY_NODES_PATH" \
  "statusImage=$CRDB_STATUS_IMAGE_PATH" \
  "statusVersion=$CRDB_STATUS_VERSION_PATH" \
  "actions=$CRDB_ACTIONS_PATH" \
  "conditions=$CRDB_CONDITIONS_PATH" \
  "certificates=$CRDB_CERTIFICATES_PATH"

For a stuck pod or node:

bash
kubectl -n "$CRDB_NAMESPACE" describe pod <crdb-pod>
kubectl -n "$CRDB_NAMESPACE" logs <crdb-pod> -c cockroachdb --tail=200
kubectl -n "$CRDB_NAMESPACE" logs <crdb-pod> -c cockroachdb --previous
kubectl -n "$CRDB_NAMESPACE" describe crdbnode <crdbnode-name>

Step 2: Classify the Failure

SymptomLikely ClassNext Check
no matches for kind "CrdbCluster"CRDs/operator not installed or not readyCRD and operator readiness
attempt to grant extra privilegesHelm RBAC restrictionRBAC and node-reader failures
TLS values validation errorTLS provider conflictTLS and certificate failures
Operator pod CrashLoopBackOff or OOMKilledOperator crash or resource limitOperator health
Operator running but no reconcile logsWatch namespace mismatch or blocked workerOperator health
observedGeneration behind generationReconcile is stuck or skippedReconciliation not progressing
Pods PendingScheduling, storage, topology, image pull, or node labelsPod scheduling and storage failures
Pods Running but not ReadyCRDB readiness, TLS, join, DNS, network, or recoveryPod readiness and CRDB issues
Upgrade stuck with mixed pod imagesVersion validation, rejected image, rollout dependency, schedulingUpgrade and version validation
Multi-region pods cannot joinDNS, network, region list, CA mismatchDNS, service, and network issues
Scale-down stuckDecommission/drain blocked or multiple nodes decommissioningScale down and decommission
Migration labels/status stuckMigration controller issuedebugging-cockroachdb-operator-migrations

CRD and Operator Readiness

bash
kubectl -n "$OPERATOR_NAMESPACE" rollout status deploy/cockroach-operator --timeout=5m
kubectl get crd crdbclusters.crdb.cockroachlabs.com -o jsonpath='{.spec.versions[*].name}{"\n"}'
kubectl get crd crdbnodes.crdb.cockroachlabs.com -o jsonpath='{.spec.versions[*].name}{"\n"}'
kubectl -n "$OPERATOR_NAMESPACE" get deploy cockroach-operator -o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'

Remediation:

  • Install or upgrade the operator chart first.
  • Wait for the operator Deployment before installing the CockroachDB chart.
  • For split charts, upgrade the operator chart before the CockroachDB chart.
  • Check the Helm chart changelog for version-specific operator fixes before deep debugging older releases.

Operator Health

bash
kubectl -n "$OPERATOR_NAMESPACE" get pods -l app=cockroach-operator -o wide
kubectl -n "$OPERATOR_NAMESPACE" describe pod <operator-pod>
kubectl -n "$OPERATOR_NAMESPACE" logs -l app=cockroach-operator --tail=100
kubectl -n "$OPERATOR_NAMESPACE" get deploy cockroach-operator -o jsonpath='{.spec.template.spec.containers[0].env}{"\n"}'

Interpretation:

  • CrashLoopBackOff: collect previous logs and check for panics.
  • OOMKilled: inspect limits and consider increasing operator memory.
  • Empty or unset WATCH_NAMESPACE: global mode.
  • Non-empty WATCH_NAMESPACE: the operator watches only listed namespaces.
  • If the CockroachDB namespace is not watched, deploy an operator for it or add it to the watch scope.

Check recent logs to see whether reconciliation is active:

bash
kubectl -n "$OPERATOR_NAMESPACE" logs -l app=cockroach-operator --tail=100 | grep -i reconcil || true

Do not add ad hoc annotations to trigger reconciliation. If a user-approved reconcile-triggering change is required, use the chart-supported timestamp path through helm upgrade --reuse-values; this updates helm.sh/restartedAt and may roll CockroachDB pods, so treat it as a mutating operation:

bash
helm -n "$CRDB_NAMESPACE" upgrade "$CRDB_HELM_RELEASE" <cockroachdb-chart> \
  --reuse-values \
  --set-string cockroachdb.crdbCluster.timestamp="$(date -u +%Y-%m-%dT%H:%M:%SZ)"

If the operator is healthy but silent and no user-approved mutation is appropriate, use collecting-cockroachdb-operator-escalation-packet to gather pprof and metrics before restarting it.

Show full SKILL.md (649 more words)Show less

RBAC and Node-Reader Failures

Common error:

text
attempt to grant extra privileges

Cause:

  • The installing principal cannot create cluster-scoped RBAC.
  • CockroachDB pods need node read access to derive locality.

Checks:

bash
kubectl auth can-i create clusterroles.rbac.authorization.k8s.io
kubectl auth can-i create clusterrolebindings.rbac.authorization.k8s.io
kubectl auth can-i get nodes

Remediation options:

  • Platform team installs the operator chart with nodeReader.enabled=true and subjects matching the CockroachDB ServiceAccount.
  • Tenant chart sets cockroachdb.crdbCluster.rbac.nodeReader.create=false only after the platform-owned binding exists.
  • If the customer accepts cluster-admin install privileges, rerun the Helm operation with an identity that can create the required ClusterRole and ClusterRoleBinding.

Do not set nodeReader.create=false before replacement RBAC exists.

Webhook Checks

bash
kubectl -n "$OPERATOR_NAMESPACE" get svc cockroach-webhook-service
kubectl -n "$OPERATOR_NAMESPACE" get endpoints cockroach-webhook-service
kubectl get validatingwebhookconfigurations | grep cockroach

If webhook validation fails, verify the CA bundle:

bash
kubectl get validatingwebhookconfiguration cockroach-webhook-config \
  -o jsonpath='{.webhooks[0].clientConfig.caBundle}' | base64 -d | openssl x509 -noout -dates -subject -issuer

For scoped operators, webhook configurations may be namespace-suffixed, such as cockroach-webhook-config-<namespace>.

Reconciliation Not Progressing

bash
jq \
  --arg modePath "$CRDB_MODE_PATH" \
  --arg desiredImagePath "$CRDB_DESIRED_IMAGE_PATH" \
  --arg observedGenerationPath "$CRDB_OBSERVED_GENERATION_PATH" \
  --arg reconciledPath "$CRDB_RECONCILED_PATH" \
  --arg readyNodesPath "$CRDB_READY_NODES_PATH" \
  --arg statusImagePath "$CRDB_STATUS_IMAGE_PATH" \
  --arg statusVersionPath "$CRDB_STATUS_VERSION_PATH" \
  --arg actionsPath "$CRDB_ACTIONS_PATH" \
  --arg conditionsPath "$CRDB_CONDITIONS_PATH" \
  '
  def value($path): if $path == "" then null else getpath($path | split(".")) end;
  {
  apiVersion,
  name: .metadata.name,
  schemaPaths: {
    mode: $modePath,
    desiredImage: $desiredImagePath,
    observedGeneration: $observedGenerationPath,
    reconciled: $reconciledPath,
    readyNodes: $readyNodesPath,
    statusImage: $statusImagePath,
    statusVersion: $statusVersionPath,
    actions: $actionsPath,
    conditions: $conditionsPath
  },
  mode: value($modePath),
  desiredImage: value($desiredImagePath),
  generation: .metadata.generation,
  observedGeneration: value($observedGenerationPath),
  reconciled: value($reconciledPath),
  readyNodes: value($readyNodesPath),
  statusImage: value($statusImagePath),
  statusVersion: value($statusVersionPath),
  actions: value($actionsPath),
  conditions: value($conditionsPath)
}' "$CRDB_DIAG_DIR/crdbcluster.json"

kubectl -n "$CRDB_NAMESPACE" get crdbnodes \
  -o 'custom-columns=NAME:.metadata.name,GENERATION:.metadata.generation,OBSERVED:.status.observedGeneration,DECOMMISSION:.status.decommission,REVISION:.metadata.annotations.crdb\.cockroachlabs\.com/clusterNodeRevision,NODE_ID:.status.nodeID'

CrdbNode status has no phase field. Use .status.decommission to see the current decommission state (empty for healthy nodes; draining, drained, transferringReplicas, zeroReplicas, or decommissioned otherwise) and the crdb.cockroachlabs.com/clusterNodeRevision annotation to compare the current revision against the operator's desired revision. Wrap the whole -o custom-columns=... value in single quotes so shells (especially zsh) do not glob the [] or consume the internal separators.

Checklist:

  1. Confirm the operator is running and watching the CockroachDB namespace.
  2. Confirm spec.mode is not Disabled.
  3. Check whether initialization conditions look correct for an existing cluster.
  4. Check operator logs for reconcile start/end pairs and errors.
  5. If no progress is visible, collect the escalation packet before restarting the operator.

Pod Readiness and CRDB Issues

bash
kubectl -n "$CRDB_NAMESPACE" get pods -l app.kubernetes.io/name=cockroachdb -o wide
kubectl -n "$CRDB_NAMESPACE" describe pod <crdb-pod>
kubectl -n "$CRDB_NAMESPACE" logs <crdb-pod> -c cockroachdb --tail=200
kubectl -n "$CRDB_NAMESPACE" logs <crdb-pod> -c cockroachdb --previous
kubectl -n "$CRDB_NAMESPACE" get pod <crdb-pod> -o jsonpath='{.spec.containers[0].readinessProbe}{"\n"}'
kubectl -n "$CRDB_NAMESPACE" get pods -l app.kubernetes.io/name=cockroachdb \
  -o 'custom-columns=NAME:.metadata.name,IMAGE:.spec.containers[0].image,PHASE:.status.phase,READY:.status.containerStatuses[0].ready,NODE:.spec.nodeName'

Common pod issues:

  • Pending during upgrade: old pods may still carry pre-upgrade scheduling or affinity constraints.
  • CrashLoopBackOff: inspect storage errors, TLS errors, join address failures, and previous logs.
  • Running but not Ready: check the readiness probe, CRDB health endpoint, certificate trust, join service, and whether the node is recovering.

Upgrade and Version Validation

bash
jq \
  --arg desiredImagePath "$CRDB_DESIRED_IMAGE_PATH" \
  --arg statusImagePath "$CRDB_STATUS_IMAGE_PATH" \
  --arg statusVersionPath "$CRDB_STATUS_VERSION_PATH" \
  --arg actionsPath "$CRDB_ACTIONS_PATH" \
  --arg conditionsPath "$CRDB_CONDITIONS_PATH" \
  '
  def value($path): if $path == "" then null else getpath($path | split(".")) end;
  {
  apiVersion,
  name: .metadata.name,
  desiredImagePath: $desiredImagePath,
  desiredImage: value($desiredImagePath),
  statusImagePath: $statusImagePath,
  statusImage: value($statusImagePath),
  statusVersionPath: $statusVersionPath,
  statusVersion: value($statusVersionPath),
  actionsPath: $actionsPath,
  actions: value($actionsPath),
  conditionsPath: $conditionsPath,
  conditions: value($conditionsPath),
  annotations: .metadata.annotations
}' "$CRDB_DIAG_DIR/crdbcluster.json"

jq '.metadata.annotations' "$CRDB_DIAG_DIR/crdbcluster.json"
kubectl -n "$CRDB_NAMESPACE" get jobs
kubectl -n "$CRDB_NAMESPACE" describe job <version-checker-job>
kubectl -n "$CRDB_NAMESPACE" logs -l job-name=<version-checker-job>
kubectl -n "$CRDB_NAMESPACE" get pods -l app.kubernetes.io/name=cockroachdb \
  -o 'custom-columns=NAME:.metadata.name,IMAGE:.spec.containers[0].image,REVISION:.metadata.annotations.crdb\.cockroachlabs\.com/nodeRevision,PHASE:.status.phase'

Interpretation:

  • If the schema-grounded desired image path differs from the schema-grounded status image path, an upgrade is in progress or stuck.
  • If a rejected-image annotation exists, inspect its value; the operator rejected the target version.
  • If the version checker job exists but the pod is gone, use job status and operator logs for validation messages.
  • Do not delete version checker jobs or pods until their status and logs are captured.

DNS, Service, and Network Issues

The operator creates separate service paths for pod DNS and join traffic. Do not change service settings without operator-team guidance.

bash
kubectl -n "$CRDB_NAMESPACE" get service,endpoints -o wide
export CRDB_SERVICE="<sql-or-public-service-name-from-output>"
export CRDB_JOIN_SERVICE="<join-service-name-from-output>"
test -n "$CRDB_SERVICE"
test -n "$CRDB_JOIN_SERVICE"

kubectl -n "$CRDB_NAMESPACE" get service "$CRDB_SERVICE" -o yaml
kubectl -n "$CRDB_NAMESPACE" get service "$CRDB_JOIN_SERVICE" -o yaml
kubectl -n "$CRDB_NAMESPACE" get endpoints "$CRDB_SERVICE"
kubectl -n "$CRDB_NAMESPACE" get endpoints "$CRDB_JOIN_SERVICE"

kubectl -n "$CRDB_NAMESPACE" exec <crdb-pod> -c cockroachdb -- \
  nslookup "$CRDB_SERVICE.$CRDB_NAMESPACE.svc.cluster.local" 2>&1 || true

kubectl -n "$CRDB_NAMESPACE" exec <crdb-pod> -c cockroachdb -- \
  nslookup "$CRDB_JOIN_SERVICE.$CRDB_NAMESPACE.svc.cluster.local" 2>&1 || true

For multi-region checks, use validating-cockroachdb-helm-multiregion.

TLS and Certificate Failures

Use configuring-cockroachdb-helm-tls for TLS mode selection and detailed certificate checks.

Quick checks:

bash
helm template <release> <chart> -n <namespace> -f values.yaml >/tmp/rendered.yaml
kubectl -n "$CRDB_NAMESPACE" get secret,configmap | grep -E 'cockroach|crdb|cert|ca|tls'
jq --arg certificatesPath "$CRDB_CERTIFICATES_PATH" '
  def value($path): if $path == "" then null else getpath($path | split(".")) end;
  {certificatesPath: $certificatesPath, certificates: value($certificatesPath)}
' "$CRDB_DIAG_DIR/crdbcluster.json"
kubectl -n "$CRDB_NAMESPACE" get pod <crdb-pod> -o jsonpath='{.spec.containers[*].name}{"\n"}'
kubectl -n "$CRDB_NAMESPACE" logs <crdb-pod> -c cert-reloader --tail=100

Remediation:

  • Ensure exactly one TLS provider is enabled.
  • Ensure self-signer caProvided=true has a valid caSecret.
  • Ensure cert-manager Issuer or ClusterIssuer exists and Certificate resources become Ready.
  • Ensure external certificate Secrets and CA ConfigMap have expected keys and share a trust root.
  • Collect expiry, subject, issuer, and SANs, but do not print private key contents.

Pod Scheduling and Storage Failures

bash
kubectl -n <namespace> describe pod <pod-name>
kubectl -n <namespace> get pvc -o wide
kubectl get storageclass
kubectl get nodes -L topology.kubernetes.io/region,topology.kubernetes.io/zone
kubectl -n <namespace> exec <crdb-pod> -c cockroachdb -- df -h /cockroach/cockroach-data

Common causes:

  • PVCs cannot bind because no default StorageClass exists or storageClassName is wrong.
  • Topology spread constraints cannot be satisfied because node zone labels are missing or insufficient.
  • Node resources are too small for requested CPU/memory.
  • Image pull failures from registry policy or air-gapped environments.
  • Migrated PVCs may be missing ownerReferences; use the migration debugging skill before deleting anything.

Scale Down and Decommission

bash
kubectl -n "$CRDB_NAMESPACE" exec <ready-crdb-pod> -c cockroachdb -- \
  /cockroach/cockroach node status --decommission

kubectl -n "$CRDB_NAMESPACE" get crdbnodes -o json | jq '[.items[] | select(.status.decommission != null and .status.decommission != "")] | {count: length, nodes: [.[] | {name: .metadata.name, decommission: .status.decommission}]}'

kubectl -n "$OPERATOR_NAMESPACE" logs -l app=cockroach-operator --tail=300 | grep -Ei 'decommission|drain|scale|blocking_ranges' || true

Questions to answer:

  • What was the original and target node count?
  • Were multiple nodes scaled down at the same time?
  • Were manual decommission or drain commands issued?
  • Did any pods or PVCs get deleted manually?

Temporary Mitigations

Only use these after collecting evidence and confirming the risk with the customer or operator team.

Disable reconciliation for one cluster:

bash
kubectl -n "$CRDB_NAMESPACE" patch crdbcluster "$CRDBCLUSTER" --type=merge -p '{"spec":{"mode":"Disabled"}}'

# Resume reconciliation:
kubectl -n "$CRDB_NAMESPACE" patch crdbcluster "$CRDBCLUSTER" --type=merge -p '{"spec":{"mode":"MutableOnly"}}'

Restart the operator after evidence is collected:

bash
kubectl -n "$OPERATOR_NAMESPACE" rollout restart deploy/cockroach-operator

User-approved timestamp rolling restart:

bash
helm -n "$CRDB_NAMESPACE" upgrade "$CRDB_HELM_RELEASE" <cockroachdb-chart> \
  --reuse-values \
  --set-string cockroachdb.crdbCluster.timestamp="$(date -u +%Y-%m-%dT%H:%M:%SZ)"

Output Format

Return findings in this order:

  1. Failure class
  2. Evidence: exact command output or Kubernetes status field
  3. Root cause or most likely cause
  4. Minimal remediation
  5. Verification command
  6. Data/availability risk, if any
  7. Whether escalation packet collection is needed

References

© cockroachdb, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/cockroachdb-observability-and-diagnostics/diagnosing-cockroachdb-helm-deployments of cockroachdb/helm-charts.

Open the folder on GitHubat commit 26e44ff

Compare with similar skills

Diagnosing Cockroachdb Helm Deployments next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Diagnosing Cockroachdb Helm Deployments compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Diagnosing Cockroachdb Helm Deployments this skillcockroachdb/helm-charts105—~6.8kAutomated safety check: PassApache-2.0
Kubeshark Installerkubeshark/kubeshark12k—~3.6kAutomated safety check: NotesApache-2.0
KubeShark for KubernetesLukasNiessen/kubernetes-skill444—~1.2kAutomated safety check: PassMIT
Release Chartzabbix-community/helm-zabbix132—~1.5kAutomated safety check: PassApache-2.0
Aks Deployment Skilltimothywarner/chatgptclass143—~916Automated safety check: PassCustom licence
KubeSphere Gateway Managementkubesphere/kubesphere17k—~2.9kAutomated safety check: PassCustom licence

Similar skills

  • Kubeshark Installer

    kubeshark/kubeshark

    Installs and configures Kubeshark on a Kubernetes cluster, choosing between the quick CLI path and a Helm install with custom values.

    12k GitHub stars~3.6k tokensUpdated yesterday
    DevOps & CloudAuto-check: notes
  • KubeShark for Kubernetes

    LukasNiessen/kubernetes-skill

    Keeps Kubernetes manifests, Helm charts and policies grounded by diagnosing six failure modes, such as insecure defaults and API drift, and loading only matching references.

    444 GitHub stars~1.2k tokensUpdated 25 days ago
    DevOps & CloudAuto-check passed
  • Release Chart

    zabbix-community/helm-zabbix

    Cut and publish a new release of the Zabbix Helm chart in this repository, following the versioning rules and maintainer release process documented in CONTRIBUTING.md and CLAUDE.md (bump…

    132 GitHub stars~1.5k tokensUpdated 3 mo ago
    DevOps & CloudAuto-check passed
  • Aks Deployment Skill

    timothywarner/chatgptclass

    Deploy and operate workloads on Azure Kubernetes Service (AKS) the safe way.

    143 GitHub stars~916 tokensUpdated 19 days ago
    DevOps & CloudAuto-check passed
  • KubeSphere Gateway Management

    kubesphere/kubesphere

    Installs, uninstalls, checks and troubleshoots the KubeSphere Gateway extension built on ingress-nginx, including gateways stuck in bad states and Helm or pod failures.

    17k GitHub stars~2.9k tokensUpdated 2 mo ago
    DevOps & CloudAuto-check passed
  • KubeSphere Extension Management

    kubesphere/kubesphere

    Installs, configures, upgrades and removes KubeSphere extensions through Extension, ExtensionVersion and InstallPlan resources, including dependencies and versions.

    17k GitHub stars~2.8k tokensUpdated 2 mo ago
    DevOps & CloudAuto-check passed

More from cockroachdb/helm-charts

  • Collects a complete CockroachDB Operator escalation packet for TSC/TSE or operator-team handoff, including Helm state, Kubernetes resources, logs, operation-specific evidence, pprof goroutine dumps…

    105 GitHub stars~5.1k tokensUpdated 7 days ago
    Auto-check passed
  • Configuring Cockroachdb Helm Tls

    cockroachdb/helm-charts

    Selects and validates TLS settings for CockroachDB Helm chart deployments, including self-signer, cert-manager, and external certificate modes.

    105 GitHub stars~3.8k tokensUpdated 7 days ago
    Auto-check passed
  • Debugs CockroachDB Operator migration scenarios, including Helm StatefulSet to v1beta1 CrdbNode migration and public operator v1alpha1 to v1beta1 migration.

    105 GitHub stars~3.6k tokensUpdated 7 days ago
    Auto-check passed
  • Installing Cockroachdb With Helm

    cockroachdb/helm-charts

    Guides customer-facing installation of CockroachDB on Kubernetes using the CockroachDB split Helm charts and operator-managed v1beta1 resources.

    105 GitHub stars~3.4k tokensUpdated 7 days ago
    Auto-check passed
  • Validates CockroachDB Helm chart values and Kubernetes prerequisites for operator-managed multi-region deployments.

    105 GitHub stars~2k tokensUpdated 7 days ago
    Auto-check passed

Works with

Categories

Questions about Diagnosing Cockroachdb Helm Deployments

What does Diagnosing Cockroachdb Helm Deployments do?

Diagnoses failed or unhealthy CockroachDB Helm chart deployments by checking Helm release state, operator health, CrdbCluster and CrdbNode status, pod readiness, RBAC, webhooks, TLS, upgrades…. Diagnosing Cockroachdb Helm Deployments is an agent skill from cockroachdb/helm-charts. Diagnoses failed or unhealthy CockroachDB Helm chart deployments by checking Helm release state, operator health, CrdbCluster and CrdbNode status, pod readiness, RBAC, webhooks, TLS, upgrades, scaling, PVCs, DNS, and multi-region assumptions.

When should I use Diagnosing Cockroachdb Helm Deployments?

Diagnosing Cockroachdb Helm Deployments fits situations like: pods are not Ready; the operator is not reconciling.

How do I install Diagnosing Cockroachdb Helm Deployments in Claude Code?

Run `npx skills add cockroachdb/helm-charts --skill diagnosing-cockroachdb-helm-deployments -a claude-code`. Or copy the skill folder (skills/cockroachdb-observability-and-diagnostics/diagnosing-cockroachdb-helm-deployments in cockroachdb/helm-charts) into .claude/skills/diagnosing-cockroachdb-helm-deployments in your project. Claude Code loads it when a task matches its description.

How do I install Diagnosing Cockroachdb Helm Deployments in Codex?

Run `npx skills add cockroachdb/helm-charts --skill diagnosing-cockroachdb-helm-deployments -a codex`. Or copy the skill folder (skills/cockroachdb-observability-and-diagnostics/diagnosing-cockroachdb-helm-deployments in cockroachdb/helm-charts) into .agents/skills/diagnosing-cockroachdb-helm-deployments in your project. Codex loads it when a task matches its description.

Can I use Diagnosing Cockroachdb Helm Deployments in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add cockroachdb/helm-charts --skill diagnosing-cockroachdb-helm-deployments -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/diagnosing-cockroachdb-helm-deployments, .gemini/skills/diagnosing-cockroachdb-helm-deployments, .github/skills/diagnosing-cockroachdb-helm-deployments and .opencode/skills/diagnosing-cockroachdb-helm-deployments in your project.

What does Diagnosing Cockroachdb Helm Deployments need to run?

Going by SKILL.md and its folder, Diagnosing Cockroachdb Helm Deployments needs the command-line tools its instructions call (kubectl, helm, jq and openssl). Compatibility (from SKILL.md): CockroachDB Helm v2 charts and operator-managed crdb.cockroachlabs.com/v1beta1 resources. Requires Kubernetes read access to the operator namespace and CockroachDB namespace; some remediation requires cluster-admin or platform-team action..

Does Diagnosing Cockroachdb Helm Deployments access the network?

SKILL.md names 1 domain. As links in the text: cockroachlabs.com. This is read from the text; nothing was executed.

Is Diagnosing Cockroachdb Helm Deployments safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Diagnosing Cockroachdb Helm Deployments use?

Diagnosing Cockroachdb Helm Deployments is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Diagnosing Cockroachdb Helm Deployments use?

About 6.8k tokens (SKILL.md is roughly 27k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Diagnosing Cockroachdb Helm Deployments?

Skills that share tags, products or a category with Diagnosing Cockroachdb Helm Deployments: Kubeshark Installer (kubeshark/kubeshark, 12k stars), KubeShark for Kubernetes (LukasNiessen/kubernetes-skill, 444 stars), Release Chart (zabbix-community/helm-zabbix, 132 stars) and Aks Deployment Skill (timothywarner/chatgptclass, 143 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Diagnosing Cockroachdb Helm Deployments?

cockroachdb (a GitHub organization) maintains it in cockroachdb/helm-charts, which has 105 GitHub stars. The repository holds 6 skills in this directory. The repository was last updated on October 1, 2026.

Source: cockroachdb/helm-charts on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.