Misleading docs/error message for gefyra up --endpoint

[sbor23]

There are a few small shortcomings we encountered when getting started with gefyra.

1. It would probably make sense to include a "Getting started" guide for a generic, remote cluster that is not vendor specific. No need to document what's needed in order to setup kubectl, just start from where kubectl is working and all that's need is something in the line of:

gefyra up --endpoint 10.33.129.51:31820
gefyra run -i myorg/dataserver-web -N dataserver-web -n dataserver --env-from deployment/lab-dataserver-web
gefyra bridge -N dataserver-web -C dataserver-web -n dataserver -p 8000:8000 -I dataserver-bridge --deployment lab-dataserver-web

2. The gefyra up --endpoint flag is not well document and implemented IMO. a) It should allow to just pass the IP of the cluster and just use the default port 31820, currently this is not accepted. Would be a handy feature. b) Because of the wording in the docs "The Wireguard endpoint in the form IP:Port for Gefyra to connect to", one can be misguided to look at the kubeconfig and use the port specified there, in our case 6443.

3. The wording of the error message is misleading, "that the [kubernetes cluster] can reach Kubenetes port 31820 from this machine". That makes no sense at all.

[ERROR] Gefyra could not successfully confirm the Wireguard connection working. Please make sure you are using the --endpoint argument for remote clusters and that 10.33.129.51:6443 can reach Kubernetes node port 31820 from this machine. Please check your firewall settings, too. If you are running a local Minikube cluster, please use the 'gefyra up --minikube' flag.

[SteinRobert]

Hey @sbor23 this is super, super valuable feedback for us. Thanks a lot. We'll be looking into this shortly!

[SteinRobert]

Things should be mostly addressed. Generic getting started is in the works (gefyrahq/gefyrahq.github.io#40)