菜单
Use when an operator is running the Node.js v1 rmq-vertical-scaler and wants to move to the Go v2 — confirming the drop-in image-tag swap, env-var parity, and that scaling decisions and generated manifests stay identical.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when an operator wants to install or deploy the rmq-vertical-scaler into a Kubernetes cluster — generating manifests from a config, ensuring the RabbitMQ credentials secret exists, applying with kubectl, and verifying the rollout.
Use when an operator needs to create or revise an rmq-vertical-scaler config.json — when they describe their RabbitMQ workload (queue depths, message rates, burst patterns, node count) and want scaling profiles, thresholds, and debounce settings chosen for them.
Use when a deployed rmq-vertical-scaler isn't behaving — it's not scaling RabbitMQ up or down, the pod is crashing or CrashLooping, it can't reach the RabbitMQ management API, or it logs RBAC/permission/secret errors.
| name | rmq-upgrade-from-v1 |
| description | Use when an operator is running the Node.js v1 rmq-vertical-scaler and wants to move to the Go v2 — confirming the drop-in image-tag swap, env-var parity, and that scaling decisions and generated manifests stay identical. |
v2 is a behaviour-identical Go rewrite of the Node.js v1: same env-var contract, byte-identical scaling decisions, byte-for-byte compatible generated manifests. The upgrade is a drop-in image-tag swap — no config or manifest changes required.
ferterahadi/rmq-vertical-scaler:1.x.Just change the image tag:
kubectl set image deployment/rmq-vertical-scaler \
rmq-vertical-scaler=ferterahadi/rmq-vertical-scaler:2 -n <ns>
kubectl rollout status deployment/rmq-vertical-scaler -n <ns>
A Deployment generated by v1 drives v2 unchanged — the env-var contract is identical.
RMQ_*, PROFILE_*, QUEUE_THRESHOLD_*, RATE_THRESHOLD_*, DEBOUNCE_*, CHECK_INTERVAL_SECONDS, NAMESPACE, CONFIG_MAP_NAME.generate emits YAML byte-for-byte compatible with v1; existing examples/*.json configs work as-is.kubectl logs deployment/rmq-vertical-scaler -n <ns> --tail=50
Confirm it reports the same current profile it held on v1 — the state ConfigMap (rmq-vertical-scaler-config) carries over, so there should be no spurious scale event.
v1 stays published — revert the tag:
kubectl set image deployment/rmq-vertical-scaler \
rmq-vertical-scaler=ferterahadi/rmq-vertical-scaler:1 -n <ns>
v1.x images and v1.x git tags remain available.
:latest instead of :2 — pin a major to avoid surprise jumps.