Bug: Port Forwarding Only Works for Default Namespace
See original GitHub issueI have been using this extension and it is awesome productivity booster.
I noticed that port forwarding currently does not propagate the namespace (selected namespace) context to kubectl
here and other places portForwardToPod
is called no namespace is passed and hence the default
namespace is used.
Happy to work on a PR if you can point me towards the implementation you would like to see to plumb in the namespace.
Issue Analytics
- State:
- Created 5 years ago
- Comments:5 (2 by maintainers)
Top Results From Across the Web
Port-forward drops connection to pod after first ... - GitHub
The problem I describe only appears when running Kubernetes above v1.23.0. Anything else we need to know?: Based on the above testing it...
Read more >Kubernetes Port Forwarding - Connection refused
First, get the name of the pods in the specified namespace kubectl get po -n <namespace> · Now check the exposed port of...
Read more >KubeSail/community - Gitter
Hey @jflamy-dev - I believe the port forwarding issue is due to the default network policy in your shared namespace.
Read more >port forwarding to application in network namespace with vpn
Basically, you need to have a daemon in your "default" workspace listening on TCP port 8112 and redirecting all traffic to 10.200.200.2 port...
Read more >Using Kubectl Port-Forward to Access Kubernetes Applications
Readers will learn how to use the kubectl port-forward functionality to access ... of all running Pods in the default namespace of your...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@bnookala Thanks for the feedback, I will give that a go tonight and open an PR (WIP) for more feedback.
@itowlson @shreyu86
I think it’s time we make
findKindNameForText
(used bytryFindKindNameFromEditor
) return an object that conforms to an interface with the three fields:namespace
,resourceType
,resourceName
, and change usages as such.Right now, we use
<object_kind>/<object_name>
because we can pass the entire string directly to kubectl without having to specify the resource type ie:kubectl describe pod/myCoolPod
Obviously that’s not going to work if we add the namespace into the same string.