前言：
kubernetes集群通常并不是只有一个集群，特别是对于业务量比较多的公司来说，可能集群的规模会非常大。所有的业务都放到一个kubernetes集群内是不现实的，也不是科学的，就如同你不会把所有数据放到一个MySQL的数据库的一张表里一样，那样会显得很傻很天真。OK，那么现在问题就来了，如果有多达上百个节点的若干kubernetes集群，如何管理？比如，A集群有10个节点，那么，远程登录到A里的一个节点进行管理吗？那么，B集群呢？C集群呢？当然，按用途来说，还有测试用集群，开发用集群，生产用集群等等。无疑的，一个个节点ssh过去是很傻的做法。
OK，可能会有人说，这没什么，我用xshell等工具就可以一个个连接了嘛，很显然，每一个登陆都需要一个节点的操作系统账号权限，对于安全来说无疑是不好的事情（比如，给了一个root账号登陆到A集群的master节点了，啪的一下子，没注意 删掉了系统的某个重要文件，这个时候是不是得懵逼一下，然后准备提桶跑路？）。
那么，有没有更加优雅的方案呢？答案是肯定的，因为kubernetes集群自己就带有RBAC权限管理系统嘛，通过kubeconfig，设置正确的kubernetes权限，在一个机器上就可以管理所有的集群无疑是一件又方便又安全的事情。
概念定义：kubeconfig就是集群的配置文件，此文件可以建立任意的用户，这个集群内的用户通过各种集群内置或者自定义的角色绑定一定的权限，OK，生成这个kuberconfig文件后，将可以在任意一台服务器上进行kubernetes集群的管理，仅仅需要一个kubernetes集群的kubectl客户端即可，这个服务器突然坏掉了？没事，只要有kuberconfig文件就可以了，在找一个有kubectl的服务器使用kubeconfig文件就可以继续管理集群了。那么，kubernetes集群的各个节点的安全性自然提高了很多（都不用登陆节点了嘛，专心的管理集群就完了（干就完了，爱谁谁！！！~~~~~~~~），比如，专心的管理pod，service这些集群资源，岂不美哉？？？）
- 用于配置集群访问信息的文件叫作 kubeconfig 文件，在开启了 TLS 的集群中，每次与集群交互时都需要身份认证，生产环境一般使用证书进行认证，其认证所需要的信息会放在 kubeconfig 文件中。此外，K8s 的组件都可以使用 kubeconfig 连接 apiserver，client-go 、operator、helm 等其他组件也使用 kubeconfig 访问 apiserver。
- 使用kubeconfig文件来组织有关集群、用户、命名空间和身份认证机制的信息。kubectl 命令行根据使用kubeconfig文件来查找选择集群所需的信息，并与集群的API服务进行通信。
- 默认情况下，kubectl 在 $HOME/.kube 目录下查找名为config的文件，可以通过设置KUBECONFIG环境变量或设置--kubeconfig参数来指定其他Kubeconfig文件。
- kubectl是操作k8s的一个客户端工具，只要为kubectl提供链接apiserver的配置(kubeconfig)，kubectl可以在任何地方操作该集群。
- kubectl加载配置文件的顺序：
- 1) kubectl 默认连接本机的 8080 端口
2) 从 $HOME/.kube 目录下查找文件名为 config 的文件
3）通过设置环境变量 KUBECONFIG 或者通过设置去指定其它 kubeconfig 文件
可能有同学问了，哪里有kubeconfig文件？需要手写吗？如何正确的优雅的使用这个所谓的kubeconfig文件？
OK，本文就是专门来讲解这些问题的。
一，kubeconfig文件在哪里？
和安装手法有关系，kubeconfig的生成也是不一定的，但不管如何说，集群部署搭建的时候必定有一个kubeconfig文件，这个文件里包含的用户是拥有最高权限的，否则集群部署完了，没有用户，那可管理不了集群了。
二进制部署方式：
通常在安装kube-apiserver服务后就会初始化一个kubeconfig文件，当然，二进制里这个文件的名称比较随意，都是自定义的，例子可见我的博客：
云原生|kubernetes|kubernetes-1.18 二进制安装教程单master（其它的版本也基本一样）_晚风_END的博客-CSDN博客_二进制安装kubelet
下面是关于kubeconfig文件生成的截图：
kubeadm部署方式（当然也包括集成部署方式，例如minkube，它们的kubeconfig文件都是全自动生成的）：
集成部署方式会贴心的给你省去自己手写kubeconfig的烦恼，自动生成，生成时间一般为初始化集群的时候，也就是说，kubeadm init 命令执行后，此命令的输出日志里会有提示，现只截取提示的那一部分：
Your Kubernetes control-plane has initialized successfully! To start using your cluster, you need to run the following as a regular user: mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config
OK，以上的意思表明 此kubeconfig文件存放在了/etc/kubernetes/目录下，名称一般固定的是admin.conf ，将此文件放入隐藏目录 .kube下并重命名为了config，然后赋予当前用户的权限。因此，不管是哪种方式部署的集群，一般有做上面这一串步骤的话，kubeconfig的存放位置都在 .kube/目录下的config文件。
二，kubeconfig文件内容
以我前面部署的minikube为例，先看看这个文件的内容吧：
[root@node3 mnt]# cat config apiVersion: v1 clusters: - cluster: certificate-authority: /root/.minikube/ca.crt server: https://192.168.217.23:8443 name: minikube contexts: - context: cluster: minikube user: minikube name: minikube current-context: minikube kind: Config preferences: {} users: - name: minikube user: client-certificate: /root/.minikube/profiles/minikube/client.crt client-key: /root/.minikube/profiles/minikube/client.key
OK，此文件表明用户minikube可以通过kubectl和server为192.168.217.23:8443的apiserver通信，这个集群名称为minikube，并且需要三个携带三个证书文件，从而管理集群。那，我不想带证书，太麻烦了，也不想用这个用户，只想在别的服务器上有一个kubectl就可以连接到这个minikube集群，就可以做集群管理了，可以吗？
答案当然是可以的。
这里多说一句，为什么这个kubeconfig和一般见到的其它集群的kubeconfig不太一样，整个都是证书路径呢？只是由于我初始化此集群的时候没有使用--embed-certs=true这个参数罢了。embed-certs 这个参数如果是true的话，那么，生成的kubeconfig将会内嵌证书。这个下面就会讲到。
三，kubeconfig文件可不可以手写？
kubeconfig文件不可手写，手写会出各种各样的问题，反正我是尝试了几个小时，也可能是坐姿不对吧，不建议手写。有命令就可以生成，手写是不是傻，对吧。
OK，上面的kubeconfig文件证书不是内嵌的，现在把它修改成内嵌的，重置集群在添加--embed-certs=true参数不是我的风格嘛（重置了等于认怂了，对吧），然后集群名称也看的不爽，修改掉。用户由于和角色绑定了，我也不知道和哪个角色绑定了就还是原来 的吧。
以下操作在192.168.217.23服务器上执行，方面读取证书的信息。
A，
设置一个变量，此变量下面的命令引用，变量值为要设置的集群的apiserverIP和端口
KUBE_APISERVER="https://192.168.217.23:8443"
kubectl config set-cluster myminikube \ --certificate-authority=/root/.minikube/ca.crt \ --embed-certs=true \ --server=${KUBE_APISERVER} \ --kubeconfig=bootstrap.kubeconfig
- set-cluster myminikube 设置集群名称为myminikube
- --kubeconfig=bootstrap.kubeconfig kubeconfig名称的定义，因为我是登陆专用文件，因此，bootstrap，当然可以任意取名，只要你知道干什么的就行
- --embed-certs=true \ 证书内嵌开启
- --certificate-authority=/root/.minikube/ca.crt \ 集群的ca证书，其实是复制了上面那个文件里写的路径，kubeadm的证书一般存放在/etc/kubernetes/pki目录下--server=${KUBE_APISERVER} \ 集群的apiserver的通信网址，此CA证书里的CN就是将要使用的用户。
- 此命令执行后，会在当前目录下生成名叫bootstrap.kubeconfig的文件
B，
- set-credentials minikube \ 这里minikube也是随意的一写，无所谓，爱谁谁，这个名字是users的名字，一哈看生成的kubeconfig就知道了，无关紧要。
- --client-certificate这个和上面的命令基本一样，只是内嵌的证书是客户端使用的，此证书将会由apiserver这个服务校验是否正确。--client-key也是客户端证书，只是是key而已。
kubectl config set-credentials minikube \ --client-certificate=/root/.minikube/profiles/minikube/client.crt \ --client-key=/root/.minikube/profiles/minikube/client.key \ --embed-certs=true \ --kubeconfig=bootstrap.kubeconfig
C，
- set-context default \ 设置上下文，这个上下文可就关键了，上下文也是有名称的，这里名字叫default，如果kubeconfig文件内定义了多个集群，可全靠这个名称切换集群了，后话，先放这。
- --cluster=myminikube \集群名称要上面定义的，这里不要瞎写了。
- --user="minikube" \ 这里也不要乱写了，要不还需要给用户设置权限，就很麻烦。
kubectl config set-context default \ --cluster=myminikube \ --user="minikube" \ --kubeconfig=bootstrap.kubeconfig
D，
- 这个命令是设置current-context 名称的，current-context 是当前使用的上下文的意思，如果使用此kubeconfig文件的话。对应命令是：kubectl config current-context，可以快速查询现在用的是哪个集群的上下文
kubectl config use-context default --kubeconfig=bootstrap.kubeconfig
OK，此kubeconfig文件就通过这四个命令生成了，可以看看此kubeconfig的内容了：
[root@node3 media]# cat bootstrap.kubeconfig apiVersion: v1 clusters: - cluster: certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM1ekNDQWMrZ0F3SUJBZ0lCQVRBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwdGFXNXAKYTNWaVpVTkJNQjRYRFRJeU1URXdNVEE1TWpnd05Gb1hEVE15TVRBek1EQTVNamd3TkZvd0ZURVRNQkVHQTFVRQpBeE1LYldsdWFXdDFZbVZEUVRDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBSm5qCm5PNm94a1VJNGR1UGlsb3RXd3FpdUp3TDVlcjJGczhqL3lIb2ViNkVDa1ZuTldncHBOZHlCS3N2UytjQjhkOTUKb1Jjd25ZamhsOGZta25YUytRK2gzbmJsY3JKWE1OQytnWkdqRldEVCtqOUwvT3NRd1BjbFE1eWFoNEtFY2kvbApUOWhhdlJCRXFRMzY2ZjhsZDZlSytaOFF5bWV4QlkvRlp6THdZMmtRajZnZU9NZkRoY0JSM3NWYjVweHRBSlByCk8xVWpudkxkRVRLekw1ajZYdXlGLzdsaGZhcE5aSFpIMUs2WjF3R3RTYUF0L0FGZmJDTFcvaDMyRlVkUExKTU0KMkVkVU1PaVVIeXorM3dWNEVONWlOY0FuUk9kYTlCdTBsRjRLbVVzNSt1SkNVc0lReXRvbDBwenpxWWZOWEtUSQpkT2trSGdYdWtSaGIyZ3JuTHg4Q0F3RUFBYU5DTUVBd0RnWURWUjBQQVFIL0JBUURBZ0trTUIwR0ExVWRKUVFXCk1CUUdDQ3NHQVFVRkJ3TUNCZ2dyQmdFRkJRY0RBVEFQQmdOVkhSTUJBZjhFQlRBREFRSC9NQTBHQ1NxR1NJYjMKRFFFQkN3VUFBNElCQVFCOHkzRzBCbEw4TDdPUFpTckJ2RlpNSWJJSEpzRE83cG5WVGkvWW95VWg5TFdndnB1TQpvMDdjOWJKM21YN25OVGFyOU1la1JnZ2hTTHBkTHBjaFlOSEY5bkFzQ3liblI3L05ZZVZlYUFSM2xRaWNETTJBCnAxV2YwYzhJZ0tJUHk0Z0k2MThOQkhtSUlnTEU1Yk1BSkczalFDNXBzcnM1ZXlsUnVrNkdCbEpia280YThJS1cKQm9QWHFtM2M1WGd3c0MvckhxU1lyL2RaYXlOL3dGQmIyRWJIS1gyMXRpZEZKYXhITGZKaUhRM1pjRGl5eHdqTwpSNTA3SzgvbTQrVEJrM012RzlFNUp4S2xiNk43M0NSbGo4ZUtJRm1vanBDRk5EWk5udkNPc3FnZ1YybXhHaEtDCkRLRXZ6SFI0VkhnRnliUHNEb0tOY2NjbERxeTRMelFkK3c4agotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== server: https://192.168.217.23:8443 name: myminikube contexts: - context: cluster: myminikube user: minikube name: default current-context: default kind: Config preferences: {} users: - name: minikube user: client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURBRENDQWVpZ0F3SUJBZ0lCQWpBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwdGFXNXAKYTNWaVpVTkJNQjRYRFRJeU1URXdNakE1TkRVeE4xb1hEVEl6TVRFd016QTVORFV4TjFvd01URVhNQlVHQTFVRQpDaE1PYzNsemRHVnRPbTFoYzNSbGNuTXhGakFVQmdOVkJBTVREVzFwYm1scmRXSmxMWFZ6WlhJd2dnRWlNQTBHCkNTcUdTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUtBb0lCQVFDM21rQThRSE14bk90aDQyZFRoc1cxc2pBeFQrdlAKQVBxeHRSam1ickNabVJOTWZxckVweXNVWWJqOWdHWGtrckhtR0FabmptRmlTVEVieTlOZVcxeGJvbE9BamVsVwp3Wlh5NFRlbTk1anVPV0EvakIzNWhNdC84c0lER2xvQ3d2R1ErZUwvcFZSSkc4bTh3RGJxOU92V2dybnRndllyCkJSMjZ4b3NpSUZONVVKdTBPb0cxNnE3bUNDY1FyblJjREVnejg2QW9rUllGYVJqUWlaUWZrcmYxK3kyWnhRVkQKdFlzUURycytuRk5kWWltcnJwdUl1SFdabXh1aXN2MFI0eWFLa0xkRHBFalkrNzBHYm9OMVF3MWxMS1VhWDdCZQpnYTFENVJWalY3RjJSMGlhTitneDQ1WUFTTUxhUHJ5WHhUakEzRmVjc01KZDZaVFpscnpuQjExNUFnTUJBQUdqClB6QTlNQTRHQTFVZER3RUIvd1FFQXdJRm9EQWRCZ05WSFNVRUZqQVVCZ2dyQmdFRkJRY0RBUVlJS3dZQkJRVUgKQXdJd0RBWURWUjBUQVFIL0JBSXdBREFOQmdrcWhraUc5dzBCQVFzRkFBT0NBUUVBZjF2NklkaWdKTlpHZURkUgo5SzZsd3RtWHdWVEJNZnliZEVlZFcxMjJEZGMwWThDdEw0VEtjOGEyeEJGNnFHQ3M5bDlzdXEwZS9aREJGbVJXCnc0d05tc0pSSm9Xejg0cm9WUGFJUTF1YlpPMmxZOUViaU9SMGZSRVZXYXNTZ1RoaExEOWdVUnpLZjd2bDFRNEgKL3A2M2ExTWJzQlBlMlFHK09GR09pMlFKcWtxTndVcnQ5ZE53RVFKSjFMbUJtQlBzUFFzQ1JoaXR0NCt6OWltagp0MlZVY0M3bVZvOWNMVVFma0pubnJRdjFmeGxDeEo2M2Z6eEVpNEtNYjM4N1ljakhqTXhiUmJDdWoyZ1dvenk0CkRRMzlzN2dqMkE4ZUdqQ2FRdWRzbVlERFB1VGlaTEtWUlZ2Nkczck9xUUdxancwaitPajRtT1BZeDdXZlR5Mm4KdnJoK3V3PT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo= client-key-data: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFcFFJQkFBS0NBUUVBdDVwQVBFQnpNWnpyWWVOblU0YkZ0Ykl3TVUvcnp3RDZzYlVZNW02d21aa1RUSDZxCnhLY3JGR0c0L1lCbDVKS3g1aGdHWjQ1aFlra3hHOHZUWGx0Y1c2SlRnSTNwVnNHVjh1RTNwdmVZN2psZ1A0d2QKK1lUTGYvTENBeHBhQXNMeGtQbmkvNlZVU1J2SnZNQTI2dlRyMW9LNTdZTDJLd1VkdXNhTElpQlRlVkNidERxQgp0ZXF1NWdnbkVLNTBYQXhJTS9PZ0tKRVdCV2tZMEltVUg1SzM5ZnN0bWNVRlE3V0xFQTY3UHB4VFhXSXBxNjZiCmlMaDFtWnNib3JMOUVlTW1pcEMzUTZSSTJQdTlCbTZEZFVNTlpTeWxHbCt3WG9HdFErVVZZMWV4ZGtkSW1qZm8KTWVPV0FFakMyajY4bDhVNHdOeFhuTERDWGVtVTJaYTg1d2RkZVFJREFRQUJBb0lCQVFDRjAwZ0k0czFVRjFXMgpkd09FYlZMRTJrbW9WK0hBYzYxSFJJSU96QldyRDFseXcwMERvL21SbEowN0laQ2paNDJGOG5NUW5rWTdWckFWCjI1NklRejF4aVVNbUM4cE5zekx4NHRrbXVZaGQ4N0pFLzRPRnNSYUhmMUdNNDNOQ1dnZXJyWWlZNEZBc0xiWUEKLzNYSUVwZW9Ob2NCS1JqM1NIWmdBb0c5Y1NTRzRrOGtlam52T2Y5TWRNZ1JTL2NvT2FMdk5qbCt4QjJwb3MxaAp3UFNKamg4bGNTZzhiUjMvMjYxQkpIMWt5RU04dU04cEZtdFp1Q3N3VU1uNFZqMnNVUnVUOWpkaDljYnFmUE1KCmZqN1VnZHhBSkZHRTBKc2VidjVBN3BZY3Q0VWg2NE1yNklmOTdjRDZSdHNOa2oxYTRTdFBwQVQ3SWs0RThiWkIKUnNoMEtKc0JBb0dCQU5DMm5mUXFlZlZHdDBYaXEvVzFPcm9mKy9MM3JXbEZCNjVpYmxQZUh2alhHRFhGZ083NgpqR2hxS2E0RWFCS1VBdER6YmZrYzlXa1FSSFhqUkxxZVhML2Fhb1FHMjJJMVZ5Z09ZdkxTSStGdmJrb0paMExsCmZpYmRmZFRaVXc1d0hsajJYRkMzVzMrMHNiUXlSQVlFaW1DeGJvU0tCNHZ5OGFhUlFsODJhOU5aQW9HQkFPRXoKTk1iUXNsaEJYVjBTVUVrTWRKbWlFYlVWdzNnemhORnAxVnNSNnlUakxIR0NvNllQZk02RzNlVDFHdndWTFZCOQpHY2lvVlZPbVF3UDBoRjJzTVl6NUtidytGTEM1bXZXZnEvVGNDQzZ3RGt0VGFZUW0vZVRzdFkzVkNDQmNZOTZ4Ck9EeEU3UFplN1RydVU3WnA2SUFCYWNKSzYyYjhleG1DWVI5RVlUY2hBb0dBTGVkY1NpMWxjV3JDT0Y2b1Qzd3kKbEdrZ2NzbkNuQnFRbSt3T00rZndpKzVTNXRDdmtPQU9MWkRiNWVnV002L1dCcnJqZnh5OVpRUXM2bmkzend1eApmb2k5VUpocGUrb2Jaelh5MFZFaWp4eUE5MHVtS0hKdEVvTTRmNjNrdEpJNE9uekV4UVB1M2VHU0MvM2FORENmCmRyRFBpOXNIMmVIdkFDR0dwWVpFcE5FQ2dZRUFscDNnMW5nT1QraW53Ty9Xc29TYUY0YkZ3UTlsUktkd1ZYOHIKSzFXNHAxc3BCbUlSZ2FjcUdoY3BvVkF0VkJ2MXlyZGczMHQyaGhQVkRuZ2piMk1UWU8za2Mvb3hiR0UydXNDbwpDWVNBRkhtN2xiV2NCTDd2WUlUUWlLUEtZNXBuVVRIR0lza1drMUM1Nllnc2hQd2dmRHgxdDNUVUxIVUEvL2FyCmJuWVZid0VDZ1lFQXFmL2JLYk5PTXFobHBhM1RrSDBZM1luM05jRGhoTHlpV2diRkM4YjN6TW45THdjdTZ5SE4Kb2Z5ekV6Y0hFbDFBZE1OSzMwMFpkaVNCYll2RldBblRaL2JIUXRydTJ4OXpoZ051VjhOL1BaUjVTNVh6TVhxTApCTUJZZmZRck1xV3FqZDdxVEQ1Y1VkMFE4MEV0cnQ3L05GcTFxcXN1SDdRNFgwdkR3Sk16dFM4PQotLS0tLUVORCBSU0EgUFJJVkFURSBLRVktLS0tLQo=
可以看到client-certificate变成了client-certificate-data，其它两个证书也是一样的，多了个-data，集群名称也变了，是myminikube，ok，现在就使用它试试。
特别提醒注意：
两个必须是一致的，是一对的，比如，现在都是default，那么， 同时修改为zsk也是可以的。
和
也是一对的，必须一致，比如，现在的这个minikube同时修改为john也是可以的。
它实际使用的用户应该是生成CA证书的那个json文件里的CN值，和这个kubeconfig里设置的用户名称毛的关系都没有。
