From 1fbc7b5038340541de939ff9c8b0e99e38246768 Mon Sep 17 00:00:00 2001 From: Dimitris-Ilias Gkanatsios Date: Wed, 12 Oct 2022 08:26:17 -0700 Subject: [PATCH] changes for 0.6 (#428) --- .versions | 2 +- docs/howtos/latencyserver.md | 31 ++++++++++---- docs/howtos/uninstallthundernetes.md | 2 +- docs/troubleshooting/controllernodeagent.md | 2 +- docs/troubleshooting/defaultportinuse.md | 10 ++--- docs/troubleshooting/stuckgameserver.md | 4 +- docs/troubleshooting/stuckinitializing.md | 4 +- docs/troubleshooting/stucknamespace.md | 46 --------------------- 8 files changed, 36 insertions(+), 65 deletions(-) delete mode 100644 docs/troubleshooting/stucknamespace.md diff --git a/.versions b/.versions index 2285fb6b..8c712d15 100644 --- a/.versions +++ b/.versions @@ -1,2 +1,2 @@ #!/bin/bash -export IMAGE_TAG=0.5.0 \ No newline at end of file +export IMAGE_TAG=0.6.0 \ No newline at end of file diff --git a/docs/howtos/latencyserver.md b/docs/howtos/latencyserver.md index 7788f9a6..7dcc0cb7 100644 --- a/docs/howtos/latencyserver.md +++ b/docs/howtos/latencyserver.md @@ -5,14 +5,35 @@ parent: How to's nav_order: 3 --- -# How to measure latency +# How to measure latency to various regions -If you have multiple Thundernetes clusters on different regions, it might be useful to have a way to measure latency to these clusters. For this, we implemented a basic UDP echo server based on PlayFab's Quality of Service Server, you can check both the [C++ implementation](https://github.com/PlayFab/XPlatCppSdk/blob/master/code/source/playfab/QoS/PlayFabQoSApi.cpp) and the [C# implementation](https://github.com/PlayFab/CSharpSDK/blob/master/PlayFabSDK/source/Qos/PlayFabQosApi.cs).This server follows these simple rules: +You can deploy Thundernetes to more than one regions. There are two reasons to do this: + +- Additional regions provide redundancy. If a single region fails, players can access servers in other regions. +- Additional regions allow players to access servers that are "nearby" and deliver low-latency connectivity. + +If you have multiple Thundernetes clusters on different regions, it is useful to have a way to measure latency from the client device (e.g. console/PC) to these clusters. For this purpose, we have implemented a basic UDP echo server based on PlayFab's Quality of Service Server. This server follows these simple rules: - The server only accepts UDP requests, and the data must be 32 bytes max and must also start with 0xFFFF (1111 1111 1111 1111). - If the requests are valid, the server will respond with the same data it received, but with the first 4 bytes flipped to 0x0000 (0000 0000 0000 0000). -In [Thundernetes' main repository](https://github.com/PlayFab/thundernetes/tree/main/cmd/latencyserver) you can find the code for the server and a Dockerfile to build the image. We also provide 2 example YAML files: one for [deploying the server](https://github.com/PlayFab/thundernetes/blob/main/samples/latencyserver/latencyserver.yaml), and another for [deploying a ServiceMonitor](https://github.com/PlayFab/thundernetes/blob/main/samples/latencyserver/monitor.yaml) to crawl the [prometheus metrics](./monitoring.md). All you have to do is run: +The usage of UDP is important, because most multiplayer games use UDP transport for their most performance-critical game traffic. Internet service providers and other elements of the Internet ecosystem may deliver differentiated performance for UDP vs TCP vs ICMP flows. + +For client code, you can check the [C++ implementation](https://github.com/PlayFab/XPlatCppSdk/blob/master/code/source/playfab/QoS/PlayFabQoSApi.cpp) and the [C# implementation](https://github.com/PlayFab/CSharpSDK/blob/master/PlayFabSDK/source/Qos/PlayFabQosApi.cs). + +## Flow + +This is the typical flow for using the latency server in the context of a player device: + +- Create a UDP socket. +- For each region, send a single UDP datagram to port 3075 on the latency server. The message content must start with 0xFFFF (1111 1111 1111 1111). +- The server will reply with a single datagram, with the message contents having the first 2 bytes "flipped" to 0x0000 (0000 0000 0000 0000). The rest of the datagram contents will be copied from the initial ping. +- Measure the time between sending the UDP message and receiving a response. +- Sort the response times from lowest to highest, and request a GameServer in the region with the lowest latency. + +## Deploying the latency server + +In [Thundernetes' main repository](https://github.com/PlayFab/thundernetes/tree/main/cmd/latencyserver) you can find the code for the server and a Dockerfile to build the image. We also provide 2 example YAML files: one for [deploying the server](https://github.com/PlayFab/thundernetes/blob/main/samples/latencyserver/latencyserver.yaml), and another for [deploying a ServiceMonitor](https://github.com/PlayFab/thundernetes/blob/main/samples/latencyserver/monitor.yaml) to grab the [prometheus metrics](./monitoring.md). All you have to do is run: {% include code-block-start.md %} # for the latency server @@ -23,7 +44,3 @@ kubectl apply -f https://raw.githubusercontent.com/PlayFab/thundernetes/main/sam {% include code-block-end.md %} The UDP server runs on the port defined by the `UDP_SERVER_PORT` environment variable. A prometheus `/metrics` endpoint is also exposed, on the port defined by the `METRICS_SERVER_PORT` environment variable, with a counter for the number of successful requests it has received. - -## Deploying the latency server - -You can find the deployment YAML file [here](https://github.com/PlayFab/thundernetes/blob/main/samples/latencyserver/latencyserver.yaml) and the corresponding ServiceMonitor file [here](https://github.com/PlayFab/thundernetes/blob/main/samples/latencyserver/monitor.yaml). diff --git a/docs/howtos/uninstallthundernetes.md b/docs/howtos/uninstallthundernetes.md index bdde24ce..1422f364 100644 --- a/docs/howtos/uninstallthundernetes.md +++ b/docs/howtos/uninstallthundernetes.md @@ -7,7 +7,7 @@ nav_order: 15 ## Uninstalling Thundernetes -You should first remove all your GameServerBuilds. Since each GameServer has a finalizer, removing the controller before removing GameServer instances will make the GameServer instances get stuck if you try to delete them. +You should first remove all your GameServerBuilds. This will remove all GameServers and the corresponding Pods. {% include code-block-start.md %} kubectl delete gsb --all -A # this will delete all GameServerBuilds from all namespaces, which in turn will delete all GameServers diff --git a/docs/troubleshooting/controllernodeagent.md b/docs/troubleshooting/controllernodeagent.md index 75f0e0e4..6b04da25 100644 --- a/docs/troubleshooting/controllernodeagent.md +++ b/docs/troubleshooting/controllernodeagent.md @@ -2,7 +2,7 @@ layout: default title: Controller/NodeAgent logs parent: Troubleshooting -nav_order: 4 +nav_order: 3 --- # How can I get access to the controller and the NodeAgent logs and status? diff --git a/docs/troubleshooting/defaultportinuse.md b/docs/troubleshooting/defaultportinuse.md index 6b48d17b..47e3ceec 100644 --- a/docs/troubleshooting/defaultportinuse.md +++ b/docs/troubleshooting/defaultportinuse.md @@ -1,17 +1,17 @@ --- layout: default -title: Port 5000 is already in use +title: Controller port 5000 parent: Troubleshooting -nav_order: 5 +nav_order: 4 --- -# How can I change the port that Thundernetes uses? +# How can I change the port that Thundernetes uses for the Allocation API service? -By default, Thundernetes's Allocation API listens on port 5000 which is opened with the kind config set-up [here](../quickstart/installing-kind.md). This port can already be in use by another service thus causing Thundernetes to fail. +By default, Thundernetes's Allocation API service listens on port 5000. Locally, it opens with the kind config set-up [here](../quickstart/installing-kind.md). This port can already be in use by another service thus causing Thundernetes to fail. ## Kind Changes -The first step (if using kind) is changing the `kind-config.yaml` to use the desired port. For example: +To use an alternate port, the first step is changing the `kind-config.yaml` to use the desired port. For example: {% include code-block-start.md %} kind: Cluster diff --git a/docs/troubleshooting/stuckgameserver.md b/docs/troubleshooting/stuckgameserver.md index 54541018..c8f9f6ce 100644 --- a/docs/troubleshooting/stuckgameserver.md +++ b/docs/troubleshooting/stuckgameserver.md @@ -2,7 +2,7 @@ layout: default title: Game server is stuck parent: Troubleshooting -nav_order: 2 +nav_order: 1 --- # What should we do if a GameServer gets stuck? @@ -13,4 +13,4 @@ If you want to delete the Pod, you can use the kubectl command `kubectl delete g ❗ Do not directly delete the Pod. It will be deleted automatically when the GameServer is deleted. -❗ Do not manually overwrite GameServer.status details, this will create issues during controller reconciliation. \ No newline at end of file +❗ Do not manually overwrite GameServer.status fields, this will create issues during controller reconciliation. \ No newline at end of file diff --git a/docs/troubleshooting/stuckinitializing.md b/docs/troubleshooting/stuckinitializing.md index 87428269..68a1c541 100644 --- a/docs/troubleshooting/stuckinitializing.md +++ b/docs/troubleshooting/stuckinitializing.md @@ -2,10 +2,10 @@ layout: default title: Game Server does not transition to StandingBy state parent: Troubleshooting -nav_order: 3 +nav_order: 2 --- -# My GameServer state stays in empty or Initializing state and does not transition into StandingBy +# GameServer state stays in empty or Initializing state and does not transition into StandingBy ❗ Check [here](../gsdk/gameserverlifecycle.md) for more information on GameServer lifecycle. diff --git a/docs/troubleshooting/stucknamespace.md b/docs/troubleshooting/stucknamespace.md deleted file mode 100644 index 822d9e95..00000000 --- a/docs/troubleshooting/stucknamespace.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -layout: default -title: GameServer objects are not deleted -parent: Troubleshooting -nav_order: 1 ---- - -# GameServer objects are not deleted - -Thundernetes creates [finalizers](https://kubernetes.io/docs/concepts/overview/working-with-objects/finalizers/) for every GameServer custom resource. If you delete the Thundernetes controller and you try to remove the GameServer Pods and/or the namespace they are in, the namespace might be stuck in terminating state since there is no controller to handle the finalizer notification. To fix this and have the resources cleaned up, you can run the following commands: - -{% include code-block-start.md %} - kubectl get namespace thundernetes-system -o json > tmp.json -{% include code-block-end.md %} - -Open tmp.json file and find this section: - -{% include code-block-start.md %} - "spec": { - "finalizers": [ - "kubernetes" - ] - }, - "status": { - "phase": "Active" - } -{% include code-block-end.md %} - -Remove the finalizer section: - -{% include code-block-start.md %} - "spec": { - - }, - "status": { - "phase": "Terminating" - } -{% include code-block-end.md %} - -Upload the json file: - -{% include code-block-start.md %} -kubectl proxy # this command is blocking, so you can either run it on background or use a different shell for the next commands -curl -k -H "Content-Type: application/json" -X PUT --data-binary @tmp.json http://127.0.0.1:8001/api/v1/namespaces/thundernetes-system/finalize -kubectl get ns # verify that the namespace is gone -{% include code-block-end.md %}