二进制部署高可用k8s集群V1.20.11版本
文章目录
- 一、操作系统初始化配置（所有节点均执行）
-
- 1、关闭防火墙
- 2、关闭selinux
- 3、关闭swap
- 4、根据规划修改主机名
- 5、在master节点上添加host
- 6、将桥接的IPv4流量传递到iptables的链
- 7、时间同步
- 二、部署Etcd集群
-
- 1、准备cfssl证书生成工具
- 2、生成Etcd证书
-
- 2.1、自签etcd证书颁发机构（根CA）
- 2.2、使用自签的CA来签发Etcd HTTPS证书
- 2.3、从Github下载Etcd二进制文件
- 2.4、部署Etcd集群
-
- （1）创建工作目录并解压二进制包
- （2）创建etcd的配置文件
- 2.5、配置systemd管理etcd
- 2.6 把刚才生成的etcd证书拷贝到配置文件中的路径中
- 2.6、启动etcd并设置开机启动
- 2.7、将etcd节点1（k8s-master1节点）所有生成的文件拷贝到其它etcd节点上（节点2和节点3）
- 2.8、查看集群状态
- 三、安装Docker
-
- 1、下载安装docker并启动；
- 2、创建docker配置文件
- 四、部署k8s-master节点
-
- 1、生成kube-apiserver服务证书
-
- 1.1、自签kubernetes证书颁发机构（根CA）
- 1.2、使用自签的CA来签发kube-apiserver HTTPS证书
- 1.3、从Github下载kubernetes二进制文件
- 1.4、解压二进制包
- 1.5、部署kube-apiserver
-
- （1）创建配置文件
- （2）拷贝刚才生成的证书
- （3）启用 TLS Bootstrapping 机制
- （4）使用systemd管理kube-apiserver
- （5）启动并设置开机自启
- 1.6、部署kube-controller-manager
-
- （1）创建配置文件
- （2）使用自签的CA来签发kube-controller-manager HTTPS证书
- （3）生成kube-controller-manager的kubeconfig文件（以下是shell命令，直接在终端执行）
- （4）部署kube-controller-manager并启动
- 1.7、部署kube-scheduler
-
- （1）创建配置文件
- （2）使用自签的CA来签发kube-scheduler HTTPS证书
- （3）生成kube-scheduler的kubeconfig文件（以下是shell命令，直接在终端执行）
- （4）部署kube-scheduler并启动
- 1.8、查看集群状态
-
- （1）生成kubectl工具连接集群的证书（kubeadm安装方式默认生成的在/root/.kube/config）
- （2）生成kubectl的kubeconfig文件（以下是shell命令，直接在终端执行）
- 1.9、授权kubelet-bootstrap用户允许请求证书
- 五、部署work node
-
- 1、创建工作目录并拷贝二进制文件
-
- 1.1、部署kubelet
-
- （1）创建配置文件
- （2）创建配置参数（kubelet-config.yml）文件
- （3）生成kubelet初次加入集群向apiserver申请证书的kubeconfig文件
- （4）systemd管理kubelet 并启动
- 1.2、在master节点上批准kubelet证书申请并加入集群
- 1.3、部署kube-proxy
-
- （1）创建配置文件
- （2）创建配置参数（kube-proxy-config.yml）文件
- （3）生成kube-proxy.kubeconfig文件
- （4）systemd管理kubelet 并启动
- 1.4、部署网络组件 calico
-
- （1）修改配置（pod使用的网络）并运行calico
- 1.5、授权apiserver访问kubelet
- 六、新增加worker node
-
- 1、拷贝已部署好的Node相关文件到新的节点
- 2、 删除kubelet证书和kubeconfig文件
- 3、 修改主机名
- 4、 启动并设置开机自启
- 5、 在master上批准新的node kubelet证书申请
- 七、部署Core DNS和Ingress
-
- 1、部署CoreDNS
- 2、修改CoreDNS配置(configmap 和 service处)
- 3、运行CoreDNS并验证域名解析功能
- 4、部署ingress
- 5、修改ingress配置
-
-
- （1）需要将镜像地址（registry.k8s.io）修改为国内的（lank8s.cn）否则会下不了镜像
- （2）修改ingress使用 共享宿主机网络（主要是宿主机的80、443端口）的方式来进行工作（这是ingress的一种工作方式，还有"Service NodePort暴露Ingress Controller"的方式，后面会有详细文章单独来讲ingress）
-
- 6、部署ingress并启动一个pod来测试
- 八、扩容多master（高可用架构）
-
- 1、部署Master2
-
- （1）安装docker
- （2）创建etcd证书目录
- （3）拷贝文件（在Master1上操作）
- （4）删除证书文件
- （5）修改配置文件IP和主机名
- （6）启动并设置开机启动
- （7）查看集群状态
- （8）批准kubelet证书申请
- 2、部署Nginx+Keeaplived高可用负载均衡器
-
- （1）安装nginx和keepalived软件包（主/备一样）
- （2）配置nginx（主/备一样）
- （3）配置keepalived（Nginx Master）
- （4）配置keepalived（Nginx Backup）
- （5）启动nginx和keepalived并设置开机启动
- （6）查看keepalived工作状态
- （7）Nginx+Keepalived高可用测试
- （8）访问负载均衡器测试
- （9）修改所有WorkNode连接LB VIP
- （10）测试高可用
- 总结
单master架构图
一、操作系统初始化配置（所有节点均执行）
1、关闭防火墙
[root@iZbp11oc69mdt2iizzqhzuZ ~]# systemctl stop firewalld
[root@iZbp11oc69mdt2iizzqhzuZ ~]# systemctl disable firewalld
2、关闭selinux
[root@iZbp11oc69mdt2iizzqhzuZ ~]# setenforce 0 #临时关闭
setenforce: SELinux is disabled
[root@iZbp11oc69mdt2iizzqhzuZ ~]# sed -i 's/enforcing/disabled/' /etc/selinux/config #永久关闭
3、关闭swap
[root@iZbp11oc69mdt2iizzqhzuZ ~]# swapoff -a #临时关闭
[root@iZbp11oc69mdt2iizzqhzuZ ~]# sed -ri 's/.*swap.*/#&/' /etc/fstab #永久关闭
4、根据规划修改主机名
master节点
[root@iZbp11oc69mdt2iizzqhzuZ ~]# hostnamectl set-hostname k8s-master1
[root@iZbp11oc69mdt2iizzqhzuZ ~]# bash
[root@k8s-master1 ~]#
node1节点
[root@iZbp109g5wnimxn10iv2krZ ~]# hostnamectl set-hostname k8s-node1
[root@iZbp109g5wnimxn10iv2krZ ~]# bash
[root@k8s-node1 ~]#
node2节点
[root@iZbp1b25lq5akibeea3sr4Z ~]# hostnamectl set-hostname k8s-node2
[root@iZbp1b25lq5akibeea3sr4Z ~]# bash
[root@k8s-node2 ~]#
5、在master节点上添加host
[root@k8s-master1 ~]# vim /etc/hosts
172.32.0.11 k8s-master1
172.32.0.12 k8s-node1
172.32.0.13 k8s-node2
6、将桥接的IPv4流量传递到iptables的链
[root@k8s-master1 ~]# vim /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
[root@k8s-master1 ~]# sysctl --system #使配置生效
7、时间同步
[root@k8s-master1 ~]# yum -y install ntpdate
[root@k8s-master1 ~]# ntpdate time.windows.com
4 Sep 11:03:38 ntpdate[31657]: adjust time server 52.231.114.183 offset 0.001765 sec
二、部署Etcd集群
Etcd是一个分布式键值存储系统，K8s使用Etcd进行数据存储，所以先准备一个Etcd数据库，为解决Etcd单点故障，应采用集群方式进行部署，这里使用3台组件集群，可容忍1台机器故障，当然 也可以使用5台组件集群，可容忍2台机器故障；
| 节点名称 | IP |
|---|---|
| etcd-1 | 172.32.0.11 |
| etcd-2 | 172.32.0.12 |
| etcd-3 | 172.32.0.13 |
提示：为了节省机器，这里与k8s节点复用，也可以独立于k8s集群之外部署，只要apiserver能连接到就行；（生产环境下还是建议大家分开部署）
1、准备cfssl证书生成工具
cfssl是一个开源的证书管理工具，使用json文件生成证书，相比于openssl更方便使用；
在随便一台服务器上操作，这里使用master节点
[root@k8s-master1 ~]# wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64
[root@k8s-master1 ~]# wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
[root@k8s-master1 ~]# wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64
[root@k8s-master1 ~]# chmod +x cfssl-certinfo_linux-amd64 cfssl_linux-amd64 cfssljson_linux-amd64
[root@k8s-master1 ~]# ll
total 18808
-rw-r--r-- 1 root root 6595195 Dec 7 2021 cfssl-certinfo_linux-amd64
-rw-r--r-- 1 root root 2277873 Dec 7 2021 cfssljson_linux-amd64
-rw-r--r-- 1 root root 10376657 Dec 7 2021 cfssl_linux-amd64
[root@k8s-master1 ~]# mv cfssl_linux-amd64 /usr/local/bin/cfssl #cfssl工具
[root@k8s-master1 ~]# mv cfssljson_linux-amd64 /usr/local/bin/cfssljson #可显示CSR或证书文件的详细信息；可用于证书校验；
[root@k8s-master1 ~]# mv cfssl-certinfo_linux-amd64 /usr/bin/cfssl-certinfo #将从cfssl和multirootca等获得的json格式的输出转化为证书格式的文件（证书，密钥，CSR和bundle）进行存储；
2、生成Etcd证书
2.1、自签etcd证书颁发机构（根CA）
创建工作目录
[root@k8s-master1 ~]# mkdir -pv /hqtbj/hqtwww/TLS/{etcd,k8s}
mkdir: created directory ‘/hqtbj’
mkdir: created directory ‘/hqtbj/hqtwww’
mkdir: created directory ‘/hqtbj/hqtwww/TLS’
mkdir: created directory ‘/hqtbj/hqtwww/TLS/etcd’
mkdir: created directory ‘/hqtbj/hqtwww/TLS/k8s’
创建请求证书的json配置文件（自签CA）
以下命令可以创建一个CA证书的请求json的默认生成方式，大家可以在此基础上面修改，也可以自行创建；
cfssl print-defaults config > ca-config.json
[root@k8s-master1 etcd]# vim ca-config.json
{
"signing": {
"default": {
"expiry": "87600h"
},
"profiles": {
"etcd": {
"expiry": "87600h",
"usages": [
"signing",
"key encipherment",
"server auth",
"client auth"
]
}
}
}
}
ca-config.json：这个配置文件只是告诉我们颁发有什么功能的证书，它用于配置证书的使用场景（profile）和具体参数（usage、过期时间、服务端认证、客户端认证、加密等）；
default：是默认策略，指定证书默认有效期是10年；
profiles：是定义使用场景，这里只是etcd，也可以定义多个场景，分别指定不同的过期时间，使用场景等参数，后续签名时使用某个profile即可；
signing：表示该证书可用于签名其他证书，生成的ca.pem证书中的CA=TRUE；
server auth：表示client可以用该CA对server提供的证书进行校验；
client auth：表示server可以用该CA对client提供的证书进行验证；
创建根CA证书签名请求文件
以下命令可以创建一个CSR默认证书签名请求文件，大家可以在此基础上面修改，也可以自行创建；
cfssl print-defaults csr > ca-csr.json
[root@k8s-master1 etcd]# vim ca-csr.json
{
"CN": "etcd CA",
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"L": "Beijing",
"ST": "Beijing"
}
]
}
生成自签CA的证书和私钥ca.pem，ca-key.pem
[root@k8s-master1 etcd]# ll
total 8
-rw-r--r-- 1 root root 288 Sep 4 11:45 ca-config.json
-rw-r--r-- 1 root root 209 Sep 4 11:43 ca-csr.json
[root@k8s-master1 etcd]# cfssl gencert -initca ca-csr.json | cfssljson -bare ca -
[root@k8s-master1 etcd]# ll
total 20
-rw-r--r-- 1 root root 288 Sep 4 11:45 ca-config.json
-rw-r--r-- 1 root root 956 Sep 4 11:48 ca.csr
-rw-r--r-- 1 root root 209 Sep 4 11:43 ca-csr.json
-rw------- 1 root root 1679 Sep 4 11:48 ca-key.pem
-rw-r--r-- 1 root root 1265 Sep 4 11:48 ca.pem
会生成ca.pem证书和ca-key.pem私钥
2.2、使用自签的CA来签发Etcd HTTPS证书
创建etcd证书的申请文件
[root@k8s-master1 etcd]# vim etcd-server.json
{
"CN": "etcd",
"hosts": [
"172.32.0.11",
"172.32.0.12",
"172.32.0.13",
"172.32.0.14",
"172.32.0.15",
"172.32.0.16",
"172.32.0.17"
],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"L": "BeiJing",
"ST": "BeiJing"
}
]
}
提示：上述文件hosts字段中IP为所有etcd节点的集群内部通信IP，一个都不能少！为了方便后期扩容可以多写几个预留的IP
CN：具体表示的域；
hosts：使用该证书的域名，这里使用的是IP；
key：加密方式，常用的就是RSA 2048；
names：证书包含的信息，例如国家、地区等；
生成etcd证书
[root@k8s-master1 etcd]# cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=etcd etcd-server.json | cfssljson -bare etcd-server
[root@k8s-master1 etcd]# ll
total 36
-rw-r--r-- 1 root root 288 Sep 4 11:45 ca-config.json
-rw-r--r-- 1 root root 956 Sep 4 11:48 ca.csr
-rw-r--r-- 1 root root 209 Sep 4 11:43 ca-csr.json
-rw------- 1 root root 1679 Sep 4 11:48 ca-key.pem
-rw-r--r-- 1 root root 1265 Sep 4 11:48 ca.pem
-rw-r--r-- 1 root root 1045 Sep 4 12:22 etcd-server.csr
-rw-r--r-- 1 root root 360 Sep 4 11:57 etcd-server.json
-rw------- 1 root root 1679 Sep 4 12:22 etcd-server-key.pem
-rw-r--r-- 1 root root 1371 Sep 4 12:22 etcd-server.pem
会生成etcd-server.pem证书和etcd-server-key.pem私钥
2.3、从Github下载Etcd二进制文件
下载地址：https://github.com/etcd-io/etcd/releases/download/v3.4.9/etcd-v3.4.9-linux-amd64.tar.gz
参考文档：https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/configure-upgrade-etcd/
2.4、部署Etcd集群
以下在节点1（master）上操作，为简化操作，待会将master生成的所有文件拷贝到节点2（node1）和节点3（node2；
（1）创建工作目录并解压二进制包
[root@k8s-master1 ~]# mkdir -pv /hqtbj/hqtwww/etcd/{bin,cfg,ssl}
mkdir: created directory ‘/hqtbj/hqtwww/etcd’
mkdir: created directory ‘/hqtbj/hqtwww/etcd/bin’
mkdir: created directory ‘/hqtbj/hqtwww/etcd/cfg’
mkdir: created directory ‘/hqtbj/hqtwww/etcd/ssl’
[root@k8s-master1 ~]# wget https://github.com/etcd-io/etcd/releases/download/v3.4.9/etcd-v3.4.9-linux-amd64.tar.gz
[root@k8s-master1 ~]# tar -zxf etcd-v3.4.9-linux-amd64.tar.gz
[root@k8s-master1 ~]# ll etcd-v3.4.9-linux-amd64
total 40540
drwxr-xr-x 14 630384594 600260513 4096 May 22 2020 Documentation
-rwxr-xr-x 1 630384594 600260513 23827424 May 22 2020 etcd
-rwxr-xr-x 1 630384594 600260513 17612384 May 22 2020 etcdctl
-rw-r--r-- 1 630384594 600260513 43094 May 22 2020 README-etcdctl.md
-rw-r--r-- 1 630384594 600260513 8431 May 22 2020 README.md
-rw-r--r-- 1 630384594 600260513 7855 May 22 2020 READMEv2-etcdctl.md
[root@k8s-master1 ~]# mv etcd-v3.4.9-linux-amd64/{etcd,etcdctl} /hqtbj/hqtwww/etcd/bin/
[root@k8s-master1 ~]# cd /hqtbj/hqtwww/etcd/bin/
[root@k8s-master1 bin]# ll
total 40472
-rwxr-xr-x 1 630384594 600260513 23827424 May 22 2020 etcd
-rwxr-xr-x 1 630384594 600260513 17612384 May 22 2020 etcdctl
（2）创建etcd的配置文件
[root@k8s-master1 cfg]# vim /hqtbj/hqtwww/etcd/cfg/etcd.conf
#[Member]
ETCD_NAME="etcd-1"
ETCD_DATA_DIR="/var/lib/etcd/default.etcd"
ETCD_LISTEN_PEER_URLS="https://172.32.0.11:2380"
ETCD_LISTEN_CLIENT_URLS="https://172.32.0.11:2379"
#[Clustering]
ETCD_INITIAL_ADVERTISE_PEER_URLS="https://172.32.0.11:2380"
ETCD_ADVERTISE_CLIENT_URLS="https://172.32.0.11:2379"
ETCD_INITIAL_CLUSTER="etcd-1=https://172.32.0.11:2380,etcd-2=https://172.32.0.12:2380,etcd-3=https://172.32.0.13:2380"
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster"
ETCD_INITIAL_CLUSTER_STATE="new"
ETCD_NAME：节点名称，集群中唯一
ETCD_DATA_DIR：etcd的数据目录
ETCD_LISTEN_PEER_URLS：集群通信的监听地址
ETCD_LISTEN_PEER_URLS：客户端访问的监听地址
ETCD_INITIAL_ADVERTISE_PEER_URLS：集群通告地址
ETCD_ADVERTISE_CLIENT_URLS：客户端通告地址
ETCD_INITIAL_CLUSTER：集群中的节点地址
ETCD_INITIAL_CLUSTER_TOKEN：集群的token
ETCD_INITIAL_CLUSTER_STATE：加入集群的当前状态，new是新集群，"existing"表示加入已有的集群
2.5、配置systemd管理etcd
[root@k8s-master1 ~]# vim /usr/lib/systemd/system/etcd.service
[Unit]
Description=Etcd Server
After=network.target
After=network-online.target
Wants=network-online.target
[Service]
Type=notify
EnvironmentFile=/hqtbj/hqtwww/etcd/cfg/etcd.conf #etcd的配置文件
ExecStart=/hqtbj/hqtwww/etcd/bin/etcd \
--cert-file=/hqtbj/hqtwww/etcd/ssl/etcd-server.pem \ #etcd对外提供服务的服务器证书
--key-file=/hqtbj/hqtwww/etcd/ssl/etcd-server-key.pem \ #etcd服务器证书对应的私钥
--peer-cert-file=/hqtbj/hqtwww/etcd/ssl/etcd-server.pem \ #peer证书，用于etcd节点之间的相互访问，这里使用etcd服务器证书
--peer-key-file=/hqtbj/hqtwww/etcd/ssl/etcd-server-key.pem \ #peer证书对应的私钥，这里使用etcd服务器证书对应的私钥
--trusted-ca-file=/hqtbj/hqtwww/etcd/ssl/ca.pem \ #用于验证访问etcd服务器的客户端证书的CA证书，就是我们给etcd颁发https的 自建的 CA机构
--peer-trusted-ca-file=/hqtbj/hqtwww/etcd/ssl/ca.pem \ #用于验证peer证书的CA根证书
--logger=zap
Restart=on-failure
LimitNOFILE=65536
[Install]
WantedBy=multi-user.target
2.6 把刚才生成的etcd证书拷贝到配置文件中的路径中
[root@k8s-master1 cfg]# cp /hqtbj/hqtwww/TLS/etcd/ca*pem /hqtbj/hqtwww/TLS/etcd/etcd-server*pem /hqtbj/hqtwww/etcd/ssl/
2.6、启动etcd并设置开机启动
[root@k8s-master1 ~]# systemctl daemon-reload
[root@k8s-master1 ~]# systemctl enable etcd
[root@k8s-master1 ~]# systemctl start etcd
#启动的时候会阻塞终端，因为我们的集群是3台，可以容忍1台etcd故障，但是现在我们剩下两台还没有启动，所以这里会尝试去连接集群内的其它节点，如果剩下两台都连不上的话就会启动不起来；日志如下：
Job for etcd.service failed because a timeout was exceeded. See "systemctl status etcd.service" and "journalctl -xe" for details.
[root@k8s-master1 ~]# journalctl -f -u etcd.service
......
Sep 04 12:38:46 k8s-master1 etcd[32366]: {"level":"warn","ts":"2022-09-04T12:38:46.299+0800","caller":"rafthttp/probing_status.go:70","msg":"prober detected unhealthy status","round-tripper-name":"ROUND_TRIPPER_RAFT_MESSAGE","remote-peer-id":"1c8006ffe5f4dc13","rtt":"0s","error":"dial tcp 172.32.0.12:2380: connect: connection refused"}
Sep 04 12:38:46 k8s-master1 etcd[32366]: {"level":"warn","ts":"2022-09-04T12:38:46.299+0800","caller":"rafthttp/probing_status.go:70","msg":"prober detected unhealthy status","round-tripper-name":"ROUND_TRIPPER_SNAPSHOT","remote-peer-id":"1c8006ffe5f4dc13","rtt":"0s","error":"dial tcp 172.32.0.12:2380: connect: connection refused"}
Sep 04 12:38:46 k8s-master1 etcd[32366]: {"level":"warn","ts":"2022-09-04T12:38:46.307+0800","caller":"rafthttp/probing_status.go:70","msg":"prober detected unhealthy status","round-tripper-name":"ROUND_TRIPPER_RAFT_MESSAGE","remote-peer-id":"c9a413f6093101a1","rtt":"0s","error":"dial tcp 172.32.0.13:2380: connect: connection refused"}
Sep 04 12:38:46 k8s-master1 etcd[32366]: {"level":"warn","ts":"2022-09-04T12:38:46.308+0800","caller":"rafthttp/probing_status.go:70","msg":"prober detected unhealthy status","round-tripper-name":"ROUND_TRIPPER_SNAPSHOT","remote-peer-id":"c9a413f6093101a1","rtt":"0s","error":"dial tcp 172.32.0.13:2380: connect: connection refused"}
Sep 04 12:38:46 k8s-master1 systemd[1]: etcd.service start operation timed out. Terminating.
Sep 04 12:38:46 k8s-master1 systemd[1]: Failed to start Etcd Server.
提示：这里的解决办法就是在启动etcd的时候把集群中的另一台节点一同起来就可以了，下一个步骤就是：
2.7、将etcd节点1（k8s-master1节点）所有生成的文件拷贝到其它etcd节点上（节点2和节点3）
[root@k8s-master1 ~]# scp -pr /hqtbj/hqtwww/etcd/ [email protected]:/hqtbj/hqtwww/
[root@k8s-master1 ~]# scp -r /usr/lib/systemd/system/etcd.service [email protected]:/usr/lib/systemd/system/
[root@k8s-master1 ~]# scp -pr /hqtbj/hqtwww/etcd/ [email protected]:/hqtbj/hqtwww/
[root@k8s-master1 ~]# scp -r /usr/lib/systemd/system/etcd.service [email protected]:/usr/lib/systemd/system/
然后在节点2和节点3上分别修改etcd.conf配置文件中的节点名称和当前服务器的IP：
[root@k8s-node1 ~]# vim /hqtbj/hqtwww/etcd/cfg/etcd.conf
#[Member]
ETCD_NAME="etcd-2" #修改此处，节点2改为etcd-2，节点3改为etcd-3
ETCD_DATA_DIR="/var/lib/etcd/default.etcd"
ETCD_LISTEN_PEER_URLS="https://172.32.0.12:2380" #修改此处为当前服务器的IP
ETCD_LISTEN_CLIENT_URLS="https://172.32.0.12:2379" #修改此处为当前服务器的IP
#[Clustering]
ETCD_INITIAL_ADVERTISE_PEER_URLS="https://172.32.0.12:2380" #修改此处为当前服务器的IP
ETCD_ADVERTISE_CLIENT_URLS="https://172.32.0.12:2379" #修改此处为当前服务器的IP
ETCD_INITIAL_CLUSTER="etcd-1=https://172.32.0.11:2380,etcd-2=https://172.32.0.12:2380,etcd-3=https://172.32.0.13:2380"
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster"
ETCD_INITIAL_CLUSTER_STATE="new"
最后启动etcd并设置开机启动（不要等一台启动了再起另一台，直接两台一起或者三台一起启动），同上；
2.8、查看集群状态
[root@k8s-master1 ~]# ETCDCTL_API=3 /hqtbj/hqtwww/etcd/bin/etcdctl --cacert=/hqtbj/hqtwww/etcd/ssl/ca.pem --cert=/hqtbj/hqtwww/etcd/ssl/etcd-server.pem --key=/hqtbj/hqtwww/etcd/ssl/etcd-server-key.pem --endpoints="https://172.32.0.11:2379,https://172.32.0.12:2379,https://172.32.0.13:2379" endpoint health --write-out=table
+--------------------------+--------+-------------+-------+
| ENDPOINT | HEALTH | TOOK | ERROR |
+--------------------------+--------+-------------+-------+
| https://172.32.0.13:2379 | true | 11.686469ms | |
| https://172.32.0.11:2379 | true | 11.83647ms | |
| https://172.32.0.12:2379 | true | 11.999272ms | |
+--------------------------+--------+-------------+-------+
如果输出上面信息，就说明集群部署成功；
三、安装Docker
这里使用Docker作为容器引擎，也可以换成别的，例如containerd
二进制下载地址：https://download.docker.com/linux/static/stable/x86_64/
以下操作需在所有节点操作，为了方便，这里使用yum安装，二进制安装也一样；
1、下载安装docker并启动；
[root@k8s-master1 ~]# yum update
[root@k8s-master1 ~]# wget https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo -O /etc/yum.repos.d/docker-ce.repo
[root@k8s-master1 ~]# yum -y install docker-ce
[root@k8s-master1 ~]# systemctl enable docker && systemctl start docker
[root@k8s-master1 ~]# docker info
2、创建docker配置文件
[root@k8s-master1 ~]# vim /etc/docker/daemon.json
{
"registry-mirrors": ["https://b9pmyelo.mirror.aliyuncs.com"]
}
[root@k8s-master1 ~]# systemctl restart docker
registry-mirrors: [“https://b9pmyelo.mirror.aliyuncs.com”]：使用阿里云的加速器，否则下载镜像会慢；
四、部署k8s-master节点
1、生成kube-apiserver服务证书
1.1、自签kubernetes证书颁发机构（根CA）
创建请求证书的json配置文件（自签CA）
[root@k8s-master1 ~]# cd /hqtbj/hqtwww/TLS/k8s/
[root@k8s-master1 k8s]# vim ca-config.json
{
"signing": {
"default": {
"expiry": "87600h"
},
"profiles": {
"kubernetes": {
"expiry": "87600h",
"usages": [
"signing",
"key encipherment",
"server auth",
"client auth"
]
}
}
}
}
创建kubernetes根CA证书签名请求文件
[root@k8s-master1 k8s]# vim ca-csr.json
{
"CN": "kubernetes",
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"L": "Beijing",
"ST": "Beijing",
"O": "k8s",
"OU": "System"
}
]
}
生成kubernetes根证书
[root@k8s-master1 k8s]# ll
total 8
-rw-r--r-- 1 root root 294 Sep 4 13:44 ca-config.json
-rw-r--r-- 1 root root 264 Sep 4 13:50 ca-csr.json
[root@k8s-master1 k8s]# cfssl gencert -initca ca-csr.json | cfssljson -bare ca -
[root@k8s-master1 k8s]# ll
total 20
-rw-r--r-- 1 root root 294 Sep 4 13:44 ca-config.json
-rw-r--r-- 1 root root 1001 Sep 4 13:51 ca.csr
-rw-r--r-- 1 root root 264 Sep 4 13:50 ca-csr.json
-rw------- 1 root root 1679 Sep 4 13:51 ca-key.pem
-rw-r--r-- 1 root root 1359 Sep 4 13:51 ca.pem
会生成ca.pem证书和ca-key.pem私钥
1.2、使用自签的CA来签发kube-apiserver HTTPS证书
创建kube-apiserver证书的csr申请文件：
[root@k8s-master1 k8s]# vim kube-apiserver-csr.json
{
"CN": "kubernetes",
"hosts": [
"10.0.0.1",
"127.0.0.1",
"172.32.0.11",
"172.32.0.12",
"172.32.0.13",
"172.32.0.14",
"172.32.0.15",
"172.32.0.16",
"172.32.0.17",
"172.32.0.18",
"172.32.0.19",
"172.32.0.20",
"172.32.0.21",
"172.32.0.22",
"172.32.0.23",
"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"
}
]
}
提示：上述文件hosts字段中IP为所有Master/LB/VIP IP，一个都不能少！为了方便后期扩容可以多写几个预留的IP，后面部署高可用会用到！！
生成kube-apisever证书
[root@k8s-master1 k8s]# ll
total 24
-rw-r--r-- 1 root root 294 Sep 4 13:44 ca-config.json
-rw-r--r-- 1 root root 1001 Sep 4 13:51 ca.csr
-rw-r--r-- 1 root root 264 Sep 4 13:50 ca-csr.json
-rw------- 1 root root 1679 Sep 4 13:51 ca-key.pem
-rw-r--r-- 1 root root 1359 Sep 4 13:51 ca.pem
-rw-r--r-- 1 root root 800 Sep 4 13:59 kube-apiserver-csr.json
[root@k8s-master1 k8s]# cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes kube-apiserver-csr.json | cfssljson -bare kube-apiserver
[root@k8s-master1 k8s]# ll
total 36
-rw-r--r-- 1 root root 294 Sep 4 13:44 ca-config.json
-rw-r--r-- 1 root root 1001 Sep 4 13:51 ca.csr
-rw-r--r-- 1 root root 264 Sep 4 13:50 ca-csr.json
-rw------- 1 root root 1679 Sep 4 13:51 ca-key.pem
-rw-r--r-- 1 root root 1359 Sep 4 13:51 ca.pem
-rw-r--r-- 1 root root 1342 Sep 4 14:03 kube-apiserver.csr
-rw-r--r-- 1 root root 761 Sep 4 14:03 kube-apiserver-csr.json
-rw------- 1 root root 1675 Sep 4 14:03 kube-apiserver-key.pem
-rw-r--r-- 1 root root 1708 Sep 4 14:03 kube-apiserver.pem
会生成kube-apiserver.pem证书和kube-apiserver-key.pem私钥
1.3、从Github下载kubernetes二进制文件
下载地址：https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#downloads-for-v12011
提示：打开链接你会发现里面有很多包，下载一个server包就够了，包含了Master和Worker Node二进制文件。
1.4、解压二进制包
[root@k8s-master1 ~]# mkdir -pv /hqtbj/hqtwww/kubernetes/{bin,cfg,ssl,logs}
mkdir: created directory ‘/hqtbj/hqtwww/kubernetes’
mkdir: created directory ‘/hqtbj/hqtwww/kubernetes/bin’
mkdir: created directory ‘/hqtbj/hqtwww/kubernetes/cfg’
mkdir: created directory ‘/hqtbj/hqtwww/kubernetes/ssl’
mkdir: created directory ‘/hqtbj/hqtwww/kubernetes/logs’
[root@k8s-master1 ~]# tar -zxf kubernetes-server-linux-amd64.tar.gz
[root@k8s-master1 ~]# cd kubernetes/server/bin/
[root@k8s-master1 bin]# cp kube-apiserver kube-scheduler kube-controller-manager /hqtbj/hqtwww/kubernetes/bin/
[root@k8s-master1 bin]# cp kubectl /usr/bin/
1.5、部署kube-apiserver
（1）创建配置文件
[root@k8s-master1 ~]# vim /hqtbj/hqtwww/kubernetes/cfg/kube-apiserver.conf
KUBE_APISERVER_OPTS="--logtostderr=false \
--v=2 \
--log-dir=/hqtbj/hqtwww/kubernetes/logs \
--etcd-servers=https://172.32.0.11:2379,https://172.32.0.12:2379,https://172.32.0.13:2379 \
--bind-address=172.32.0.11 \
--secure-port=6443 \
--advertise-address=172.32.0.11 \
--allow-privileged=true \
--service-cluster-ip-range=10.0.0.0/24 \
--enable-admission-plugins=NodeRestriction \
--authorization-mode=RBAC,Node \
--enable-bootstrap-token-auth=true \
--token-auth-file=/hqtbj/hqtwww/kubernetes/cfg/token.csv \
--service-node-port-range=30000-32767 \
--kubelet-client-certificate=/hqtbj/hqtwww/kubernetes/ssl/kube-apiserver.pem \
--kubelet-client-key=/hqtbj/hqtwww/kubernetes/ssl/kube-apiserver-key.pem \
--tls-cert-file=/hqtbj/hqtwww/kubernetes/ssl/kube-apiserver.pem \
--tls-private-key-file=/hqtbj/hqtwww/kubernetes/ssl/kube-apiserver-key.pem \
--client-ca-file=/hqtbj/hqtwww/kubernetes/ssl/ca.pem \
--service-account-key-file=/hqtbj/hqtwww/kubernetes/ssl/ca-key.pem \
--service-account-issuer=api \
--service-account-signing-key-file=/hqtbj/hqtwww/kubernetes/ssl/ca-key.pem \
--etcd-cafile=/hqtbj/hqtwww/etcd/ssl/ca.pem \
--etcd-certfile=/hqtbj/hqtwww/etcd/ssl/etcd-server.pem \
--etcd-keyfile=/hqtbj/hqtwww/etcd/ssl/etcd-server-key.pem \
--requestheader-client-ca-file=/hqtbj/hqtwww/kubernetes/ssl/ca.pem \
--proxy-client-cert-file=/hqtbj/hqtwww/kubernetes/ssl/kube-apiserver.pem \
--proxy-client-key-file=/hqtbj/hqtwww/kubernetes/ssl/kube-apiserver-key.pem \
--requestheader-allowed-names=kubernetes \
--requestheader-extra-headers-prefix=X-Remote-Extra- \
--requestheader-group-headers=X-Remote-Group \
--requestheader-username-headers=X-Remote-User \
--enable-aggregator-routing=true \
--audit-log-maxage=30 \
--audit-log-maxbackup=3 \
--audit-log-maxsize=100 \
--audit-log-path=/hqtbj/hqtwww/kubernetes/logs/k8s-audit.log"
–logtostderr：启用日志
–v：日志等级
–log-dir：日志的存放目录
–etcd-servers：etcd集群的地址
–bind-address：kube-apiserver监听地址
–secure-port：https安全端口
–advertise-address：集群通告地址
–allow-privileged：启用授权
–service-cluster-ip-range：service虚拟ip地址段
–enable-admission-plugins：准入控制模块
–authorization-mode：认证授权，启用RBAC授权和节点自管理
–enable-bootstrap-token-auth：启动TLS bootstrap机制
–token-auth-file：bootstrap tonken 文件
–service-node-port：service nodeport类型默认分配端口范围
–kubelet-client-xxx：kube-apiserver访问kubelet客户端的证书和私钥
–tls-xxxx-file：用于kube-apiserver对外提供服务的服务器证书和私钥（apiserver https证书）
–1.20版本必须加的参数：–service-account-issuer，–service-account-signing-key-file
–etcd-xxxfile：连接etcd集群的证书
–audit-log-xxx：审计日志
–启动聚合层相关配置：–requestheader-client-ca-file,–proxy-client-cert-file,–proxy-client-key-file,–requestheader-allowed-names,–requestheader-extra-headers-prefix,–requestheader-group-headers,–requestheader-username-headers,–enable-aggregator-routing
（2）拷贝刚才生成的证书
把刚才生成的kube-apiserver证书拷贝到配置文件中的路径：
[root@k8s-master1 ~]# cp /hqtbj/hqtwww/TLS/k8s/ca*pem /hqtbj/hqtwww/TLS/k8s/kube-apiserver*pem /hqtbj/hqtwww/kubernetes/ssl/
（3）启用 TLS Bootstrapping 机制
TLS Bootstraping：Master apiserver启用TLS认证后，Node节点kubelet和kube-proxy要与kube-apiserver进行通信，必须使用CA签发的有效证书才可以，当Node节点很多时，这种客户端证书颁发需要大量工作，同样也会增加集群扩展复杂度。为了简化流程，Kubernetes引入了TLS bootstraping机制来自动颁发客户端证书，kubelet会以一个低权限用户自动向apiserver申请证书，kubelet的证书由apiserver动态签署。所以强烈建议在Node上使用这种方式，目前主要用于kubelet，kube-proxy还是由我们统一颁发一个证书；
TLS bootstraping工作流程：
创建上面配置文件中的token文件（–token-auth-file=/hqtbj/hqtwww/kubernetes/cfg/token.csv）
[root@k8s-master1 ~]# head -c 16 /dev/urandom | od -An -t x | tr -d ' '
6c02be6b3c0875bc5783ecafcb6e10bc
[root@k8s-master1 ~]# vim /hqtbj/hqtwww/kubernetes/cfg/token.csv
6c02be6b3c0875bc5783ecafcb6e10bc,kubelet-bootstrap,10001,"system:node-bootstrapper"
格式：token,用户名,UID,用户组
这里的token也可以用上述命令自己生成然后替换；
（4）使用systemd管理kube-apiserver
[root@k8s-master1 ~]# vim /usr/lib/systemd/system/kube-apiserver.service
[Unit]
Description=Kubernetes API Server
Documentation=https://github.com/kubernetes/kubernetes
[Service]
EnvironmentFile=/hqtbj/hqtwww/kubernetes/cfg/kube-apiserver.conf
ExecStart=/hqtbj/hqtwww/kubernetes/bin/kube-apiserver $KUBE_APISERVER_OPTS
Restart=on-failure
[Install]
WantedBy=multi-user.target
（5）启动并设置开机自启
[root@k8s-master1 ~]# systemctl daemon-reload
[root@k8s-master1 ~]# systemctl start kube-apiserver
[root@k8s-master1 ~]# systemctl enable kube-apiserver
1.6、部署kube-controller-manager
（1）创建配置文件
[root@k8s-master1 ~]# vim /hqtbj/hqtwww/kubernetes/cfg/kube-controller-manager.conf
KUBE_CONTROLLER_MANAGER_OPTS="--logtostderr=false \
--v=2 \
--log-dir=/hqtbj/hqtwww/kubernetes/logs \
--leader-elect=true \
--kubeconfig=/hqtbj/hqtwww/kubernetes/cfg/kube-controller-manager.kubeconfig \
--bind-address=127.0.0.1 \
--allocate-node-cidrs=true \
--cluster-cidr=10.244.0.0/16 \
--service-cluster-ip-range=10.0.0.0/24 \
--cluster-signing-cert-file=/hqtbj/hqtwww/kubernetes/ssl/ca.pem \
--cluster-signing-key-file=/hqtbj/hqtwww/kubernetes/ssl/ca-key.pem \
--root-ca-file=/hqtbj/hqtwww/kubernetes/ssl/ca.pem \
--service-account-private-key-file=/hqtbj/hqtwww/kubernetes/ssl/ca-key.pem \
--cluster-signing-duration=87600h0m0s"
–cluster-cidr：设置集群内pod使用的网络
–kubeconfig：连接apiserver的配置文件
–leader-elect：当该组件启动多个时，自动选举（HA）
–cluster-signing-cert-file：用于签发证书的根CA证书
–cluster-signing-key-file：用于签发证书的根CA私钥
（2）使用自签的CA来签发kube-controller-manager HTTPS证书
创建controller-manager证书的csr申请文件
[root@k8s-master1 ~]# cd /hqtbj/hqtwww/TLS/k8s/
[root@k8s-master1 k8s]# vim kube-controller-manager-csr.json
{
"CN": "system:kube-controller-manager",
"hosts": [],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"L": "BeiJing",
"ST": "BeiJing",
"O": "system:masters",
"OU": "System"
}
]
}
生成kube-controller-manager证书
[root@k8s-master1 k8s]# cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes kube-controller-manager-csr.json | cfssljson -bare kube-controller-manager
[root@k8s-master1 k8s]# ll
total 52
-rw-r--r-- 1 root root 294 Sep 4 13:44 ca-config.json
-rw-r--r-- 1 root root 1001 Sep 4 13:51 ca.csr
-rw-r--r-- 1 root root 264 Sep 4 13:50 ca-csr.json
-rw------- 1 root root 1679 Sep 4 13:51 ca-key.pem
-rw-r--r-- 1 root root 1359 Sep 4 13:51 ca.pem
-rw-r--r-- 1 root root 1342 Sep 4 14:03 kube-apiserver.csr
-rw-r--r-- 1 root root 761 Sep 4 14:03 kube-apiserver-csr.json
-rw------- 1 root root 1675 Sep 4 14:03 kube-apiserver-key.pem
-rw-r--r-- 1 root root 1708 Sep 4 14:03 kube-apiserver.pem
-rw-r--r-- 1 root root 1045 Sep 4 15:02 kube-controller-manager.csr
-rw-r--r-- 1 root root 255 Sep 4 15:01 kube-controller-manager-csr.json
-rw------- 1 root root 1675 Sep 4 15:02 kube-controller-manager-key.pem
-rw-r--r-- 1 root root 1436 Sep 4 15:02 kube-controller-manager.pem
会生成kube-controller-manager.pem证书和kube-controller-manager-key.pem私钥
（3）生成kube-controller-manager的kubeconfig文件（以下是shell命令，直接在终端执行）
设置kubeconfig文件的目录以及kube-apiserver地址的变量，方便后面引用
[root@k8s-master1 k8s]# KUBE_CONFIG="/hqtbj/hqtwww/kubernetes/cfg/kube-controller-manager.kubeconfig"
[root@k8s-master1 k8s]# KUBE_APISERVER="https://172.32.0.11:6443"
设置集群信息
[root@k8s-master1 k8s]# kubectl config set-cluster kubernetes \
> --certificate-authority=/hqtbj/hqtwww/kubernetes/ssl/ca.pem \
> --embed-certs=true \
> --server=${KUBE_APISERVER} \
> --kubeconfig=${KUBE_CONFIG}
Cluster "kubernetes" set.
–certificate-authority：用于验证kube-apiserver服务器证书的CA证书
设置kube-controller-manager的用户信息
[root@k8s-master1 k8s]# kubectl config set-credentials kube-controller-manager \
> --client-certificate=/hqtbj/hqtwww/TLS/k8s/kube-controller-manager.pem \
> --client-key=/hqtbj/hqtwww/TLS/k8s/kube-controller-manager-key.pem \
> --embed-certs=true \
> --kubeconfig=${KUBE_CONFIG}
User "kube-controller-manager" set.
–client-certificate：用于访问kube-apiserver的客户端证书
–client-key：客户端证书所对应的私钥
设置controller-manager的kubeconfig上下文信息
[root@k8s-master1 k8s]# kubectl config set-context default \
> --cluster=kubernetes \
> --user=kube-controller-manager \
> --kubeconfig=${KUBE_CONFIG}
Context "default" created.
[root@k8s-master1 k8s]# kubectl config use-context default --kubeconfig=${KUBE_CONFIG}
Switched to context "default".
这样我们的kube-controller-manager连接api-server的kubeconfig配置文件就生成好了；可以看出kube-controller是作为客户端去连接apiserver服务的；
##########待补充############
（4）部署kube-controller-manager并启动
[root@k8s-master1 k8s]# vim /usr/lib/systemd/system/kube-controller-manager.service
[Unit]
Description=Kubernetes Controller Manager
Documentation=https://github.com/kubernetes/kubernetes
[Service]
EnvironmentFile=/hqtbj/hqtwww/kubernetes/cfg/kube-controller-manager.conf
ExecStart=/hqtbj/hqtwww/kubernetes/bin/kube-controller-manager \$KUBE_CONTROLLER_MANAGER_OPTS
Restart=on-failure
[Install]
WantedBy=multi-user.target
[root@k8s-master1 k8s]# systemctl daemon-reload
[root@k8s-master1 k8s]# systemctl start kube-controller-manager
[root@k8s-master1 k8s]# systemctl enable kube-controller-manager
1.7、部署kube-scheduler
（1）创建配置文件
[root@k8s-master1 ~]# vim /hqtbj/hqtwww/kubernetes/cfg/kube-scheduler.conf
KUBE_SCHEDULER_OPTS="--logtostderr=false \
--v=2 \
--log-dir=/hqtbj/hqtwww/kubernetes/logs \
--leader-elect \
--kubeconfig=/hqtbj/hqtwww/kubernetes/cfg/kube-scheduler.kubeconfig \
--bind-address=127.0.0.1"
–kubeconfig：连接api-server的配置文件
–leader-elect：当该组件启动多个时，自动选举（HA）
（2）使用自签的CA来签发kube-scheduler HTTPS证书
创建scheduler证书的csr申请文件
[root@k8s-master1 ~]# cd /hqtbj/hqtwww/TLS/k8s/
[root@k8s-master1 k8s]# vim kube-scheduler-csr.json
{
"CN": "system:kube-scheduler",
"hosts": [],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"L": "BeiJing",
"ST": "BeiJing",
"O": "system:masters",
"OU": "System"
}
]
}
生成证书
[root@k8s-master1 k8s]# cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes kube-scheduler-csr.json | cfssljson -bare kube-scheduler
[root@k8s-master1 k8s]# ll
total 68
-rw-r--r-- 1 root root 294 Sep 4 13:44 ca-config.json
-rw-r--r-- 1 root root 1001 Sep 4 13:51 ca.csr
-rw-r--r-- 1 root root 264 Sep 4 13:50 ca-csr.json
-rw------- 1 root root 1679 Sep 4 13:51 ca-key.pem
-rw-r--r-- 1 root root 1359 Sep 4 13:51 ca.pem
-rw-r--r-- 1 root root 1342 Sep 4 14:03 kube-apiserver.csr
-rw-r--r-- 1 root root 761 Sep 4 14:03 kube-apiserver-csr.json
-rw------- 1 root root 1675 Sep 4 14:03 kube-apiserver-key.pem
-rw-r--r-- 1 root root 1708 Sep 4 14:03 kube-apiserver.pem
-rw-r--r-- 1 root root 1045 Sep 4 15:02 kube-controller-manager.csr
-rw-r--r-- 1 root root 255 Sep 4 15:01 kube-controller-manager-csr.json
-rw------- 1 root root 1675 Sep 4 15:02 kube-controller-manager-key.pem
-rw-r--r-- 1 root root 1436 Sep 4 15:02 kube-controller-manager.pem
-rw-r--r-- 1 root root 1029 Sep 4 15:24 kube-scheduler.csr
-rw-r--r-- 1 root root 245 Sep 4 15:22 kube-scheduler-csr.json
-rw------- 1 root root 1679 Sep 4 15:24 kube-scheduler-key.pem
-rw-r--r-- 1 root root 1424 Sep 4 15:24 kube-scheduler.pem
（3）生成kube-scheduler的kubeconfig文件（以下是shell命令，直接在终端执行）
[root@k8s-master1 k8s]# KUBE_CONFIG="/hqtbj/hqtwww/kubernetes/cfg/kube-scheduler.kubeconfig"
[root@k8s-master1 k8s]# KUBE_APISERVER="https://172.32.0.11:6443"
[root@k8s-master1 k8s]# kubectl config set-cluster kubernetes \
> --certificate-authority=/hqtbj/hqtwww/kubernetes/ssl/ca.pem \
> --embed-certs=true \
> --server=${KUBE_APISERVER} \
> --kubeconfig=${KUBE_CONFIG}
Cluster "kubernetes" set.
[root@k8s-master1 k8s]# kubectl config set-credentials kube-scheduler \
> --client-certificate=/hqtbj/hqtwww/TLS/k8s/kube-scheduler.pem \
> --client-key=/hqtbj/hqtwww/TLS/k8s/kube-scheduler-key.pem \
> --embed-certs=true \
> --kubeconfig=${KUBE_CONFIG}
User "kube-scheduler" set.
[root@k8s-master1 k8s]# kubectl config set-context default \
> --cluster=kubernetes \
> --user=kube-scheduler \
> --kubeconfig=${KUBE_CONFIG}
Context "default" created.
[root@k8s-master1 k8s]# kubectl config use-context default --kubeconfig=${KUBE_CONFIG}
Switched to context "default".
（4）部署kube-scheduler并启动
[root@k8s-master1 k8s]# vim /usr/lib/systemd/system/kube-scheduler.service
[Unit]
Description=Kubernetes Scheduler
Documentation=https://github.com/kubernetes/kubernetes
[Service]
EnvironmentFile=/hqtbj/hqtwww/kubernetes/cfg/kube-scheduler.conf
ExecStart=/hqtbj/hqtwww/kubernetes/bin/kube-scheduler $KUBE_SCHEDULER_OPTS
Restart=on-failure
[Install]
WantedBy=multi-user.target
[root@k8s-master1 k8s]# systemctl daemon-reload
[root@k8s-master1 k8s]# systemctl start kube-scheduler
[root@k8s-master1 k8s]# systemctl enable kube-scheduler
1.8、查看集群状态
（1）生成kubectl工具连接集群的证书（kubeadm安装方式默认生成的在/root/.kube/config）
创建kubect证书的csr申请文件
[root@k8s-master1 k8s]# vim kubectl-admin-cluster-csr.json
{
"CN": "admin",
"hosts": [],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"L": "BeiJing",
"ST": "BeiJing",
"O": "system:masters",
"OU": "System"
}
]
}
生成证书
[root@k8s-master1 k8s]# cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes kubectl-admin-cluster-csr.json | cfssljson -bare kubectl-admin-cluster
[root@k8s-master1 k8s]# ll
total 84
-rw-r--r-- 1 root root 294 Sep 4 13:44 ca-config.json
-rw-r--r-- 1 root root 1001 Sep 4 13:51 ca.csr
-rw-r--r-- 1 root root 264 Sep 4 13:50 ca-csr.json
-rw------- 1 root root 1679 Sep 4 13:51 ca-key.pem
-rw-r--r-- 1 root root 1359 Sep 4 13:51 ca.pem
-rw-r--r-- 1 root root 1342 Sep 4 14:03 kube-apiserver.csr
-rw-r--r-- 1 root root 761 Sep 4 14:03 kube-apiserver-csr.json
-rw------- 1 root root 1675 Sep 4 14:03 kube-apiserver-key.pem
-rw-r--r-- 1 root root 1708 Sep 4 14:03 kube-apiserver.pem
-rw-r--r-- 1 root root 1045 Sep 4 15:02 kube-controller-manager.csr
-rw-r--r-- 1 root root 255 Sep 4 15:01 kube-controller-manager-csr.json
-rw------- 1 root root 1675 Sep 4 15:02 kube-controller-manager-key.pem
-rw-r--r-- 1 root root 1436 Sep 4 15:02 kube-controller-manager.pem
-rw-r--r-- 1 root root 1009 Sep 4 15:39 kubectl-admin-cluster.csr
-rw-r--r-- 1 root root 229 Sep 4 15:38 kubectl-admin-cluster-csr.json
-rw------- 1 root root 1675 Sep 4 15:39 kubectl-admin-cluster-key.pem
-rw-r--r-- 1 root root 1399 Sep 4 15:39 kubectl-admin-cluster.pem
-rw-r--r-- 1 root root 1029 Sep 4 15:24 kube-scheduler.csr
-rw-r--r-- 1 root root 245 Sep 4 15:22 kube-scheduler-csr.json
-rw------- 1 root root 1679 Sep 4 15:24 kube-scheduler-key.pem
-rw-r--r-- 1 root root 1424 Sep 4 15:24 kube-scheduler.pem
（2）生成kubectl的kubeconfig文件（以下是shell命令，直接在终端执行）
[root@k8s-master1 k8s]# mkdir /root/.kube
[root@k8s-master1 k8s]# KUBE_CONFIG="/root/.kube/config"
[root@k8s-master1 k8s]# KUBE_APISERVER="https://172.32.0.11:6443"
[root@k8s-master1 k8s]# kubectl config set-cluster kubernetes \
> --certificate-authority=/hqtbj/hqtwww/kubernetes/ssl/ca.pem \
> --embed-certs=true \
> --server=${KUBE_APISERVER} \
> --kubeconfig=${KUBE_CONFIG}
Cluster "kubernetes" set.
[root@k8s-master1 k8s]# kubectl config set-credentials cluster-admin \
> --client-certificate=/hqtbj/hqtwww/TLS/k8s/kubectl-admin-cluster.pem \
> --client-key=/hqtbj/hqtwww/TLS/k8s/kubectl-admin-cluster-key.pem \
> --embed-certs=true \
> --kubeconfig=${KUBE_CONFIG}
User "cluster-admin" set.
[root@k8s-master1 k8s]# kubectl config set-context default \
> --cluster=kubernetes \
> --user=cluster-admin \
> --kubeconfig=${KUBE_CONFIG}
Context "default" created.
[root@k8s-master1 k8s]# kubectl config use-context default --kubeconfig=${KUBE_CONFIG}
Switched to context "default".
上面我们就把kubectl连接kube-api-server的配置完成了，接下来执行kubectl命令查看集群组件的状态；
[root@k8s-master1 k8s]# kubectl get cs
Warning: v1 ComponentStatus is deprecated in v1.19+
NAME STATUS MESSAGE ERROR
controller-manager Healthy ok
scheduler Healthy ok
etcd-1 Healthy {"health":"true"}
etcd-2 Healthy {"health":"true"}
etcd-0 Healthy {"health":"true"}
如上输出说明master节点运行正常
1.9、授权kubelet-bootstrap用户允许请求证书
允许 kubelet-bootstrap 用户创建首次启动的 CSR 请求（kubelet组件加入集群的请求）
[root@k8s-master1 k8s]# kubectl create clusterrolebinding kubelet-bootstrap \
> --clusterrole=system:node-bootstrapper \
> --user=kubelet-bootstrap
clusterrolebinding.rbac.authorization.k8s.io/kubelet-bootstrap created
[root@k8s-master1 k8s]# kubectl get clusterrolebinding
NAME ROLE AGE
cluster-admin ClusterRole/cluster-admin 54m
kubelet-bootstrap ClusterRole/system:node-bootstrapper 8s
......
在有些用户首次启动的时候，可能会遇到kubelet报401无权访问apiserver的错误；这是因为在默认情况下，kubelet通过bootstrap.kubeconfig中的预设用户Token声明了自己的身份，然后创建CSR请求；但是不要忘记这个用户在我们不处理的情况下它没任何权限，包括创建CSR请求；所以需要如上命令创建一个ClusterRoleBinding，将预设用户kubelet-bootstrap与内置的ClusterRole system:node-bootstrapper绑定到一起，使其能够发起CSR请求；
五、部署work node
下面还是在Master Node上操作，即同时作为Worker Node
1、创建工作目录并拷贝二进制文件
在所有worker node创建工作目录
将从github下载的kubernete二进制文件包里的kubelet、kube-proxy组件拷贝到工作节点
[root@k8s-master1 ~]# cd /root/kubernetes/server/bin
[root@k8s-master1 bin]# ll
total 968412
-rwxr-xr-x. 1 root root 46690304 Sep 16 2021 apiextensions-apiserver
-rwxr-xr-x. 1 root root 39219200 Sep 16 2021 kubeadm
-rwxr-xr-x. 1 root root 44687360 Sep 16 2021 kube-aggregator
-rwxr-xr-x. 1 root root 118272000 Sep 16 2021 kube-apiserver
-rw-r--r--. 1 root root 9 Sep 16 2021 kube-apiserver.docker_tag
-rw-------. 1 root root 123088384 Sep 16 2021 kube-apiserver.tar
-rwxr-xr-x. 1 root root 112799744 Sep 16 2021 kube-controller-manager
-rw-r--r--. 1 root root 9 Sep 16 2021 kube-controller-manager.docker_tag
-rw-------. 1 root root 117616128 Sep 16 2021 kube-controller-manager.tar
-rwxr-xr-x. 1 root root 40226816 Sep 16 2021 kubectl
-rwxr-xr-x. 1 root root 114150568 Sep 16 2021 kubelet
-rwxr-xr-x. 1 root root 39489536 Sep 16 2021 kube-proxy
-rw-r--r--. 1 root root 9 Sep 16 2021 kube-proxy.docker_tag
-rw-------. 1 root root 101492224 Sep 16 2021 kube-proxy.tar
-rwxr-xr-x. 1 root root 43724800 Sep 16 2021 kube-scheduler
-rw-r--r--. 1 root root 9 Sep 16 2021 kube-scheduler.docker_tag
-rw-------. 1 root root 48541184 Sep 16 2021 kube-scheduler.tar
-rwxr-xr-x. 1 root root 1634304 Sep 16 2021 mounter
[root@k8s-master1 bin]# cp kubelet kube-proxy /hqtbj/hqtwww/kubernetes/bin/
1.1、部署kubelet
（1）创建配置文件
[root@k8s-master1 ~]# cd /hqtbj/hqtwww/kubernetes/cfg
[root@k8s-master1 cfg]# vim kubelet.conf
KUBELET_OPTS="--logtostderr=false \
--v=2 \
--log-dir=/hqtbj/hqtwww/kubernetes/logs \
--hostname-override=k8s-master1 \
--network-plugin=cni \
--kubeconfig=/hqtbj/hqtwww/kubernetes/cfg/kubelet.kubeconfig \
--bootstrap-kubeconfig=/hqtbj/hqtwww/kubernetes/cfg/bootstrap.kubeconfig \
--config=/hqtbj/hqtwww/kubernetes/cfg/kubelet-config.yml \
--cert-dir=/hqtbj/hqtwww/kubernetes/ssl \
--pod-infra-container-image=registry.cn-hangzhou.aliyuncs.com/google_containers/pause-amd64:3.0"
–hostname-override：显示名称，集群中唯一
–network-plugin：启用CNI
–kubeconfig：空路径，会自动生成，后面用于连接apiserver
–bootstrap-kubeconfig：首次启动向apiserver申请证书的文件
–config：配置参数文件
–cert-dir：kubelet证书生成目录
–pod-infra-container-image：管理pod网络容器（infra容器）的镜像
（2）创建配置参数（kubelet-config.yml）文件
[root@k8s-master1 cfg]# vim kubelet-config.yml
kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
address: 0.0.0.0
port: 10250
readOnlyPort: 10255
cgroupDriver: cgroupfs
clusterDNS:
- 10.0.0.2
clusterDomain: cluster.local
failSwapOn: false
authentication:
anonymous:
enabled: false
webhook:
cacheTTL: 2m0s
enabled: true
x509:
clientCAFile: /hqtbj/hqtwww/kubernetes/ssl/ca.pem
authorization:
mode: Webhook
webhook:
cacheAuthorizedTTL: 5m0s
cacheUnauthorizedTTL: 30s
evictionHard:
imagefs.available: 15%
memory.available: 100Mi
nodefs.available: 10%
nodefs.inodesFree: 5%
maxOpenFiles: 1000000
maxPods: 110
clusterDNS:为集群内部dns的地址（后面安装CoreDNS的时候需要）；
clusterDomain: 为本地集群的dns域名，后面部署CoreDNS也需要用；
（3）生成kubelet初次加入集群向apiserver申请证书的kubeconfig文件
在我理解这里也可以是kubelet的kubeconfig文件（kubelet.kubeconifg）
[root@k8s-master1 cfg]# KUBE_CONFIG="/hqtbj/hqtwww/kubernetes/cfg/bootstrap.kubeconfig"
[root@k8s-master1 cfg]# KUBE_APISERVER="https://172.32.0.11:6443" #apiserver的地址
[root@k8s-master1 cfg]# TOKEN="6c02be6b3c0875bc5783ecafcb6e10bc" #与token.csv文件里保持一直
[root@k8s-master1 cfg]# kubectl config set-cluster kubernetes \
> --certificate-authority=/hqtbj/hqtwww/kubernetes/ssl/ca.pem \
> --embed-certs=true \
> --server=${KUBE_APISERVER} \
> --kubeconfig=${KUBE_CONFIG}
Cluster "kubernetes" set.
[root@k8s-master1 cfg]# kubectl config set-credentials "kubelet-bootstrap" \
> --token=${TOKEN} \
> --kubeconfig=${KUBE_CONFIG}
User "kubelet-bootstrap" set.
[root@k8s-master1 cfg]# kubectl config set-context default \
> --cluster=kubernetes \
> --user="kubelet-bootstrap" \
> --kubeconfig=${KUBE_CONFIG}
Context "default" created.
[root@k8s-master1 cfg]# kubectl config use-context default --kubeconfig=${KUBE_CONFIG}
Switched to context "default".
（4）systemd管理kubelet 并启动
[root@k8s-master1 ~]# vim /usr/lib/systemd/system/kubelet.service
[Unit]
Description=Kubernetes Kubelet
After=docker.service
[Service]
EnvironmentFile=/hqtbj/hqtwww/kubernetes/cfg/kubelet.conf
ExecStart=/hqtbj/hqtwww/kubernetes/bin/kubelet $KUBELET_OPTS
Restart=on-failure
LimitNOFILE=65536
[Install]
WantedBy=multi-user.target
[root@k8s-master1 ~]# systemctl daemon-reload
[root@k8s-master1 ~]# systemctl start kubelet
[root@k8s-master1 ~]# systemctl enable kubelet
1.2、在master节点上批准kubelet证书申请并加入集群
#查看kubelet证书请求
[root@k8s-master1 ~]# kubectl get csr
NAME AGE SIGNERNAME REQUESTOR CONDITION
node-csr-gLVg4Mw43pDAk6aEP8MSHzQKVgx_aitjPr9o-InDFxw 8m13s kubernetes.io/kube-apiserver-client-kubelet kubelet-bootstrap Pending
#批准申请
[root@k8s-master1 ~]# kubectl certificate approve node-csr-gLVg4Mw43pDAk6aEP8MSHzQKVgx_aitjPr9o-InDFxw
certificatesigningrequest.certificates.k8s.io/node-csr-gLVg4Mw43pDAk6aEP8MSHzQKVgx_aitjPr9o-InDFxw approved
[root@k8s-master1 ~]# kubectl get csr
NAME AGE SIGNERNAME REQUESTOR CONDITION
node-csr-gLVg4Mw43pDAk6aEP8MSHzQKVgx_aitjPr9o-InDFxw 17m kubernetes.io/kube-apiserver-client-kubelet kubelet-bootstrap Approved,Issued
#查看节点
[root@k8s-master1 ~]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-master1 NotReady <none> 79s v1.20.11
注：由于网络插件还没有部署，节点会没有准备就绪 NotReady
1.3、部署kube-proxy
（1）创建配置文件
[root@k8s-master1 cfg]# vim kube-proxy.conf
KUBE_PROXY_OPTS="--logtostderr=false \
--v=2 \
--log-dir=/hqtbj/hqtwww/kubernetes/logs \
--config=/hqtbj/hqtwww/kubernetes/cfg/kube-proxy-config.yml"
（2）创建配置参数（kube-proxy-config.yml）文件
[root@k8s-master1 cfg]# vim kube-proxy-config.yml
kind: KubeProxyConfiguration
apiVersion: kubeproxy.config.k8s.io/v1alpha1
bindAddress: 0.0.0.0
metricsBindAddress: 0.0.0.0:10249
clientConnection:
kubeconfig: /hqtbj/hqtwww/kubernetes/cfg/kube-proxy.kubeconfig
hostnameOverride: k8s-master1
clusterCIDR: 10.244.0.0/16
（3）生成kube-proxy.kubeconfig文件
切换至工作目录
[root@k8s-master1 ~]# cd /hqtbj/hqtwww/TLS/k8s/
创建kube-proxy证书的csr申请文件
[root@k8s-master1 k8s]# vim kube-proxy-csr.json
{
"CN": "system:kube-proxy",
"hosts": [],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"L": "BeiJing",
"ST": "BeiJing",
"O": "k8s",
"OU": "System"
}
]
}
生成证书
[root@k8s-master1 k8s]# cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes kube-proxy-csr.json | cfssljson -bare kube-proxy
[root@k8s-master1 k8s]# ll
total 100
-rw-r--r--. 1 root root 294 Oct 2 16:39 ca-config.json
-rw-r--r--. 1 root root 1001 Oct 2 16:44 ca.csr
-rw-r--r--. 1 root root 264 Oct 2 16:44 ca-csr.json
-rw-------. 1 root root 1679 Oct 2 16:44 ca-key.pem
-rw-r--r--. 1 root root 1359 Oct 2 16:44 ca.pem
-rw-r--r--. 1 root root 1285 Oct 2 16:47 kube-apiserver.csr
-rw-r--r--. 1 root root 614 Oct 2 16:47 kube-apiserver-csr.json
-rw-------. 1 root root 1675 Oct 2 16:47 kube-apiserver-key.pem
-rw-r--r--. 1 root root 1651 Oct 2 16:47 kube-apiserver.pem
-rw-r--r-- 1 root root 1045 Oct 3 09:37 kube-controller-manager.csr
-rw-r--r-- 1 root root 254 Oct 3 09:36 kube-controller-manager-csr.json
-rw------- 1 root root 1679 Oct 3 09:37 kube-controller-manager-key.pem
-rw-r--r-- 1 root root 1436 Oct 3 09:37 kube-controller-manager.pem
-rw-r--r-- 1 root root 1009 Oct 3 16:53 kubectl-admin-cluster.csr
-rw-r--r-- 1 root root 229 Oct 3 16:31 kubectl-admin-cluster-csr.json
-rw------- 1 root root 1679 Oct 3 16:53 kubectl-admin-cluster-key.pem
-rw-r--r-- 1 root root 1399 Oct 3 16:53 kubectl-admin-cluster.pem
-rw-r--r-- 1 root root 1009 Oct 4 10:17 kube-proxy.csr
-rw-r--r-- 1 root root 230 Oct 4 10:13 kube-proxy-csr.json
-rw------- 1 root root 1675 Oct 4 10:17 kube-proxy-key.pem
-rw-r--r-- 1 root root 1403 Oct 4 10:17 kube-proxy.pem
-rw-r--r-- 1 root root 1029 Oct 3 10:54 kube-scheduler.csr
-rw-r--r-- 1 root root 245 Oct 3 10:29 kube-scheduler-csr.json
-rw------- 1 root root 1679 Oct 3 10:54 kube-scheduler-key.pem
-rw-r--r-- 1 root root 1424 Oct 3 10:54 kube-scheduler.pem
生成kubeconfig文件
[root@k8s-master1 k8s]# KUBE_CONFIG="/hqtbj/hqtwww/kubernetes/cfg/kube-proxy.kubeconfig"
[root@k8s-master1 k8s]# KUBE_APISERVER="https://172.32.0.11:6443"
[root@k8s-master1 k8s]# kubectl config set-cluster kubernetes \
> --certificate-authority=/hqtbj/hqtwww/kubernetes/ssl/ca.pem \
> --embed-certs=true \
> --server=${KUBE_APISERVER} \
> --kubeconfig=${KUBE_CONFIG}
Cluster "kubernetes" set.
[root@k8s-master1 k8s]# kubectl config set-credentials kube-proxy \
> --client-certificate=/hqtbj/hqtwww/TLS/k8s/kube-proxy.pem \
> --client-key=/hqtbj/hqtwww/TLS/k8s/kube-proxy-key.pem \
> --embed-certs=true \
> --kubeconfig=${KUBE_CONFIG}
User "kube-proxy" set.
[root@k8s-master1 k8s]# kubectl config set-context default \
> --cluster=kubernetes \
> --user=kube-proxy \
> --kubeconfig=${KUBE_CONFIG}
Context "default" created.
[root@k8s-master1 k8s]# kubectl config use-context default --kubeconfig=${KUBE_CONFIG}
Switched to context "default".
（4）systemd管理kubelet 并启动
[root@k8s-master1 ~]# vim /usr/lib/systemd/system/kube-proxy.service
[Unit]
Description=Kubernetes Proxy
After=network.target
[Service]
EnvironmentFile=/hqtbj/hqtwww/kubernetes/cfg/kube-proxy.conf
ExecStart=/hqtbj/hqtwww/kubernetes/bin/kube-proxy $KUBE_PROXY_OPTS
Restart=on-failure
LimitNOFILE=65536
[Install]
WantedBy=multi-user.target
[root@k8s-master1 ~]# systemctl daemon-reload
[root@k8s-master1 ~]# systemctl start kube-proxy
[root@k8s-master1 ~]# systemctl enable kube-proxy
1.4、部署网络组件 calico
直接执行上面的kubectl命令即可安装
（1）修改配置（pod使用的网络）并运行calico
[root@k8s-master1 cfg]# wget https://docs.projectcalico.org/archive/v3.19/manifests/calico.yaml
[root@k8s-master1 cfg]# vim calico.yaml
- name: CALICO_IPV4POOL_CIDR #去掉注释，修改pod网络，这里的值需要跟kube-controller和kube-proxy的"--cluster-cidr"参数（设置集群网络）的值一样
value: "10.244.0.0/16"
...
#如果节点上有多块网卡的话可以绑定 指定的网卡
- name: IP_AUTODETECTION_METHOD
value: interface=ens33
# Auto-detect the BGP IP address.
[root@k8s-master1 cfg]# kubectl apply -f calico.yaml
configmap/calico-config created
...
[root@k8s-master1 cfg]# kubectl get pod -n kube-system
NAME READY STATUS RESTARTS AGE
calico-kube-controllers-848c5d445f-nnj4w 1/1 Running 0 13m
calico-node-n5gcl 1/1 Running 0 114s
等calico的pod都Running之后，节点也会准备就绪
[root@k8s-master1 cfg]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-master1 Ready <none> 14h v1.20.11
1.5、授权apiserver访问kubelet
在使用 kubectl exec、logs 命令时，会转到kubelet，需要对 apiserver 调用 kubelet API 的授权（否则在使用命令时会报
"error: unable to upgrade connection: Forbidden (user=kubernetes, verb=create, resource=nodes, subresource=proxy)"
"Error from server (Forbidden): Forbidden (user=kubernetes, verb=get, resource=nodes, subresource=proxy) ( pods/log busybox)"
的错误）。
[root@k8s-master1 cfg]# vim apiserver-to-kubelet-rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
annotations:
rbac.authorization.kubernetes.io/autoupdate: "true"
labels:
kubernetes.io/bootstrapping: rbac-defaults
name: system:kube-apiserver-to-kubelet
rules:
- apiGroups:
- ""
resources:
- nodes/proxy
- nodes/stats
- nodes/log
- nodes/spec
- nodes/metrics
- pods/log
verbs:
- "*"
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: system:kube-apiserver
namespace: ""
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: system:kube-apiserver-to-kubelet
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: kubernetes
[root@k8s-master1 cfg]# kubectl apply -f apiserver-to-kubelet-rbac.yaml
clusterrole.rbac.authorization.k8s.io/system:kube-apiserver-to-kubelet created
clusterrolebinding.rbac.authorization.k8s.io/system:kube-apiserver created
[root@k8s-master1 cfg]# kubectl get clusterrolebinding | grep "system:kube-apiserver"
system:kube-apiserver ClusterRole/system:kube-apiserver-to-kubelet 3m12s
[root@k8s-master1 cfg]# kubectl get clusterrole | grep "system:kube-apiserver-to-kubelet"
system:kube-apiserver-to-kubelet 2022-10-04T03:28:25Z
六、新增加worker node
1、拷贝已部署好的Node相关文件到新的节点
在Master节点将Worker Node涉及文件（也就是上面的kubelet和kube-proxy
配置）拷贝到新节点172.32.0.12/13
[root@k8s-master1 hqtwww]# scp -pr /hqtbj/hqtwww/kubernetes [email protected]:/hqtbj/hqtwww/
[root@k8s-master1 hqtwww]# scp -pr /usr/lib/systemd/system/{kubelet.service,kube-proxy.service} [email protected]:/usr/lib/systemd/system/
2、 删除kubelet证书和kubeconfig文件
注：这几个文件是证书申请审批后自动生成的，每个Node不同，必须删除
[root@k8s-node1 ~]# rm -rf /hqtbj/hqtwww/kubernetes/cfg/kubelet.kubeconfig
[root@k8s-node1 ~]# rm -rf /hqtbj/hqtwww/kubernetes/ssl/kubelet*
3、 修改主机名
将kubelet的配置文件和kube-proxy的配置参数文件里的主机名需要改成自己节点对应的主机名；
[root@k8s-node1 ~]# vim /hqtbj/hqtwww/kubernetes/cfg/kubelet.conf
--hostname-override=k8s-node1
[root@k8s-node1 ~]# vim /hqtbj/hqtwww/kubernetes/cfg/kube-proxy-config.yml
hostnameOverride: k8s-node1
4、 启动并设置开机自启
[root@k8s-node1 ~]# systemctl daemon-reload
[root@k8s-node1 ~]# systemctl start kubelet kube-proxy
[root@k8s-node1 ~]# systemctl enable kubelet kube-proxy
5、 在master上批准新的node kubelet证书申请
[root@k8s-master1 ~]# kubectl get csr
NAME AGE SIGNERNAME REQUESTOR CONDITION
node-csr-MkyR4V740DfH22Spd127UhuzUE38JXo_1garuCSpVUA 6m18s kubernetes.io/kube-apiserver-client-kubelet kubelet-bootstrap Pending
[root@k8s-master1 ~]# kubectl certificate approve node-csr-MkyR4V740DfH22Spd127UhuzUE38JXo_1garuCSpVUA
certificatesigningrequest.certificates.k8s.io/node-csr-MkyR4V740DfH22Spd127UhuzUE38JXo_1garuCSpVUA approved
node2节点同上，记得修改主机名
[root@k8s-master1 ~]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-master1 Ready <none> 21h v1.20.11
k8s-node1 Ready <none> 117s v1.20.11
k8s-node2 Ready <none> 10m v1.20.11
七、部署Core DNS和Ingress
CoreDNS用于集群内部Service名称解析；
在不安装CoreDNS的情况下，我们的pod是解析不了域名的；
1、部署CoreDNS
地址：https://github.com/coredns/deployment/blob/master/kubernetes/coredns.yaml.sed
这个目录下有一个deploy.sh的脚本，里面会有需要替换的参数，大家可以参考一下，也可以直接将一整个源码down下来然后改配置用这个deploy.sh的脚本启动；
这里我们直接将将这个文件下载下来修改配置（或者直接复制粘贴也可以）
2、修改CoreDNS配置(configmap 和 service处)
[root@k8s-master1 ~]# cd /hqtbj/hqtwww/kubernetes/cfg
[root@k8s-master1 cfg]# mv coredns.yaml.sed coredns.yml
然后需要修改configmap为本地集群解析，其它的内容不变！
[root@k8s-master1 cfg]# vim coredns.yml
apiVersion: v1
kind: ConfigMap
metadata:
name: coredns
namespace: kube-system
data:
Corefile: |
.:53 {
errors
health {
lameduck 5s
}
ready
#kubernetes CLUSTER_DOMAIN REVERSE_CIDRS {
kubernetes cluster.local in-addr.arpa ip6.arpa { #需要修改为本地集群的dns域名（在部署kubelet处配置过；详情请参考第“五”步的kubelet-config.yml 配置参数文件）
fallthrough in-addr.arpa ip6.arpa
}
prometheus :9153
#forward . UPSTREAMNAMESERVER {
forward . /etc/resolv.conf { #需要修改为本地DNS解析
max_concurrent 1000
}
cache 30
loop
reload
loadbalance
} #STUBDOMAINS
---
apiVersion: v1
kind: Service
metadata:
name: kube-dns
namespace: kube-system
annotations:
prometheus.io/port: "9153"
prometheus.io/scrape: "true"
labels:
k8s-app: kube-dns
kubernetes.io/cluster-service: "true"
kubernetes.io/name: "CoreDNS"
spec:
selector:
k8s-app: kube-dns
#clusterIP: CLUSTER_DNS_IP
clusterIP: 10.0.0.2 #需要修改为集群内部dns的地址（在部署kubelet处配置过；详情请参考第“五”步的kubelet-config.yml 配置参数文件）
- name: dns
port: 53
protocol: UDP
- name: dns-tcp
port: 53
protocol: TCP
- name: metrics
port: 9153
protocol: TCP
3、运行CoreDNS并验证域名解析功能
kubectl运行coredns.yml
[root@k8s-master1 cfg]# kubectl apply -f coredns.yml
serviceaccount/coredns created
clusterrole.rbac.authorization.k8s.io/system:coredns created
clusterrolebinding.rbac.authorization.k8s.io/system:coredns created
configmap/coredns created
deployment.apps/coredns created
service/kube-dns created
[root@k8s-master1 cfg]# kubectl get pod -n kube-system
NAME READY STATUS RESTARTS AGE
calico-kube-controllers-848c5d445f-c85b5 1/1 Running 0 95m
calico-node-dsmfk 1/1 Running 0 79m
calico-node-n5gcl 1/1 Running 1 2d2h
calico-node-rvss5 1/1 Running 1 43h
coredns-84bf88d4b-nkmgr 1/1 Running 0 2m18s #等待coredns pod Running之后再次尝试域名解析
[root@k8s-master1 cfg]# kubectl exec -it pod/busybox sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
/ # nslookup www.baidu.com
Server: 10.0.0.2 使用的是CoreDNS的地址
Address 1: 10.0.0.2 kube-dns.kube-system.svc.cluster.local
Name: www.baidu.com #可以看到已经解析成功
Address 1: 110.242.68.4
Address 2: 110.242.68.3
4、部署ingress
ingress项目地址：https://github.com/kubernetes/ingress-nginx
文档：https://kubernetes.github.io/ingress-nginx/deploy/
下载ingress的yml文件
[root@k8s-master1 ~]# mkdir -pv /hqtbj/hqtwww/kubernetes/Plug-in/ingress-nginx
[root@k8s-master1 ~]# cd /hqtbj/hqtwww/kubernetes/Plug-in/ingress-nginx
[root@k8s-master1 ingress-nginx]# wget -c https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.3.0/deploy/static/provider/baremetal/deploy.yaml
下载其它版本的话直接修改中间的版本号就行
[root@k8s-master1 ingress-nginx]# mv deploy.yaml ingress-controller.yaml
5、修改ingress配置
（1）需要将镜像地址（registry.k8s.io）修改为国内的（lank8s.cn）否则会下不了镜像
查看现在需要使用镜像
[root@k8s-master1 ingress-nginx]# grep -r "image:" ingress-controller.yaml
image: registry.k8s.io/ingress-nginx/controller:v1.3.0@sha256:d1707ca76d3b044ab8a28277a2466a02100ee9f58a86af1535a3edf9323ea1b5
image: registry.k8s.io/ingress-nginx/kube-webhook-certgen:v1.1.1@sha256:64d8c73dca984af206adf9d6d7e46aa550362b1d7a01f3a0a91b20cc67868660
image: registry.k8s.io/ingress-nginx/kube-webhook-certgen:v1.1.1@sha256:64d8c73dca984af206adf9d6d7e46aa550362b1d7a01f3a0a91b20cc67868660
批量修改镜像地址
[root@k8s-master1 ingress-nginx]# sed -i 's/registry.k8s.io/lank8s.cn/g' ingress-controller.yaml
[root@k8s-master1 ingress-nginx]# grep -r "image:" ingress-controller.yaml
image: lank8s.cn/ingress-nginx/controller:v1.3.0@sha256:d1707ca76d3b044ab8a28277a2466a02100ee9f58a86af1535a3edf9323ea1b5
image: lank8s.cn/ingress-nginx/kube-webhook-certgen:v1.1.1@sha256:64d8c73dca984af206adf9d6d7e46aa550362b1d7a01f3a0a91b20cc67868660
image: lank8s.cn/ingress-nginx/kube-webhook-certgen:v1.1.1@sha256:64d8c73dca984af206adf9d6d7e46aa550362b1d7a01f3a0a91b20cc67868660
（2）修改ingress使用 共享宿主机网络（主要是宿主机的80、443端口）的方式来进行工作（这是ingress的一种工作方式，还有"Service NodePort暴露Ingress Controller"的方式，后面会有详细文章单独来讲ingress）
在ingress的Deployment处添加一下配置
[root@k8s-master1 ingress-nginx]# vim ingress-controller.yaml
spec:
#共享宿主机的网络协议栈
hostNetwork: True
#将Pod调度到指定的Node上，不经过调度器
nodeName: k8s-master1
#根据标签控制pod在哪个node节点上，受scheduler调度器控制（例如有污点便不能调度）
#例如将pod调度到含有[test-label-ingress-controller: "true"]标签的节点上
#nodeSelector:
# test-label-ingress-controller: "true"
containers:
...
nodeName: k8s-master1：因为我的集群只有master1有公网ip，所以就把ingress controller这个pod固定部署在master1上，让ingress共享master1的宿主机网络,这样外网直接通过ingress来访问到我们的应用了
6、部署ingress并启动一个pod来测试
[root@k8s-master1 ingress-nginx]# kubectl apply -f ingress-controller.yaml
namespace/ingress-nginx created
serviceaccount/ingress-nginx created
serviceaccount/ingress-nginx-admission created
....
[root@k8s-master1 ingress-nginx]# kubectl get pod -n ingress-nginx
NAME READY STATUS RESTARTS AGE
ingress-nginx-admission-create-sbrwz 0/1 Completed 0 2m49s
ingress-nginx-admission-patch-28f8j 0/1 Completed 2 2m49s
ingress-nginx-controller-97bc6db4b-mwjpl 1/1 Running 0 2m49s
这时ingress已经部署好了，我们启动一个nginx的pod自建ingress 来进行测试；
[root@k8s-master1 ingress-nginx]# vim test-nginx.yml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: web
spec:
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: web
spec:
ingressClassName: "nginx"
rules:
- host: web.fandaoshuai777.wonderlink.cc
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: web
port:
number: 80
启动pod
[root@k8s-master1 ingress-nginx]# kubectl apply -f test-nginx.yml
deployment.apps/nginx created
service/web created
Error from server (InternalError): error when creating "test-nginx.yml": Internal error occurred: failed calling webhook "validate.nginx.ingress.kubernetes.io": Post "https://ingress-nginx-controller-admission.ingress-nginx.svc:443/networking/v1/ingresses?timeout=10s": x509: certificate has expired or is not yet valid: current time 2022-10-06T14:32:37+08:00 is before 2022-10-06T14:12:03Z
发现报错了，这个问题是我刚开始使用yaml的方式创建nginx-ingress，之后删除了它创建的命名空间以及 clusterrole and clusterrolebinding ，但是没有删除ValidatingWebhookConfiguration ingress-nginx-admission，这个ingress-nginx-admission是在yaml文件中安装的。当我再次使用helm安装nginx-ingress之后，创建自定义的ingress就会报这个错误。
解决方案：
[root@k8s-master1 ingress-nginx]# kubectl get validatingwebhookconfigurations
NAME WEBHOOKS AGE
ingress-nginx-admission 1 17m
[root@k8s-master1 ingress-nginx]# kubectl delete -A ValidatingWebhookConfiguration ingress-nginx-admission
validatingwebhookconfiguration.admissionregistration.k8s.io "ingress-nginx-admission" deleted
[root@k8s-master1 ingress-nginx]# kubectl apply -f test-nginx.yml
deployment.apps/nginx unchanged
service/web unchanged
ingress.networking.k8s.io/web created 创建成功
pod已经创建完成了，接下来等待pod Running之后去用ingress访问这个nginx pod
[root@k8s-master1 ingress-nginx]# kubectl get pod,ingress
NAME READY STATUS RESTARTS AGE
pod/busybox 1/1 Running 0 151m
pod/nginx-66b6c48dd5-f9t5z 1/1 Running 0 7m21s
NAME CLASS HOSTS ADDRESS PORTS AGE
ingress.networking.k8s.io/web nginx web.fandaoshuai777.wonderlink.cc 172.32.0.11 80 6m
浏览器访问web.fandaoshuai777.wonderlink.cc
可以发现访问成功，我们修改下nginx pod的html页面 再次访问查看是否访问的是这个nginx pod
[root@k8s-master1 ingress-nginx]# kubectl exec -it pod/nginx-66b6c48dd5-f9t5z sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
# cd /usr/share/nginx/html
# ls
50x.html index.html
# echo "fandaoshuai is ingress-nginx" > index.html
# exit
访问成功，ingress部署完成；
大家在测试时，也可以使用修改本地hosts文件解析来进行验证
八、扩容多master（高可用架构）
Kubernetes作为容器集群系统，通过健康检查+重启策略实现了Pod故障的自我修复能力，通过调度算法实现将Pod分布式部署，并保持预期的副本数；根据Node失效的状态自动在其它Node拉起Pod，实现了应用层的高可用性；
针对kubernetes集群，高可用性还应包含以下两个层面的考虑，Etcd数据库的高可用性和Kubernetes Master组件的高可用性。而Etcd我们已经采用3个节点组建集群实现了高可用；接下来我们将对Master节点高可用进行说明和实施；
Master节点扮演着总控中心的角色，通过不断与工作节点上的Kubelet和kube-proxy进行通信来维护整个集群的健康工作状态。如果Master节点故障，将无法使用kubectl工具或者API做任何集群管理；
Master节点主要有三个服务kube-apiserver、kube-controller-manager和kube-scheduler，其中kube-controller-manager和kube-scheduler组件自身通过选择机制已经实现了高可用，所以Master高可用主要针对kube-apiserver组件,而该组件是以HTTP API提供服务，因此对他高可用与web服务器类似，增加负载均衡器对其负载均衡即可，并且可水平扩容；
多Master架构图：
1、部署Master2
现在需要再增加一台新服务器，作为Master2，IP是192.168.1.4
Master2与已部署的Master1所有操作一致。所以我们只需要将Master1所有k8s文件拷贝过来，再修改下服务器IP和主机名即可启动
（1）安装docker
[root@k8s-master2 ~]# wget https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo -O /etc/yum.repos.d/docker-ce.repo
[root@k8s-master2 ~]# yum -y install docker-ce
[root@k8s-master2 ~]# systemctl enable docker && systemctl start docker
[root@k8s-master2 ~]# vim /etc/docker/daemon.json
{
"registry-mirrors": ["https://b9pmyelo.mirror.aliyuncs.com"]
}
[root@k8s-master2 ~]# systemctl restart docker
（2）创建etcd证书目录
在Master2创建etcd证书目录
[root@k8s-master2 ~]# mkdir -pv /hqtbj/hqtwww/etcd
mkdir: created directory ‘/hqtbj’
mkdir: created directory ‘/hqtbj/hqtwww’
（3）拷贝文件（在Master1上操作）
拷贝Master1上所有k8s文件和etcd证书到Master2
[root@k8s-master1 ~]# scp -pr /hqtbj/hqtwww/kubernetes [email protected]:/hqtbj/hqtwww/
[root@k8s-master1 ~]# scp -pr /hqtbj/hqtwww/etcd/ssl [email protected]:/hqtbj/hqtwww/etcd/
[root@k8s-master1 ~]# scp -pr /usr/lib/systemd/system/kube [email protected]:/usr/lib/systemd/system/
[root@k8s-master1 ~]# scp /usr/bin/kubectl [email protected]:/usr/bin/
[root@k8s-master1 ~]# scp -pr /root/.kube [email protected]:/root/
（4）删除证书文件
删除kubelet证书和kubeconfig文件
[root@k8s-master2 ~]# rm -rf /hqtbj/hqtwww/kubernetes/cfg/kubelet.kubeconfig
[root@k8s-master2 ~]# rm -rf /hqtbj/hqtwww/kubernetes/ssl/kubelet*
（5）修改配置文件IP和主机名
修改apiserver、kubelet和kube-proxy配置文件为本地IP
[root@k8s-master2 ~]# vim /hqtbj/hqtwww/kubernetes/cfg/kube-apiserver.conf
...
--bind-address=192.168.1.4 \
--advertise-address=192.168.1.4 \
...
[root@k8s-master2 ~]# vim /hqtbj/hqtwww/kubernetes/cfg/kube-controller-manager.kubeconfig
server: https://192.168.1.4:6443
[root@k8s-master2 ~]# vim /hqtbj/hqtwww/kubernetes/cfg/kube-scheduler.kubeconfig
server: https://192.168.1.4:6443
[root@k8s-master2 ~]# vim /hqtbj/hqtwww/kubernetes/cfg/kubelet.conf
--hostname-override=k8s-master2
[root@k8s-master2 ~]# vim /hqtbj/hqtwww/kubernetes/cfg/kube-proxy-config.yml
hostnameOverride: k8s-master2
[root@k8s-master2 ~]# vim /root/.kube/config
server: https://192.168.1.4:6443
（6）启动并设置开机启动
[root@k8s-master2 ~]# systemctl daemon-reload
[root@k8s-master2 ~]# systemctl start kube-apiserver kube-controller-manager kube-scheduler kubelet kube-proxy
[root@k8s-master2 ~]# systemctl enable kube-apiserver kube-controller-manager kube-scheduler kubelet kube-proxy
（7）查看集群状态
[root@k8s-master2 ~]# kubectl get cs
Warning: v1 ComponentStatus is deprecated in v1.19+
NAME STATUS MESSAGE ERROR
controller-manager Healthy ok
scheduler Healthy ok
etcd-2 Healthy {“health”:“true”}
etcd-1 Healthy {“health”:“true”}
etcd-0 Healthy {“health”:“true”}
（8）批准kubelet证书申请
[root@k8s-master2 ~]# kubectl get csr
NAME AGE SIGNERNAME REQUESTOR CONDITION
node-csr-7WhQYEMwPLI4_p17djP_VIjnElMb3PLQkmZ8OBXPjg0 40m kubernetes.io/kube-apiserver-client-kubelet kubelet-bootstrap Pending
[root@k8s-master2 ~]# kubectl certificate approve node-csr-7WhQYEMwPLI4_p17djP_VIjnElMb3PLQkmZ8OBXPjg0
certificatesigningrequest.certificates.k8s.io/node-csr-7WhQYEMwPLI4_p17djP_VIjnElMb3PLQkmZ8OBXPjg0 approved
[root@k8s-master2 ~]# kubectl get csr
NAME AGE SIGNERNAME REQUESTOR CONDITION
node-csr-7WhQYEMwPLI4_p17djP_VIjnElMb3PLQkmZ8OBXPjg0 40m kubernetes.io/kube-apiserver-client-kubelet kubelet-bootstrap Approved,Issued
#查看Node
[root@k8s-master2 ~]# kubectl get node
NAME STATUS ROLES AGE VERSION
k8s-master1 Ready <none> 17d v1.20.11
k8s-master2 Ready <none> 50s v1.20.11
k8s-node1 Ready <none> 16d v1.20.11
k8s-node2 Ready <none> 15d v1.20.11
2、部署Nginx+Keeaplived高可用负载均衡器
kube-apiserver 高可用架构图：
- Nginx是一个主流Web服务和反向代理服务器，这里用四层对apiserver实现负载均衡；
- Keepalived是一个主流的高可用软件，基于VIP绑定实现服务器双击热备，在上述拓扑中，Keepalived主要根据Nginx运行状态判断是否需要故障转移（漂移VIP），例如当Nginx主节点挂掉，VIP会自动绑定在Nginx备节点上，从而保证VIP一直高可用，实现Nginx高可用；
注：如果是在共有云上，一般都不支持Keepalived，那么你可以直接用它们的负载均衡产品，直接复杂均衡到多台Master kube-apiserver，架构与上面一样；
准备两台linux做nginx+keepalived机器
（1）安装nginx和keepalived软件包（主/备一样）
[root@nginx-m ~]# yum -y install epel-release
[root@nginx-m ~]# yum -y install nginx keepalived
[root@nginx-m ~]# yum -y install nginx-all-modules
（2）配置nginx（主/备一样）
[root@nginx-m ~]# vim /etc/nginx/nginx.conf
####全局块(进程数等)####
user nginx; #启动nginx时使用的用户；
worker_processes auto; #启动多少个nginx工作/子 进程进行服务，跟cpu的数量一样就可以，cpu有几个核这里就是几，或者直接"auto"自动检测；
worker_cpu_affinity auto;#nginx默认是没有开启利用多核cpu的配置的。需要通过增加worker_cpu_affinity配置参数来充分利用多核cpu，cpu是任务处理，当计算最费时的资源的时候，cpu核使用上的越多，性能就越好;为什么要绑定nginx到不同的cpu上？默认情况下，nginx的多个进程可能跑在某一个cpu或cpu的某一核心上，导致nginx进程使用硬件资源不均，此外，在多任务、高并发的场景下，进程可能会被系统在cpu的不同核心上调度，使得cpu缓存命中率低，因此绑定nginx进程到不同cpu上可以充分的利用硬件的多cpu多核资源，同时在提高系统性能，经测试，开启这个cpu亲和性设置之后，nginx的响应速度普遍会变快；也可以手动开启，如果 "worker_processes 2" 那么 "worker_cpu_affinity 01 10",如果"worker_processes 4"那么"worker_cpu_affinity 0001 0010 0100 1000";最好开启auto;让nginx自动检测；
error_log /var/log/nginx/error.log crit; #错误日志的存储位置，"cirt"是错误日志的级别；日志等级分为[ debug | info | notice | warn | error | crit ]，从左至右，日志详细程度逐级递减，即debug最详细，crit最少。
pid /run/nginx.pid; #存储nginx pid的文件，如果nginx没有启动的话是没有这个文件的；
# Load dynamic modules. See /usr/share/doc/nginx/README.dynamic.
include /usr/share/nginx/modules/*.conf; #用来引入其他的配置文件，使nginx配置更加的灵活；
####事件驱动模块(工作模式等)用来配置与用户的网络连接####
events {
use epoll; #用来设置nginx服务器选择哪种事件驱动(模型)来处理网络消息；##nginx性能优化！ 使用io多路复用异步非阻塞；
worker_connections 65535; #用来设置 单个work进程最大的连接数，这个值，不能大于操作系统支持打开的最大文件句柄数量（65535）；
multi_accept on; #用来设置nginx进程是否可以同一时间接受多个连接on|off；当你的服务器连接数不多时，开启这个参数会让负载有一定的降低，但是当服务器的吞吐量很大时，为了效率，可以关闭这个参数。
accept_mutex on; #用来防止防止惊群现象(默认是打开的)；
}
#四层负载均衡，为两台Master apiserver组件提供负载均衡
stream {
log_format basic '$remote_addr $upstream_addr - [$time_local] $status $upstream_bytes_sent';
access_log /var/log/nginx/stream-access.log basic;
# 为了让这个配置文件简单一些，将配置stream放入到/usr/local/nginx/stream_conf.d/，并以.stream做后缀名,然后引用。
# 需要为每个端口创建一个.stream做后缀名的配置文件
include /etc/nginx/stream_conf.d/*.stream;
}
http {
log_format main '$remote_addr - $remote_user [$time_iso8601] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"'; #日志格式，名字是main；
#$remote_addr:记录客户端的IP #-:分隔符 #$remote_user:记录访问网站所使用的用户名（在网站需要登录的情况下）如果没有的话则默认是"-"
#[$time_iso8601]: 服务器的时间 ISO8610格式（[2022-01-06T16:26:21+08:00]）
#"$request":记录请求的内容 #$status:客户端请求的状态
#$status $body_bytes_sent:返回给客户端的字节数（客户端访问网站页面index.html的大小）
#"$http_referer":url跳转来源，用来记录从哪个页面链接访问过来的
#"$http_user_agent":客户端使用的浏览器信息
#"$http_x_forwarded_for": 代理IP
access_log /var/log/nginx/access.log main; #客户端请求日志的目录位置，main需要和日志格式log_format的名字相等
#sendfile on;
#tcp_nopush on;
#tcp_nodelay on;
#keepalive_timeout 65;
types_hash_max_size 4096;
include /etc/nginx/mime.types; #媒体访问类型，应用程序与文件类型的一个关联（知道什么样的程序打开什么样的文件，音频就用mp3打开等等）
default_type application/octet-stream; #用来设置nginx响应前端请求默认的MIME类型，如果不设置的话默认是text/html类型；
server_names_hash_bucket_size 128;
client_header_buffer_size 32k; #如果客户端的"请求头+请求行"的大小小于32k那么则放行请求，如果大于32k则以large_client_header_buffers参数为准；
large_client_header_buffers 4 64k;
#(1请求行(request line)的大小不能超过8k，否则会报414错误；
#(2请求头(request header)中的每一个头部字段大小不能超过64k，否则会报400错误（实际是494错误，但nginx统一返回400了）curl -H "header1=aaa" -H "header2=bbb" -v http://127.0.0.1/，这里的header1=xxx和header2=xxx就是请求头中的头部字段；
#(3)请求头+请求行的大小不能超过4*64k
client_max_body_size 1024m;
client_body_buffer_size 10m;
client_header_timeout 120s;
keepalive_timeout 600; #用来设置长连接的超时时间(客户端连接保持会话的超时时间，超过这个时间，服务器断开这个连接)，默认是75s；
server_tokens off; #隐藏版本号（错误页面下会有版本号的提示），设置成on则是显示版本号，隐藏版本号对于安全性有好处；
sendfile on; #开启高效文件传输模式，sendfile指令指定nginx是否调用sendfile函数来输出文件，对于普通应用设为 on，如果用来进行下载等应用磁盘IO重负载应用，可设置为off，以平衡磁盘与网络I/O处理速度，降低系统的负载。注意：如果图片显示不正常把这个改成off；如果是静态资源服务器的话开启sendfile会大大提高系统的性能，但是当nginx是最为反向代理来使用的时候sendfile就没什么用了；
tcp_nopush on; #tcp_nopush（没有延迟）“实时性”指的是在客户端与服务端之间进行通信时，只要服务端有数据准备好了就立即发送给客户端，不会管发送的数据大小；实时性较好，但是效率低，因为是通过tcp进行的建立连接、发送数据的，而tcp在发送数据时，会在原有数据的基础上包装一些其它用于寻址的数据，这样tcp_nodelay一有数据就会发送就可能会导致1%是所需的数据，剩下的99%都是用于寻址的数据，所以会导致效率低下；(必须在开启sendfile的情况下才可以开启此参数)
tcp_nodelay on; #Tcp_nopush（不着急推送） “效率”：指的是在客户端与服务端之间进行通信时，会先把准备好的数据放入一个缓存区里面，如果缓存区满了的话再发送数据，好处就是效率高，先把数据准备好之后再去发送给客户端，虽然效率高，但是实时性并没有tcp_nodelay好；(必须在开启keepalive_timeout的情况下才可以开启此参数)
#"tcp_nopush和tcp_nodelay"看起来是互斥的关系，但是建议将这两个值都打开，因为在linux2.5.9之后的版本中这两者是可以相互兼容的，三个指令都开启的好处是，sendfile可以开启高效的文件传输模式，tcp_nopush开启可以确保在发送数据到客户端之前的数据包是已经充分“填满”的（所以一般在传输大数据、视频类的文件的时候建议开启tcp_nopush），可以大大减少网络传输开销，也可以增加文件发送速度；然后还有一种情况：当发送数据到达最后一个可能因为没有“填满”而暂停的数据包时，nginx会忽略tcp_nopush参数，然后直接使用tcp_nodelay强制把这些数据发送出去。 所以tcp_nopush和tcp_nodelay可以一起设置，它比单独配置tcp_nodelay具有更强的性能;
fastcgi_connect_timeout 600;
fastcgi_send_timeout 600;
fastcgi_read_timeout 600;
fastcgi_buffer_size 64k;
fastcgi_buffers 4 64k;
fastcgi_busy_buffers_size 128k;
fastcgi_temp_file_write_size 128k;
fastcgi_intercept_errors on;
gzip on; #开启压缩；
#gzip off;
gzip_buffers 16 8k; #用于处理请求压缩的缓冲区数量和大小；不同的操作系统值不相等，默认即可；
gzip_comp_level 6; #压缩级别，1-9，1表示压缩程度最低，效率最高；9表示压缩程度最高，但是效率最低最费时间；推荐6；
gzip_http_version 1.1; #针对不同的http协议版本，可以选择性的开启和关闭gzip，默认即可；
gzip_min_length 256; #该指令针对传输数据的大小，可以选择性的开启和关闭gzip，默认是kb大小，这里代表的是，如果传输的数据小于256kb那么就不对它进行压缩了；
gzip_proxied any; #用于nginx做反向代理的情况下，设置是否对服务端返回的结果进行gzip压缩；
#off-关闭nginx服务器对后台服务器返回结果的gzip压缩；
#expired-启用压缩，如果header头中包含”Expired“头信息；
#no-cache-启用压缩，如果header头中包含“cache-control:no-cache”头信息；
#no-store-启用压缩，如果header头中包含“cache-control：no-store”头信息；
#private-启用压缩，如果header投中包含“cache-control：private”头信息；
#no_last_modified-启用压缩，如果header头中不包含“last-modified”头信息；
#no_etag-启用压缩，如果header头中不包含“ETag”头信息；
#auth-启用压缩，如果header头中包含“authorization”头信息；
#any-无条件压缩；
gzip_vary on; #用于设置使用Gzip进行压缩发送是否携带“Vary: Accept-Encoding”头域的响应头部。主要是告诉接收方，所发送的数据经过了gzip的压缩处理；
gzip_types #需要压缩的文件类型，生产环境下最好不要使用*，因为图片视频等都已经是被高度压缩过的了，再进行压缩大小不会发生什么改变而且还浪费cpu的资源；
text/xml application/xml application/atom+xml application/rss+xml application/xhtml+xml image/svg+xml
text/javascript application/javascript application/x-javascript
text/x-json application/json application/x-web-app-manifest+json
text/css text/plain text/x-component
font/opentype application/x-font-ttf application/vnd.ms-fontobject
image/x-icon;
gzip_disable "MSIE [1-6]\.(?!.*SV1)"; #针对不同种类客户端发起的请求，可以选择性的开启和关闭gzip功能；支持正则表达式，根据客户端的浏览器标志（user-agent）来设置，指定的浏览器标志不使用gzip，该指令一般用来排除一些明显不支持gzip或版本较低（如果使用的话会出现乱码）的浏览器；这里禁用的是ie6以下的浏览器；
#open_file_cache max=1000 inactive=20s; #生产环境可以不需要打开，因为在某种程度上会占用内存，不打开的话只是占用磁盘io而已；
#open_file_cache_valid 30s; #生产环境可以不需要打开，因为在某种程度上会占用内存，不打开的话只是占用磁盘io而已；
#open_file_cache_min_uses 2; #生产环境可以不需要打开，因为在某种程度上会占用内存，不打开的话只是占用磁盘io而已；
#open_file_cache_errors on; #生产环境可以不需要打开，因为在某种程度上会占用内存，不打开的话只是占用磁盘io而已；
# Load modular configuration files from the /etc/nginx/conf.d directory.
# See http://nginx.org/en/docs/ngx_core_module.html#include
# for more information.
include /etc/nginx/conf.d/*.conf;
server {
listen 80 default_server; #监听的端口,default_server 可以定义默认的server，它可以去处理一些没有匹配到server_name例如（直接在浏览器访问192.168.1.1是个ip而不是个域名）的请求，如果没有定义，则会选取第一个定义的server作为default_server
#ps:nginx 批量载入配置 conf 时会按 ascii 排序载入，这就会以 server_a.conf server_b.conf server_c.conf 的顺序载入，如果没有生命 default_server 的话，那 server_a 会作为默认的 server 去处理 未绑定域名/ip 的请求。
listen [::]:80 default_server; #监听的端口（ipv6版本）
server_name _; #监听的域名 #_、__或者!@#等无效的域名，可以理解为其可以匹配任意域名，但是优先级最低，最常见的用法是用来设置默认的server,即当一个请求的Host没有命中其他规则时，会采用默认server的配置。
#server_name的匹配执行顺序
#No1:精准匹配server_name
#No2:通配符在开始时匹配server_name成功
#No3:通配符在结束时匹配server_name成功
#No4:正则表达式匹配server_name成功
#No5:被默认的default_server处理，如果没有指定默认找第一个server
root /usr/share/nginx/html; #网站的根目录
# Load configuration files for the default server block.
include /etc/nginx/default.d/*.conf;
return 404;
error_page 404 /404.html;
location = /404.html {
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}
}
[root@nginx-m ~]# mkdir /etc/nginx/stream_conf.d #创建存放nginx四层复杂均衡文件的目录，与配置文件里的对应
[root@nginx-m ~]# vim /etc/nginx/stream_conf.d/kube-api-server.stream
upstream k8s-apiserver{
server 192.168.1.1:6443; #Master1 APISERVER IP:PORT
server 192.168.1.4:6443; #Master2 APISERVER IP:PORT
}
server {
listen 16443; #在nginx上监听的端口，我这里设置的16379，为了方便时也可以直接设置成6379
proxy_pass k8s-apiserver;
}
[root@nginx-m ~]# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
（3）配置keepalived（Nginx Master）
虚拟IP（VIP）一定要设置的是上面kube-apiserver里面预留的IP否则在第(9)步 重启kubelet会报如下错误：
[root@nginx-m ~]# vim /etc/keepalived/keepalived.conf
global_defs {
notification_email {
[email protected]
[email protected]
[email protected]
}
notification_email_from [email protected]
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id NGINX_MASTER
}
vrrp_script check_nginx {
script "/etc/keepalived/check_nginx.sh"
}
vrrp_instance VI_1 {
state MASTER
interface ens33 #修改为实际网卡名
virtual_router_id 51 #每个虚拟路由器惟一标识，范围：0-255，同一组虚拟路由器的vrid必须一致
priority 100 #优先级，备服务设置90
advert_int 1 #指定VRRP心跳包通告间隔时间，默认为1秒
authentication {
auth_type PASS
auth_pass 1111
}
#虚拟IP
virtual_ipaddress {
192.168.1.9/24
}
track_script {
check_nginx
}
}
vrrp_script：指定检查nginx工作状态的脚本（根据nginx状态判断是否故障转移）
virtual_ipaddress：虚拟IP（VIP）
准备上述配置文件中检查nginx运行状态的脚本：
[root@nginx-m ~]# vim /etc/keepalived/check_nginx.sh
nginx_status=$(ss -antp |grep 16443 |egrep -cv "grep|$$")
if [ "$nginx_status" -eq 0 ];then
exit 1
else
exit 0
fi
[root@nginx-m ~]# chmod +x /etc/keepalived/check_nginx.sh
（4）配置keepalived（Nginx Backup）
[root@nginx-s ~]# vim /etc/keepalived/keepalived.conf
global_defs {
notification_email {
[email protected]
[email protected]
[email protected]
}
notification_email_from [email protected]
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id NNGINX_BACKUP
}
vrrp_script check_nginx {
script "/etc/keepalived/check_nginx.sh"
}
vrrp_instance VI_1 {
state BACKUP
interface ens33
virtual_router_id 51 #每个虚拟路由器惟一标识，范围：0-255，同一组虚拟路由器的vrid必须一致
priority 90
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.1.9/24
}
track_script {
check_nginx
}
}
准备上述配置文件中检查nginx运行状态的脚本：
[root@nginx-s ~]# vim /etc/keepalived/check_nginx.sh
nginx_status=$(ss -antp |grep 16443 |egrep -cv "grep|$$")
if [ "$nginx_status" -eq 0 ];then
exit 1
else
exit 0
fi
[root@nginx-s ~]# chmod +x /etc/keepalived/check_nginx.sh
注：keepalived根据脚本返回状态码（0为工作正常，非0不正常）来判断是否故障转移
（5）启动nginx和keepalived并设置开机启动
[root@nginx-m ~]# systemctl daemon-reload
[root@nginx-m ~]# systemctl start nginx keepalived
[root@nginx-m ~]# systemctl enable nginx keepalived
（6）查看keepalived工作状态
[root@nginx-m ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:0c:29:26:5f:b1 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.20/24 brd 192.168.1.255 scope global ens33
valid_lft forever preferred_lft forever
inet 192.168.1.9/24 scope global ens33
valid_lft forever preferred_lft forever
inet6 fe80::e6b3:c4dd:bd0c:d25e/64 scope link
valid_lft forever preferred_lft forever
可以看到，在主机点ens33网卡上绑定了192.168.1.9虚拟IP，说明工作正常；
（7）Nginx+Keepalived高可用测试
关闭主节点Nginx，测试VIP是否漂移到备节点服务器
`在Nginx Master关闭nginx`
[root@nginx-m ~]# killall nginx
`可以看到VIP已经不在Nginx Master节点了`
[root@nginx-m ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:0c:29:26:5f:b1 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.20/24 brd 192.168.1.255 scope global ens33
valid_lft forever preferred_lft forever
inet6 fe80::e6b3:c4dd:bd0c:d25e/64 scope link
valid_lft forever preferred_lft forever
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN qlen 1000
link/ether 52:54:00:f9:39:0e brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN qlen 1000
link/ether 52:54:00:f9:39:0e brd ff:ff:ff:ff:ff:ff
`在Nginx Backup上可以看到VIP漂过来了`
[root@nginx-s ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:0c:29:f8:23:ea brd ff:ff:ff:ff:ff:ff
inet 192.168.1.21/24 brd 192.168.1.255 scope global ens33
valid_lft forever preferred_lft forever
inet 192.168.1.9/24 scope global ens33
valid_lft forever preferred_lft forever
inet6 fe80::9265:d392:a397:a8ab/64 scope link
valid_lft forever preferred_lft forever
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN qlen 1000
link/ether 52:54:00:33:81:3b brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN qlen 1000
link/ether 52:54:00:33:81:3b brd ff:ff:ff:ff:ff:ff
（8）访问负载均衡器测试
找k8s集群中任意一个节点，使用curl查看k8s版本测试，使用VIP访问：
[root@k8s-node1 ~]# curl -k https://192.168.1.9:16443/version
{
"major": "1",
"minor": "20",
"gitVersion": "v1.20.11",
"gitCommit": "27522a29febbcc4badac257763044d0d90c11abd",
"gitTreeState": "clean",
"buildDate": "2021-09-15T19:16:25Z",
"goVersion": "go1.15.15",
"compiler": "gc",
"platform": "linux/amd64"
可以正确获取到k8s版本信息，说明负载均衡器搭建正常。该请求数据流程：curl -->vip（nginx）–>apiserver
通过查看nginx日志也可以看到转发apiserver日志
[root@nginx-m ~]# tail -5 /var/log/nginx/stream-access.log
192.168.1.4 192.168.1.1:6443 - [21/Oct/2022:20:46:20 +0800] 200 426
192.168.1.4 192.168.1.4:6443 - [21/Oct/2022:20:46:20 +0800] 200 426
192.168.1.4 192.168.1.1:6443 - [21/Oct/2022:20:46:20 +0800] 200 426
192.168.1.4 192.168.1.4:6443 - [21/Oct/2022:20:46:21 +0800] 200 426
192.168.1.4 192.168.1.1:6443 - [21/Oct/2022:20:46:21 +0800] 200 426
（9）修改所有WorkNode连接LB VIP
虽然我们增加了Master2和负载均衡器，但是我们是从单Master架构扩容的，也就是说目前所有的Work Node组件连接都还是Master1，如果不改为连接VIP走负载均衡器，那么Master还是会单点故障；
因此接下来就是要改所有Work Node（kubectl get node 命令查看到的节点,这里包括两个master节点，因为master节点也是work node节点）组件配置文件，由原来的192.168.1.1 修改为 192.168.1.9（VIP）
在所有Work Node执行：
-----------master1、node1、node2执行-----------
[root@k8s-master1 ~]# sed -i 's#192.168.1.1:6443#192.168.1.9:16443#g' /hqtbj/hqtwww/kubernetes/cfg/*
-----------master2执行-----------
[root@k8s-master2 ~]# sed -i 's#192.168.1.4:6443#192.168.1.9:16443#g' /hqtbj/hqtwww/kubernetes/cfg/*
（10）测试高可用
关闭master1服务器模拟master1宕机
[root@k8s-master1 ~]# poweroff
在master2上进行操作
[root@k8s-master2 ~]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-master1 NotReady <none> 8h v1.22.4 可以看到现在master1是未就绪的，master2还是可以控制集群的
k8s-master2 Ready <none> 7h59m v1.22.4
k8s-node1 Ready <none> 178m v1.22.4
k8s-node2 Ready <none> 8h v1.22.4
启动一个pod来进行测试
[root@k8s-master2 ~]# cat > test.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
name: busybox
namespace: default
spec:
containers:
- name: busybox
image: busybox:1.28.4
command:
- sleep
- "36000000000"
imagePullPolicy: IfNotPresent
restartPolicy: Always
EOF
[root@k8s-master2 ~]# kubectl apply -f test.yaml
pod/busybox created
[root@k8s-master2 ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
busybox 1/1 Running 0 45s
[root@k8s-master2 ~]# kubectl exec -it pod/busybox sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
/ # ls
bin dev etc home proc root sys tmp usr var
/ # exit
至此，一套完整的 Kubernetes 高可用集群就部署完成了！
总结
提示：这里对文章进行总结：
例如：以上就是今天要讲的内容，本文仅仅简单介绍了pandas的使用，而pandas提供了大量能使我们快速便捷地处理数据的函数和方法。