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

Feat | Differentiated updates to GameServers #112

Open
chrisliu1995 opened this issue Nov 28, 2023 · 0 comments
Open

Feat | Differentiated updates to GameServers #112

chrisliu1995 opened this issue Nov 28, 2023 · 0 comments

Comments

@chrisliu1995
Copy link
Member

chrisliu1995 commented Nov 28, 2023

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:

  1. 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.

  2. 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"`
}
  1. 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.

  2. 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:

image

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.

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

1 participant