当我尝试配置与:串联的几个KUBECONFIG环境条目时，我遇到一个奇怪的行为，例如此处的示例:
export KUBECONFIG=/Users/user/Work/company/project/setup/secrets/dev-qz/users/admin.conf:/Users/user/Work/company/project/setup/secrets/dev-wer/users/admin.conf:/Users/user/Work/company/project/setup/secrets/test-wer/users/admin.conf:/Users/user/Work/company/project/setup/secrets/test/users/admin.conf:/Users/user/Work/company/project/setup/secrets/dev-jg/users/admin.conf:/Users/user/Work/company/project/setup/secrets/preprod/users/admin.conf:/Users/user/Work/company/project/setup/secrets/dev/users/admin.conf:/Users/user/Work/company/project/setup/secrets/dev-fxc/users/admin.conf:/Users/user/Work/company/project/setup/secrets/cluster-setup/users/admin.conf:/Users/user/Work/company/project/setup/secrets/test-fxc/users/admin.conf:/Users/user/Work/company/project/setup/secrets/test-jg/users/admin.conf:/Users/user/Work/company/project/setup/secrets/test-qz/users/admin.conf
这就是发生的情况:如果我用
kubectx选择集群(不是列表中的每个集群，而是任何集群)，当我尝试kubectl get po时，我会收到:error: You must be logged in to the server (Unauthorized)。但是，如果尝试到达同一群集，并使用
--kubeconfig=<path to the config>将其直接传递给kubectl命令，则它可以工作。我对此很挣扎，只想知道是否还有其他人也面临此类问题以及如何解决
最佳答案
最终我发现了问题。向我建议@mario的flatten命令帮助我更好地调试了这种情况。
基本上，in memory或in file合并完成了它应该做的事情:使用每个kubeconfig文件的所有uniq参数创建一个kubeconfig。除非在一个或多个kubeconfig上具有标识相同组件的相同标签，否则这将完美工作。在这种情况下，last按顺序获胜。因此，如果您有以下示例:
grep -Rn 'name: kubernetes-admin$' infra/secrets/*/users/admin.conf
infra/secrets/cluster1/users/admin.conf:16:- name: kubernetes-admin
infra/secrets/cluster2/users/admin.conf:17:- name: kubernetes-admin
infra/secrets/cluster3/users/admin.conf:16:- name: kubernetes-admin
cluster1和cluster2无法正常工作，而cluster3则可以完美工作(顺便说一下)。此问题的解决方案是通过重命名标识用户的标签来避免非uniq字段(对于上面的示例)。完成此更改后，一切将正常运行。