gefyrahq / gefyra

Blazingly-fast :rocket:, rock-solid, local application development :arrow_right: with Kubernetes.
https://gefyra.dev
Apache License 2.0
692 stars 28 forks source link

[Guide EKS public/private request]: How to configure Gefyra with EKS node group in private network #345

Open maxmonterumisi opened 1 year ago

maxmonterumisi commented 1 year ago

My goal

I would to like setup gefyra to connect my frontend application deployed on my laptop on minikube to my database deployed on remote EKS cluster.

My Kubernetes development setup

The EKS cluster is up and running, and had the node instances running on private network. (not EXTERNAL_IP) Instead the API endpoint is public. My laptop is a Windows 10 with minikube + docker desktop.

My test

Find AWS EKS cluster SG: aws eks describe-cluster --name crazy-eks --query "cluster.resourcesVpcConfig.clusterSecurityGroupId" --region eu-central-1 --profile default "sg-9999999a999e9cb99"

Add to sg-9999999a999e9cb99 on ingress the UDP 31820

Find the IP address of the EKS API server Endpoint

nslookup C0xxxxxxxxxxxxxxxxxxxxxxxxx3.gr7.eu-central-1.eks.amazonaws.com
Server:  my.server.local
Address:  1.1.1.1.

Risposta da un server non autorevole:
Nome:    C0xxxxxxxxxxxxxxxxxxxxxxxxx3.gr7.eu-central-1.eks.amazonaws.com
Addresses:  A.B.C.D , E.F.G.H    

Try gefyra up

gefyra up --host A.B.C.D --kubeconfig c:\Users\my.user\.kube\config
[INFO] Installing Gefyra Operator
[INFO] Created network 'gefyra' (e1d9a9ad7ab9)
[INFO] Container image "quay.io/gefyra/operator:1.0.2" already present on machine
[INFO] Pulling image "quay.io/gefyra/stowaway:1.0.2"
[INFO] Successfully pulled image "quay.io/gefyra/stowaway:1.0.2" in 467.883545ms
[INFO] Operator became ready in 7.0376 seconds
[INFO] Deploying Cargo (network sidecar) with IP 172.23.0.149
[ERROR] Gefyra could not successfully confirm the Wireguard connection working. Please make sure you are using the --endpoint argument for remote clusters and that the Kubernetes NodePort A.B.C.D:31820 can be reached from this machine. Please check your firewall settings, too. If you are running a local Minikube cluster, please use the 'gefyra up --minikube' flag.
[INFO] Removing running bridges
[INFO] Uninstalling Operator
[INFO] Removing Cargo
[INFO] Removing Docker network gefyra
[CRITICAL] There was an error running Gefyra: Failed to start Gefyra

Can you help me to make this configuration ?

Best Regards M.M.

SteinRobert commented 1 year ago

Hello @maxmonterumisi - thank your very much for your feedback! From what I see you're basically asking for something similar to this: https://github.com/gefyrahq/gefyra/issues/292 - Note --endpoint is now --host + --port. I'm afraid Gefyra is not able to connect to Nodes which aren't exposed publicly, currently.

We're working on a solution that does not involve the NodePort - but it's not done yet.

Moreover - just to make sure I understood you correctly: You're trying to connect a container from within your local Minikube cluster to a remote cluster? If that's the case - I'm also sorry to say that Gefyra is for connecting local containers with remote clusters. Meaning the local containers actually need to run through the docker client on your local machine.

maxmonterumisi commented 1 year ago

Hi @SteinRobert thank you so much for your reply. I'm sorry I can't use your excellent product, ...right now our EKS Worker Nodes are private only. The only thing public is EKS API endpoint. We hope in the future that Gefyra can support this type of configuration. Thanks also for the clarification regarding the local cluster which can only be Docker...I didn't get it.

Schille commented 1 year ago

@maxmonterumisi stay tuned. We are working on an "installation procedure" that will add a loadbalancer to your AWS EKS setup. With that, you can prepare any private EKS cluster to work with Gefyra from your local host. =)

SteinRobert commented 1 year ago

@maxmonterumisi thank you so much for letting us know about your use case! It does help us to prioritise feature development and you pushed this one a bit further up our roadmap! 😉

Schille commented 1 year ago

I have created a new issue to discuss our final solution to these types of challenges: #353 If you @maxmonterumisi do have some thoughts about this, I would be very happy to hear them. =)