Kubernetes 集群 之 二进制安装部署（单Master节点）
目录
- 前言
- 一、常见的K8S按照部署方式
- 二、安装部署分析
- 三、首先部署ETCD集群
-
- 3.1 ETCD 介绍
- 3.2 准备 CFSSL 证书签发环境
- 3.3 环境部署
-
- 3.3.1 搭建 ETCD 步骤
- 3.3.2 下载准备 CFSSL 证书制作工具
- 3.3.3 上传 etcd-cert.sh 和 etcd.sh 到 /opt/k8s/ 目录中
- 3.3.4 安装 ETCD 服务
- 3.3.5 配置 ETCD 集群
- 3.3.6 在Master01 节点上操作验证etcd集群状态
- 四、在所有 Node 节点上部署 Docker 引擎
- 五、Flannel 网络配置
-
- 5.1 不同 Node 上 Pod 之间的通信？
- 5.2 通信方式之：Overlay Network 与 VXLAN
- 5.3 Flannel 介绍
- 5.4 Flannel 的工作流程
- 5.5 ETCD 之 Flannel 提供说明
- 5.6 Flannel 配置
-
- 配置步骤
- 5.6.1 在 Master01 节点上添加网络配置信息
- 5.6.2 准备 flannel.sh 和 flannel 压缩包，解压flannel压缩包
- 5.6.3 编写 Flannel 启动脚本、执行脚本 启动 Flannel 服务
- 5.6.4 查看 flannel 网卡
- 5.6.5 配置 docker 连接 Flannel，重启 docker 服务
- 5.6.6 验证 Flannel
- 六、部署 单Master 节点
-
- 6.1 搭建步骤
- 6.2 解压 Master 软件包，创建工作目录
- 6.3 创建证书目录，执行脚本生成CA 和 私钥证书
- 6.4 解压 kubernetes 压缩包
- 6.5 创建 bootstrap token 认证文件
- 6.6 启动 Apiserver 服务
- 6.8 启动 Scheduler 服务`cd /opt/k8s/
- 6.9 启动 Controller-manager 服务
- 6.10 查看Master节点状态
- 七、部署 Node 节点
-
- 7.1 搭建步骤
- 7.2 先在 Master01 节点上操作
- 7.3 在 Node01 节点上操作
- 7.4 Master01上 生成 kubelet 的配置文件，对 kubelet进行 RBAC 授权
-
- 创建用于生成 kubelet 的配置文件的目录，生成kubelet的配置文件
- 把配置文件 `bootstrap.kubeconfig`、`kube-proxy.kubeconfig` 拷贝到 Node 节点
- kubelet 组件加入集群时，进行 RBAC 授权
- 7.5 在 Node01 节点上 启动 kubelet 服务
- 7.6 Master01上
- 7.7 在 Node01 节点上 加载 ip_vs 模块，启动proxy服务
- 7.8 Node02 节点部署
- 八、测试Kubernetes 单节点集群
- 九、K8S 通信方式
- 十、命令
前言
一、常见的K8S按照部署方式
Minikube
- Minikube是一个工具，可以在本地快速运行一个单节点微型K8s，仅用于学习、 预览K8S的一些特性使用，没有商业价值。
- 部署地址: https://kubernetes.io/docs/setup/minikube
Kubeadmin
- Kubeadmin也是一个工具，提供 yum安装 kubeadm init 和 kubeadm join，用于快速部署K8s集群，相对简单。
- 部署地址: https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/
- 缺点：证书只有一年，修改证书有效期为 100 年（默认为 1 年）
vim ./cmd/kubeadm/app/constants/constants.go，CertificateValidity =24.365.100修改后需要重新编译和安装服务。
二进制安装部署
- 大型企业生产首选，从官方下载发行版的二进制包，手动部署每个组件 和 自签TLS证书，组成K8S集群，新手推荐。
- 有 zip 和 tar.gz 两个系统的包
- https://github.com/kubernetes/kubernetes/releases
Rancher
- https://rancher.com/docs/rancher/v1.6/zh/
二、安装部署分析
先搭建单Master 集群（企业都是多Master 节点高可用，暂时部署一台）
Master 节点
| k8s集群master01 | 192.168.10.40 | kube-apiserver、kube-controller-manage、kube-scheduler、etcd |
| k8s集群master02 | 192.168.10.70 |
Worker Node 节点
| k8s集群node01 | 192.168.10.50 | kubelet、kube-proxy、docker、flannel |
| k8s集群node02 | 192.168.10.60 |
ETCD（实验为了节省机器，和Master Node 节点共用机器）
| etcd集群节点1 | 192.168.10.40 |
| etcd集群节点2 | 192.168.10.50 |
| etcd集群节点3 | 192.168.10.60 |
web服务负载均衡
| 负载均衡 nginx+keepalive01 (master) | 192.168.10.111 |
| 负载均衡 nginx+keepalive02 (backup) | 192.168.10.101 |
先所有机器关闭防火墙
systemctl stop firewalld
systemctl disable firewalld
setenforce 0
修改所有主机的主机名（方便部署）
hostnamectl set-hostname master01 10.40
hostnamectl set-hostname node01 10.50
hostnamectl set-hostname node02 10.60
ETCD 集群介绍：
- 使用三台 ETCD集群 实现高可用，可以容忍一台机器故障，如果使用5台，容忍2台机器故障，即容忍半数以上ETCD机器存活。
- ETCD集群也可以放在 Master 或 Node 节点的机器上，也可以独立部署在独立机器上。
- 注意点：ApiServer 和 ETCD 之间的通信需要CA证书进行加密；ETCD 与 ETCD 之间通信也需要通过证书加密，
Kubernetes 单 Master 集群 架构图如下：
暂时没有node3
三、首先部署ETCD集群
3.1 ETCD 介绍
- ETCD 是Coreos团队于2013年6月发起的开源项目，它的目标是构建一个高可用的分布式键值（key-value）数据库。
- ETCD 内部采用raft协议作为一致性算法，ETCD 是 GO 语言编写的。
- ETCD 作为服务发现系统，有以下的特点:
- 简单：安装配置简单，而且提供了HTTP API进行交互，使用也很简单
- 安全：支持SSL证书验证（需要创建签发证书）
- 快速：单实例支持每秒2k+读操作
- 可靠：采用raft算法，实现分布式系统数据的可用性和一致性
ETCD 端口：
- ETCD 目前默认使用 2379 端口 提供 HTTP API服务，
- 2380 端口 和 peer通信（这两个端口已经被IANA(互联网数字分配机构)官方预留给ETCD ）。
- 即 ETCD 默认使用 2379 端口对外为客户端提供通讯，使用端口 2380 来进行服务器间内部通讯。
ETCD 在生产环境中一般推荐集群方式部署。由于ETCD 的 Leader选举机制，要求至少为3台或以上的奇数台。
3.2 准备 CFSSL 证书签发环境
ETCD 通过CFSSL 生成证书。
CFSSL 是 CloudFlare 公司开源的一款 PKI/TLS 工具。CFSSI 包含一个命令行工具和一个用于签名、验证和捆绑TLS 证书的 HTTP API 服务。使用Go语言编写。
CFSSL 使用配置文件生成证书，因此自签之前，需要生成它识别的 .JSON 格式的配置文件，CFSSL 提供了方便的命令行生成配置文件。
CFSSL 用来为 ETCD 提供 TLS 证书，它支持签三种类型的证书：
- client 证书，服务端连接客户端时携带的证书，用于客户端验证服务端身份，如 kube-apiserver 访问 ETCD;
- server 证书，客户端连接服务端时携带的证书，用于服务端验证客户端身份，如 ETCD对外提供服务;
- peer 证书，相互之间连接时使用的证书，如 ETCD节点之间 进行验证和通信。
这里全部都使用同一套证书认证。
3.3 环境部署
3.3.1 搭建 ETCD 步骤
环境准备：
| etcd集群节点 node01 | 192.168.10.40 |
| etcd集群节点 node02 | 192.168.10.50 |
| etcd集群节点 node03 | 192.168.10.60 |
- 需要准备 CFSSL 证书生成工具，用它来生成证书；
- 准备 ETCD 二进制软件包；
- 生成 ETCD 的配置文件和服务管理文件；
- 启动 ETCD 服务；
- 把经过上面一到四步骤在etcd01生成的配置文件、可执行文件、认证证书、etcd 服务管理文件，都复制到 etcd02，etcd03 节点上，分别在两台上修改配置文件中的节点名称与节点IP地址；
- 分别启动etcd，加入到 ETCD 集群中；
- 验证 ETCD 集群状态
主体架构：
- 三台 ETCD集群 实现高可用，容忍一台机器故障，即容忍半数以上ETCD机器存活。
- ETCD集群也可以放在 Master 或 Node 节点的机器上，也可以独立部署在独立机器上。这里为了节约机器 部署在Mster 和 Node机器上
3.3.2 下载准备 CFSSL 证书制作工具
Linux 中下载命令用 wget 和 curl -L 重定向
wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 -o /usr/local/bin/cfssl
wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 -o /usr/local/bin/cfssljson
wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 -0 /usr/local/bin/cfssl-certinfo
或
curl -L https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 -o /usr/local/bin/cfss
curl -L https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 -o /usr/local/bin/cfssljson
curl -L https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 -o /usr/local/bin/cfssl-certinfo
下载CFSSL 证书工具后，放到 /usr/local/bin/ 目录中，为了全局能执行cfssl命令，赋予可执行权限
chmod +x /usr/local/bin/cfssl*
文件介绍：
- cfssl：证书签发的工具命令
- cfssljson：将cfssl 生成的证书（json格式）变为文件承载式证书cfssl-certinfo:验证证书的信息
- cfssl-certinfo：-cert<证书名称> #查看证书的信息
创建 k8s 工作目录
mkdir /opt/k8s
cd/opt/k8s/
3.3.3 上传 etcd-cert.sh 和 etcd.sh 到 /opt/k8s/ 目录中
chmod +x etcd-cert.sh etcd.sh
#创建用于生成CA证书、etcd服务器证书 以及 私钥的目录
mkdir /opt/k8s/etcd-cert
mv etcd-cert.sh etcd-cert/
cd /opt/k8s/etcd-cert/
./etcd-cert.sh
#执行etcd-cert.sh脚本文件生成CA证书、etcd服务器证书以及私钥
etcd-cert.sh 用来定义签发根证书的信息，包括证书期限，JSON 格式。
特别说明： cfssl 和 openssl 有一些区别，openssl需要先生成私钥，然后用私钥生成请求文件，最后生成签名的证书和私钥等；而cfssl可以直接得到请求文件，不需要先生成私钥。
server.pem 证书用于客户端服务端通信的认证
ca.pem 证书用于验证是否合法
3.3.4 安装 ETCD 服务
#上传 etcd-v3.3.10-linux-amd64.tar.gz 到/opt/k8s/目录中，解压etcd 压缩包
cd/opt/k8s/
tar zxvf etcd-v3.3.10-linux-amd64.tar.gz
ls etcd-v3.3.10-linux-amd64
etcd：就是etcd 服务的启动命令，后面可跟各种启动参数
etcdctl：主要为etcd 服务提供了命令行操作
创建用于存放etcd 配置文件，命令文件，证书的目录
mkdir -p /opt/etcd/{cfg,bin,ssl}
mv /opt/k8s/etcd-v3.3.10-linux-amd64/etcd /opt/k8s/etcd-v3.3.10-linux-amd64/etcdctl /opt/etcd/bin/
cp /opt/k8s/etcd-cert/ *.pem /opt/etcd/ssl/ #所有的pem证书移过去
创建启动脚本 etcd.sh
./etcd.sh etcd01 192.168.10.40 etcd02=https://192.168.10.50:2380,etcd03=https://192.168.10.60:2380
#会发现卡住了，是因为在等待其他节点加入，
#这里需要三台etcd服务同时启动，如果只启动其中一台后，服务会卡在那里，直到集群中所有etcd节点都已启动，可忽略这个情况
#另外打开一个窗口查看etcd进程是否正常
ps -ef | grep etcd
新开窗口发现服务已启动
etcd.sh 脚本内容如下
#!/bin/bash
# example: ./etcd.sh etcd01 192.168.10.40 etcd02=https://192.168.10.50:2380,etcd03=https://192.168.10.60:2380
#创建etcd配置文件/opt/etcd/cfg/etcd
ETCD_NAME=$1
ETCD_IP=$2
ETCD_CLUSTER=$3
WORK_DIR=/opt/etcd
cat > $WORK_DIR/cfg/etcd <<EOF
#[Member]
ETCD_NAME="${ETCD_NAME}"
ETCD_DATA_DIR="/var/lib/etcd/default.etcd"
ETCD_LISTEN_PEER_URLS="https://${ETCD_IP}:2380"
ETCD_LISTEN_CLIENT_URLS="https://${ETCD_IP}:2379"
#[Clustering]
ETCD_INITIAL_ADVERTISE_PEER_URLS="https://${ETCD_IP}:2380"
ETCD_ADVERTISE_CLIENT_URLS="https://${ETCD_IP}:2379"
ETCD_INITIAL_CLUSTER="etcd01=https://${ETCD_IP}:2380,${ETCD_CLUSTER}"
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster"
ETCD_INITIAL_CLUSTER_STATE="new"
EOF
#Member:成员配置
#ETCD_NAME：节点名称，集群中唯一。成员名字，集群中必须具备唯一性，如etcd01
#ETCD_DATA_DIR：数据目录。指定节点的数据存储目录，这些数据包括节点ID，集群ID，集群初始化配置，Snapshot文件，若未指定-wal-dir，还会存储WAL文件；如果不指
定会用缺省目录
cat <<EOF >/usr/lib/systemd/system/etcd.service #定义ectd的启动脚本
[Unit] #基本项
Description=Etcd Server #类似为 etcd 服务
After=network.target #vu癌症
After=network-online.target
Wants=network-online.target
[Service] #服务项
Type=notify
EnvironmentFile=${WORK_DIR}/cfg/etcd #etcd文件位置
ExecStart=${WORK_DIR}/bin/etcd \ #准启动状态及以下的参数
--name=\${ETCD_NAME} \
--data-dir=\${ETCD_DATA_DIR} \
--listen-peer-urls=\${ETCD_LISTEN_PEER_URLS} \
--listen-client-urls=\${ETCD_LISTEN_CLIENT_URLS},http://127.0.0.1:2379 \
--advertise-client-urls=\${ETCD_ADVERTISE_CLIENT_URLS} \ #以下为群集内部的设定
--initial-advertise-peer-urls=\${ETCD_INITIAL_ADVERTISE_PEER_URLS} \
--initial-cluster=\${ETCD_INITIAL_CLUSTER} \
--initial-cluster-token=\${ETCD_INITIAL_CLUSTER_TOKEN} \ #群集内部通信，也是使用的令牌，为了保证安全（防范中间人窃取）
--initial-cluster-state=new \
--cert-file=${WORK_DIR}/ssl/server.pem \ #证书相关参数
--key-file=${WORK_DIR}/ssl/server-key.pem \
--peer-cert-file=${WORK_DIR}/ssl/server.pem \
--peer-key-file=${WORK_DIR}/ssl/server-key.pem \
--trusted-ca-file=${WORK_DIR}/ssl/ca.pem \
--peer-trusted-ca-file=${WORK_DIR}/ssl/ca.pem
Restart=on-failure
LimitNOFILE=65536 #开放最多的端口号
[Install]
WantedBy=multi-user.target
EOF
#--listen-client-urls：用于指定etcd和客户端的连接端口
#--advertise-client-urls：用于指定etcd服务器之间通讯的端口，etcd有要求，如果--listen-client-urls被设置了，那么就必须同时设置--advertise-client-urls，所
以即使设置和默认相同，也必须显式设置
#--peer开头的配置项用于指定集群内部TLS相关证书（peer 证书），这里全部都使用同一套证书认证
#不带--peer开头的的参数是指定 etcd 服务器TLS相关证书（server 证书），这里全部都使用同一套证书认证
systemctl daemon-reload
systemctl enable etcd
systemctl restart etcd
3.3.5 配置 ETCD 集群
把 etcd 相关证书文件 和 命令文件全部拷贝到另外两个etcd集群节点，生成证书的文件都一样，所以证书是通用的。
#在192.168.10.40机器上 复制所有etcd文件
scp -r /opt/etcd/ root@192.168.10.50:/opt/
scp -r /opt/etcd/ root@192.168.10.60:/opt/
#复制etcd 启动服务
scp etcd.service root@192.168.10.50:/usr/lib/systemd/system/
scp etcd.service root@192.168.10.60:/usr/lib/systemd/system/
node02 node03 分别执行 vim /opt/etcd/cfg/etcd
#以 192.168.10.60 node03为例
#[Member]
ETCD_NAME="etcd03"
ETCD_DATA_DIR="/var/lib/etcd/default.etcd"
ETCD_LISTEN_PEER_URLS="https://192.168.10.60:2380"
ETCD_LISTEN_CLIENT_URLS="https://192.168.10.60:2379"
#[Clustering]
ETCD_INITIAL_ADVERTISE_PEER_URLS="https://192.168.10.60:2380"
ETCD_ADVERTISE_CLIENT_URLS="https://192.168.10.60:2379"
ETCD_INITIAL_CLUSTER="etcd01=https://192.168.10.40:2380,etcd02=https://192.168.10.50:2380,etcd03=https://192.168.10.60:2380"
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster"
ETCD_INITIAL_CLUSTER_STATE="new"
3.3.6 在Master01 节点上操作验证etcd集群状态
先将 master01 192.168.10.40 etcd 的 etcdctl 服务添加到环境变量中。
cd /opt/etcd/bin/
ln -s /opt/etcd/bin/etcdctl /usr/local/bin/
#一定要在/opt/etcd/ssl/ 目录下执行，因为--cert-file执行了认证文件了
#用外部端口2379
cd /opt/etcd/ssl/
etcdctl --ca-file=ca.pem --cert-file=server.pem --key-file=server-key.pem --endpoints="https://192.168.10.40:2379,https://192.168.10.50:2379,https://192.168.10.60:2379" cluster-health
-------------------
--cert-file:识别HTTPS端使用SSL证书文件
--key-file:使用此SSL密钥文件标识HTTPS客户端
--ca-file:使用此CA证书验证启用https的服务器的证书
--endpoints:集群中以逗号分隔的机器地址列表
cluster-health:检查etcd集群的运行状况
----------------------
#切换到etcd3版本查看集群节点状态和成员列表
#v2和v3命令略有不同，etcd2和etcd3也是不兼容的，默认是v2版本
export ETCDCTL_API=3
etcdctl --write-out=table endpoint status
etcdctl --write-out=table member list
export ETCDCTL_API=2
#再切回v2版本, 就是用V3的功能看一下
集群中的列表都已经启动了，ETCD 集群搭建完成。
四、在所有 Node 节点上部署 Docker 引擎
在 192.168.10.50 、192.168.10.60 上安装 Docker
使用 yum 在线源 进行安装
#docker 安装详解：https://blog.csdn.net/duanbaoke/article/details/119022848?spm=1001.2014.3001.5501
#安装依赖包
yum install -y yum-utils device-mapper-persistent-data lvm2
yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
yum install -y docker-ce ##这里我只安装docker-ce了
systemctl start docker
systemctl status docker
五、Flannel 网络配置
5.1 不同 Node 上 Pod 之间的通信？
K8S 中Pod 网络通信种类：
-
Pod内容器与容器之间的通信
在同一个 Pod 内的容器（Pod 内的容器是不会跨宿主机的）共享同一个网络命令空间，相当于它们在同一台机器上一样，可以用 localhost 地址访问彼此的端口。 -
同一个Node内 Pod之间的通信
每个Pod 都有一个真实的全局IP地址，同一个 Node内的不同Pod之间可以直接采用对方 Pod 的IP 地址进行通信，Pod1 与 Pod2 都是通过 Veth 连接到同一个docker0 网桥，网段相同（172.17.0.0 网段），所以它们之间可以直接通信。 -
不同 Node 上 Pod 之间的通信
Pod 地址与 docker0 在同一网段，docker0 网段与宿主机网卡是两个不同的网段，且不同 Node 之间的通信只能通过宿主机的物理网卡进行。 docker0 是所有 pod 对外通信的端口。
所以：
- 要想实现不同 Node 上Pod 之间的通信，就必须想办法通过主机的物理网卡IP地址进行寻址和通信。
- 因此要满足两个条件：
- Pod 的 IP不能冲突;
- 将 Pod 的 IP 和所在的 Node 的 IP 关联起来，通过这个关联让不同 Node 上 Pod 之间直接通过内网IP地址通信。
5.2 通信方式之：Overlay Network 与 VXLAN
Overlay Network:
- 叠加网络，在二层或者三层基础网络上叠加的一种虚拟网络技术模式，该网络中的主机通过虚拟链路隧道连接起来（类似于VPN)。
VXLAN:
- 将源数据包封装到 UDP中，并使用基础网络的 IP/MAC 作为外层报文头进行封装，然后在以太网上传输，到达目的地后由隧道端点解封装并将数据发送给目标地址。
- 性能比UDP好，默认模式是UDP
K8S三种网络：
- 节点网络
- POD网络
- Server网络
k8s 的网络模型思考：
- 从 k8s 的网络模型我们可以看出来，在 k8s 当中希望做到的是每一个 Pod 都有一个在集群当中独一无二的IP，并且可以通过这个IP直接跟集群当中的其他 Pod 以及节点自身的网络进行通信。
- 一句话概括就是 k8s 当中希望网络是扁平化的。
- 所以只要再符合 k8s 网络模型的要求，就可以以插件的方式在 k8s 集群中作为跨节点网络通信实现。
- 目前比较流行的实现有 Flannel, calico, weave, canal 等。
5.3 Flannel 介绍
Flannel 学习链接
https://www.cnblogs.com/goldsunshine/p/10740928.html
https://www.cnblogs.com/k8s/p/12066624.html
- Flannel是 CoreOS 团队针对 Kubernetes 设计的一个网络规划服务，简单来说，它的功能是：让集群中的不同Node节点主机创建的 Docker容器都具有全集群唯一的虚拟IP地址。
- 即Flannel是一个插件，实现不同 Node 上 Pod 之间的通信。
- Flannel 转发的时候会去 ETCD 的存储路由条目中去查找地址；
5.4 Flannel 的工作流程
功能： Flannel 可以让每一个 Pod 都有一个在集群当中独一无二的IP，可以通过这个IP 实现不同 Node 上 Pod 之间的通信。
工作流程：
- 在Pod 之间进行通信的时候
- Flannel 会把内部的pod数据包封装到 UDP 当中，这个UDP 中会包含源地址（自己 Pod 的地址）和目标 Pod IP 地址，Flannel 直接通过证书 和 ETCD 通信 获取路由表，根据在 ETCD 保存的路由表，将信息通过 物理网卡 转发给目的 Node；
- 目的 Node 在接受到转发来的数据后，由 Flannel 服务进行解封装，然后暴露出 UDP 里的目的 Pod ip ，再根据目的 IP 由 Flannel 网卡转发到 docker 0 上，最后由 docker 0 转发到 目的 Pod 中。
5.5 ETCD 之 Flannel 提供说明
- 存储管理 Flannel 可分配的IP地址段资源；
- 监控 ETCD 中每个 Pod 的实际地址，并在内存中建立维护 Pod 节点路由表；
- Flannel 转发的时候会去 ETCD 的存储路由条目中去查找地址；
- Flannel 会直接通过证书跟 ETCD 通信获取路由表；
5.6 Flannel 配置
配置步骤
- 使用 etcdctl 在 etcd 中添加 flannel 的网段和转发模式 upd、vxlan、
- 准备flannel 安装包
- 生成docker 网络配置参数并启动flannel服务
- 修改 docker启动参数，使docker0 网卡和 flannel网卡保持在一个网段里
- 验证node之间的容器通信是否正常
5.6.1 在 Master01 节点上添加网络配置信息
- 在 master01 192.168.10.40 上操作
写入分配的子网段到 ETCD中，供Flannel使用，所以Flannel要使用认证文件，通过2379端口进行访问。
cd /opt/etcd/ssl
/opt/etcd/bin/etcdctl \
--ca-file=ca.pem \
--cert-file=server.pem \
--key-file=server-key.pem \
--endpoints="https://192.168.10.40:2379,https://192.168.10.50:2379,https://192.168.10.60:2379" \
set /coreos.com/network/config '{ "Network": "172.17.0.0/16", "Backend": {"Type": "vxlan"}}'
5.6.2 准备 flannel.sh 和 flannel 压缩包，解压flannel压缩包
- 所有node节点 192.168.10.50 192.168.10.60 上操作
上传 flannel.sh 和 flannel-v0.10.0-linux-amnd64.tar.gz 到 /opt目录中，解压flannel 压缩包。
tar -zxvf flannel-v0.10.0-linux-amd64.tar.gz
#创建工作目录
mkdir -p /opt/kubernetes/{cfg,bin,ssl}
#将 flanneld 和 mk-docker-opts.sh 放入工作目录中的bin目录下
mv flanneld mk-docker-opts.sh /opt/kubernetes/bin/
5.6.3 编写 Flannel 启动脚本、执行脚本 启动 Flannel 服务
vim /opt/flannel.sh
#!/bin/bash
#定义etcd集群的端点IP地址和对外提供服务的2379端口
#${var:-string}：若变量var为空，则用在命令行中用string来替换；否则变量var不为空时，则用变量var的值来替换，这里的1代表的是位置变量$1
ETCD_ENDPOINTS=${1:-"http://127.0.0.1:2379"}
#创建flanneld配置文件
cat > /opt/kubernetes/cfg/flanneld <<EOF
FLANNEL_OPTIONS="--etcd-endpoints=${ETCD_ENDPOINTS} \\
-etcd-cafile=/opt/etcd/ssl/ca.pem \\
-etcd-certfile=/opt/etcd/ssl/server.pem \\
-etcd-keyfile=/opt/etcd/ssl/server-key.pem"
EOF
#flanneld 本应使用 etcd 客户端TLS相关证书（client 证书），这里全部都使用同一套证书认证。
#创建flanneld.service服务管理文件
cat > /usr/lib/systemd/system/flanneld.service <<EOF
[Unit]
Description=Flanneld overlay address etcd agent
After=network-online.target network.target
Before=docker.service
[Service]
Type=notify
EnvironmentFile=/opt/kubernetes/cfg/flanneld
ExecStart=/opt/kubernetes/bin/flanneld --ip-masq \$FLANNEL_OPTIONS
ExecStartPost=/opt/kubernetes/bin/mk-docker-opts.sh -k DOCKER_NETWORK_OPTIONS -d /run/flannel/subnet.env
Restart=on-failure
[Install]
WantedBy=multi-user.target
EOF
#flanneld启动后会使用 mk-docker-opts.sh 脚本生成 docker 网络相关配置信息
#mk-docker-opts.sh -k DOCKER_NETWORK_OPTIONS：将组合选项键设置为环境变量DOCKER_NETWORK_OPTIONS，docker启动时将使用此变量
#mk-docker-opts.sh -d /run/flannel/subnet.env：指定要生成的docker网络相关信息配置文件的路径，docker启动时候引用此配置
systemctl daemon-reload
systemctl enable flanneld
systemctl restart flanneld
chmod +x flannel.sh
./flannel.sh https://192.168.10.40:2379,https://192.168.10.60:2379,https://192.168.10.60:2379
systemctl status flanneld.service
5.6.4 查看 flannel 网卡
ifconfig
cat /run/flannel/subnet.env
5.6.5 配置 docker 连接 Flannel，重启 docker 服务
- 所有node节点 192.168.10.50 192.168.10.60 上操作一样配置
#修改 docker 配置项
vim /usr/lib/systemd/system/docker.service
----------------添加13行 和 修改14行------------------
EnvironmentFile=/run/flannel/subnet.env
ExecStart=/usr/bin/dockerd $DOCKER_NETWORK_OPTIONS -H fd:// --containerd=/run/containerd/containerd.sock
重载和重启docker服务
systemctl daemon-reload
systemctl restart docker
ifconfig
5.6.6 验证 Flannel
node1和node2
直接ping docker0 网卡，或者进入容器ping
或
两台node都需要这样操作
docker run -it centos:7 /bin/bash
yum install net-tools -y
用 Node1 中的容器IP 去ping Node 2 中的容器IP
能 ping 通，表示 flannel 配置成功。
六、部署 单Master 节点
- Master 节点上的服务： Apserver 与 Controller-manager 、Scheduler 因为【在同一个节点上】，直接通过 127.0.0.1:8080 进行通信，不需要安装证书，直接通过 http 请求进行通信。
#获取16位的十六进制随机数
head -c 16 /dev/urandom | od -An -t x | tr -d ' '
6.1 搭建步骤
- 创建 Master 和 生成证书 的工作目录
- 准备 k8s 软件包
- 生成 Master 认证证书
- 生成 bootstrap token 认证文件
- 启动 Apiserver
- 启动 Controller-manager
- 启动 Scheduler
- 验证 Master 组件状态
6.2 解压 Master 软件包，创建工作目录
在master01节点上操作（192.168.10.40）
上传 master.zip 和 k8s-cert.sh 到 /opt/k8s 目录中，解压 master.zip 压缩包
cd /opt/k8s/
unzip master.zip
- apiserver.sh
- scheduler.sh
- controller-manager.sh
chmod +x *.sh
//创建 kubernetes 工作目录
mkdir -p /opt/kubernetes/{cfg,bin,ssl}
6.3 创建证书目录，执行脚本生成CA 和 私钥证书
//创建用于生成 CA证书、相关组件的证书 和 私钥 的目录
mkdir /opt/k8s/k8s-cert
mv /opt/k8s/k8s-cert.sh /opt/k8s/k8s-cert
cd /opt/k8s/k8s-cert/
#执行脚本生成CA证书、相关组件的证书和私钥
./k8s-cert.sh
--------------------------------------------------------------
# ./k8s-cert.sh 脚本文件中 生成apiserver 证书的脚本 代码片段
--------------------------------------------------------------
#生成 apiserver 的证书和私钥（apiserver和其它k8s组件通信使用）
#hosts中将所有可能作为 Apiserver 的 ip 添加进去，
#后面 keepalived 使用的 VIP 也要加入, 负载均衡机器也要提前加进去
#生成 Master 证书的时候们可以将预留的IP地址都配置进去，预留后到时候新的机器直接加入即可。
#防止后面新增Master时还需要重新生成证书，
cat > apiserver-csr.json <<EOF
{
"CN": "kubernetes",
"hosts": [
"10.0.0.1",
"127.0.0.1",
"192.168.10.40", #master01
"192.168.10.70", #master02（后面配置多master时加入）
"192.168.10.120", #vip，后面 keepalived 使用
"192.168.10.111", #load balancer01（master）
"192.168.10.101", #load balancer02（backup）
"kubernetes",
"kubernetes.default",
"kubernetes.default.svc",
"kubernetes.default.svc.cluster",
"kubernetes.default.svc.cluster.local"
],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"L": "BeiJing",
"ST": "BeiJing",
"O": "k8s",
"OU": "System"
}
]
}
EOF
cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes apiserver-csr.json | cfssljson -bare apiserver
...
生成的证书文件
ls *pem
admin-key.pem apiserver-key.pem ca-key.pem kube-proxy-key.pem
admin.pem apiserver.pem ca.pem kube-proxy.pem
- X-key.pem 表示私钥文件，X.pem 表示认证文件；
//复制CA证书、Apiserver 相关证书 和 私钥到 kubernetes工作目录的 ssl子目录中
cp ca*pem apiserver*pem /opt/kubernetes/ssl/
6.4 解压 kubernetes 压缩包
//上传 kubernetes-server-linux-amd64.tar.gz 到 /opt/k8s/ 目录中，解压 kubernetes压缩包
cd /opt/k8s/
tar zxvf kubernetes-server-linux-amd64.tar.gz
//复制 master 组件的关键命令文件到 kubernetes 工作目录的 bin子目录中
cd /opt/k8s/kubernetes/server/bin
cp kube-apiserver kubectl kube-controller-manager kube-scheduler /opt/kubernetes/bin/
ln -s /opt/kubernetes/bin/* /usr/local/bin/
6.5 创建 bootstrap token 认证文件
- RBAC 是 K8S 给用户的一种授权机制。
- RBAC授权，将预设用户 kubelet-bootstrap 与内置的用户组 system:kubelet-bootstrap 绑定到一起，使其能够发起CSR请求。
创建 bootstrap token 认证文件，Apiserver 在启动时会调用，然后就相当于在集群内创建了一个这个用户，接下来就可以用 RBAC 给他授权。
cd /opt/k8s/
vim token.sh
#!/bin/bash
#获取随机数前16个字节内容，以十六进制格式输出，并删除其中空格
BOOTSTRAP_TOKEN=$(head -c 16 /dev/urandom | od -An -t x | tr -d ' ')
#生成 token.csv 文件，按照 Token序列号,用户名,UID,用户组 的格式生成
cat > /opt/kubernetes/cfg/token.csv <<EOF
${BOOTSTRAP_TOKEN},kubelet-bootstrap,10001,"system:kubelet-bootstrap"
EOF
chmod +x token.sh
./token.sh
#就是为了生成 token.csv 文件
cat /opt/kubernetes/cfg/token.csv
#Token序列号,用户名,UID,用户组
#f9f6ded8517ba96a141b5a27e5c0c586,kubelet-bootstrap,10001,"system:kubelet-bootstrap"
6.6 启动 Apiserver 服务
二进制文件、token、证书都准备好后，开启 Apiserver 服务
cd /opt/k8s/
#格式：./apiserver.sh 本节点地址 ETCD集群地址信息和端口
./apiserver.sh 192.168.10.40 https://192.168.10.40:2379,https://192.168.10.50:2379,https://192.168.10.60:2379
//检查进程是否启动成功
ps aux | grep kube-apiserver
//k8s通过kube-apiserver这个进程提供服务，该进程运行在单个master节点上。默认有两个端口6443和8080
//安全端口6443用于接收HTTPS请求，用于基于Token文件或客户端证书等认证
netstat -natp | grep 6443
//本地端口8080用于接收HTTP请求，非认证或授权的HTTP请求通过该端口访问API Server
netstat -natp | grep 8080
//查看版本信息（必须保证apiserver启动正常，不然无法查询到server的版本信息）
kubectl version
systemctl status kube-apiserver.service
apiserver.sh 脚本内容
#!/bin/bash
#example: apiserver.sh 192.168.80.10 https://192.168.80.10:2379,https://192.168.80.11:2379,https://192.168.80.12:2379
#创建 kube-apiserver 启动参数配置文件
MASTER_ADDRESS=$1
ETCD_SERVERS=$2
cat >/opt/kubernetes/cfg/kube-apiserver <<EOF
KUBE_APISERVER_OPTS="--logtostderr=true \\ # \\ 第一个 \是转义符，第二个是换行符
--v=4 \\
--etcd-servers=${ETCD_SERVERS} \\
--bind-address=${MASTER_ADDRESS} \\
--secure-port=6443 \\
--advertise-address=${MASTER_ADDRESS} \\
--allow-privileged=true \\
--service-cluster-ip-range=10.0.0.0/24 \\
--enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,ResourceQuota,NodeRestriction \\
--authorization-mode=RBAC,Node \\
--kubelet-https=true \\
--enable-bootstrap-token-auth \\
--token-auth-file=/opt/kubernetes/cfg/token.csv \\
--service-node-port-range=30000-50000 \\
--tls-cert-file=/opt/kubernetes/ssl/apiserver.pem \\
--tls-private-key-file=/opt/kubernetes/ssl/apiserver-key.pem \\
--client-ca-file=/opt/kubernetes/ssl/ca.pem \\
--service-account-key-file=/opt/kubernetes/ssl/ca-key.pem \\
--etcd-cafile=/opt/etcd/ssl/ca.pem \\
--etcd-certfile=/opt/etcd/ssl/server.pem \\
--etcd-keyfile=/opt/etcd/ssl/server-key.pem"
EOF
#--logtostderr=true：输出日志到标准错误控制台，不输出到文件
#--v=4：指定输出日志的级别，v=4为调试级别详细输出
#--etcd-servers：指定etcd服务器列表（格式：//ip:port），逗号分隔
#--bind-address：指定 HTTPS 安全接口的监听地址，默认值0.0.0.0
#--secure-port：指定 HTTPS 安全接口的监听端口，默认值6443
#--advertise-address：通过该 ip 地址向集群其他节点公布 api server 的信息，必须能够被其他节点访问
#--allow-privileged=true：允许拥有系统特权的容器运行，默认值false
#--service-cluster-ip-range：指定 Service Cluster IP 地址段
#--enable-admission-plugins：kuberneres集群的准入控制机制，各控制模块以插件的形式依次生效，集群时必须包含ServiceAccount，运行在认证（Authentication）、授权（Authorization）之后，Admission Control是权限认证链上的最后一环， 对请求API资源对象进行修改和校验
#--authorization-mode：在安全端口使用RBAC,Node授权模式，未通过授权的请求拒绝，默认值AlwaysAllow。RBAC是用户通过角色与权限进行关联的模式；Node模式（节点授权）是一种特殊用途的授权模式，专门授权由kubelet发出的API请求，在进行认证时，先通过用户名、用户分组验证是否是集群中的Node节点，只有是Node节点的请求才能使用Node模式授权
#--kubelet-https=true：kubelet通信使用https，默认值true
#--enable-bootstrap-token-auth：在apiserver上启用Bootstrap Token 认证
#--token-auth-file=/opt/kubernetes/cfg/token.csv：指定Token认证文件路径
#--service-node-port-range：指定 NodePort 的端口范围，默认值30000-32767
#创建 kube-apiserver.service 服务管理文件
cat >/usr/lib/systemd/system/kube-apiserver.service <<EOF
[Unit]
Description=Kubernetes API Server
Documentation=https://github.com/kubernetes/kubernetes
[Service]
EnvironmentFile=-/opt/kubernetes/cfg/kube-apiserver
ExecStart=/opt/kubernetes/bin/kube-apiserver \$KUBE_APISERVER_OPTS
Restart=on-failure
[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload
systemctl enable kube-apiserver
systemctl restart kube-apiserver
6.8 启动 Scheduler 服务`cd /opt/k8s/
./scheduler.sh 127.0.0.1
ps aux | grep kube-scheduler`
scheduler.sh 脚本内容
#!/bin/bash
#创建 kube-scheduler 启动参数配置文件
MASTER_ADDRESS=$1
cat >/opt/kubernetes/cfg/kube-scheduler <<EOF
KUBE_SCHEDULER_OPTS="--logtostderr=true \\
--v=4 \\
--master=${MASTER_ADDRESS}:8080 \\
--leader-elect=true"
EOF
#--master：监听 apiserver 的地址和8080端口
#--leader-elect=true：启动 leader 选举
#k8s中Controller-Manager和Scheduler的选主逻辑：k8s中的etcd是整个集群所有状态信息的存储，涉及数据的读写和多个etcd之间数据的同步，对数据的一致性要求严格，所以使用较复杂的 raft 算法来选择用于提交数据的主节点。而 apiserver 作为集群入口，本身是无状态的web服务器，多个 apiserver 服务之间直接负载请求并不需要做选主。Controller-Manager 和 Scheduler 作为任务类型的组件，比如 controller-manager 内置的 k8s 各种资源对象的控制器实时的 watch apiserver 获取对象最新的变化事件做期望状态和实际状态调整，调度器watch未绑定节点的pod做节点选择，显然多个这些任务同时工作是完全没有必要的，所以 controller-manager 和 scheduler 也是需要选主的，但是选主逻辑和 etcd 不一样的，这里只需要保证从多个 controller-manager 和 scheduler 之间选出一个 leader 进入工作状态即可，而无需考虑它们之间的数据一致和同步。
#创建 kube-scheduler.service 服务管理文件
cat >/usr/lib/systemd/system/kube-scheduler.service <<EOF
[Unit]
Description=Kubernetes Scheduler
Documentation=https://github.com/kubernetes/kubernetes
[Service]
EnvironmentFile=-/opt/kubernetes/cfg/kube-scheduler
ExecStart=/opt/kubernetes/bin/kube-scheduler \$KUBE_SCHEDULER_OPTS
Restart=on-failure
[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload
systemctl enable kube-scheduler
systemctl restart kube-scheduler
6.9 启动 Controller-manager 服务
cd /opt/k8s/
./controller-manager.sh 127.0.0.1
6.10 查看Master节点状态
kubectl get componentstatuses
#也可以
kubectl get cs
都是 healthy 就没问题
七、部署 Node 节点
- Node 节点：kublet、kube-proxy 与 apserver 【不在同一个节点上】，需要通过 https 协议的 6443 端口 进行跨节点进行通信。
- Node 想加入到 Master 集群中需要通过认证，这个过程就是 CSR（证书请求文件）。
7.1 搭建步骤
两个Node节点 ：192.168.10.50、192.168.10.60
步骤：
- 先在 Master 节点将 kubelet 、kube-proxy 文件复制到 多台 Node 节点上；这两个文件用于 启动、停止等操作，用来管理 kubelet 和 kube-proxy 进程用的；
- 在Master节点上准备 kubelet 和 kube-proxy 加入k8s 群集所要使用的 kubeconfig 文件（kubeconfig 文件主要包含加入 k8s 集群需要的 CA 证书，TLS 证书 和 私钥，bootstrap 的 token 信息 ，master 的 apiserver IP+端口），把配置文件
bootstrap.kubeconfig、kube-proxy.kubeconfig拷贝到 Node 节点上。 - node 节点启动 kubelet，node节点的 kubelet 会向 master 的 apiserver 发起 CSR 认证请求；
- 在 master 节点上 通过 CSR 认证， node 会自动生成 证书 ，以后的 node 的 kubelet 访问都会通过这个证书做认证；
- node 节点上加载 ipvs 模块， 启动 kube-proxy
7.2 先在 Master01 节点上操作
Master01 192.168.10.40
把 kubernetes 软件包中的 kubelet、kube-proxy 文件 拷贝到 Node 节点中。
cd /opt/k8s/kubernetes/server/bin
scp kubelet kube-proxy root@192.168.10.50:/opt/kubernetes/bin/
scp kubelet kube-proxy root@192.168.10.60:/opt/kubernetes/bin/
7.3 在 Node01 节点上操作
两个Node节点 ：192.168.10.50、192.168.10.60
上传 node.zip 到 /opt 目录中，解压 node.zip 压缩包，获得 kubelet.sh、proxy.sh 文件
cd /opt/
unzip node.zip
7.4 Master01上 生成 kubelet 的配置文件，对 kubelet进行 RBAC 授权
192.168.10.40
创建用于生成 kubelet 的配置文件的目录，生成kubelet的配置文件
创建用于生成 kubelet 的配置文件的目录，上传 kubeconfig.sh 文件到 /opt/k8s/kubeconfig 目录中
mkdir /opt/k8s/kubeconfig
cd /opt/k8s/kubeconfig
chmod +x kubeconfig.sh
./kubeconfig.sh 192.168.10.40 /opt/k8s/k8s-cert/
ls
- bootstrap.kubeconfig
- kubeconfig.sh
- kube-proxy.kubeconfig #连接 API server 的认证信息
#kubeconfig.sh 文件包含：
集群参数（CA 证书、API Server 地址），
客户端参数（上面生成的证书和私钥），
集群 context 上下文参数（集群名称、用户名）。
Kubenetes 组件（如 kubelet、kube-proxy）通过启动时指定不同的 kubeconfig 文件可以切换到不同的集群，连接到 apiserver。
kubeconfig.sh 脚本内容
#!/bin/bash
#example: kubeconfig 192.168.10.40 /opt/k8s/k8s-cert/
#创建bootstrap.kubeconfig文件
#该文件中内置了 token.csv 中用户的 Token，以及 apiserver CA 证书；kubelet 首次启动会加载此文件，使用 apiserver CA 证书建立与 apiserver 的 TLS 通讯，使用其中的用户 Token 作为身份标识向 apiserver 发起 CSR 请求
BOOTSTRAP_TOKEN=$(awk -F ',' '{print $1}' /opt/kubernetes/cfg/token.csv)
APISERVER=$1
SSL_DIR=$2
export KUBE_APISERVER="https://$APISERVER:6443"
# 设置集群参数
kubectl config set-cluster kubernetes \
--certificate-authority=$SSL_DIR/ca.pem \
--embed-certs=true \
--server=${KUBE_APISERVER} \
--kubeconfig=bootstrap.kubeconfig
#--embed-certs=true：表示将ca.pem证书写入到生成的bootstrap.kubeconfig文件中
# 设置客户端认证参数，kubelet 使用 bootstrap token 认证
kubectl config set-credentials kubelet-bootstrap \
--token=${BOOTSTRAP_TOKEN} \
--kubeconfig=bootstrap.kubeconfig
# 设置上下文参数
kubectl config set-context default \
--cluster=kubernetes \
--user=kubelet-bootstrap \
--kubeconfig=bootstrap.kubeconfig
# 使用上下文参数生成 bootstrap.kubeconfig 文件
kubectl config use-context default --kubeconfig=bootstrap.kubeconfig
#----------------------
#创建kube-proxy.kubeconfig文件
# 设置集群参数
kubectl config set-cluster kubernetes \
--certificate-authority=$SSL_DIR/ca.pem \
--embed-certs=true \
--server=${KUBE_APISERVER} \
--kubeconfig=kube-proxy.kubeconfig
# 设置客户端认证参数，kube-proxy 使用 TLS 证书认证
kubectl config set-credentials kube-proxy \
--client-certificate=$SSL_DIR/kube-proxy.pem \
--client-key=$SSL_DIR/kube-proxy-key.pem \
--embed-certs=true \
--kubeconfig=kube-proxy.kubeconfig
# 设置上下文参数
kubectl config set-context default \
--cluster=kubernetes \
--user=kube-proxy \
--kubeconfig=kube-proxy.kubeconfig
# 使用上下文参数生成 kube-proxy.kubeconfig 文件
kubectl config use-context default --kubeconfig=kube-proxy.kubeconfig
把配置文件 bootstrap.kubeconfig、kube-proxy.kubeconfig 拷贝到 Node 节点
cd /opt/k8s/kubeconfig
scp bootstrap.kubeconfig kube-proxy.kubeconfig root@192.168.10.50:/opt/kubernetes/cfg/
scp bootstrap.kubeconfig kube-proxy.kubeconfig root@192.168.10.60:/opt/kubernetes/cfg/
kubelet 组件加入集群时，进行 RBAC 授权
RBAC 授权：将预设用户 kubelet-bootstrap 与内置的 ClusterRole system:node-bootstrapper 绑定到一起，使其能够发起 CSR 请求
kubectl create clusterrolebinding kubelet-bootstrap --clusterrole=system:node-bootstrapper --user=kubelet-bootstrap
------------------------------------------------------------------------------------------
【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 生成一个证书，以后的访问都是用证书做认证了】
------------------------------------------------------------------------------------------
查看已授权的角色，进行验证
#查看角色：
kubectl get clusterroles | grep system:node-bootstrapper
#查看已授权的角色：
kubectl get clusterrolebinding
7.5 在 Node01 节点上 启动 kubelet 服务
使用kubelet.sh脚本启动服务
cd /opt/
chmod +x kubelet.sh
./kubelet.sh 192.168.10.50
//检查kubelet服务启动
ps aux | grep kubelet
//此时还没有生成证书
ls /opt/kubernetes/ssl/
可见 kubelet 想 Master01 的 Apiserver 发了CSR请求，去master01 上kubectl get csr查看CSR请求。
在 7.6 认证通过后，再查看：
7.6 Master01上
检查到 Node01 节点的 kubelet 发起的 CSR 请求，Pending 表示等待集群给该节点签发证书
kubectl get csr
Pending等待，master01 需要 通过 CSR 请求
//通过 CSR 请求
kubectl certificate approve node-csr-H1SkFX2dVYO_ZWD3ITv62sTqnwCiUDGLvw542t7LOP4
//再次查看 CSR 请求状态，Approved,Issued 表示已授权 CSR 请求并签发证书
kubectl get csr
//查看群集节点状态，成功加入Node01节点，状态为Ready
kubectl get nodes
7.7 在 Node01 节点上 加载 ip_vs 模块，启动proxy服务
- 后面都是通过 ip_vs 模块进行流量调度
//自动生成了证书和 kubelet.kubeconfig 文件
ls /opt/kubernetes/cfg/kubelet.kubeconfig
ls /opt/kubernetes/ssl/
用/sbin/modprobe 把 ipvs 模块添加到系统当中
//通过内核加载 ip_vs 模块，192.168.10.50 192.168.10.60 都要操作
for i in $(ls /usr/lib/modules/$(uname -r)/kernel/net/netfilter/ipvs|grep -o "^[^.]*");do echo $i; /sbin/modinfo -F filename $i >/dev/null 2>&1 && /sbin/modprobe $i;done
//使用proxy.sh脚本启动proxy服务
cd /opt/
chmod +x proxy.sh
./proxy.sh 192.168.10.50
systemctl status kube-proxy.service
7.8 Node02 节点部署
就是将 node01 做的操作在 node02 上也做一遍
方法一：
//在 node01 节点上将 kubelet.sh、proxy.sh 文件拷贝到 node02 节点
cd /opt/
scp kubelet.sh proxy.sh root@192.168.10.60:/opt/
##### 在 node02 节点上操作 #####
//使用kubelet.sh脚本启动kubelet服务
cd /opt/
chmod +x kubelet.sh
./kubelet.sh 192.168.10.60
##### 在 master01 节点上操作 #####
//在 master01 节点上操作查看 CSR 请求
kubectl get csr
//通过 CSR 请求
kubectl certificate approve node-csr-OaH9HpIKh6AKlfdjEKm4C6aJ0UT_1YxNaa70yEAxnsU
kubectl get csr
//查看群集中的节点状态
kubectl get nodes
NAME STATUS ROLES AGE VERSION
192.168.10.50 Ready
192.168.10.60 Ready
//加载 ipvs 模块
for i in $(ls /usr/lib/modules/$(uname -r)/kernel/net/netfilter/ipvs|grep -o "^[^.]*");do echo $i; /sbin/modinfo -F filename $i >/dev/null 2>&1 && /sbin/modprobe $i;done
//使用proxy.sh脚本启动proxy服务
cd /opt/
chmod +x proxy.sh
./proxy.sh 192.168.10.60
systemctl status kubelet.service
systemctl status kube-proxy.service
#查看Master下的 node 节点列表
kubectl get nodes
还一种方法部署 Node02，在这里不做演示。
##方法二：
//在node01节点操作，把现成的/opt/kubernetes目录和kubelet、kube-proxy的service服务管理文件复制到其他node节点
scp -r /opt/kubernetes/ root@192.168.100.60:/opt/
scp /usr/lib/systemd/system/{kubelet,kube-proxy}.service root@192.168.10.60:/usr/lib/systemd/system/
//在node02节点上操作，进行修改
//首先删除复制过来的证书，等会node02会自行申请证书
cd /opt/kubernetes/ssl/
rm -rf *
//修改配置文件kubelet、kubelet.config、kube-proxy的相关IP地址配置为当前节点的IP地址
cd /opt/kubernetes/cfg
vim kubelet
KUBELET_OPTS="--logtostderr=true \
--v=4 \
--hostname-override=192.168.10.60\ #修改
......
vim kubelet.config
kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
address: 192.168.10.60 #修改
vim kube-proxy
KUBE_PROXY_OPTS="--logtostderr=true \
--v=4 \
--hostname-override=192.168.10.60 \ #修改
//加载 ipvs 模块
modprobe ip_vs
//启动kubelet和kube-proxy服务并设置开机自启
systemctl start kubelet.service
systemctl enable kubelet.service
systemctl start kube-proxy.service
systemctl enable kube-proxy.service
//到master01节点上发现未授权的node02请求，授权node02加入集群
kubectl get csr
//授权许可加入群集，让 kubelet 获取到证书
kubectl certificate approve XXXX
kubectl get csr
kubectl get nodes
八、测试Kubernetes 单节点集群
创建 Pod
查看 k8s 命名空间
kubectl get ns
#创建POD
#格式：kubectl create deployment 自定义镜像名 --image=镜像源名
kubectl create deployment nginx-test --image=nginx
#创建后因为要拉取镜像，要等待
#查看急群众 pod 列表
kubectl get pods
在一台Node机器上就能看到创建的容器
九、K8S 通信方式
etcd 内部通信用 2380 端口
etcd 外部通信用 2379 端口
K8S 通信方式有两种：
- Master 节点上的服务： Apserver 与 Controller-manager 、Scheduler 因为【在同一个节点上】，直接通过 127.0.0.1:8080 进行通信，不需要安装证书，直接通过 http 请求进行通信。
- Node 节点：kublet、kube-proxy 与 apserver 【不在同一个节点上】，需要通过 https 协议的 6443 端口 进行跨节点进行通信。
- Node 想加入到 Master 集群中需要通过认证，这个过程就是 CSR（证书请求文件）。
十、命令
查看 k8s 命名空间
kubectl get ns
查看 k8s 资源类型列表
kubectl api-resources