关于网关:Higress-×-OpenKruiseGame-游戏网关最佳实践

12次阅读

共计 3977 个字符,预计需要花费 10 分钟才能阅读完成。

OpenKruiseGame(下文简称:OKG)是一个面向多云的开源游戏服 Kubernetes 工作负载,是 CNCF 工作负载开源我的项目 OpenKruise 在游戏畛域的子项目,其提供了热更新、原地降级、定向治理等罕用的游戏服治理性能。而游戏作为典型的流量密集型场景,在吞吐量、提早性能、弹性与安全性等方面对入口网关提出了很高的要求。

Higress 是基于阿里外部两年多的 Envoy 网关实际积淀,以开源 Istio 与 Envoy 为外围构建的下一代云原生网关。Higress 实现了平安防护网关、流量网关、微服务网关三层网关合一,能够显著升高网关的部署和运维老本。Higress 能够作为 K8s 集群的 Ingress 入口网关,并且兼容了大量 K8s Nginx Ingress 的注解,能够从 K8s Nginx Ingress 疾速平滑迁徙到 Higress。同时也反对 K8s Gateway API 规范,反对用户从 Ingress API 平滑迁徙到 Gateway API。

本文将演示 Higress 如何无缝对接 OKG 游戏服,并为其带来的优良个性。

Higress 无缝接入 OKG

前置步骤:

  1. 装置 OpenKruiseGame[1]。
  2. 装置 Higress[2]。

OKG 提供诸多游戏服热更新和游戏服伸缩的优良个性,便于游戏运维人员治理游戏服的全生命周期。游戏不同于无状态类型的服务,玩家战斗的网络流量是不容许被负载平衡的,因而每一个游戏服须要独立的拜访地址。

应用原生工作负载(如 Deployment 或 StatefulSet)时,运维工程师须要为泛滥游戏服一一配置接入层网络,这无疑妨碍了开服效率,同时手动配置也无形中减少了故障的概率。OKG 提供的 GameServerSet 工作负载能够自动化地治理游戏服的接入网络,大幅度降低运维工程师的累赘。

对于 TCP/UDP 网络游戏,OKG 提供了诸如 HostPort、SLB、NATGW 等网络模型;而对于 H5/WebSocket 类型的网络游戏,OKG 也相应提供了 Ingress 网络模型,如 Higress、Nginx、ALB 等。

本文采纳了一款开源游戏 Posio 来构建 demo 游戏服。下述配置中,IngressClassName=”higress” 指定了 Higress 作为游戏服的网络层,Higress 通过上面配置能够无缝接入 Posio 游戏服,并且能够基于 Annotation 实现 Higress 定义的高阶流量治理等性能。示例 Yaml 如下所示,GameServerSet 生成的游戏服对应的拜访域名与游戏服 ID 相干。

在此例中,游戏服 0 的拜访域名为 http://game0.postio.example.com,游戏服 1 的拜访域名为 game1.postio.example.com. 客户端以此来拜访不同的游戏服。

piVersion: game.kruise.io/v1alpha1
kind: GameServerSet
metadata:
  name: postio
  namespace: default
spec:
  replicas: 1
  updateStrategy:
    rollingUpdate:
      podUpdatePolicy: InPlaceIfPossible
  network:
    networkType: Kubernetes-Ingress
    networkConf:
    - name: IngressClassName
      value: "higress"
    - name: Port
      value: "5000"
    - name: Path
      value: /
    - name: PathType
      value: Prefix
    - name: Host
      value: game<id>.postio.example.com
  gameServerTemplate:
    spec:
      containers:
        - image: registry.cn-beijing.aliyuncs.com/chrisliu95/posio:8-24
          name: postio

OKG 程度伸缩 [3] 提供主动扩容、依据游戏服的 OpsState 缩容、依据 DeletionPriority 缩容、依据游戏服序号缩容等性能来反对游戏运维的业务需要。程度伸缩的个性在给游戏开发者带来便当的同时,也对入口网关提出了更高的要求:入口网关必须具备配置热更新的能力,实现路由配置的平滑下发。

起因在于:在进行游戏服的扩容时,OKG 会同步创立 Ingress 等相干网络相干资源,以此来保障游戏服的主动上线。如果入口网关不具备配置热更新的能力,在扩容时就,线上玩家就会遇到连贯断开等问题,影响玩耍体验。

Nginx reload 无奈优雅热更新

在游戏服呈现扩容,或者定义的路由策略产生变更时,Nginx 的配置变更会触发 reload,导致上下游的连贯都断开并触发重连。

咱们以 Posio 游戏服为例,模仿 Nginx+OKG 在游戏服扩容时呈现的问题。Posio 服务端依赖于 Socket 连贯与客户端通信。游戏服扩容时,触发对应的 Ingress 资源创立,此时 Nginx-ingress-controller 监听到 Ingress 资源变更,触发本身 reload 机制,此时原来与游戏服建设的连贯(如本例中的 Socket 连贯会被断开)。在正在游戏的玩家侧的体感便是呈现了异样卡顿。

为了直观的展现 Nginx Ingress reload 带来的影响,咱们对 Nginx 默认配置参数进行一些更改:

kubectl edit configmap nginx-configuration -n kube-system
data:
  ...
  worker-shutdown-timeout: 30s # 一个很难做衡量的配置

Nginx 配置参数中 worker-shutdown-timeout 是 Nginx 的 worker 过程优雅下线的超时配置,worker 过程会先进行接管新的连贯,并期待老的连贯逐步敞开,达到超时工夫后,才会去强制敞开以后的所有连贯,实现过程退出。

此参数配置过小,会导致大量沉闷连贯霎时断开;而此参数配置过大时,又会导致 websocket 长连贯始终维持住 Nginx 过程,当产生频繁 reload 时会产生大量 shutting down 状态的 worker 过程,老 worker 占有的内存迟迟得不到开释,可能会导致 OOM 引发线上故障:

理论玩耍的测试过程如下:客户端拜访游戏服,进行失常玩耍。在此过程中通过 OKG 能力触发游戏服扩容,查看此时客户端的响应。通过网页开发者工具能够看到,呈现了两条 Socket 连贯,一条是原先浏览器拜访游戏服建设,另一条是因为 Nginx 断连后重连产生的 Socket 连贯。

原有连贯收到的最初一个包工夫戳是 15:10:26。

而新建连贯到获取第一个失常游戏包的工夫是 15:10:37,网页与游戏服的断连大略继续 5s 左右。

除了玩家的玩耍体验受影响,这个机制也会给业务整体稳定性埋雷。在高并发场景下,因为连贯瞬断,导致大批量客户端的并发重连,会导致 Nginx 的 CPU 霎时飙升;而后端游戏服务器须要解决更多业务逻辑,个别比网关的资源需要更高,因而 Nginx 透传过来的大量并发重连,也更容易打垮后端,造成业务雪崩。

Higress 如何实现优雅热更新

Higress 反对采纳 K8s Ingress 裸露游戏服内部 IP 端口,供玩家连贯拜访。当游戏服伸缩或者定义的路由配置发生变化时,Higress 反对路由配置的热更新,以此保障玩家连贯的稳定性。

Higress 基于 Envoy 的准确配置变更治理,做到了真正的配置动静热更新。在 Envoy 中 downstream 对应 listener 配置,交由 LDS 实现配置发现;upstream 对应 cluster 配置,交由 CDS 实现配置发现。listener 配置更新重建,只会导致 downstream 连贯断开,不会影响 upstream 的连贯;downstream 和 upstream 的配置能够独立变更,互不影响。再进一步,listener 下的证书 (cert),过滤器插件(filter),路由(router) 均能够实现配置独立变更,这样不论是证书 / 插件 / 路由配置变更都不再会引起 downstream 连贯断开

准确的配置变更机制,除了让 Envoy 能够实现真正的热更新,也让 Envoy 的架构变的更牢靠,Envoy 配置管理从设计之初就是为数据面 (DP) 和管制面 (CP) 拆散而设计的,因而应用 gRPC 实现近程配置动静拉取,并借助 proto 来标准配置字段,并放弃版本兼容。这个设计实现了数据面和管制面的平安域隔离,加强了架构的安全性。

应用 OKG 接入 Higress 后,上面仍然模仿客户端拜访游戏服,进行失常玩耍。在此过程中通过 OKG 能力触发游戏服扩容,查看此时客户端的响应。通过网页开发者工具能够看到,在此过程中客户端与游戏服建设的连贯稳固不受影响。

此外,在大规模游戏服场景下,每个游戏服对应一个独立的 Ingress,会产生大量的 Ingress 资源,咱们测试在达到 1k 级别规模时,Nginx Ingress 要新扩一个游戏服须要分钟级失效,而 Higress 能够在秒级失效。Nginx Ingress 的这一问题也被 Sealos 踩坑,并最终通过切换到 Higress 解决,有趣味能够浏览这篇文章理解:《云原生网关哪家强:Sealos 网关血泪史》

相干链接:

[1] OpenKruiseGame

https://openkruise.io/zh/kruisegame/installation/

[2] Higress

https://higress.io/zh-cn/docs/user/quickstart/

[3] OKG 程度伸缩

https://openkruise.io/zh/kruisegame/user-manuals/gameservers-…

作者:赵伟基、力铭、澄潭

原链接

本文为阿里云原创内容,未经容许不得转载。

正文完
 0