kubeblocks-op-expose

Expose Day-2 service entries for existing KubeBlocks clusters.

3|Updated Mar 12, 2026
One-click install
npx skills add https://github.com/apecloud/kubeblocks-skills --skill kubeblocks-op-expose
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: kubeblocks-op-expose
Source: https://github.com/apecloud/kubeblocks-skills/tree/main/skills/kubeblocks-op-expose
Command: npx skills add https://github.com/apecloud/kubeblocks-skills --skill kubeblocks-op-expose

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Exposes Day-2 service entry for existing KubeBlocks clusters to enable external access and routing.

Core Features & Use Cases

  • Primary Day-2 exposure entry for existing clusters.
  • Verifies support in the ops capability matrix before acting.
  • Routes monitoring questions to kubeblocks-observability-router and broken-state diagnosis to kubeblocks-troubleshoot.

Quick Start

Identify the target cluster and engine, verify capability support in the ops matrix, and initiate the exposure workflow.

Frequently Asked Questions about kubeblocks-op-expose

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I expose a KubeBlocks cluster for external access?

To expose a KubeBlocks cluster for external access, initiate the Day-2 service exposure workflow after verifying engine-specific capabilities in the ops matrix.

What is the Day-2 ops feature for service exposure in KubeBlocks?

The Day-2 ops feature for service exposure provides a primary entry point to enable external access and routing for existing KubeBlocks clusters.

Does KubeBlocks check capability support before exposing a service?

Yes, KubeBlocks checks the ops-capability-matrix to enforce capability availability before acting, preserving engine-specific workflows and handling unsupported results with explicit guidance.

How do I troubleshoot a broken KubeBlocks cluster during service exposure?

To troubleshoot a broken KubeBlocks cluster during service exposure, the exposure workflow routes broken-state diagnosis directly to the dedicated troubleshoot path.

Can I route monitoring tasks when exposing KubeBlocks services?

Yes, you can route monitoring tasks during KubeBlocks service exposure, as the workflow directs monitoring questions to the observability path.

What should I do if my KubeBlocks engine does not support service exposure?

If your KubeBlocks engine does not support service exposure, the workflow handles unsupported results by providing explicit guidance on the limitation.