在 Kubernetes 日常运维中，很多人都是在master节点上使用kubectl命令来操作集群的。但有时想在其他节点执行kubectl时就会出现下面的报错：
这种是很典型的报错，其实就是该节点上的 kubectl 没有加载任何 kubeconfig 配置文件
大部分kubectl 使用问题，本质都源于对它工作原理的不理解。接下来将通过两个真实且高频的案例，彻底讲清楚：
kubectl 到底是如何工作的
为什么“不在集群里”也能操作集群
1 其他 K8S节点上执行失败
1.1 问题现象
在非首个 master 节点上执行：
kubectl get nodes通常会得到下面错误信息：
很多人的第一反应是：
API Server 挂了？
kube-apiserver 没启动？
节点网络不通？
这些判断在这个场景下，全部是错误排错方向的。
1.2 问题本质
先一句话总结一下：
kubectl 只是一个 Kubernetes API 客户端程序，它会根据kubeconfig 配置文件的描述，向 API Server 发送 HTTP(S) 请求
当 kubectl 找不到有效配置时，会退回到一个早已废弃的默认行为，这个逻辑来自 Kubernetes 早期版本（单机、无认证时代）：
http://localhost:8080所以，如果你未配置的情况下就会出现上面的报错
1.3 快速解决
在已能正常使用 kubectl 的 master 节点上执行：
# 在目标节点创建目录 ssh root@k8s-node1 mkdir -p /root/.kube # 复制配置文件过去 scp /root/.kube/config root@k8s-node1:/root/.kube/config # 授权 ssh root@k8s-node1 chmod 600 /root/.kube/config验证：
kubectl get nodes2 在K8S集群外执行 kubectl
这个场景在生产环境中更加常见，也更容易被误解。有些团队往往会将kubectl移动到其他非K8S节点对集群进行管理。
肯定有人有疑问：
“这台机器又不是 Kubernetes 节点，kubectl 肯定不能用”
其实原理跟上面也是一样的
kubectl 只是一个 Kubernetes API 客户端程序。
它的权限只由kubeconfig文件控制，跟是否在集群内，是否运行kubelet，containerd，是否是master节点都没有关系。
只要满足以下条件，kubectl 就一定能工作：
能网络访问 API Server（通常是 6443）
kubeconfig 中的证书 / token 有效
下面将在集群外机器安装kubectl来管理集群。我在Harbor仓库机器安装kubectl
2.1 安装 kubectl
# 下载最新稳定版本： curl -LO https://dl.k8s.io/release/stable.txt curl -LO https://dl.k8s.io/release/$(cat stable.txt)/bin/linux/amd64/kubectl # 配置权限 chmod +x kubectl mv kubectl /usr/local/bin/2.2 拷贝 kubeconfig
从 master 节点拷贝：
# 现在目前创建目录 ssh root@10.0.0.207 mkdir /root/.kube # 复制过去 scp /root/.kube/config root@10.0.0.207:/root/.kube/config # 赋予权限 ssh root@10.0.0.207 chmod 600 /root/.kube/config2.3 验证
在目前节点验证
kubectl get nodes可以看到这台完全不属于 Kubernetes 集群的机器，已经具备完整集群管理能力。
3 kubectl 查找配置的完整逻辑
kubectl 查找 kubeconfig 的顺序如下：
使用
--kubeconfig参数指定查找环境变量
$KUBECONFIG如果前面没找到，就找默认路径
~/.kube/config
如果三者都不存在或无效，kubectl 将：
尝试访问 http://localhost:8080这也是80% kubectl 连接失败问题的根因。
总之，kubectl 是否可用，与是否在集群中无关，kubectl 只认 kubeconfig
还有一个生产环境忠告：不要在多个节点保存kubeconfig，这样会增加安全风险，调试时可以临时用一下，用后删除！
