Add Cloud Best Practices guide, add guide on Release Channels #3152
Conversation
|
Build Failed 😱 Build Id: 0e3e22c6-df4e-4a8f-92ab-3f39e73caf8b To get permission to view the Cloud Build view, join the agones-discuss Google Group. |
zmerlynn
force-pushed
the
release-channels-docs
branch
from
9878c34
to
1dd9b7e
Compare
|
Build Failed 😱 Build Id: 0e8d0960-ec5d-47a7-83c4-97aeb6bda649 To get permission to view the Cloud Build view, join the agones-discuss Google Group. |
|
Build Failed 😱 Build Id: 00407e1a-1ec0-478e-b2d4-8e0654b56007 To get permission to view the Cloud Build view, join the agones-discuss Google Group. |
zmerlynn
force-pushed
the
release-channels-docs
branch
from
5cc306b
to
d22fd3f
Compare
|
Build Failed 😱 Build Id: a5f9e82a-8182-4a0e-a19f-8227df889efb To get permission to view the Cloud Build view, join the agones-discuss Google Group. |
zmerlynn
force-pushed
the
release-channels-docs
branch
from
d22fd3f
to
6a45ada
Compare
|
Build Succeeded 👏 Build Id: 000bc174-61d9-4dfe-88f8-3dcda1bf505c The following development artifacts have been built, and will exist for the next 30 days:
A preview of the website (the last 30 builds are retained): To install this version:
|
zmerlynn
force-pushed
the
release-channels-docs
branch
from
6a45ada
to
a2641a2
Compare
|
(no new changes to review, merely forcing an e2e build) |
|
Build Failed 😱 Build Id: 1b61488c-db0b-4ce6-b528-48e129609b85 To get permission to view the Cloud Build view, join the agones-discuss Google Group. |
|
Build Succeeded 👏 Build Id: 416e5f49-539a-4ede-bc49-b857b655d4d1 The following development artifacts have been built, and will exist for the next 30 days:
A preview of the website (the last 30 builds are retained): To install this version:
|
zmerlynn
force-pushed
the
release-channels-docs
branch
3 times, most recently
from
a69e226
to
ae79bca
Compare
|
Build Succeeded 👏 Build Id: d15e765d-d02c-4e1d-9b7f-1d51450f60c2 The following development artifacts have been built, and will exist for the next 30 days:
A preview of the website (the last 30 builds are retained): To install this version:
|
|
Build Failed 😱 Build Id: 616c436d-d86a-458a-a33a-b8c7131a6d88 To get permission to view the Cloud Build view, join the agones-discuss Google Group. |
|
Build Failed 😱 Build Id: bd4c86c2-0fa9-43ab-a688-3b797f34fa8a To get permission to view the Cloud Build view, join the agones-discuss Google Group. |
|
Build Failed 😱 Build Id: 7ad6b5ee-4ec3-4daa-8433-0e5f7d0b4798 To get permission to view the Cloud Build view, join the agones-discuss Google Group. |
|
|
||
| ## Separate game servers from other workloads | ||
|
|
||
| We recommend using [taints and tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) to ensure that your game servers are running separate from Agones controllers. There are many ways to accomplish this, here we discuss one: |
There was a problem hiding this comment.
This section loses the information from the prior best practice that agones by default is configured to put the system components on these nodes. Also with @gongmax's PR, we could actually suggest setting the helm property to force the system components onto these nodes.
There was a problem hiding this comment.
Let's make that change when #3161 goes in?
I addressed the rest by just reverting to the old verbiage.
|
|
||
| If you are interested in submitting best practices for your cloud prodiver / on-prem, [please contribute!]({{< relref "/Contribute" >}}) | ||
|
|
||
| ## Separate game servers from other workloads |
There was a problem hiding this comment.
The title is backwards from what we had before. What we are saying is to move the agones components away from game servers.
You could also move the game servers away by using taints and tolerations for them, but the suggestion here is showing how to move the agones components so that the game servers don't need taints and tolerations.
Consider flipping the title to be more like what we had on the other page ("Separation of Agones from GameServer nodes").
There was a problem hiding this comment.
FWIW I actually disagree with the direction we have it. I actually had read this recommendation several times due to @gongmax's work but I never actually parsed it fully. When I did, I was surprised which way we were recommending. Why are we separating controllers from the default pool? Why are we not separating game servers and keeping the control plane, kube-system, etc, in the default pool? This sounds backwards.
I didn't intend to flip the recommendation, but the title is a reflection of the direction I think it should be. Freudian slip. :)
* Adds a "Best Practices" section to the sidebar
* Adds some generic Best Practices
* And a GKE section that discussed Release Channels
* Move the GKE-specific "long-session" discussion out of "Controlling
Disruption" and into GKE.
* Refactor the GKE getting started page considerably:
* Add a section on choosing a release channel that calls out to
the guide but otherwise suggests using `regular`.
* Move discussion of zonal/regional to top - current instructions
lean towards a zonal cluster but there is really no disadvantage
to defaulting to regional.
* Along the way, remove `gcloud config set` references. We strongly
encourage multiple clusters, it's not clear to me why the instructions
lean so heavily on changing your global gcloud config.
* Assume that the `SplitControllerAndExtensions` gate is getting
graduated, remove reference to Alpha support for Autopilot.
(Does not remove feature flag, will leave for graduation.)
zmerlynn
force-pushed
the
release-channels-docs
branch
from
70d0931
to
76a344d
Compare
|
Build Succeeded 👏 Build Id: b67e1e87-71ca-40ed-9180-d1d436af621b The following development artifacts have been built, and will exist for the next 30 days:
A preview of the website (the last 30 builds are retained): To install this version:
|
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: gongmax, roberthbailey, zmerlynn The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Adds a "Best Practices" section to the sidebar
Move the GKE-specific "long-session" discussion out of "Controlling Disruption" and into GKE.
Refactor the GKE getting started page considerably:
regular.gcloud config setreferences. We strongly encourage multiple clusters, it's not clear to me why the instructions lean so heavily on changing your global gcloud config.SplitControllerAndExtensionsgate is getting graduated, remove reference to Alpha support for Autopilot. (Does not remove feature flag, will leave for graduation.)