Python: Examples show off `load_kube_config()` as the Right Way to set up the module, but an attempt at `load_incluster_config()` is also required to match the behavior of kubectl and work form inside pods

[adamnovak]

Link to the issue (please include a link to the specific documentation or example):

See the examples in the README:

https://github.com/kubernetes-client/python#examples

Description of the issue (please include outputs or screenshots if possible):

The examples of how to set up the module all (except for in_cluster_config.py) look like this:

from kubernetes import client, config
config.load_kube_config()
v1 = client.CoreV1Api()
# Do stuff with Kubernetes

This gives the impression that this is all you need to do to pick up "the" Kubernetes configuration that your user is going to expect you to use (i.e. whatever kubectl would use). However, this is not the case.

If you are running in a pod, and you want to use the configuration that kubectl picks up (for the pod's service account, talking to the current Kubertnetes), you need to run config.load_incluster_config() if/when config.load_kube_config() fails. Since, outside of very specialized situations, you don't really know where your user's will run your software or which method will produce the actual Kubernetes credentials in advance, the Right Way to connect to Kubernetes is not a single method call but a try/except, something like this:

try:
    config.load_kube_config()
except:
    # load_kube_config throws if there is no config, but does not document what it throws, so I can't rely on any particular type here
    config.load_incluster_config()

The examples in the README, and possibly in the examples folder, should be changed to demonstrate credential loading that works like kubectl and pulls from either of these sources as available.

Ideally, the two utility methods should be merged/wrapped in a utility method that loads whichever config is available.

It looks like a similar proposal (with the order reversed) was made as part of #487, but that was part of a larger request, and it was killed by the stale bot without anyone actually solving this particular problem.

[roycaihw]

/assign @fabianvf

[adamnovak]

Some documentation of the Right Way to get the "current" namespace would also be helpful here; the way that works when using config files (config.list_kube_config_contexts() to get the active context, then asking it about its namespace) doesn't work when using a pod's service account (when you need to read /var/run/secrets/kubernetes.io/serviceaccount/namespace instead). Most of the examples seem written to avoid having to do this by calling methods that don't need a namespace, or by hardcoding "default".

[ramnes]

Frankly, all of this would be much simpler with a single load_config function that does the try-except mentioned above.

[fabianvf]

Yeah, I think a general load_config function that mimics more closely what kubectl is doing would make sense, I've always ended up reimplementing it in projects that make use of the client. The configuration code is all here: https://github.com/kubernetes-client/python-base/tree/master/config , is there anyone with the bandwidth/desire to pick this up?

[adamnovak]

This is also related to https://github.com/kubernetes-client/python/issues/741 in that, having loaded the config, credentials which expire aren't refreshed in the background. So the Right Way to get credentials ought to include some kind of periodic refresh, or at least a note that you need it.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[adamnovak]

Most of the examples still ignore load_incluster_config.

/remove-lifecycle stale

[roycaihw]

client-go has a function that does "try and fallback". We should have a method mimics its behavior

[iamneha]

I would like to work on this issue.

/assign @iamneha

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[adamnovak]

The Python examples still don't note the need for load_incluster_config().

/remove-lifecycle stale

[MoShitrit]

Hey @iamneha
Are you actively working on that issue?
If not- I'd like to take a stab at it.
Please let me know if you have any objections.

[MoShitrit]

Looks like this isn't being actively worked on.
I'm going to try and start working on that over the weekend.
/assign

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[dinvlad]

/remove-lifecycle stale

[jiang-wei]

any updates?

[MoShitrit]

Hey,
Sorry, I completely dropped the ball on this one due to other distractions.
I'll do my best to get to work on it ASAP and update.