共计 3296 个字符，预计需要花费 9 分钟才能阅读完成。
【本文内容基于 9 月份 Cloud Ace CTO 江文远分享的线上研讨会内容总结而成。】
摘要
Kubernetes，简称 K8s，是 Google 开发的，目前最为风行的容器编排和治理引擎，它反对自动化部署、大规模可伸缩、利用容器化治理。K8s 的个性使得它实用于架构简单且要求高的服务，也就是游戏架构的搭建。
因为 Cloud Ace 为谷歌云代理公司，所以咱们本次分享的实操是在谷歌开发的 Google Kubernetes Engines 上运行的，GKE 是谷歌基于 K8s 所开发的 Kubernetes 治理平台，次要在谷歌云平台上运行。
Kubernetes 与微服务架构
随着利用的倒退，程序变得越来越简单，传统一体化架构的服务会造成微小的不便，比如说：新增性能与测试放在一起，使得程序十分复杂；开发和利用新语言和新框架的效率低；安全性低，所有的模块构建在一个 process 里，一旦呈现 bug 可能牵一发而动全身。
而微服务 (microservices) 架构正好解决了这样的问题，将每一个具备商业逻辑的服务独立进去，例如不再将所有材料都写入同一个资料库，而是每个独自的服务都有一个最适宜本人自身构造的资料库。益处是让每个服务都能够用最适宜本人的语言、资料库来开发。在实操时，每一个商业性能 / 服务都可能是一台 VM 或者一个容器。
微服务架构的呈现给了游戏一个新的抉择，下图的两个架构就是游戏应用的架构，都是通过不同的功能模块来划分的，按功能模块划分不同的服务，前端通过 HAProxy 来代理用户申请，后端服务能够依据负载来实现扩缩容。在服务发现模块中，通过 registrator 来监督容器的启动和进行，依据容器裸露的端口和环境变量主动注册服务，后端存储应用了 consul，联合 consul-template 来发现服务的变动时，能够更新业务配置，并重载。
K8s 就是微服务架构
后面提到 K8s 适宜微服务架构，为什么呢？
因为 k8s 的架构与微服务十分相似，在某些性能上是统一的，第一就是 k8s 的 master 和 node，能够实现不同性能不同服务器之间的隔离；第二是 k8s 下面提供了 API server，基本上能够等同于网关；第三是 k8s 的服务编排性能好，能够实现弹性伸缩；第四点是 k8s 的 configmap 基本上能够作为配置核心；第五是 k8s 能够通过在 node 上部署 agent 来实现日志的收集和监控。
Kubernetes 将数个容器组合起来成一个服务 (Service，注：Service 是 K8S 的专有名词，上面会介绍)，Kubernetes 也提供了良好的服务发现(Service discovery) 机制，让每个服务彼此能够通信。最重要的是 K8S 弱小的编程能够主动扩大服务，甚至还能够对大规模的容器作滚动更新 (Rolling update) 以及回滚机制 (Rolling back/Undo)，更能够整合 CI/CD 等 DevOps 的工具。
K8s 在游戏架构搭建上的劣势
基于前两者，咱们总结进去 K8s 在游戏架构搭建上的劣势为：
- 定制的网络与调度计划，为游戏容器的运行提供根底环境；
- 域名服务与负载平衡，解决游戏高可用、弹性伸缩问题；
- 通过性能数据、日志的收集、统计分析，及时发现程序问题与性能瓶颈，保障游戏容器稳固、可持续性运行；
- 基于 image 的公布扩容，使得游戏部署流程更加标准化以及高效。
Google Kubernetes Engine(GKE）游戏架构搭建实操
咱们的实操参考的是谷歌的技术文档来搭建的。
游戏：Open Arena（雷神之锤）— 开源游戏
游戏架构如下图，明天咱们只讲对于 dedicated game server 这一部分。
游戏环境设定如下：
为什么这么设置呢？
第一是处于占用资源上思考，如果是地图比拟大的游戏，关上地图就会须要比拟长的工夫去载入，同样的，你工夫越长须要载入的材料越多，占用越多的资源，因而大部分游戏都会定义工夫限度，因为一旦有玩家在玩，主机就无奈敞开，造成大量的资源节约。
第二点是出于老本管制上设置的，因为线上游戏须要弹性，高峰期和非高峰期的人数差别较大，因而须要尽可能的 match 更多的玩家进来，把玩家集中在一个服务器上玩，这样对 vm 的需要会比拟少，有利于老本管制。
第三点是思考到游戏技术上的难度，如果说玩家呈现问题掉线了，那么就间接重开游戏，不要复原它的状态，因为复原状态对技术要求十分高。
GKE 搭建后盾示例如下：
首先咱们先从右上角开始，右上角就是一个根本的游戏的组成，DGS 也就是 delicate game server，它是一个 open source 的套件，能够在 GKE 上运行。
这里波及到两个 VM，第一个 VM 用来搭建 image，第二个 VM 用于加载数据 / 资料片，也就是 Asset Disk，咱们把 Asset Disk 挂起来后，VM2 咱们就间接删掉，VM2 是不会留下来的，咱们只有留下 Disk 就能够，之后一旦 GKE 的 class 开起来，也就是把 gke-dgs image 部署进去，部署进去之后，这边就他会去把资料片挂起来。
在 K8s 上的话，有个点须要留神，如果 pod 想用到 disk 外面的材料，那么 disk 须要做成 PV，也就是群集中的资源。PVC 是对这些资源的申请，只有用户申请后发送了 PVC 能力拜访存储的资料片。
一轮游戏一个回合，可能容许的玩家是有肯定限度的，如果说 node 上有两个 pod，两个 pod 可能容许 20 集体玩，那么当玩家数量超过了 20 集体的时候，就须要零碎及时监控到这个状况，开新的 pod，这里就波及到了 scaling manager。
Scaling manager 翻译过去叫缩放管理器，它其实就是一直的在监控整个 class 里的每一个 node 的状态。在 k8s 外面有个性能叫 HPA，Horizontal Pod Autoscaler，HPA 能够实现 Pod 主动弹性伸缩，HPA 是怎么实现主动弹性伸缩的呢？是通过对 Pod 中运行的容器各项指标（CPU 占用、内存占用、网络申请量）的检测，实现对 Pod 实例个数的动静新增和缩小。
然而这里会产生一个问题，比方一个游戏回合，因为会设定游戏工夫，因而可能玩家都退出了，然而游戏可能还在进行。HPA 这里检测到的仍然是游戏占用了很多资源，所以会认定 pod 不能关掉，然而玩家其实都退出了。这里波及到了一些底层的监控和运算公式在外面，绝对比较复杂。所以在理论的操作过程中，工程师须要去设置监控和弹性缩放的逻辑和算法。
游戏服务器常常会碰到的问题就是如何实现主动扩大和缩放，这里咱们总结了一下：
Cordon 指令是什么意思呢？就是说 pod 在缩放的时候，如果确定某个 node 的玩家都退出了，要把 node 撤掉的时候，要标记为不可调度。因为 GKE 的规定是，只有明天有玩家进来玩，scaling manager 就会主动调配 pod 给他。如果咱们想删减 node，可是 scaling manager 发现 node 的下面没有任何的 pod 在跑，它就会主动在这个咱们想删减的 node 下面开 pod 给玩家，就会发生冲突，因而如果咱们要删除 node，须要把它标记为不可调度。
当这两个程序如果之间没有做好沟通的话，一个在缩小 pod，一个在部署 pod，两个就会互相冲突，要想方法让另外一个程序晓得说这个 Pod 是不可调度的。
第一点就是 abandon instance，依照谷歌云的 instance group 原先的规定，设定了 node 是 20 个，那么当咱们缩减掉一个 node 的时候，instance group 为了确保 node 数量满足 20 个，会主动减少新的 node，这里也是抵触的，咱们缩减一个 node，它主动减少一个新的 node，因而咱们就须要通过 abandon instance 指令来缩减 node。abandon instance 命令上来之后，node 会间接变少，不会增长。
以上就是咱们本次分享的内容，这里附上 qwiklab 的链接，有须要的能够在 qwiklab 上进行游戏架构搭建的实操。
https://www.qwiklabs.com/focu…
11 月 4 日 Cloud Ace 工程师将分享对于谷歌推出的 Cloud Spanner——寰球散布且强一致性的企业级数据库服务，欢送各位报名加入。
