Agones 1.34.0 版本解析：Kubernetes 1.27 支持、Allocation 状态过滤稳定化与 GameServer 地址增强

• 游戏开发
• 云原生

Agones 1.34.0 是面向 Kubernetes 的多人在线游戏专用服务器托管与扩缩容项目的一次重要里程碑版本。本版本将 Kubernetes 兼容范围扩展至 1.25、1.26、1.27 三个版本，将StateAllocationFilter（分配状态过滤）与自定义 Fleet 自动扩缩容同步间隔（CustomFasSyncInterval）两大特性正式转正（Stable），并大幅增强了GameServer与GameServerAllocation的地址（Address）支持，为双栈 IPv4/IPv6 节点与带主机名的节点提供了完整可用的连接地址信息。阅读本文后，你将掌握 1.34.0 的核心变更细节、gameServerState过滤字段的配置方式与适用场景、自动扩缩容同步间隔的调优方法，以及新版本镜像与 Helm Chart 的获取途径。

版本概览：发布时间与核心变更

本版本发布于 2023 年 8 月 15 日（见 1.34.0 发布说明 的 front matter），围绕四个主线展开：

• Kubernetes 兼容性升级：扩展支持 Kubernetes 1.25、1.26、1.27，与当前主流 K8s 集群部署保持同步；
• Allocation State Filter 转正：分配状态过滤特性从测试阶段晋升为稳定特性；
• 自定义 Fleet 自动扩缩容同步间隔转正：FleetAutoscaler状态同步与底层 Fleet 更新的时间间隔配置正式稳定；
• GameServer 地址增强：GameServer与GameServerAllocation结果现在会返回其来源节点的完整 Address 记录集合，对双栈节点、带主机名节点等场景尤为有用。

此外，Agones 团队将基础容器镜像从 Alpine 迁移至 Distroless，便于统一管理基础镜像的持续更新。

Kubernetes 1.25 / 1.26 / 1.27 支持

本次发布将兼容矩阵扩展至 Kubernetes 1.25、1.26、1.27，这意味着你可以在上述版本的集群中部署并运行 Agones 控制器、分配器（allocator）、SDK Server 等全部组件。结合 K8s 的版本演进节奏，这保证了 Agones 用户能够在更新集群时获得对应的控制器版本匹配支持。

部署方式与以往版本一致，推荐通过官方 Helm 仓库安装：

helm repo add agones https://agones.dev/chart/stable helm install agones agones/agones --version 1.34.0

使用前请确保已经添加官方稳定版 Helm 仓库helm repo add agones https://agones.dev/chart/stable，并确认集群版本处于 1.25～1.27 的支持范围内。

Allocation State Filter（分配状态过滤）转正为 Stable

特性说明

分配状态过滤决定了在通过GameServerAllocation获取GameServer时应过滤的具体状态。该字段默认值为Ready，同时也可以设置为Allocated。当选择Allocated时，可以将其与标签（label）或玩家（player）选择器组合使用，以获取一个已经被分配过的GameServer——这对于玩家断线重连、会话迁移（session handover）等需要找回既有会话的场景非常关键。

源码级实现依据

该字段定义于 gameserverallocation.go 的GameServerSelector结构中：

// GameServerState specifies which State is the filter to be used when attempting to retrieve a GameServer // via Allocation. Defaults to "Ready". The only other option is "Allocated", which can be used in conjunction with // label/annotation/player selectors to retrieve an already Allocated GameServer. GameServerState *agonesv1.GameServerState `json:"gameServerState,omitempty"`

在默认值填充逻辑中，若GameServerState为 nil，则默认写入Ready状态（同文件第 210-212 行）；校验逻辑则强制要求该字段取值只能是Allocated或Ready两者之一（同文件第 371-372 行），避免非法状态值传入分配流程：

if s.GameServerState != nil && *s.GameServerState != agonesv1.GameServerStateAllocated && *s.GameServerState != agonesv1.GameServerStateReady { allErrs = append(allErrs, field.Invalid(fldPath.Child("gameServerState"), *s.GameServerState, "GameServerState must be either Allocated or Ready")) }

在分配执行层面，find.go 中的findGameServerForAllocation会依据Packed（顺序遍历）或Distributed（随机遍历）两种调度策略遍历候选GameServer列表，并通过 gameserverallocation.go 中的匹配逻辑（gs.Status.State != *s.GameServerState则跳过）完成状态过滤。相关测试用例可在 allocation_cache_test.go 与 find_test.go 中看到，例如 "allocated first (StateAllocationFilter)" 与 "one label with player state (StateAllocationFilter)"，分别验证了「优先返回已分配 GameServer」与「结合标签与玩家状态进行过滤」两种行为。

配置示例

以下是一个将状态过滤设置为Allocated、并叠加标签选择器来定位已分配 GameServer 的GameServerAllocation配置片段：

apiVersion: allocation.agones.dev/v1 kind: GameServerAllocation spec: scheduling: Packed selectors: - gameServerState: Allocated matchLabels: session-id: "abc-123"

在该配置下，分配器会在所有处于Allocated状态且带session-id=abc-123标签的GameServer中寻找目标，适用于按会话标识找回正在运行中的游戏实例。完整的示例文件可参考 examples/gameserverallocation.yaml。

自定义 Fleet 自动扩缩容同步间隔转正为 Stable

FleetAutoscaler需要以固定周期同步自身状态并更新其背后的 Fleet 副本数。此前该能力依赖特性门控（feature gate），在 1.34.0 中正式转正为稳定特性，用户可以在FleetAutoscaler的spec.sync.fixedInterval.seconds字段中自定义同步间隔。

底层实现位于 fleetautoscalers/controller.go：控制器按固定间隔创建定时器线程，并将fas.Spec.Sync.FixedInterval.Seconds转换为time.Duration后驱动扩缩容循环：

log.WithField("seconds", fas.Spec.Sync.FixedInterval.Seconds).Debug("Thread for Autoscaler created") duration := time.Duration(fas.Spec.Sync.FixedInterval.Seconds) * time.Second

对应的FleetAutoscaler配置示例如下（完整示例见 examples/fleetautoscaler.yaml）：

apiVersion: autoscaling.agones.dev/v1 kind: FleetAutoscaler metadata: name: simple-game-server-autoscaler spec: fleetName: simple-game-server sync: type: FixedInterval fixedInterval: seconds: 30 policy: type: Buffer buffer: bufferSize: 2 maxReplicas: 10

同步间隔越短，扩缩容响应越及时，但对 API Server 的请求压力也越大；间隔越长则越节省资源。建议根据业务峰值到达速度和集群规模权衡该值。

GameServer 地址增强：完整返回节点地址

特性说明

此前GameServer状态与GameServerAllocation结果仅暴露部分连接信息。1.34.0 起，GameServer与GameServerAllocation结果会返回其来源节点上挂载的全部 Address 记录（对应 Kubernetes Node 的Status.Addresses）。这对以下场景尤其有价值：

• 双栈 IPv4/IPv6 节点：节点同时拥有 IPv4 与 IPv6 地址，客户端可根据自身网络栈选择对应地址；
• 带主机名的节点：Hostname、InternalDNS、ExternalDNS等类型的地址可以一并返回，便于基于 DNS 的连接方式；
• 边缘场景下的多网卡节点，返回的地址集合可用于更精确的连接路由。

实现路径

实现上包含两个 PR 的联动：先在 GameServer 的 Status 中增加 Node 地址字段（PR #3299） 会将选中的GameServer的Status.Addresses直接追加到GameServerAllocation的状态字段中：

gsa.Status.Addresses = append(gsa.Status.Addresses, gs.Status.Addresses...)

这意味着分配请求的响应体（包括 gRPC 与 REST 两种通道）都会携带完整的地址列表，客户端无需二次查询GameServer即可获得可用的连接地址。

基础镜像迁移：Alpine 到 Distroless

本版本将 Agones 各组件（controller、allocator、ping、sdk-server 等）的基础镜像从 Alpine 迁移至 Distroless）。

Distroless 镜像只包含应用运行所需的依赖，不含 shell、包管理器等非必要组件，带来的收益包括：

• 更小的镜像体积与更小的攻击面；
• 更一致的基础镜像更新管理，Agones 团队可以更简单地统一维护各组件的基础镜像版本；
• 非 root 用户运行，进一步降低安全风险。

需要注意：Distroless 镜像不含 shell，若你依赖kubectl exec进入容器执行调试命令，请改用Dockerfile.debug等调试专用镜像（如 cmd/controller/Dockerfile.debug）。

其他值得关注的增强

除上述主线变更外，1.34.0 还包含多项增强（详见 CHANGELOG.md）：

• Counts and Lists 自动扩缩容策略（PR #3211）：为FleetAutoscaler增加基于 Counter/List 的扩缩容策略支持，扩展了容量计算的维度；
• 本地开发服务器支持增强（PR #3252）：进一步提升了本地开发服务器的能力，方便无集群环境下的 SDK 开发调试；
• GameServerAllocation 按已分配容量排序优先级（PR #3282）：结合Distributed调度策略（PR #3296），分配器可依据优先级对候选 GameServer 排序，优先选择已分配容量更充足的实例，相关实现可参考 gameserverallocation.go 中的Priorities字段；
• 一批示例项目的 Cloud Build 脚本补齐：为 supertuxkart、crd-client、rust-simple、autoscaler-webhook、allocation-endpoint、nodejs-simple、Xonotic、cpp-simple 等示例项目补充了 CI 构建脚本；
• Xonotic 示例升级至 0.8.6（PR #3273）。

其中CountsAndLists与分配优先级排序能力当前仍处于 Beta 阶段，由CountsAndLists特性门控控制，默认开启（见 pkg/util/runtime/features.go 与 defaultfeaturegates.yaml）。

版本产物一览

官方镜像

本版本发布的镜像均托管于us-docker.pkg.dev：

Helm Chart

Helm Chart 随本版本一并发布：

helm repo add agones https://agones.dev/chart/stable helm install agones agones/agones --version 1.34.0

升级与特性门控注意事项

1.34.0 中，StateAllocationFilter与CustomFasSyncInterval已从特性门控中移除并固化为默认行为。Agones 的稳定特性不允许被显式关闭，其在 features.go 的featureDefaults中保留true值的目的，是为了让从旧版本携带特性门控标志升级上来的用户不会因解析到未知标志而失败。如果你此前在部署参数中通过--feature-gates显式配置了这两个特性，升级后可以直接移除对应参数。

其余仍处于 Alpha/Beta 阶段的特性（如CountsAndLists、PlayerTracking、WasmAutoscaler、ScheduledAutoscaler等）继续由 defaultfeaturegates.yaml 控制，可通过 Helm values 中的agones.featureGates进行调整。

• 游戏开发
• 云原生