You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As is known to all, there are certain differences between each server in PvE games, and these differences become more apparent over time. This usually manifests in two scenarios:
The number of players typically fluctuates over time, so the resource allocation of game servers needs to be adjusted accordingly to adapt to these changes and avoid anomalies in service quality or wasted resources. In this case, it is likely that the resource allocation between servers will be different in an ideal situation.
Some games have the concept of gameplay modes, and these gameplay strategies often have variations. Additionally, there are concepts like test servers and experimental servers, where different versions of the same service may exist on different servers. In this case, the ideal situation would be that the Image versions between servers are likely to be different.
Proposal
Based on the above situations, I propose to enhance the targeted management capability of OKG to support different resource configurations and image versions for different GameServers under the same GameServerSet.
To achieve this, I suggest adding a new field called "Containers" to the GameServerSpec.
// GameServerSpec defines the desired state of GameServer
type GameServerSpec struct {
OpsState OpsState `json:"opsState,omitempty"`
UpdatePriority *intstr.IntOrString `json:"updatePriority,omitempty"`
DeletionPriority *intstr.IntOrString `json:"deletionPriority,omitempty"`
NetworkDisabled bool `json:"networkDisabled,omitempty"`
// Containers can be used to make the corresponding GameServer container fields
// different from the fields defined by GameServerTemplate in GameServerSetSpec.
Containers []GameServerContainer `json:"containers,omitempty"`
}
type GameServerContainer struct {
// Name indicates the name of the container to update.
Name string `json:"name"`
// Image indicates the image of the container to update.
Image string `json:"image,omitempty"`
// Resources indicates the resources of the container to update.
Resources corev1.ResourceRequirements `json:"resources,omitempty"`
}
When the image or resources configuration of a GameServer's containers is different from the pod spec, the corresponding fields of the pod will be updated. In case of conflicts, the content declared in the GameServer takes precedence.
Newly created GameServers will follow the default settings specified in the GameServerTemplate within the GameServerSet.
Please refer to the diagram below for an illustration of the proposed effects:
Resources update
As we all know, pod.containers[*].resources can't be updated by default.
However, Kubernetes 1.27 add a new feature-gate named InPlacePodVerticalScaling, which can help pod execute vertical scaling in-place(pod won not be recreated, containers could be restart or not), which means that GameServers could resize their resources, without affecting the players on those GameServers.
In order to avoid update failure, we should add a GameServer validating webhook, which only allow to update those containers with resizePolicy.
The text was updated successfully, but these errors were encountered:
Background
As is known to all, there are certain differences between each server in PvE games, and these differences become more apparent over time. This usually manifests in two scenarios:
The number of players typically fluctuates over time, so the resource allocation of game servers needs to be adjusted accordingly to adapt to these changes and avoid anomalies in service quality or wasted resources. In this case, it is likely that the resource allocation between servers will be different in an ideal situation.
Some games have the concept of gameplay modes, and these gameplay strategies often have variations. Additionally, there are concepts like test servers and experimental servers, where different versions of the same service may exist on different servers. In this case, the ideal situation would be that the Image versions between servers are likely to be different.
Proposal
Based on the above situations, I propose to enhance the targeted management capability of OKG to support different resource configurations and image versions for different GameServers under the same GameServerSet.
To achieve this, I suggest adding a new field called "Containers" to the GameServerSpec.
When the image or resources configuration of a GameServer's containers is different from the pod spec, the corresponding fields of the pod will be updated. In case of conflicts, the content declared in the GameServer takes precedence.
Newly created GameServers will follow the default settings specified in the GameServerTemplate within the GameServerSet.
Please refer to the diagram below for an illustration of the proposed effects:
Resources update
As we all know, pod.containers[*].resources can't be updated by default.
However, Kubernetes 1.27 add a new feature-gate named
InPlacePodVerticalScaling
, which can help pod execute vertical scaling in-place(pod won not be recreated, containers could be restart or not), which means that GameServers could resize their resources, without affecting the players on those GameServers.In order to avoid update failure, we should add a GameServer validating webhook, which only allow to update those containers with resizePolicy.
The text was updated successfully, but these errors were encountered: