Pod的节点调度实现按Pod的编号取模滚动部署的效果

[LHB6540]

在滚服类游戏项目中，由于预注册、大量买量等原因导致，首次开服通常是流量高峰期。
对于未实现game服无状态+负载均衡架构的游戏项目，当前正在导量的game会负载较高。一般的做法是提前准备多台服务器节点，按照取模的方式滚动部署，度过流量高峰期。
举例：
1、准备3台机器：n1、n2、n3。
2、game的部署方式为：
n1：g1、g4、g7
n2：g2、g5、g8
n3：g3、g6、g9
同时随着游戏生命周期的演进，人数少的游戏服将被合服或者集中移动至特定的机器上，因此取模计算的时候，还需要考虑可供调度的节点及数量。

[sigboom]

对于长连接的传统部署游戏，通常都会有这种需求，不只是节点，其他数据库负载均衡等资源都有这种调度需求
一种更通用的描述是：实现一个自定义调度器，根据生成 pod 序号分散调度，能够定义连续的几个序号尽可能或强制不调度到相同节点

[chrisliu1995]

如果合理设置request / limit 是否能规避这种情况？

[LHB6540]

1、仅设置request/limit，默认的调度器应该无法保证初始逻辑服部署的时候，连续的序号不调度到同一个节点，调度器在调度的时候是否考虑规避序号的连续性待确认。
2、假如通过设置过高的request，使初始部署的时候使目标节点池中的每个节点上仅有一个pod。这会导致两个问题：1、资源利用率下降，需要准备更多的服务器以准备更多的逻辑服。2、即使不考虑成本，待开服流量高峰期过去后，如果想在现有节点上部署更多逻辑服，为了让pod能调度到节点成功的概率更大，需要降低原先部署集的request，这会导致pod的原地重启或者重建。

上述问题的一个可能的解决思路是：
对于每个部署集，在pod被创建时，被调度之前，通过admission webhook更新pod的属性。

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  name: toleration-webhook
webhooks:
- name: toleration-webhook.example.com
  rules:
  - operations: ["CREATE"]
    apiGroups: [""]
    apiVersions: ["v1"]
    resources: ["pods"]
  objectSelector:
    matchExpressions:
    - key: "app"
      operator: In
      values: ["my-app"]
  admissionReviewVersions: ["v1"]
  sideEffects: None
  clientConfig:
    url: http://toleration-webhook-service:8080/mutate

在被触发的webhook中：
1、假如部署集为pod template添加了额外的注解或label，用于标识目标节点的数量（因为此时还在pod的创建阶段，无法预知经过调度器过滤后有多少个可用节点），因此可以人为对环境进行一个预估，此数量同时作为模数。从另一个角度看，此数量也可以代表另一个含义，即获知节点数量并不是必须的，此数量代表希望的不连续的pod编号中间间隔多少个逻辑服。
2、为每个pod的编号进行取模运算，并作为标签。
3、利用取模运算的值，为pod添加pod亲和性，同模数的label的尽可能在同一个node上。

affinity = {
    "podAffinity": {
        "preferredDuringSchedulingIgnoredDuringExecution": [
            {
                "weight": 100,
                "podAffinityTerm": {
                    "labelSelector": {
                        "matchExpressions": [
                            {
                                "key": "node-index",
                                "operator": "In",
                                "values": [str(node_index)]
                            }
                        ]
                    },
                    "topologyKey": "kubernetes.io/hostname"
                }
            }
        ]
    },
    "podAntiAffinity": {
        "preferredDuringSchedulingIgnoredDuringExecution": [
            {
                "weight": 100,
                "podAffinityTerm": {
                    "labelSelector": {
                        "matchExpressions": [
                            {
                                "key": "node-index",
                                "operator": "NotIn",
                                "values": [str(node_index)]
                            }
                        ]
                    },
                    "topologyKey": "kubernetes.io/hostname"
                }
            }
        ]
    }
}

4、针对前面的节点数的指定，也可以尝试用注解添加一些节点简单过滤的属性，例如nodeselector等，避免人为设置。

在这种模式下，应该可以实现：
1、在准备开服时，预留的逻辑服按照gameServerSet的节点选择和副本数，均匀的不连续分布。
2、在开服一段时间负载平稳后，如果不新增机器，仅增加副本数，新的gameServer会被调度到合适的节点上。
3、在开服一段时间后，如果新增机器再开新服，可以新建gameServerSet，在新的节点上进行均匀部署。如果不新建gameServerSet，为了让节点均匀部署，可以考虑在停服时重建gameServerSet以均匀部署。

但是此方法是否可行还在测试中，目前经过webhook修改返回后pod的属性并没有变更，还在调试中。如果此思路有问题，或者如果有更好的实现思路，烦请指正下。