Read proxy-url from kubeconfig cluster

[yurnov]

What type of PR is this?

/kind bug
/kind feature

What this PR does / why we need it:

load_kube_config() ignored the proxy-url field of a kubeconfig cluster
entry, so Configuration.proxy stayed None and requests went direct,
bypassing the configured proxy. There was no warning — the field was parsed
and dropped.

Two changes in kubernetes/base/config/kube_config.py:

• _load_cluster_info() reads proxy-url into self.proxy
• _set_config() copies proxy to the client configuration

This mirrors kubernetes/aio/config/kube_config.py, which already does both,
and brings the sync client in line with kubectl/client-go.

The keys list in _set_config() is wrapped across two lines; it was 94
characters and missing a space after 'verify_ssl',.

Which issue(s) this PR fixes:

Fixes #2679

Special notes for your reviewer:

Scope was agreed with @yliaog in #2679: loader only, no generated files
touched. The HTTPS_PROXY/HTTP_PROXY problem described in that issue is
deliberately left out, since it would land in the generated
kubernetes/client/configuration.py — happy to file it separately.

Tests are ported from the existing async suite:

• test_proxy_url_from_cluster — loader level, mirrors the async test of the
  same name
• test_new_client_from_config_proxy — through the public entry point

Both fail without the change (verified by reverting kube_config.py alone and
re-running); the full sync config suite is 77 passed.

Also verified end to end against a kind cluster whose API server was reachable
only through a proxy: the control-plane container's DNS name is not resolvable
from the host, and kubeadm already puts that name in the apiserver cert SANs,
so TLS validates normally without insecure-skip-tls-verify. Before the
change the call failed with a name-resolution error and Configuration.proxy
was None; after it, proxy is set, the request succeeds, and the proxy logs
CONNECT proxytest-control-plane:6443.

Does this PR introduce a user-facing change?

`load_kube_config()` now honors the `proxy-url` field of a kubeconfig cluster entry and sets `Configuration.proxy` from it.

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

- [kubeconfig v1 Cluster reference]: https://kubernetes.io/docs/reference/config-api/kubeconfig.v1/#Cluster

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: yurnov / name: Yuriy Novostavskiy (7fb3581)

[kubernetes-prow]

Welcome @yurnov!

It looks like this is your first PR to kubernetes-client/python 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-client/python has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[yurnov]

/pony

[kubernetes-prow]

@yurnov:

Details

In response to this:

/pony

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.

[yurnov]

Ready for review. The GitHub Actions runs are sitting at action_required (first-time contributor), so they need a maintainer to approve the workflow run before CI reports anything.

[yliaog]

thanks for the PR
/lgtm
/approve

[kubernetes-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: yliaog, yurnov

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• kubernetes/base/OWNERS [yliaog]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[yurnov]

@yliaog @roycaihw a question on release mechanics rather than the change itself: does this ride into a 36.0.x patch automatically, or should I open something against release-36.0?

My reading is that nothing is needed — scripts/release.sh cuts the release branch from master and merges the release branch back with -X theirs, and #2628 (36.0.3) picked up ordinary master commits without individual cherry-picks. Asking only because the "Patch a release branch" section of devel/release.md says the opposite.

Happy to open a cherry-pick against release-36.0 if you'd prefer one: it applies with no conflicts and the config tests pass there. Worth doing if it's easy, since anyone hitting this today is on 36.x and there's no workaround short of setting Configuration.proxy in user code.