az aks get-credentials does not work with kind

[lbruun]

Related command

az aks get-credentials

Describe the bug

The az aks get-credentials command incorrectly expects that the local kube config file must have a clusters key in order to be valid.

This kube config will work with the az command:

apiVersion: v1
kind: Config
clusters: []
preferences: {}

while this will not:

apiVersion: v1
kind: Config
preferences: {}

and produces error message:

ERROR: No such key 'clusters' in existing config, please confirm whether it is a valid config file. May back up this config file, delete it and retry the command.

Other tools in the Kubernetes ecosystem do not behave like this when parsing the kube config file. This is specifically a problem in CI pipelines for example together with kind. See reproduction below.

To Reproduce

1. rm -r -f ~/.kube/config (This removes local kube config and thereby simulates that we start out fresh, just like a CI pipeline would do.)
2. kind create cluster
3. kind delete cluster
4. az aks get-credentials ..... results in error:

ERROR: No such key 'clusters' in existing config, please confirm whether it is a valid config file. 
May back up this config file, delete it and retry the command.

Expected behavior

That az aks get-credentials ..... would parse the kube config file similarly to other tools in the Kubernetes ecosystem, in particular those from the Kubernetes project itself (cough: kind).

Current workaround

In a CI pipeline you'll need to completely remove the kube config file (rm -r -f ~/.kube/config) after having used kind (or any other tool which may manipulate the kube config file). This will make the az aks get-credentials command work.

[yonzhan]

Thank you for opening this issue, we will look into it.

[FredrikMeyer]

I got this error when I had an almost empty ~/.kube/config file (I assume kind created it) when I tried to run az aks get-credentials --resource-group myResourceGroup --name myAKSCluster. Deleting the file and rerunning the az command solved it.

[lbruun]

I've found this: https://kubernetes.io/docs/reference/config-api/kubeconfig.v1/

This indicates that the clusters property is indeed mandatory. So having a kubeconfig file without it would constitute an invalid kubeconfig file. If this is correctly understood it means that it is Kind which is doing something wrong and the problem should probably be reported in the their issue tracker.

[pfredeli]

For anyone in need. Here's a workaround that works with yq v4.44.3:

yq eval '.clusters = .clusters // [] | .users = .users // [] | .contexts = .contexts // []' -i ~/.kube/config