You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
tl;dr: In order to support working simultaneously against a shared and an isolated cluster, we should support working with two agents, one in each cluster.
We have few users who want to "bridge" a local cluster and a remote cluster. The reason they want to bridge is that setting up their local resources is easier with k8s (databases, other services, etc) so they wrap it with Tilt + k9s or something similar, but still they want to leverage the remote cluster for other cases (Stealing, kafka splitting, etc.)
Right now they run mirrord inside the k9s which works but requires a lot of red tape (mounting kubeconfig, someties doesn't work because needs cloud cli, then more dependencies)
It also leads them to run the actual workload inside the local cluster, losing great usability with the IDE.
This leads to the idea - what if the user could specify two targets? give each target kubectx, kubeconfig (maybe we need to move the config to be under target in general?) and then route requests to each target based on rules (Ip/host + defaults).
The text was updated successfully, but these errors were encountered:
tl;dr: In order to support working simultaneously against a shared and an isolated cluster, we should support working with two agents, one in each cluster.
We have few users who want to "bridge" a local cluster and a remote cluster. The reason they want to bridge is that setting up their local resources is easier with k8s (databases, other services, etc) so they wrap it with Tilt + k9s or something similar, but still they want to leverage the remote cluster for other cases (Stealing, kafka splitting, etc.)
Right now they run mirrord inside the k9s which works but requires a lot of red tape (mounting kubeconfig, someties doesn't work because needs cloud cli, then more dependencies)
It also leads them to run the actual workload inside the local cluster, losing great usability with the IDE.
This leads to the idea - what if the user could specify two targets? give each target kubectx, kubeconfig (maybe we need to move the config to be under target in general?) and then route requests to each target based on rules (Ip/host + defaults).
The text was updated successfully, but these errors were encountered: