Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] DeletionPriority-Topology-Rater #198

Open
chrisliu1995 opened this issue Feb 5, 2025 · 1 comment
Open

[Feature] DeletionPriority-Topology-Rater #198

chrisliu1995 opened this issue Feb 5, 2025 · 1 comment

Comments

@chrisliu1995
Copy link
Member

在有些场景下,决定删除哪个游戏服是由基础设施而非业务决定的。比如,不存在明显的对局概念游戏服,玩家可随时进入和退出游戏服务器。玩家数量可能会持续增多,游戏服务是否空闲没有确定的时间点。若当游戏服整体负载较低时,将触发HPA自动缩容,而具体要将哪些游戏服进行下线需要由基础设施决定。

通常情况下,考虑到节点应该尽可能空闲进而容易被缩容,这里应该有两个原则:

  • 节点上pod数量越少,越应该被删除,删除优先级越大
  • 节点上pod的owner数量越少,越应该被删除,删除优先级越大

因此,我们需要感知到节点的拓扑情况,也就是上述pod与节点的关系,并根据当前拓扑状态设置对应gameserver的删除优先级。

In some scenarios, the decision to delete which game server is determined by the infrastructure rather than the business logic. For example, in games where there is no clear concept of a match, and players can enter and exit game servers at any time, the number of players may continuously increase, and there is no definite point in time when the game service becomes idle. When the overall load on the game servers is low, it will trigger HPA (Horizontal Pod Autoscaler) to automatically scale down. The specific game servers to be taken offline need to be decided by the infrastructure.

Generally, considering that nodes should be as idle as possible to facilitate scaling down, there should be two principles:

  • The fewer the number of pods on a node, the higher the priority for deletion.
  • The fewer the number of pod owners on a node, the higher the priority for deletion.

Therefore, we need to be aware of the topology of the nodes, specifically the relationship between the pods and the nodes, and set the deletion priority of the corresponding game servers based on the current topological state.

@furykerry
Copy link
Member

furykerry commented Feb 5, 2025

@chrisliu1995 the issue seems very generic, maybe we can extend podprobemarker or add another marker (e.g. PodNodeMarker) CRD in the kruise repository

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants