Does this work on a remote cluster?

[sander76]

Hi gefyra,

Thanks for this great software. I did try this on a remote cluster but got a message I don't have rights to create a namespace. Some digging in the source indicated this only works within a 'gefyra' namespace.

To me it seems this makes it (currently ?) unable to work inside a cloud-based cluster with namespaces already defined ? Is this correct ?

Thanks !

[SteinRobert]

Hey @sander76 thank you for your question! We're currently on holiday in Germany - the team will get back to you within the next couple of days! Stay tuned!

[tschale]

Hi @sander76,

you're correct, gefyra is currently limited to only work in a gefyra namespace. However it would absolutely be possible to loosen up that limitation. Currently this is probably further ahead in the roadmap.
Do you mind sharing some information about your workflow/setup, so that we can gain a better understanding of your usecase? For example do you have a local development cluster with more permissions (and if so, have you tried gefyra there), or do you have a cloud development cluster? Or is this a staging or production system where you want to use gefyra?

[djivko]

When you guys are considering the priority of namespace scoped gefyra install you would probably want to have the following setup in mind:
There is a dedicated remote development cluster where every developer has a dedicated namespace to bring up a production like environment.

[Schille]

Thanks for this input. Multi-peer Gefyra support is absolutely on our roadmap.

However, I think a namespace approach for shared development clusters is not completely sufficient. For another project I am currently working on provisioning K8s-in-K8s (see: https://github.com/Getdeck/beiboot/) which would also support multi-namespace applications to be developed within a single host development cluster. Gefyra will soon integrate with this; so you can spin up a dedicated remote K8s cluster for developers (using the deck CLI) while maintaining only one real host cluster. Would that be of interest for you, too?

Anyway, this is on our radar.

[sander76]

Hi @tschale , Thanks for the reply.

First a thing to know: My knowledge on this matter is intermediate at best.

My current work environment is a remote openshift kubernetes cluster with two namespaces: dev and prod.
The goal I am trying to reach is easy access from my local dev machine to the remote services inside that openshift cluster, in any way (directly, from inside a docker container, or pod from a local running cluster, which I have never done yet))

Currently I have two ways of access, both of which are only partly usable:

From my local machine I can access our remote services (API http endpoints) by going through an sso login procedure which involves redirects and user interactions inside a browser. This is only useful for "human" interaction with a service: It has no use for an automated test prodedure, where I am unable to go through the login procedure.

Another way of access is to exchange keys (using a copy paste action) which involves kubectl port forwarding from local to a remote service. This is -kind of- useful in that it allows access from my local test procedure, but the login is elaborate and involves setting special test endpoints among other hurdles to take.

I am familiar with wireguard, so I am/was under the impression that my local machine becomes part of the remote network which could pretty much remove all boundaries of accessing them.

Hope this makes sense.

[Schille]

Hi @sander76
Thank you very much for elaborating your setup. In short: Gefyra is supposed to work on remote clusters just as well as on local Kubernetes installations. However, there are two points to consider:

• you need to have access to one of the data plane nodes (not only the K8s API server) to establish the underlying VPN connection based on Wireguard (please check your firewall settings, too)
• you need the required cluster privileges to operate (create and mange) a new namespace for Gefyra

That's it.

You run gefyra up --endpoint ip:port with ip:port being the address to one of your cluster nodes. If there is no firewall hiding the cluster nodes from you network, the node port is 31820. If there is a firewall with some sort of port mapping you need to specify that port.

From the latest CLI release (0.7.x) on, Gefyra checks its ability to communicate with the cluster. In case it's not working, Gefyra rolls everything back and you can review the --endpoint argument.

Finally, Gefyra offers you to run any container locally on your local machine (with all the advantages) that behaves as it would be part of the target cluster namespace. For example if you would like to have an Ubunut running in the cluster namespace "dev" you can simply do:

gefyra run -i ubuntu -N myubuntu -n dev -c "tail -f /dev/null"

(-i = docker image, -N = name of your local container instance, -n = Kubernetes namespace, -c = command to keep the container instance running)

and then:

docker exec -it myubuntu bash

which will drop you into a bash shell that runs in the Kubernetes namespace "dev". You can confirm it working by installing (apt update && apt install wget -y) and running wget to one of your Kubernetes services (kubectl -n dev get service), for example wget -O- my-service.

Remove it with docker kill myubuntu.

Please consider it is intended that Gefyra explicitly does not make your entire development machine to become part of the cluster. Rather your local containers can become part of a Kubernetes namespace by running gefyra run ....

Installing Gefyra to a specific Kubernetes namespace (let's say like so gefyra up --namespace dev --endpoint ...) can be discussed as a feature request which is actually not to difficult to integrate.

[Schille]

Btw: I took the example from here: https://gefyra.dev/usecases/ubuntu-in-namespace/

[Schille]

Hi @sander76
Just wanted to follow up on this one. Did you have the time to check this out?

[sander76]

Sorry for not responding earlier. I had some days off. This is still on my radar, but it is something I need to discuss with my team first. For starters, I don't have the required privileges. I'll update you asap. Sander.