Michael Schilonka

This could be something like: `[INFO] Created a bridge for Pod '%pod-name%' in namespace '%namespace%' on port %source% to local container '%container-name%' on port %target%.` making it more obvious what...

New action (~ `reflect`) to instantly bring up a local container bridged to the cluster

1

I want to run `gefyra reflect -n mynamespace deploy/fancy1` (or similar; some more options) to 1) fetch the Pod's information 2) set up a local container instance based on the...

Add missing `docker run` options to `gefyra run`

2

Since the container is run locally, I expected to be able to give it similar switches as the docker run command, such as `--entrypoint`, `--cap-add` and others if necessary.

Improved DX for `gefyra bridge` action

1

What do you think about removing the following options from `gefyra bridge` - --container-name - --statefulset - --deployment - --pod replacing it with some sort of `--target` options which takes...

So other services in the cluster can consume my (potentially) newly added service "the Kubernetes way". This probably needs some conceptional work and is of low prio at the moment.

`gefyra list --container` command should include the Kubernetes namespace (and if bridged) of the running containers `gefyra list --bridges` command should include in output, the namespace, deployment/statefulset and pod container...

This could be easily done with docker-py built-in features https://docker-py.readthedocs.io/en/stable/containers.html#docker.models.containers.Container.stats

Once a bridge is established, Gefyra currently doesn't care about the proper functioning of the bridge. Is the Pod unhealthy? - readyness issues? Did Kubernetes already remove the Pod and...