kubectl在Pod中使用proxy的凭据来源及优先级问询

核心逻辑：kubectl 凭据与集群地址的查找优先级 #

kubectl 按以下顺序查找配置（优先级从高到低）：

1. 命令行参数：通过 --kubeconfig 指定的配置文件
2. 环境变量：KUBECONFIG 环境变量定义的配置文件路径（可指定多个，用系统对应分隔符分隔）
3. 默认用户配置：用户主目录下的 ~/.kube/config 文件
4. 集群内服务账号挂载：当运行在 Kubernetes Pod 内且上述配置都不存在时，自动读取 /var/run/secrets/kubernetes.io/serviceaccount/ 路径下的挂载资源：
   • token：服务账号的认证令牌
   • ca.crt：集群根CA证书，用于验证API Server身份
   • 集群地址从环境变量 KUBERNETES_SERVICE_HOST 和 KUBERNETES_SERVICE_PORT_HTTPS 获取

针对你的场景的解答 #

1. kubectl proxy 在 Pod 内的工作逻辑
   你在Pod内执行kubectl proxy能成功调用API，确实是使用了默认服务账号的挂载资源：凭据来自/var/run/secrets/kubernetes.io/serviceaccount/token，集群地址通过KUBERNETES_SERVICE_HOST和KUBERNETES_SERVICE_PORT_HTTPS确定，proxy会代理到该集群地址的API Server。

2. 禁用默认服务账号挂载，复制本地~/.kube/config到Pod后的情况
   只要Pod能访问到~/.kube/config中配置的集群地址（比如你的本地主机可被Pod访问，且config里的集群地址是主机的可访问IP/域名），kubectl proxy完全可以正常工作。此时kubectl会优先使用~/.kube/config里的凭据和集群配置，不会再尝试读取服务账号挂载路径。

关于你发现的特殊情况说明 #

当~/.kube/config和服务账号挂载都不存在时，kubectl会回退到旧的默认行为：尝试连接localhost:8080。这是因为早期Kubernetes API Server默认监听8080未加密本地端口，该逻辑被保留作为最后的 fallback。

内容的提问来源于stack exchange，提问作者wujek