开始是一个master，两个node节点，后面再扩。
创新互联网站建设服务商，为中小企业提供成都做网站、成都网站制作服务，网站设计，绵阳服务器托管等一站式综合服务型公司，专业打造企业形象网站，让您在众多竞争对手中脱颖而出创新互联。
使用centos7系统，前面文章已经安装过etcd。
wget
tar -zxf kubernetes-server-linux-amd64.tar.gz
cd kubernetes/server/bin/
cp kube-apiserver kubectl kube-controller-manager kube-scheduler /usr/local/bin
scp kubelet kube-proxy FNSHB109:/usr/local/bin
scp kubelet kube-proxy node1:/usr/local/bin
scp kubelet kube-proxy node2:/usr/local/bin
mkdir -p /etc/kubernetes
mkdir -p /etc/kubernetes/ssl
mkdir -p /var/log/kubernetes
一个应用程序访问https API（自签证书），有两种方式，证书添加IP可信任（写在证书的json的host文件里面）和携带CA证书。ca证书在etcd那篇文章里面已经配置过，这里直接配置kube-apiserver-csr.json请求文件，再利用ca证书和私钥，形成kube-apiserver证书。
cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes kube-apiserver-csr.json | cfssljson -bare kube-apiserver
随机生成序列号，并定义token.csv
kubelet 采用 TLS Bootstrapping 机制，自动完成到 kube-apiserver 的注册，在 node 节点量较大或者后期自动扩容时非常有用。
Master apiserver 启用 TLS 认证后，node 节点 kubelet 组件想要加入集群，必须使用CA签发的有效证书才能与 apiserver 通信，当 node 节点很多时，签署证书是一件很繁琐的事情。因此 Kubernetes 引入了 TLS bootstraping 机制来自动颁发客户端证书，kubelet 会以一个低权限用户自动向 apiserver 申请证书，kubelet 的证书由 apiserver 动态签署。
kubelet 首次启动通过加载 bootstrap.kubeconfig 中的用户 Token 和 apiserver CA 证书发起首次 CSR 请求，这个 Token 被预先内置在 apiserver 节点的 token.csv 中，其身份为 kubelet-bootstrap 用户和 system:kubelet-bootstrap 用户组；想要首次 CSR 请求能成功（即不会被 apiserver 401 拒绝），则需要先创建一个 ClusterRoleBinding，将 kubelet-bootstrap 用户和 system:node-bootstrapper 内置 ClusterRole 绑定（通过 kubectl get clusterroles 可查询），使其能够发起 CSR 认证请求。
TLS bootstrapping 时的证书实际是由 kube-controller-manager 组件来签署的，也就是说证书有效期是 kube-controller-manager 组件控制的；kube-controller-manager 组件提供了一个 --experimental-cluster-signing-duration 参数来设置签署的证书有效时间；默认为 8760h0m0s，将其改为 87600h0m0s，即 10 年后再进行 TLS bootstrapping 签署证书即可。
也就是说 kubelet 首次访问 API Server 时，是使用 token 做认证，通过后，Controller Manager 会为 kubelet 生成一个证书，以后的访问都是用证书做认证了。
cd /root/k8sbinary/TLS/k8s
cp /root/k8sbinary/TLS/k8s/token.csv /etc/kubernetes/ssl
cp /root/k8sbinary/TLS/k8s/ca*.pem /etc/kubernetes/ssl
cp /root/k8sbinary/TLS/k8s/kube-api*.pem /etc/kubernetes/ssl
scp ca*.pem node1:/etc/kubernetes/ssl
scp ca*.pem node2:/etc/kubernetes/ssl
scp /root/k8sbinary/TLS/k8s/token.csv node1:/etc/kubernetes/ssl
scp /root/k8sbinary/TLS/k8s/token.csv node1:/etc/kubernetes/ssl
systemctl daemon-reload
systemctl enable kube-apiserver
systemctl start kube-apiserver
systemctl status kube-apiserver
通过kubeadmin安装K8S集群可以做到快速部署，但是如果需要调整K8S各个组件及服务的安全配置，高可用模式，最好通过二进制模式进行K8S的安装
生产环境K8S Master节点最好在3个节点以上，且配置不低于4核16g
生产环境：确保Master高可用，启用安全访问机制
PS：
服务器节点只是起名字，与是否为k8s-master或k8s-node无关，可根据需要增加或删减测试用例的数量，如多台master主机只部署k8s-master组件。多台node主机只部署k8s-node组件
master1 192.168.100.100
node1 192.168.100.101
node2 192.168.100.102
注：本节中创建的证书为部署流程全过程证书，测试用例为openssl生成证书，cfssl生成证书需要参考cfssl生成k8s证书，并在对应配置文件的相关证书位置替换对应证书
在配置文件中需要在[alt_names]设置Master服务的全部域名和IP地址，包括：
参数解析
配置文件详解：
分发配置文件
配置文件详解：
配置详解
分发配置文件
分发配置文件
在三个kube-apiserver的前段部署HAProxy和keepalived，使用VIP（虚拟IP地址）192.168.100.200作为Master的唯一入口地址，供客户端访问
将HAProxy和keepalived均部署为至少有两个实例的高可用架构，以避免单点故障。
接下来在主机master（192.168.100.100）和主机node1（192.168.100.101）中部署
HAProxy负责将客户端请求转发到后端的3个kube-apiserver实例上，keepalived负责维护VIP的高可用
准备 HAProxy 的配置文件 haproxy.cfg
参数说明：
分发配置文件
在master（192.168.100.100）和node1（192.168.100.101）上使用docker部署HAProxy，并将配置文件挂载到容器的/usr/local/etc/haproxy下
访问192.168.100.100:8888/stats，192.168.100.101:8888/stats
keepalived用于维护VIP地址的高可用，同样在master和node1中部署
主节点配置文件
子节点配置文件
参数解析
主节点和子节点配置异同
健康检查脚本
keeplived需要持续监控HAProxy的运行状态，在某个节点运行不正常时转移到另外的节点上去
监控运行状态需要创建健康检查脚本，定期运行监控
脚本内容如下：
分发脚本
在master（192.168.100.100）和node1（192.168.100.101）上使用docker部署keeplived，并将配置文件挂载到容器的/container/service/keepalived/assets下，将脚本挂载到容器的/usr/bin下
检查ens33网卡是否存在keeplived VIP地址
检测keeplived是否进行转发
注：master集群已经配置完毕，后续需要在node中需要部署docker，kubelet，kube-proxy，且在加入k8s集群后，还需要部署CNI网络插件、DNS插件等
之前已经在master，node1，node2中部署了docker，接下来需要部署其他服务组件，本节部署kubelet组件
参数说明
参数说明
参数说明
当前显示所有node为NOT READY，需要部署完网络插件才可使用
为方便使用kubectl
二进制包
注：推荐用二进制包部署Kubernetes集群，虽手动部署麻烦，但可以学习很多工作原理利于后期维护。
环境
可以使用VMware虚拟机，宿主机必须8G内存以上
• 服务器可以访问外网，有从网上拉取镜像的需求
单Master服务器规划：（ 注：部署时候根据具体环境进行IP地址调整即可 ）
这里使用3台组建集群，可容忍1台机器故障，当然，你也可以使用5台组建集群
etcd1： 192.168.3.110 etcd2： 192.168.3.112 etcd3： 192.168.3.113
cfssl是一个开源的证书管理工具，使用json文件生成证书，相比openssl更方便使用。
找任意一台服务器操作，这里用Master节点。
创建工作目录：
自签CA：
生成证书：
会生成ca.pem和ca-key.pem文件。
创建证书申请文件：
注：上述文件hosts字段中IP为所有etcd节点的集群内部通信IP，一个都不能少！为了方便后期扩容可以多写几个预留的IP。
生成证书：
会生成etcd.pem和etcd-key.pem文件。
etcd-v3.5.1-linux-amd64.tar.gz
以下在节点1上操作，然后将文件拷贝到其他集群机器
把刚才生成的证书拷贝到配置文件中的路径：
注意修改节点2和节点3分别etcd.conf配置，按照下面提示的修改
启动各节点的etcd服务
如果输出上面信息，就说明集群部署成功。
如果有问题看日志：/var/log/message
docker二进制下载地址：
注：使用yum安装也行
集群所有机器都安装docker
生成证书：
会生成ca.pem和ca-key.pem文件。
创建证书申请文件：
生成证书：
会生成k8s.pem和k8s-key.pem文件。
下载地址参考：
Wget
把刚才生成的证书拷贝到配置文件中的路径：
TLS Bootstrapping 机制，对work-node加入进行自签证书用
创建上述配置文件中token文件：
token 可以自行生产，百度下怎么生产
kube-apiserver服务
生成kube-controller-manager证书：
生成kubeconfig文件（以下是shell命令，直接在终端执行）：
生成kube-scheduler证书：
生成kubeconfig文件：
生成kubeconfig文件：
通过kubectl工具查看当前集群组件状态：
在所有worker node创建工作目录：
从master节点拷贝：
注：由于网络插件还没有部署，节点会没有准备就绪 NotReady
二进制包下载地址：
确保kubelet启用CNI：
在Master执行：
应用场景：例如kubectl logs
在Master节点将Worker Node涉及文件拷贝到新节点192.168.3.112/113
注：这几个文件是证书申请审批后自动生成的，每个Node不同，必须删除
Node2（192.168.3.113 ）节点同上。记得修改主机名！
访问地址：
创建service account并绑定默认cluster-admin管理员集群角色：
使用输出的token登录Dashboard。
CoreDNS用于集群内部Service名称解析。
DNS解析测试：
这样 单Master集群就搭建完成了