Nakama × Kubernetes构建高可用游戏服务器集群的完整实战【免费下载链接】nakamaScalable open-source game backend server: multiplayer, matchmaking, leaderboards, chat, and social features for games.项目地址: https://gitcode.com/GitHub_Trending/na/nakama开服当天连接池先炸了新游戏 10 点开服第一小时在线数翻了前三倍。VM 上那个单进程 Nakama 开始陆续拒绝 WebSocket 连接数据库连接池告警刷屏扩容还得手动把二进制拷到另一台机器再调流量。Nakama 是开源游戏服务器后端如果你希望它随流量弹性伸缩就得在 Kubernetes 上以集群方式跑起来。这场线上事故的解法就是本文要展开的全部内容把扩容、自愈、观测交给平台开服不再靠人肉。单机形态为什么撑不住三个瓶颈对比瓶颈可以归纳成三条。横向扩容难。Nakama 的计算部分本身是无状态的——玩家状态都落在数据库里——但单机部署意味着进程 CPU/内存就是容量上限加机器重新部署。数据库与应用强耦合。按 docker-compose.yml 那种单机编排思路数据库和应用同机起停数据库抖一下全链路跟着抖也无法独立升级。没有自愈机制。进程 OOM 或 panic 后没人拉起只能等 oncall 发现。 两种形态放在一起看差异更清楚维度单机进程K8s 集群横向扩容手工迁移、改配置Deployment 副本数 HPA 自动数据库与同机应用绑定独立 CockroachDB 三副本解耦部署故障恢复人工重启探针判定 自动重建 Pod发布需要停服窗口滚动更新流量不中断流量入口单 IP 手工反代Service Ingress 声明式可观测性看日志文件9100 端口暴露 Prometheus 指标集群拓扑数据面与观测面两个平面把整个部署切成两个平面来理解数据面负责玩家流量从入口到 Nakama 副本池再到数据库观测面不承载业务只负责从每个副本的 9100 端口拉指标。数据面的关键是副本池里的每个 Pod 都可以随时被替换因为会话 token、存储对象这些状态全部落在 CockroachDB 里观测面独立部署Nakama 挂了也能看到它是怎么挂的。分层落地从存储到观测存储层用 Helm 拉起三副本 CockroachDB 集群CockroachDB 兼容 PostgreSQL 协议官方 chart 已经处理好 StatefulSet、持久化和副本同步我们只负责选参数。下面这条命令部署三副本集群参数含义如下--set statefulset.replicas3保证数据库自身多副本、无单点--set storage.persistentVolume.size100Gi为每副本预留数据卷空间--namespace nakama-system让数据库与应用共用命名空间简化网络策略。helm repo add cockroachdb https://charts.cockroachdb.com/ helm install cockroachdb cockroachdb/cockroachdb \ --set statefulset.replicas3 \ --set storage.persistentVolume.size100Gi \ --namespace nakama-system计算层把 Nakama Pod 做成标准件配置先外置成 ConfigMap副本里只保留四个关键项——数据库地址、会话 token 有效期、指标端口、日志级别。这份 docker-compose.yml 里以命令行参数下发的配置在这里全部挪进配置文件方便后续用 K8s 手段统一变更。apiVersion: v1 kind: ConfigMap metadata: name: nakama-config namespace: nakama-system data: nakama.yaml: | database: address: rootcockroachdb-public:26257 session: token_expiry_sec: 7200 metrics: prometheus_port: 9100 logger: level: DEBUG️ Deployment 部分体现标准件思路容器启动时先执行数据库迁移再拉起服务保证每个副本的 schema 版本一致liveness 探针负责死了就重启readiness 探针负责没准备好就不接流量两者配合实现自愈。apiVersion: apps/v1 kind: Deployment metadata: name: nakama namespace: nakama-system spec: replicas: 3 selector: matchLabels: app: nakama template: metadata: labels: app: nakama spec: containers: - name: nakama image: registry.heroiclabs.com/heroiclabs/nakama:3.30.0 command: [/bin/sh, -c] args: - | /nakama/nakama migrate up --database.address $(DB_ADDRESS) exec /nakama/nakama --config /config/nakama.yaml env: - name: DB_ADDRESS value: rootcockroachdb-public:26257 ports: - containerPort: 7350 # API - containerPort: 7351 # 控制台 - containerPort: 9100 # Prometheus 指标 volumeMounts: - name: config-volume mountPath: /config livenessProbe: exec: command: [/nakama/nakama, healthcheck] initialDelaySeconds: 30 periodSeconds: 10 readinessProbe: exec: command: [/nakama/nakama, healthcheck] initialDelaySeconds: 5 periodSeconds: 5 volumes: - name: config-volume configMap: name: nakama-config运行时模块目录如果需要持久化Lua 脚本、Go 模块等再挂一个 PVC 到/nakama/data/modules即可volumes: - name: modules persistentVolumeClaim: claimName: nakama-modules volumeMounts: - name: modules mountPath: /nakama/data/modules接入层API 与控制台为什么要拆两个域名7350 是玩家 API高并发、面向公网7351 是运维控制台低频但敏感账户管理、ACL、MFA。拆两个域名后控制台可以单独收紧访问来源、上更严格的限流和认证策略不会被玩家流量策略牵连。Service 只负责按标签转发Ingress 负责按域名分发。apiVersion: v1 kind: Service metadata: name: nakama namespace: nakama-system spec: selector: app: nakama ports: - port: 80 targetPort: 7350 name: api - port: 7351 targetPort: 7351 name: console --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: nakama namespace: nakama-system annotations: kubernetes.io/ingress.class: nginx spec: rules: - host: api.nakama.example.com http: paths: - path: / pathType: Prefix backend: service: name: nakama port: name: api - host: console.nakama.example.com http: paths: - path: / pathType: Prefix backend: service: name: nakama port: name: console弹性与观测层HPA 双指标 ServiceMonitor弹性HPAHorizontalPodAutoscaler即根据指标自动加减副本和观测放在同一层因为扩缩容的输入就是指标。HPA 这里配了双指标CPU 利用率 70% 是兜底防止会话少但计算重的场景扩不动nakama_active_sessions是业务指标每个 Pod 平均 1000 个会话就触发扩容直接对齐玩家规模。apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: nakama namespace: nakama-system spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: nakama minReplicas: 3 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 - type: Pods pods: metric: name: nakama_active_sessions target: type: AverageValue averageValue: 1000 ServiceMonitor 是 Prometheus Operator 的 CRD作用是声明去哪抓指标比手写 scrape 配置更贴合 K8s 标签体系。Nakama 的指标路径是/端点对应 9100 端口apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: nakama namespace: monitoring spec: selector: matchLabels: app: nakama endpoints: - port: metrics path: / interval: 15s指标落到 Prometheus 后接上 Grafana副本数、会话数、错误率就都有了面板集群的高可用不再停留在设计图上。验收健康检查 1000 并发压测部署完成后按顺序做两步验收。第一步在任意一个 Nakama Pod 里跑健康检查确认服务与数据库链路都通了kubectl exec -it nakama-pod-name -n nakama-system -- /nakama/nakama healthcheck预期输出OK: Nakama server is healthy第二步用官方压测工具对集群做 1000 并发验证go install github.com/heroiclabs/nakama-cli/v2latest nakama-cli loadtest --address api.nakama.example.com --concurrency 1000 --duration 5m 压测时重点盯nakama_active_sessions它必须随并发量爬升说明指标真实且在 HPA 的 averageValue1000 附近触达时副本数应当自动增长同时看 API 响应 P99 延迟是否保持在可接受区间。控制台侧也可以在 API 页面交叉核对调用统计。排障手册两个高频事故症状健康检查不过 → 动作先查数据库连通性healthcheck 失败绝大多数情况是到 CockroachDB 的链路问题网络策略、DNS、端口而不是 Nakama 本身。起一个临时 Pod 做连通性自查kubectl run test --imagepostgres:14 -it --rm -- psql -h cockroachdb-public.nakama-system -U root -p 26257连不上就先查 NetworkPolicy 和 Service DNS连得上再回头查 Nakama 日志。症状跨实例会话不一致 → 动作确认共享密钥已统一多实例部署下会话 token 的加解密密钥必须由所有副本共享否则 A 实例签发的 token 到 B 实例验不过。自查当前 ConfigMap 里的配置kubectl -n nakama-system get cm nakama-config -o yaml | grep encryption_key若缺失把session.encryption_key加进 ConfigMap所有副本使用同一个值再滚动重启 Deployment。演进路线集群跑起来之后的四件事蓝绿 / 金丝雀发布用两套副本集加流量切分把停服更新变成无感切换。数据库读写分离分析型查询排行榜聚合、审计走从库降低主库压力。服务网格如 Istio在 Pod 之间加细粒度流量控制、超时与重试。CI/CD 流水线镜像构建、migrate 灰度、滚动发布全部自动化。可以马上做的两件事把 HPA 的minReplicas按你的玩家基线调到 3 以上并kubectl apply为 9100 端口补一条告警规则指标 5 分钟无数据即触发观测面从此闭环。后续版本演进与破坏性变更以 CHANGELOG.md 为准升级前逐条过一遍。更多能力背景可回看 官方 README。【免费下载链接】nakamaScalable open-source game backend server: multiplayer, matchmaking, leaderboards, chat, and social features for games.项目地址: https://gitcode.com/GitHub_Trending/na/nakama创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Nakama × Kubernetes：构建高可用游戏服务器集群的完整实战
Nakama × Kubernetes构建高可用游戏服务器集群的完整实战【免费下载链接】nakamaScalable open-source game backend server: multiplayer, matchmaking, leaderboards, chat, and social features for games.项目地址: https://gitcode.com/GitHub_Trending/na/nakama开服当天连接池先炸了新游戏 10 点开服第一小时在线数翻了前三倍。VM 上那个单进程 Nakama 开始陆续拒绝 WebSocket 连接数据库连接池告警刷屏扩容还得手动把二进制拷到另一台机器再调流量。Nakama 是开源游戏服务器后端如果你希望它随流量弹性伸缩就得在 Kubernetes 上以集群方式跑起来。这场线上事故的解法就是本文要展开的全部内容把扩容、自愈、观测交给平台开服不再靠人肉。单机形态为什么撑不住三个瓶颈对比瓶颈可以归纳成三条。横向扩容难。Nakama 的计算部分本身是无状态的——玩家状态都落在数据库里——但单机部署意味着进程 CPU/内存就是容量上限加机器重新部署。数据库与应用强耦合。按 docker-compose.yml 那种单机编排思路数据库和应用同机起停数据库抖一下全链路跟着抖也无法独立升级。没有自愈机制。进程 OOM 或 panic 后没人拉起只能等 oncall 发现。 两种形态放在一起看差异更清楚维度单机进程K8s 集群横向扩容手工迁移、改配置Deployment 副本数 HPA 自动数据库与同机应用绑定独立 CockroachDB 三副本解耦部署故障恢复人工重启探针判定 自动重建 Pod发布需要停服窗口滚动更新流量不中断流量入口单 IP 手工反代Service Ingress 声明式可观测性看日志文件9100 端口暴露 Prometheus 指标集群拓扑数据面与观测面两个平面把整个部署切成两个平面来理解数据面负责玩家流量从入口到 Nakama 副本池再到数据库观测面不承载业务只负责从每个副本的 9100 端口拉指标。数据面的关键是副本池里的每个 Pod 都可以随时被替换因为会话 token、存储对象这些状态全部落在 CockroachDB 里观测面独立部署Nakama 挂了也能看到它是怎么挂的。分层落地从存储到观测存储层用 Helm 拉起三副本 CockroachDB 集群CockroachDB 兼容 PostgreSQL 协议官方 chart 已经处理好 StatefulSet、持久化和副本同步我们只负责选参数。下面这条命令部署三副本集群参数含义如下--set statefulset.replicas3保证数据库自身多副本、无单点--set storage.persistentVolume.size100Gi为每副本预留数据卷空间--namespace nakama-system让数据库与应用共用命名空间简化网络策略。helm repo add cockroachdb https://charts.cockroachdb.com/ helm install cockroachdb cockroachdb/cockroachdb \ --set statefulset.replicas3 \ --set storage.persistentVolume.size100Gi \ --namespace nakama-system计算层把 Nakama Pod 做成标准件配置先外置成 ConfigMap副本里只保留四个关键项——数据库地址、会话 token 有效期、指标端口、日志级别。这份 docker-compose.yml 里以命令行参数下发的配置在这里全部挪进配置文件方便后续用 K8s 手段统一变更。apiVersion: v1 kind: ConfigMap metadata: name: nakama-config namespace: nakama-system data: nakama.yaml: | database: address: rootcockroachdb-public:26257 session: token_expiry_sec: 7200 metrics: prometheus_port: 9100 logger: level: DEBUG️ Deployment 部分体现标准件思路容器启动时先执行数据库迁移再拉起服务保证每个副本的 schema 版本一致liveness 探针负责死了就重启readiness 探针负责没准备好就不接流量两者配合实现自愈。apiVersion: apps/v1 kind: Deployment metadata: name: nakama namespace: nakama-system spec: replicas: 3 selector: matchLabels: app: nakama template: metadata: labels: app: nakama spec: containers: - name: nakama image: registry.heroiclabs.com/heroiclabs/nakama:3.30.0 command: [/bin/sh, -c] args: - | /nakama/nakama migrate up --database.address $(DB_ADDRESS) exec /nakama/nakama --config /config/nakama.yaml env: - name: DB_ADDRESS value: rootcockroachdb-public:26257 ports: - containerPort: 7350 # API - containerPort: 7351 # 控制台 - containerPort: 9100 # Prometheus 指标 volumeMounts: - name: config-volume mountPath: /config livenessProbe: exec: command: [/nakama/nakama, healthcheck] initialDelaySeconds: 30 periodSeconds: 10 readinessProbe: exec: command: [/nakama/nakama, healthcheck] initialDelaySeconds: 5 periodSeconds: 5 volumes: - name: config-volume configMap: name: nakama-config运行时模块目录如果需要持久化Lua 脚本、Go 模块等再挂一个 PVC 到/nakama/data/modules即可volumes: - name: modules persistentVolumeClaim: claimName: nakama-modules volumeMounts: - name: modules mountPath: /nakama/data/modules接入层API 与控制台为什么要拆两个域名7350 是玩家 API高并发、面向公网7351 是运维控制台低频但敏感账户管理、ACL、MFA。拆两个域名后控制台可以单独收紧访问来源、上更严格的限流和认证策略不会被玩家流量策略牵连。Service 只负责按标签转发Ingress 负责按域名分发。apiVersion: v1 kind: Service metadata: name: nakama namespace: nakama-system spec: selector: app: nakama ports: - port: 80 targetPort: 7350 name: api - port: 7351 targetPort: 7351 name: console --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: nakama namespace: nakama-system annotations: kubernetes.io/ingress.class: nginx spec: rules: - host: api.nakama.example.com http: paths: - path: / pathType: Prefix backend: service: name: nakama port: name: api - host: console.nakama.example.com http: paths: - path: / pathType: Prefix backend: service: name: nakama port: name: console弹性与观测层HPA 双指标 ServiceMonitor弹性HPAHorizontalPodAutoscaler即根据指标自动加减副本和观测放在同一层因为扩缩容的输入就是指标。HPA 这里配了双指标CPU 利用率 70% 是兜底防止会话少但计算重的场景扩不动nakama_active_sessions是业务指标每个 Pod 平均 1000 个会话就触发扩容直接对齐玩家规模。apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: nakama namespace: nakama-system spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: nakama minReplicas: 3 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 - type: Pods pods: metric: name: nakama_active_sessions target: type: AverageValue averageValue: 1000 ServiceMonitor 是 Prometheus Operator 的 CRD作用是声明去哪抓指标比手写 scrape 配置更贴合 K8s 标签体系。Nakama 的指标路径是/端点对应 9100 端口apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: nakama namespace: monitoring spec: selector: matchLabels: app: nakama endpoints: - port: metrics path: / interval: 15s指标落到 Prometheus 后接上 Grafana副本数、会话数、错误率就都有了面板集群的高可用不再停留在设计图上。验收健康检查 1000 并发压测部署完成后按顺序做两步验收。第一步在任意一个 Nakama Pod 里跑健康检查确认服务与数据库链路都通了kubectl exec -it nakama-pod-name -n nakama-system -- /nakama/nakama healthcheck预期输出OK: Nakama server is healthy第二步用官方压测工具对集群做 1000 并发验证go install github.com/heroiclabs/nakama-cli/v2latest nakama-cli loadtest --address api.nakama.example.com --concurrency 1000 --duration 5m 压测时重点盯nakama_active_sessions它必须随并发量爬升说明指标真实且在 HPA 的 averageValue1000 附近触达时副本数应当自动增长同时看 API 响应 P99 延迟是否保持在可接受区间。控制台侧也可以在 API 页面交叉核对调用统计。排障手册两个高频事故症状健康检查不过 → 动作先查数据库连通性healthcheck 失败绝大多数情况是到 CockroachDB 的链路问题网络策略、DNS、端口而不是 Nakama 本身。起一个临时 Pod 做连通性自查kubectl run test --imagepostgres:14 -it --rm -- psql -h cockroachdb-public.nakama-system -U root -p 26257连不上就先查 NetworkPolicy 和 Service DNS连得上再回头查 Nakama 日志。症状跨实例会话不一致 → 动作确认共享密钥已统一多实例部署下会话 token 的加解密密钥必须由所有副本共享否则 A 实例签发的 token 到 B 实例验不过。自查当前 ConfigMap 里的配置kubectl -n nakama-system get cm nakama-config -o yaml | grep encryption_key若缺失把session.encryption_key加进 ConfigMap所有副本使用同一个值再滚动重启 Deployment。演进路线集群跑起来之后的四件事蓝绿 / 金丝雀发布用两套副本集加流量切分把停服更新变成无感切换。数据库读写分离分析型查询排行榜聚合、审计走从库降低主库压力。服务网格如 Istio在 Pod 之间加细粒度流量控制、超时与重试。CI/CD 流水线镜像构建、migrate 灰度、滚动发布全部自动化。可以马上做的两件事把 HPA 的minReplicas按你的玩家基线调到 3 以上并kubectl apply为 9100 端口补一条告警规则指标 5 分钟无数据即触发观测面从此闭环。后续版本演进与破坏性变更以 CHANGELOG.md 为准升级前逐条过一遍。更多能力背景可回看 官方 README。【免费下载链接】nakamaScalable open-source game backend server: multiplayer, matchmaking, leaderboards, chat, and social features for games.项目地址: https://gitcode.com/GitHub_Trending/na/nakama创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考