kubeblocks-engine-minio

Provision MinIO clusters on KubeBlocks with topology, storage, and preflight validation.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

MinIO deployment on KubeBlocks often requires careful topology selection, version strategy, storage configuration, and preflight validation. This skill provides the primary create-time entry to standardize MinIO provisioning, reduce guesswork, and ensure a repeatable workflow.

Core Features & Use Cases

  • Topology and sizing guidance: default distributed topology with production recommendations and dev/test adjustments.
  • Version strategy and preflight: uses stable addon evidence and requires preflight when environment unknown.
  • Minimal create path and validation: ensures a single-component manifest with proper PVCs and placement constraints, plus validation steps before handoff.
  • Next hops and recovery: routes to lifecycle, observability, troubleshooting, and optional TLS/config adjustments.
  • Forbidden routes: prevents routing create through generic engines to maintain trust in the dedicated MinIO engine.
  • Evidence anchors: optional corroboration with addon evidence (examples/minio/cluster.yaml) for stronger runtime checks.

Quick Start

Draft the MinIO cluster manifest following the distributed topology default and apply it to your cluster.

Frequently Asked Questions about kubeblocks-engine-minio

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

FAQPage Schema
How do I provision a MinIO cluster on KubeBlocks with distributed topology?

Provisioning MinIO on KubeBlocks requires a single-component manifest with distributed topology defaults, proper PVCs, and placement constraints. Validate topology, storage class, and replica counts before applying the manifest to ensure environment readiness.

What is preflight validation for MinIO deployment and when do I need it?

Preflight validation for MinIO deployment checks environment readiness by verifying topology, storage class, and replica counts. It is required when the environment is unknown or needs validation, using stable addon evidence to ensure safe defaults.

Does KubeBlocks support production and dev/test sizing profiles for MinIO storage?

KubeBlocks supports MinIO sizing with a default distributed topology for production and dev/test adjustments. Sizing guidance covers replica counts and storage class configuration to match different deployment scales and environment requirements.

Can I use a generic KubeBlocks engine to create a MinIO cluster instead?

No, routing MinIO creation through generic KubeBlocks engines is a forbidden route. MinIO provisioning must use the dedicated MinIO engine to maintain trust in topology selection, version strategy, and storage configuration.

What should I do after successfully creating a MinIO cluster on KubeBlocks?

After MinIO cluster creation, next hops include routing to lifecycle management, observability, troubleshooting, and optional TLS or configuration adjustments to maintain and monitor the deployed MinIO instances.

Why does my MinIO deployment on KubeBlocks fail topology or storage validation?

MinIO deployment validation fails when topology, storage class, or replica counts do not meet distributed topology requirements. Running preflight checks and verifying against addon evidence like examples/minio/cluster.yaml helps identify and correct configuration mismatches.