Agones Getting Started Guide with Minikube uses wrong IP due to minikube bug

[dav-otero]

What happened:
Following the Installation and [Getting Started] (https://agones.dev/site/docs/getting-started/create-gameserver/) guide allows the user to have the simple-upd sample server up and running.

The problem is that the minikube reported Node IP for the game server is not correct and does not allow the user to connect to the game server, using the nc command provided.

What you expected to happen:
The main expectation when following the guide is that it works out of the box. The result is that you have a game server running correctly in the cluster, but not able to connect to it, thus not being able to finish the getting started guide.

How to reproduce it (as minimally and precisely as possible):
Follow the steps provided in the links provided above. When getting to the point of doing:

kubectl get gs

You get something like:

NAME               STATE   ADDRESS     PORT   NODE       AGE
simple-udp-q8p77   Ready   10.0.2.15   7601   minikube   4h

Where the ADDRESS is unreachable when doing:

nc -u {IP} {PORT}

Anything else we need to know?:
The solution to this problem with the minikube version I am using is to use this command to get the correct ADDRESS:

minikube ip

Then, you can use this IP + the port reported in:

kubectl get gs

Then you are able to connect.
This has been discussed in the slack channel, and we found this bug reported to minikube:

Environment:

• OS: OSX Mojave 10.14.4
• Agones version: 0.9
• Kubernetes version (use kubectl version): client 1.13.1 / server 1.11.0
• Cloud provider or hardware configuration: minikube v1.0
• Install method (yaml/helm): yaml

[dav-otero]

Result of kubectl describe node:

$kubectl describe node
Name:               minikube
Roles:              master
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/os=linux
                    kubernetes.io/hostname=minikube
                    node-role.kubernetes.io/master=
Annotations:        kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock
                    node.alpha.kubernetes.io/ttl: 0
                    volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp:  Wed, 24 Apr 2019 11:02:45 +0200
Taints:             <none>
Unschedulable:      false
Conditions:
  Type             Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message
  ----             ------  -----------------                 ------------------                ------                       -------
  OutOfDisk        False   Thu, 25 Apr 2019 17:07:52 +0200   Wed, 24 Apr 2019 11:02:40 +0200   KubeletHasSufficientDisk     kubelet has sufficient disk space available
  MemoryPressure   False   Thu, 25 Apr 2019 17:07:52 +0200   Wed, 24 Apr 2019 11:02:40 +0200   KubeletHasSufficientMemory   kubelet has sufficient memory available
  DiskPressure     False   Thu, 25 Apr 2019 17:07:52 +0200   Wed, 24 Apr 2019 11:02:40 +0200   KubeletHasNoDiskPressure     kubelet has no disk pressure
  PIDPressure      False   Thu, 25 Apr 2019 17:07:52 +0200   Wed, 24 Apr 2019 11:02:40 +0200   KubeletHasSufficientPID      kubelet has sufficient PID available
  Ready            True    Thu, 25 Apr 2019 17:07:52 +0200   Wed, 24 Apr 2019 11:02:40 +0200   KubeletReady                 kubelet is posting ready status
Addresses:
  InternalIP:  10.0.2.15
  Hostname:    minikube
Capacity:
 cpu:                2
 ephemeral-storage:  17784772Ki
 hugepages-2Mi:      0
 memory:             2038624Ki
 pods:               110
Allocatable:
 cpu:                2
 ephemeral-storage:  16390445849
 hugepages-2Mi:      0
 memory:             1936224Ki
 pods:               110
System Info:
 Machine ID:                 562f35f800d74eeb93791ebfcfaa8008
 System UUID:                2A2E0027-81D2-46B2-9109-29B27BA7D95A
 Boot ID:                    6da465dc-0529-4039-96c0-6b87b0d54f12
 Kernel Version:             4.15.0
 OS Image:                   Buildroot 2018.05
 Operating System:           linux
 Architecture:               amd64
 Container Runtime Version:  docker://18.6.2
 Kubelet Version:            v1.11.0
 Kube-Proxy Version:         v1.11.0
Non-terminated Pods:         (14 in total)
  Namespace                  Name                                     CPU Requests  CPU Limits  Memory Requests  Memory Limits  AGE
  ---------                  ----                                     ------------  ----------  ---------------  -------------  ---
  agones-system              agones-controller-799c74ff54-hhn7n       0 (0%)        0 (0%)      0 (0%)           0 (0%)         30h
  agones-system              agones-ping-6d4d5d7f4d-85g2k             0 (0%)        0 (0%)      0 (0%)           0 (0%)         30h
  agones-system              agones-ping-6d4d5d7f4d-tckgn             0 (0%)        0 (0%)      0 (0%)           0 (0%)         30h
  default                    simple-udp-q8p77                         50m (2%)      20m (1%)    32Mi (1%)        32Mi (1%)      5h5m
  kube-system                coredns-78fcdf6894-h492h                 100m (5%)     0 (0%)      70Mi (3%)        170Mi (8%)     30h
  kube-system                coredns-78fcdf6894-mm2kr                 100m (5%)     0 (0%)      70Mi (3%)        170Mi (8%)     30h
  kube-system                etcd-minikube                            0 (0%)        0 (0%)      0 (0%)           0 (0%)         30h
  kube-system                kube-addon-manager-minikube              5m (0%)       0 (0%)      50Mi (2%)        0 (0%)         30h
  kube-system                kube-apiserver-minikube                  250m (12%)    0 (0%)      0 (0%)           0 (0%)         30h
  kube-system                kube-controller-manager-minikube         200m (10%)    0 (0%)      0 (0%)           0 (0%)         30h
  kube-system                kube-proxy-n6rm4                         0 (0%)        0 (0%)      0 (0%)           0 (0%)         30h
  kube-system                kube-scheduler-minikube                  100m (5%)     0 (0%)      0 (0%)           0 (0%)         30h
  kube-system                kubernetes-dashboard-6fcb8b9cbb-6lfs4    0 (0%)        0 (0%)      0 (0%)           0 (0%)         22m
  kube-system                storage-provisioner                      0 (0%)        0 (0%)      0 (0%)           0 (0%)         30h
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests     Limits
  --------           --------     ------
  cpu                805m (40%)   20m (1%)
  memory             222Mi (11%)  372Mi (19%)
  ephemeral-storage  0 (0%)       0 (0%)
Events:              <none>`

[roberthbailey]

If you run kubectl get nodes - o wide on a GKE cluster vs. a minikube cluster you can see that on the GKE cluster the columns for the internal IP and external IP of each node is populated while on the minikube cluster only the column for internal IP is filled in. Looking at the output of kubectl get gs on the GKE cluster I see the external IP for the node being used while on the minikube cluster it uses the internal IP (the only one available).

It makes sense that the minikube node wouldn't be reachable via an internal IP from "outside of the cluster" since that is what internal IP means and generally a gameserver is intended to be reachable externally. The underlying problem seems to be similar to this issue where it's explained that the minikube VM is taking the address of eth0 but eth1 is what is returned by minikube ip.

I've opened kubernetes/minikube#4330 against the minikube repo to see if there is something they can fix on that end. If not, we can update the docs specifically for minikube with the workaround you put into the initial bug report.

[dav-otero]

Sounds good! Cheers :y: El El jue, 23 may 2019 a las 10:43, Robert Bailey <notifications@github.com> escribió:

…

If you run kubectl get nodes - o wide on a GKE cluster vs. a minikube cluster you can see that on the GKE cluster the columns for the internal IP and external IP of each node is populated while on the minikube cluster only the column for internal IP is filled in. Looking at the output of kubectl get gs on the GKE cluster I see the external IP for the node being used while on the minikube cluster it uses the internal IP (the only one available). It makes sense that the minikube node wouldn't be reachable via an internal IP from "outside of the cluster" since that is what internal IP means and generally a gameserver is intended to be reachable externally. The underlying problem seems to be similar to this issue <kubernetes/minikube#2922 (comment)> where it's explained that the minikube VM is taking the address of eth0 but eth1 is what is returned by minikube ip. I've opened kubernetes/minikube#4330 <kubernetes/minikube#4330> against the minikube repo to see if there is something they can fix on that end. If not, we can update the docs specifically for minikube with the workaround you put into the initial bug report. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#751>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACKYNMB6EQ5KVCGPLBBAM2TPWZKLXANCNFSM4HJI7YLQ> .

[roberthbailey]

My minikube issue was a dupe and I've bumped kubernetes/minikube#3416 which is where the feature is being tracked on that end. If this isn't fixed in minikube before our 1.0 milestone we will definitely update our docs.