文章目录
- 一、操作系统初始化配置(所有节点均执行)
- 二、部署Etcd集群
-
- 1、准备cfssl证书生成工具
- 2、生成Etcd证书
-
- 2.1、自签etcd证书颁发机构(根CA)
- [2.2、使用自签的CA来签发Etcd HTTPS证书](#2.2、使用自签的CA来签发Etcd HTTPS证书)
- 2.3、从Github下载Etcd二进制文件
- 2.4、部署Etcd集群
- 2.5、配置systemd管理etcd
- [2.6 把刚才生成的etcd证书拷贝到配置文件中的路径中](#2.6 把刚才生成的etcd证书拷贝到配置文件中的路径中)
- 2.6、启动etcd并设置开机启动
- 2.7、将etcd节点1(k8s-master1节点)所有生成的文件拷贝到其它etcd节点上(节点2和节点3)
- 2.8、查看集群状态
- 三、安装Docker
- 四、部署k8s-master节点
-
- 1、生成kube-apiserver服务证书
-
- 1.1、自签kubernetes证书颁发机构(根CA)
- [1.2、使用自签的CA来签发kube-apiserver HTTPS证书](#1.2、使用自签的CA来签发kube-apiserver HTTPS证书)
- 1.3、从Github下载kubernetes二进制文件
- 1.4、解压二进制包
- 1.5、部署kube-apiserver
-
- (1)创建配置文件
- (2)拷贝刚才生成的证书
- [(3)启用 TLS Bootstrapping 机制](#(3)启用 TLS Bootstrapping 机制)
- (4)使用systemd管理kube-apiserver
- (5)启动并设置开机自启
- 1.6、部署kube-controller-manager
-
- (1)创建配置文件
- [(2)使用自签的CA来签发kube-controller-manager HTTPS证书](#(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证书](#(2)使用自签的CA来签发kube-scheduler HTTPS证书)
- (3)生成kube-scheduler的kubeconfig文件(以下是shell命令,直接在终端执行)
- (4)部署kube-scheduler并启动
- 1.8、查看集群状态
- 1.9、授权kubelet-bootstrap用户允许请求证书
- [五、部署work node](#五、部署work node)
-
- 1、创建工作目录并拷贝二进制文件
-
- 1.1、部署kubelet
-
- (1)创建配置文件
- (2)创建配置参数(kubelet-config.yml)文件
- (3)生成kubelet初次加入集群向apiserver申请证书的kubeconfig文件
- [(4)systemd管理kubelet 并启动](#(4)systemd管理kubelet 并启动)
- 1.2、在master节点上批准kubelet证书申请并加入集群
- 1.3、部署kube-proxy
-
- (1)创建配置文件
- (2)创建配置参数(kube-proxy-config.yml)文件
- (3)生成kube-proxy.kubeconfig文件
- [(4)systemd管理kubelet 并启动](#(4)systemd管理kubelet 并启动)
- [1.4、部署网络组件 calico](#1.4、部署网络组件 calico)
- 1.5、授权apiserver访问kubelet
- [六、新增加worker node](#六、新增加worker node)
-
- 1、拷贝已部署好的Node相关文件到新的节点
- [2、 删除kubelet证书和kubeconfig文件](#2、 删除kubelet证书和kubeconfig文件)
- [3、 修改主机名](#3、 修改主机名)
- [4、 启动并设置开机自启](#4、 启动并设置开机自启)
- [5、 在master上批准新的node kubelet证书申请](#5、 在master上批准新的node kubelet证书申请)
- [七、部署Core DNS和Ingress](#七、部署Core DNS和Ingress)
-
- 1、部署CoreDNS
- [2、修改CoreDNS配置(configmap 和 service处)](#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)](#(2)修改ingress使用 共享宿主机网络(主要是宿主机的80、443端口)的方式来进行工作(这是ingress的一种工作方式,还有"Service NodePort暴露Ingress Controller"的方式,后面会有详细文章单独来讲ingress))
-
- 6、部署ingress并启动一个pod来测试
- 八、扩容多master(高可用架构)
-
- 1、部署Master2
- 2、部署Nginx+Keeaplived高可用负载均衡器
-
- (1)安装nginx和keepalived软件包(主/备一样)
- (2)配置nginx(主/备一样)
- [(3)配置keepalived(Nginx Master)](#(3)配置keepalived(Nginx Master))
- [(4)配置keepalived(Nginx Backup)](#(4)配置keepalived(Nginx Backup))
- (5)启动nginx和keepalived并设置开机启动
- (6)查看keepalived工作状态
- (7)Nginx+Keepalived高可用测试
- (8)访问负载均衡器测试
- [(9)修改所有WorkNode连接LB VIP](#(9)修改所有WorkNode连接LB VIP)
- (10)测试高可用
- 总结
单master架构图
一、操作系统初始化配置(所有节点均执行)
1、关闭防火墙
bash
[root@iZbp11oc69mdt2iizzqhzuZ ~]# systemctl stop firewalld
[root@iZbp11oc69mdt2iizzqhzuZ ~]# systemctl disable firewalld
2、关闭selinux
bash
[root@iZbp11oc69mdt2iizzqhzuZ ~]# setenforce 0 #临时关闭
setenforce: SELinux is disabled
[root@iZbp11oc69mdt2iizzqhzuZ ~]# sed -i 's/enforcing/disabled/' /etc/selinux/config #永久关闭
3、关闭swap
bash
[root@iZbp11oc69mdt2iizzqhzuZ ~]# swapoff -a #临时关闭
[root@iZbp11oc69mdt2iizzqhzuZ ~]# sed -ri 's/.*swap.*/#&/' /etc/fstab #永久关闭
4、根据规划修改主机名
master节点
bash
[root@iZbp11oc69mdt2iizzqhzuZ ~]# hostnamectl set-hostname k8s-master1
[root@iZbp11oc69mdt2iizzqhzuZ ~]# bash
[root@k8s-master1 ~]#
node1节点
bash
[root@iZbp109g5wnimxn10iv2krZ ~]# hostnamectl set-hostname k8s-node1
[root@iZbp109g5wnimxn10iv2krZ ~]# bash
[root@k8s-node1 ~]#
node2节点
bash
[root@iZbp1b25lq5akibeea3sr4Z ~]# hostnamectl set-hostname k8s-node2
[root@iZbp1b25lq5akibeea3sr4Z ~]# bash
[root@k8s-node2 ~]#
5、在master节点上添加host
bash
[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的链
bash
[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、时间同步
bash
[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节点
bash
[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)
创建工作目录
bash
[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
bash
[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
bash
[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
bash
[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证书的申请文件
bash
[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证书
bash
[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)创建工作目录并解压二进制包
bash
[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的配置文件
bash
[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
bash
[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证书拷贝到配置文件中的路径中
bash
[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并设置开机启动
bash
[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)
bash
[root@k8s-master1 ~]# scp -pr /hqtbj/hqtwww/etcd/ root@172.32.0.12:/hqtbj/hqtwww/
[root@k8s-master1 ~]# scp -r /usr/lib/systemd/system/etcd.service root@172.32.0.12:/usr/lib/systemd/system/
[root@k8s-master1 ~]# scp -pr /hqtbj/hqtwww/etcd/ root@172.32.0.13:/hqtbj/hqtwww/
[root@k8s-master1 ~]# scp -r /usr/lib/systemd/system/etcd.service root@172.32.0.13:/usr/lib/systemd/system/
然后在节点2和节点3上分别修改etcd.conf配置文件中的节点名称和当前服务器的IP:
bash
[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、查看集群状态
bash
[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并启动;
bash
[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配置文件
bash
[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)
bash
[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证书签名请求文件
bash
[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根证书
bash
[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申请文件:
bash
[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证书
bash
[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、解压二进制包
bash
[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)创建配置文件
bash
[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证书拷贝到配置文件中的路径:
bash
[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)
bash
[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
bash
[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)创建配置文件
bash
[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申请文件
bash
[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证书
bash
[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地址的变量,方便后面引用
bash
[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"
设置集群信息
bash
[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的用户信息
bash
[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上下文信息
bash
[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并启动
bash
[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)创建配置文件
bash
[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申请文件
bash
[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"
}
]
}
生成证书
bash
[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命令,直接在终端执行)
bash
[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并启动
bash
[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申请文件
bash
[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"
}
]
}
生成证书
bash
[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命令,直接在终端执行)
bash
[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命令查看集群组件的状态;
bash
[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组件加入集群的请求)
bash
[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组件拷贝到工作节点
bash
[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)创建配置文件
bash
[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)文件
bash
[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)
bash
[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 并启动
bash
[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证书申请并加入集群
bash
#查看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)创建配置文件
bash
[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)文件
bash
[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文件
bash
切换至工作目录
[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 并启动
bash
[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
bash
[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之后,节点也会准备就绪
bash
[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)"
的错误)。
bash
[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
bash
[root@k8s-master1 hqtwww]# scp -pr /hqtbj/hqtwww/kubernetes root@172.32.0.12:/hqtbj/hqtwww/
[root@k8s-master1 hqtwww]# scp -pr /usr/lib/systemd/system/{kubelet.service,kube-proxy.service} root@172.32.0.12:/usr/lib/systemd/system/
2、 删除kubelet证书和kubeconfig文件
注:这几个文件是证书申请审批后自动生成的,每个Node不同,必须删除
bash
[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的配置参数文件里的主机名需要改成自己节点对应的主机名;
bash
[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、 启动并设置开机自启
bash
[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证书申请
bash
[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节点同上,记得修改主机名
bash
[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处)
bash
[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并验证域名解析功能
bash
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文件
bash
[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)否则会下不了镜像
bash
查看现在需要使用镜像
[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处添加一下配置
bash
[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来测试
bash
[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 来进行测试;
bash
[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
bash
[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就会报这个错误。
解决方案:
bash
[root@k8s-master1 ingress-nginx]# kubectl get validatingwebhookconfigurations
NAME WEBHOOKS AGE
ingress-nginx-admission 1 17m
bash
[root@k8s-master1 ingress-nginx]# kubectl delete -A ValidatingWebhookConfiguration ingress-nginx-admission
validatingwebhookconfiguration.admissionregistration.k8s.io "ingress-nginx-admission" deleted
bash
[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
bash
[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
bash
[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
bash
[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证书目录
bash
[root@k8s-master2 ~]# mkdir -pv /hqtbj/hqtwww/etcd
mkdir: created directory '/hqtbj'
mkdir: created directory '/hqtbj/hqtwww'
(3)拷贝文件(在Master1上操作)
拷贝Master1上所有k8s文件和etcd证书到Master2
bash
[root@k8s-master1 ~]# scp -pr /hqtbj/hqtwww/kubernetes root@192.168.1.4:/hqtbj/hqtwww/
[root@k8s-master1 ~]# scp -pr /hqtbj/hqtwww/etcd/ssl root@192.168.1.4:/hqtbj/hqtwww/etcd/
[root@k8s-master1 ~]# scp -pr /usr/lib/systemd/system/kube root@192.168.1.4:/usr/lib/systemd/system/
[root@k8s-master1 ~]# scp /usr/bin/kubectl root@192.168.1.4:/usr/bin/
[root@k8s-master1 ~]# scp -pr /root/.kube root@192.168.1.4:/root/
(4)删除证书文件
删除kubelet证书和kubeconfig文件
bash
[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
bash
[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证书申请
bash
[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软件包(主/备一样)
bash
[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(主/备一样)
bash
[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会报如下错误:
bash
[root@nginx-m ~]# vim /etc/keepalived/keepalived.conf
global_defs {
notification_email {
acassen@firewall.loc
failover@firewall.loc
sysadmin@firewall.loc
}
notification_email_from Alexandre.Cassen@firewall.loc
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运行状态的脚本:
bash
[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)
bash
[root@nginx-s ~]# vim /etc/keepalived/keepalived.conf
global_defs {
notification_email {
acassen@firewall.loc
failover@firewall.loc
sysadmin@firewall.loc
}
notification_email_from Alexandre.Cassen@firewall.loc
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运行状态的脚本:
bash
[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并设置开机启动
bash
[root@nginx-m ~]# systemctl daemon-reload
[root@nginx-m ~]# systemctl start nginx keepalived
[root@nginx-m ~]# systemctl enable nginx keepalived
(6)查看keepalived工作状态
bash
[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是否漂移到备节点服务器
bash
`在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访问:
bash
[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日志
bash
[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执行:
bash
-----------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宕机
bash
[root@k8s-master1 ~]# poweroff
在master2上进行操作
bash
[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来进行测试
bash
[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提供了大量能使我们快速便捷地处理数据的函数和方法。