Is "current-context" a mandatory key in a kubeconfig file?

Question

THE PLOT:

I am working on a kubernetes environment where we have PROD and ITG setup. The ITG setup has multi-cluster environment whereas PROD setup is a single-cluster environment. I am trying to automate some process using Python where I have to deal with kubeconfig file and I am using the kubernetes library for it.

THE PROBLEM:

The kubeconfig file for PROD has "current-context" key available but the same is missing from the kubeconfig file for ITG.

prdconfig:

apiVersion: v1
clusters:
- cluster:
    insecure-skip-tls-verify: true
    server: https://cluster3.url.com:3600
  name: cluster-ABC
contexts:
- context:
    cluster: cluster-LMN
    user: cluster-user
  name: cluster-LMN-context
current-context: cluster-LMN-context
kind: Config
preferences: {}
users:
- name: cluster-user
  user:
    exec:
      command: kubectl
      apiVersion: <clientauth/version>
      args:
      - kubectl-custom-plugin
      - authenticate
      - https://cluster.url.com:8080
      - --user=user
      - --token=/api/v2/session/xxxx
      - --token-expiry=1000000000
      - --force-reauth=false
      - --insecure-skip-tls-verify=true

itgconfig:

apiVersion: v1
clusters:
- cluster:
    insecure-skip-tls-verify: true
    server: https://cluster1.url.com:3600
  name: cluster-ABC
- cluster:
    insecure-skip-tls-verify: true
    server: https://cluster2.url.com:3601
  name: cluster-XYZ
contexts:
- context:
    cluster: cluster-ABC
    user: cluster-user
  name: cluster-ABC-context
- context:
    cluster: cluster-XYZ
    user: cluster-user
  name: cluster-XYZ-context
kind: Config
preferences: {}
users:
- name: cluster-user
  user:
    exec:
      command: kubectl
      apiVersion: <clientauth/version>
      args:
      - kubectl-custom-plugin
      - authenticate
      - https://cluster.url.com:8080
      - --user=user
      - --token=/api/v2/session/xxxx
      - --token-expiry=1000000000
      - --force-reauth=false
      - --insecure-skip-tls-verify=true

When I try loading the kubeconfig file for PROD using config.load_kube_config(os.path.expanduser('~/.kube/prdconfig')) it works.

And when I try loading the kubeconfig file for ITG using config.load_kube_config(os.path.expanduser('~/.kube/itgconfig')), I get the following error:

ConfigException: Invalid kube-config file. Expected key current-context in C:\Users<username>/.kube/itgconfig

Although it is very clear from the error message that it is considering the kubeconfig file as invalid, as it does not have "current-context" key in it.

THE SUB-PLOT:

When working with kubectl, the missing "current-context" does not make any difference as we can always specify context along with the command. But the 'load_kube_config()' function makes it mandatory to have "current-context" available.

THE QUESTION:

So, is "current-context" a mandatory key in kubeconfig file?

THE DISCLAIMER:

I am very new to kubernetes and have very little experience working with it.

Answer 1

As described in the comments: If we want to use kubeconfig file to work out of the box by default, with specific cluster using kubectl or python script we can mark one of the contexts in our kubeconfig file as the default by specifying current-context.

Note about Context:

A context element in a kubeconfig file is used to group access parameters under a convenient name. Each context has three parameters: cluster, namespace, and user. By default, the kubectl command-line tool uses parameters from the current context to communicate with the cluster.

In order to mark one of our contexts (f.e. dev-fronted) in our kubeconfig file as the default one please run:

kubectl config use-context dev-fronted

Now whenever you run a kubectl command, the action will apply to the cluster, and namespace listed in the dev-frontend context. And the command will use the credentials of the user listed in the dev-frontend context

Please take a look at:

- Mering kubeconfig files:

2. determine the context to use based on the first hit in this chain:

   Use the --context command-line flag if it exists. Use the current-context from the merged kubeconfig files.

An empty context is allowed at this point.

3. determine the cluster and user. At this point, there might or might not be a context. Determine the cluster and user based on the first hit in this chain, which is run twice: once for user and once for cluster:

   Use a command-line flag if it exists: --user or --cluster. If the context is non-empty, take the user or cluster from the context.

The user and cluster can be empty at this point.

Whenever we run kubectl commands without specified current-context we should provide additional configuration parameters to tell kubectl which configuration to use, in your example it could be f.e.:

kubectl --kubeconfig=/your_directory/itgconfig get pods --context cluster-ABC-context

As described earlier - to simplify this task we can use configure current-context in kubeconfig file configuration:

kubectl config --kubeconfig=c/your_directory/itgconfig use-context cluster-ABC-context

Going further into errors generated by your script we should notice errors from config/kube_config.py:

config/kube_config.py", line 257, in set_active_context context_name = self._config['current-context']

kubernetes.config.config_exception.ConfigException:: Invalid kube-config file. Expected key current-context in ...

Here is an example with additional context="cluster-ABC-context" parameter:

from kubernetes import client, config

config.load_kube_config(config_file='/example/data/merged/itgconfig', context="cluster-ABC-context")

v1 = client.CoreV1Api()
print("Listing pods with their IPs:")
ret = v1.list_pod_for_all_namespaces(watch=False)
for i in ret.items:
    print("%s\t%s\t%s" % (i.status.pod_ip, i.metadata.namespace, i.metadata.name))

...
Listing pods with their IPs:
10.200.xxx.xxx  kube-system coredns-558bd4d5db-qpzb8
192.168.xxx.xxx kube-system etcd-debian-test
...

Additional information

• Configure Access to Multiple Clusters
• Organizing Cluster Access Using kubeconfig Files