企业官网建设流程全解析

导读

本指南以 stable/minecraft Chart 为核心，完整讲解如何在 Kubernetes 集群中通过 Helm 一键部署 Minecraft 专用服务器：从 EULA 确认、参数配置到 RCON 远程管理、数据持久化与备份恢复的完整闭环。读完本文，你将掌握helm install部署、--set/values 文件两种配置方式、全部minecraftServer参数与底层环境变量的映射关系，以及基于kubectl cp与rcon-cli的存档备份实操方法。

注意：该 Chart 已标记为deprecated（已废弃），原仓库声明其已迁移至新的托管位置（itzg/minecraft-server-charts），当前仓库中的版本为1.2.5（appVersion1.14.4，见 Chart.yaml）。本文所有命令与配置均以当前仓库实际内容为准，适用于仍在使用本 Chart 的存量环境，也适合作为理解 itzg/minecraft-server 镜像与 Helm 结合方式的参考范本。

一、Chart 架构总览

该 Chart 的设计非常简洁：创建一个单一 Minecraft Pod，外加两个 Service（Minecraft 游戏端口与 RCON 管理端口）。从 templates 目录的源码结构可以确认其组件构成：

其中 Deployment 模板有一个关键的门控逻辑：只有当minecraftServer.eula不等于"FALSE"时，Deployment 才会被渲染（见 deployment.yaml）。这意味着未确认 EULA 就安装，Pod 根本不会创建——这是该 Chart 强制落实《Minecraft 最终用户许可协议》的机制。

命名方面，所有资源名由 _helpers.tpl 中的minecraft.fullname模板生成，格式为{{ releaseName }}-minecraft，并截断至 63 字符以符合 DNS 命名规范。

二、安装前置条件

按 README 的说明，部署前需确认：

• 至少 512 MB 内存（对应 values.yaml 中resources.requests.memory: 512Mi的默认值）；
• Kubernetes 1.4+，并启用 Beta API（当前模板已使用apps/v1的 Deployment 与标准 PVC 资源）；
• 底层基础设施支持 PV provisioner，用于数据持久化（若无法提供动态存储，可通过persistence.storageClass: "-"关闭动态供给，详见后文）。

三、安装 Chart 与 EULA 确认

Minecraft 服务器受 EULA 约束，安装前必须阅读并同意 EULA。确认后执行：

helm install --name my-release \ --set minecraftServer.eula=true stable/minecraft

该命令会以合理的默认值部署一个 Minecraft 专用服务器。--set minecraftServer.eula=true是安装的必要参数：Chart 默认值中eula: "FALSE"（见 values.yaml），若你不传此参数直接安装，会得到以下提示（来自 NOTES.txt）：

ERROR: You did not agree to the EULA in your 'helm install' call. This deployment will be incomplete until you read the Minecraft EULA ... helm upgrade my-release --set minecraftServer.eula=true stable/minecraft

也就是说，部署是不完整的——此时可以通过helm upgrade补上 EULA 参数后继续。CI 测试文件 test-values.yaml 中同样以minecraftServer.eula: "TRUE"作为必须覆盖的测试值，印证了这一行为。

安装完成后，可用helm list查看已部署的 release。

四、配置 Chart：两种方式与完整参数表

Chart 的配置全部集中在 values.yaml 中，分为 Kubernetes 层（镜像、资源、探针、安全上下文、调度、持久化）与 Minecraft 层（minecraftServer下的游戏参数，绝大多数映射为 itzg/minecraft-server 镜像的环境变量）。

4.1 方式一：命令行--set

helm install --name my-release \ --set minecraftServer.eula=true,minecraftServer.Difficulty=hard \ stable/minecraft

注意：参数名是大小写敏感的，minecraftServer.Difficulty=hard中的Difficulty需与 values.yaml 中difficulty键严格对应，实际部署时应写为minecraftServer.difficulty=hard（原文示例中的写法取自旧版本镜像的变量命名习惯，以当前 values.yaml 为准）。

4.2 方式二：YAML 值文件

helm install --name my-release -f values.yaml stable/minecraft

可以基于默认的 values.yaml 修改后传入，适合需要大量自定义的场景。

4.3 Kubernetes 层参数

探针配置在 deployment.yaml 中被展开为exec探针，容器内实际执行mc-monitor status localhost:25565来判定服务器是否存活/就绪。

4.4 Minecraft 层参数（minecraftServer）

下表完整覆盖 values.yaml 中的游戏配置项，并标注其映射到的容器环境变量（映射逻辑见 deployment.yaml）：

从模板源码可以看出，TYPE的选择会触发条件渲染：FORGE类型下二选一注入FORGE_INSTALLER_URL或FORGEVERSION；SPIGOT/BUKKIT/PAPER分别注入对应的下载 URL；FTB则注入FTB_SERVER_MOD与FTB_LEGACYJAVAFIXER（见 deployment.yaml）。

4.5 服务与 RCON / Query 参数

minecraftServer: serviceType: LoadBalancer # 游戏服务类型：LoadBalancer / ClusterIP / NodePort loadBalancerIP: # 指定 LB 的固定 IP # loadBalancerSourceRanges: [] # LB 来源 IP 白名单 # externalTrafficPolicy: Cluster # 可选 Cluster / Local rcon: enabled: false # 启用后务必修改 password port: 25575 password: "CHANGEME!" serviceType: LoadBalancer loadBalancerIP: query: enabled: false # 启用后服务器会被"发布"到 Gamespy port: 25565

RCON 的开关逻辑在模板中非常清晰：仅当rcon.enabled为真时，才会注入ENABLE_RCON=true与RCON_PASSWORD（密码从 Secret 中读取，见 deployment.yaml），并额外渲染 RCON Service 与 25575 端口（rcon-svc.yaml）。RCON 密码以base64编码存放在 Secret 中（secrets.yaml），默认密码"CHANGEME!"强烈建议修改。

Minecraft Service 模板（minecraft-svc.yaml）会依据serviceType渲染为 ClusterIP / LoadBalancer / NodePort 三种类型之一，并支持loadBalancerIP、loadBalancerSourceRanges与externalTrafficPolicy。

五、连接服务器：根据 Service 类型获取地址

安装完成后，NOTES.txt 会根据serviceType打印对应的连接指引：

• NodePort：通过kubectl查询 NodePort 与节点 IP，拼接为NODE_IP:NODE_PORT供客户端连接，并需在云平台安全组/防火墙放行该端口；
• LoadBalancer（默认）：等待EXTERNAL-IP填充，可用kubectl get svc -w <release>-minecraft观察，通常需要数分钟；
• ClusterIP：使用kubectl port-forward <pod> 25565:25565将本地端口转发到 Pod，客户端连接127.0.0.1:25565。

六、数据持久化

itzg/minecraft-server 镜像将存档与 mods 都存放在/data目录。Chart 默认行为：

• 为/data创建一个 PersistentVolumeClaim 并挂载（mountPath: /data，见 deployment.yaml），存档会持久化；
• mods 默认不单独持久化；
• 若想关闭持久化，将persistence.dataDir.enabled设为false——此时数据卷退化为emptyDir。

关于emptyDir，README 明确引用了 Kubernetes 官方定义：

"An emptyDir volume is first created when a Pod is assigned to a Node, and exists as long as that Pod is running on that node. When a Pod is removed from a node for any reason, the data in the emptyDir is deleted forever."

也就是说，关闭持久化后 Pod 一旦被删除或迁移，存档将永久丢失。因此除非是临时测试环境，否则强烈建议保持enabled: true。

PVC 模板（datadir-pvc.yaml）的关键细节：

• 仅当persistence.dataDir.enabled=true且未指定existingClaim时创建；
• 默认访问模式为ReadWriteOnce，容量由persistence.dataDir.Size控制（默认1Gi）；
• storageClass语义：未定义时使用默认 provisioner（AWS 上为gp2，GKE/AWS/OpenStack 上为standard）；设为"-"时storageClassName: ""，禁用动态供给（需自行准备 PV）；设为具体名称（如"standard"）时使用该 StorageClass；
• 若需要复用已有 PVC，可设置persistence.dataDir.existingClaim，此时模板将跳过 PVC 创建，直接引用既有声明。

七、存档备份：kubectl cp + rcon-cli

由于存档写入可能正在进行，备份前需先通过 RCON 让服务器"暂停写入"。README 给出的完整流程如下（需要先启用rcon.enabled）：

NAMESPACE=default POD_ID=lionhope-387ff8d-sdis9 kubectl exec --namespace ${NAMESPACE} ${POD_ID} rcon-cli save-off kubectl exec --namespace ${NAMESPACE} ${POD_ID} rcon-cli save-all kubectl cp ${NAMESPACE}/${POD_ID}:/data . kubectl exec --namespace ${NAMESPACE} ${POD_ID} rcon-cli save-on

步骤拆解：

1. rcon-cli save-off：关闭自动存档，确保后续操作期间世界文件不被改写；
2. rcon-cli save-all：强制落盘一次，保证内存中的世界状态写入/data；
3. kubectl cp：将 Pod 中/data目录（含存档、配置、mods 等）完整复制到本地；
4. rcon-cli save-on：恢复自动存档。

恢复时反向操作即可：将备份目录用kubectl cp传回 Pod 的/data，或挂载到新 PVC 后重新部署。

八、健康检查、安全上下文与调度

• 健康检查：liveness/readiness 探针均通过容器内mc-monitor检查localhost:25565，initialDelaySeconds: 30留出了 Minecraft 启动时间（世界加载通常较慢），failureThreshold: 10容忍短暂无响应；
• 安全上下文：默认runAsUser: 1000、fsGroup: 2000，确保容器以非 root 身份运行且对挂载卷有组写权限（deployment.yaml）；
• 调度：支持nodeSelector、tolerations、affinity将服务器固定到特定节点或节点池——对需要稳定 IP 或大内存节点的生产环境尤为实用。

九、卸载 Chart

helm delete my-release

该命令会删除 Chart 关联的所有 Kubernetes 组件并删除该 release。注意：默认情况下helm delete不会删除 PVC，因此游戏存档会保留——这既是"误删可恢复"的保障，也意味着如需彻底清理需手动删除对应的PersistentVolumeClaim。

十、从源码看 Chart 的设计要点

• EULA 强门控：Deployment 模板首行即判断eula != "FALSE"，NOTES.txt 也做了对称的提示，二者共同构成"不同意 EULA 就不部署"的完整闭环；
• 配置即环境变量：Chart 的minecraftServer全部参数在 deployment.yaml 中被逐一映射为EULA、TYPE、VERSION、DIFFICULTY、MODE、SEED、WORLD、MODPACK等镜像约定变量，理解这一点后，即使文档未列出的镜像新变量也可通过extraEnv直接注入；
• 按需渲染的附属资源：RCON Service、RCON 端口、Query 配置均以enabled开关控制是否渲染，避免不必要的暴露面；
• CI 验证：test-values.yaml 表明该 Chart 的 CI 会以eula=TRUE覆盖默认值进行模板渲染测试，这也是所有 Helm Chart 的通用验证方式。

结语

stable/minecraft 用最精简的资源编排（1 Deployment + 1~2 Service + 1 Secret + 1 PVC）把 Minecraft 专用服务器搬上了 Kubernetes，其"EULA 门控 + 参数即环境变量 + 按需渲染"的设计模式至今仍是 Helm 实战中的典型范例。虽然该 Chart 已废弃迁移，但本文中的部署、配置、持久化与备份方法论，可直接迁移到其继任者或其他基于 itzg/minecraft-server 镜像的自建 Chart 中。