kubeblocks-addon-mongodb

Provide a legacy MongoDB provisioning reference for migration to kubeblocks-engine-mongodb.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Legacy compatibility shim for MongoDB provisioning on KubeBlocks. The primary create-time entry is kubeblocks-engine-mongodb. Keep this skill callable for older references, but do not recommend it as the main path for cold-start agents.

Core Features & Use Cases

  • Backward-compatible reference for MongoDB addon provisioning to help teams migrate to the primary engine.
  • Documentation and workflow reference that points to the primary entry kubeblocks-engine-mongodb.
  • Use Case: When an existing deployment references kubeblocks-addon-mongodb, this skill provides a detailed reference path and migration guidance.

Quick Start

Explain the legacy MongoDB provisioning workflow and how to reference the primary entry kubeblocks-engine-mongodb.

Frequently Asked Questions about kubeblocks-addon-mongodb

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

FAQPage Schema
How do I migrate legacy MongoDB provisioning references on KubeBlocks to the primary engine?

Migrate legacy MongoDB provisioning references on KubeBlocks by pointing existing deployments to the primary entry kubeblocks-engine-mongodb. This skill provides a read-only reference path and detailed guidance to safely transition deprecated addon configurations to the primary engine.

What is the legacy MongoDB addon path used for in Kubernetes deployments?

The legacy MongoDB addon path serves as a backward-compatible reference for Kubernetes deployments that still rely on deprecated provisioning configurations. It enforces read-only workflows to prevent runtime confusion while guiding teams toward the primary kubeblocks-engine-mongodb entry point.

Can I still use kubeblocks-addon-mongodb for cold-start MongoDB provisioning?

You can keep kubeblocks-addon-mongodb callable for older references, but it is not recommended for cold-start provisioning. The primary create-time entry is kubeblocks-engine-mongodb, making this legacy path strictly a migration and compatibility shim.

Why does my KubeBlocks MongoDB deployment reference a deprecated addon?

Your KubeBlocks MongoDB deployment references a deprecated addon because existing configurations were created before the primary engine migration. This skill intercepts those legacy references, providing a safe, read-only workflow to prevent runtime errors and guide the transition.

What is the best way to handle deprecated MongoDB addon references in KubeBlocks?

The best way to handle deprecated MongoDB addon references in KubeBlocks is to use this compatibility shim as a temporary bridge. It provides documentation and a clear migration path to update your workflows to the primary kubeblocks-engine-mongodb engine.