二进制Metrics&Dashboard安装
二进制高可用集群可用性验证
生产环境k8s集群关键性配置
Bootstrapping: Kubelet启动过程
Bootstrapping: CSR申请和证书颁发原理
Bootstrapping: 证书自动续期原理
安装CoreDNS
安装Metrics Server
安装dashboard
安装对应版本（推荐）
如果更改了k8s service的网段需要将coredns的serviceIP改成k8s service网段的第十个IP
安装coredns
安装最新版CoreDNS（不推荐）
查看状态
状态
强制删除一直处于Terminating的pod
在新版的Kubernetes中系统资源的采集均使用Metrics-server，可以通过Metrics采集节点和Pod的内存、磁盘、CPU和网络的使用率。
安装metrics server
等待metrics server启动然后查看状态
节点状态
查看pod状态
pod状态
安装指定版本dashboard
安装最新版dashboard
登录dashboard
Dashboard用于展示集群中的各类资源，同时也可以通过Dashboard实时查看Pod的日志和在容器中执行一些命令等。
官方GitHub地址：https://github.com/kubernetes/dashboard
可以在官方dashboard查看到最新版dashboard
创建管理员用户
执行
在谷歌浏览器（Chrome）启动文件中加入启动参数，用于解决无法访问Dashboard的问题，因为使用的证书是自签名（属性->快捷方式->目标，粘贴到最后）
更改dashboard的svc为NodePort：
修改 type: ClusterIP 为 type:NodePort
修改完成之后会暴露一个端口号，查看端口号：
端口号
根据自己的实例端口号，通过任意安装了kube-proxy的宿主机或者VIP的IP+端口即可访问到dashboard：访问Dashboard：https://192.168.232.236:31874（请更改18282为自己的端口），选择登录方式为令牌（即token方式）
查看token值：
token值
安装busybox
Pod必须能解析Service
Pod必须能解析跨namespace的Service
每个节点都必须要能访问Kubernetes的kubernetes svc 443和kube-dns的service 53
Pod和Pod之前要能通（同namespace能通信、跨namespace能通信、跨机器能通信）
集群安装成功后默认的kubernetes server
每个节点都必须要能访问Kubernetes的kubernetes svc 443和kube-dns的service 53（发送键输入到所有的会话）
Pod和Pod之前要能通（同namespace能通信、跨namespace能通信、跨机器能通信）（取消发送键输入到所有的会话）
创建一个带有三个副本的deployment
docker配置
controller-manager配置
kubelet配置
kubelet-conf.yml
安装总结
（发送键输入到所有的会话）
更新配置
注释新版本已经默认配置，设置证书过期时间
（发送键输入到所有的会话，取消node节点）
k8s默认加密方式会被识别为漏洞，需要修改加密方式
kubelet下载镜像的deadline，避免重复循环加载
查看日志
验证
kubeadm
二进制
自动化安装
安装需要注意的细节
Master节点安装不需要写自动化。
添加Node节点，playbook。
上面的细节配置
生产环境中etcd一定要和系统盘分开，一定要用ssd硬盘。
Docker数据盘也要和系统盘分开，有条件的话可以使用ssd硬盘
Bootstrapping：自动为node节点颁发证书
二进制高可用安装生成证书的时候，我们为每个k8s组件都生成了一个kubeconfig文件，比如controller-manager.kubeconfig，配置中保存了apiserver的一些信息，以及它去连接apiserver的证书
kube-controller-manager.service指定了kubeconfig，组件启动的时候会通过config文件去连接apiserver进行认证，通讯
kube-controller-manager.service和kube-scheduler.service是我们自己颁发证书，但是kubelet不建议通过这种方式，建议使用TLS BootStrapping，它会自动地为node节点的kubelet颁发证书，那么它是如何生成的呢？
使用node02节点举例
当我们配置一个节点的时候，节点上面是没有kubelet.kubeconfig文件的，它是通过bootstrap-kubelet.kubeconfig与apiserver进行交互，然后自动申请了一个kubelet.kubeconfig文件，kubelet启动的时候如果缺少kubelet.kubeconfig文件，就会这样申请
删除kubelet.kubeconfig
查看kubelet配置文件
在配置中可以看到指定了bootstrap-kubeconfig文件
指定了kubeconfig文件，但是这个文件是没有的，kubelet启动的时候会通过前面描述的方式申请一个新的kubelet.kubeconfig
重启kubelet，可以看到生成了kubelet.kubeconfig证书，生成之后就可以和apiserver进行交互
TLS BootStrapping 官方文档：https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#initialization-process
在一个k8s集群中，工作节点的组件kubelet和kube-proxy需要连接master节点的组件，尤其是apiserver。为了确保连接是私有的，强烈建议为每一个客户端配置一个TLS证书在所有的节点上
kubelet启动过程
查找kubeconfig文件，文件一般位于/etc/kubernetes/kubelet.kubeconfig
从kubeconfig文件中检索APIServer的URL和证书
然后去和APIServer进行交互
查看证书
查看kubelet.kubeconfig证书有效期：
然后使用OpenSSL即可查看证书过期时间（100年有效期）：
官方文档：https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#bootstrap-initialization
1、 Kubelet启动
2、 Kubelet查看kubelet.kubeconfig文件，假设没有这个文件
3、 Kubelet会查看本地的bootstrap.kubeconfig
4、 Kubelet读取bootstrap.kubeconfig文件，检索apiserver的url和一个token
5、 Kubelet链接apiserver，使用这个token进行认证
a) Apiserver会识别tokenid，apiserver会查看该tokenid对于的bootstrap的一个secret
secret就是二进制高可用安装集群的时候创建的bootstrap.secret.yaml
如果要修改bootstrap.secret.yaml的token-id和token-secret，需要保证 c8ad9c 字符串一致的，并且位数是一样的。还要保证上个命令的黄色字体：c8ad9c.2e4d610cf3e7426e与你修改的字符串要一致
根据后缀c8ad9c找到token
读取secret中的内容，得到token-id，token-secret
解密token-id，与配置文件kubectl config中的token=c8ad9c.2e4d610cf3e7426e的前缀一致
解密token-secret，与配置文件kubectl config中的token=c8ad9c.2e4d610cf3e7426e的后缀一致
验证通过之后才会进入下一步
b) 找个这个secret中的一个字段auth-extra-groups，apiserver把这个token识别成一个username，名称是system:bootstrap:，属于system:bootstrappers这个组，这个组具有申请csr的权限，该组的权限绑定在一个叫system:node-bootstrapper的clusterrole
解密auth-extra-groups查询组名
clusterrole是k8s集群级别的权限控制，它作用整个k8s集群
clusterrolebinding是集群权限的绑定，它可以帮某个clusterrole绑定到一个用户、组或者seviceaccount
查看clusterrole
查看system:node-bootstrapper
查看clusterrolebinding
可以看到clusterrolebinding把一个名为system:node-bootstrapper的ClusterRole绑定到一个名为system:bootstrappers:default-node-token的Group
查看Group是否一致，解密auth-extra-groups查询组名
c) CSR：相当于一个申请表，可以拿着这个申请表去申请我们的证书。
6、 经过上面的认证，kubelet就有了一个创建和检索CSR的权限
7、 Kubelet为自己创建一个CSR，名称为kubernetes.io/kube-apiserver-client-kubelet
8、 CSR被允许有两种方式：
a) K8s管理员使用kubectl手动的颁发证书
b) 如果配置了相关权限，kube-controller-manager会自动同意。
i. Controller-manager有一个CSRApprovingController。他会校验kubelet发来的csr的username和group是否有创建csr的权限，而且还要验证签发着是否是kubernetes.io/kube-apiserver-client-kubelet
ii. Controller-manager同意CSR请求
9、 CSR被同意后，controller-manager创建kubelet的证书文件
10、 Controller-manager将证书更新至csr的status字段
11、 Kubelet从apiserver获取证书
12、 Kubelet从获取到的key和证书文件创建kubelet.kubeconfig
13、 Kubelet启动完成并正常工作
14、 可选：如果配置了自动续期，kubelet会在证书文件过期的时候利用之前的kubeconfig文件去申请一个新的证书，相当于续约。
15、 新的证书被同意或签发，取决于我们的配置
查看node-autoapprove-certificate-rotation
查看名为system:certificates.k8s.io:certificatesigningrequests:selfnodeclient的ClusterRole
a) Kubelet创建的CSR是属于一个组织：system:nodes
b) CN（比如域名）：system:nodes:主机名
http://www.kubeasy.com/
本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。
欢迎转载、使用、重新发布，但务必保留文章署名 郑子铭 （包含链接： http://www.cnblogs.com/MingsonZheng/ ），不得用于商业目的，基于本文修改后的作品务必以相同的许可发布。