read proxy-url from kubeconf
What is the feature and why do you need it:
kubeconfig support the cluster option proxy-url.
I think it would be useful if function like load_kube_config would use that to set kubernetes.client.configuration.proxy
Describe the solution you'd like to see: the changes that are need to implemented are minimal. already started with merge request #2182
Just came across this as I was trying to use the rubusta krr plugin to k9s and I use a proxy->vpn configuration to access the clusters which are locked down to certain IP addresses. I've had to work back through the python code to this dependency to figure out that proxy-url wasn't supported to then find that there are multiple people trying to get this use case working recently.
I will say though that the associated PR is missing any kind of test coverage which means it's unlikely to be accepted.
I tried to set the proxy as this:
from kubernetes import client, config
config.load_kube_config(DEFAULT_KUBECONFIG)
configuration = client.Configuration()
configuration.proxy = DEFAULT_PROXY
c = client.ApiClient(configuration=configuration)
And it works for the CoreV1Api methods:
client.CoreV1Api(c).list_namespaced_pod(...)
But doesn't work for:
dynamic.DynamicClient(c).resources.get(...)
Would you share any ideas? Thanks!
@richardnpaul merge request does now include unittest. Did not have time until now to add them. But i agree its better to add them
@tianshihan818 don`t know if this is best location to ask questions, But might be able to help you.
from kubernetes import client, config
config.load_kube_config(DEFAULT_KUBECONFIG) # this sets Configuration._default
# this creates a new empty Configuration not using Configuration._default
# configuration = client.Configuration()
# use this instead
configuration = client.Configuration().get_default_copy()
configuration.proxy = DEFAULT_PROXY
c = client.ApiClient(configuration=configuration)
# are you sure this worked before?
client.CoreV1Api(c).list_namespaced_pod(...)
# I assume this will work now
dynamic.DynamicClient(c).resources.get(...)
I am also new to this project, so i can be wrong. But i hope this helps,
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle rotten - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
I would really like to see this move forward also, it's very unintuitive to have to set this manually in the code.
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Reopen this issue with
/reopen - Mark this issue as fresh with
/remove-lifecycle rotten - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
In response to this:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied- After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied- After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closedYou can:
- Reopen this issue with
/reopen- Mark this issue as fresh with
/remove-lifecycle rotten- Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.