【Kubernetes】Kubernetes 二进制部署

常见的K8S按照部署方式：

●Minikube

Minikube是一个工具，可以在本地快速运行一个单节点微型K8S，仅用于学习、预览K8S的一些特性使用。
部署地址：https://kubernetes.io/docs/setup/minikube

●Kubeadmin

Kubeadmin也是一个工具，提供kubeadm init和kubeadm join，用于快速部署K8S集群，相对简单。
https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/

●二进制安装部署

生产首选，从官方下载发行版的二进制包，手动部署每个组件和自签TLS证书，组成K8S集群，新手推荐，可以方便对k8s数据的流向进行了解。
https://github.com/kubernetes/kubernetes/releases

小结：Kubeadm降低部署门槛，但屏蔽了很多细节，遇到问题很难排查。如果想更容易可控，推荐使用二进制包部署Kubernetes集群，虽然手动部署麻烦点，期间可以学习很多工作原理，也利于后期维护

二进制搭建Kubernetes v1.20

1.0 环境准备

k8s集群master01：192.168.67.30    kube-apiserver、kube-controller-manager、kube-scheduler、etcd
k8s集群master02：192.168.67.11

k8s集群node01：192.168.67.12    docker、etcd、kubelet、kube-proxy
k8s集群node02：192.168.67.13

etcd集群节点1：192.168.67.30    etcd
etcd集群节点2：192.168.67.12    etcd
etcd集群节点3：192.168.67.13    etcd

VIP：192.168.67.35

负载均衡nginx+keepalive01（master）：192.168.67.21
负载均衡nginx+keepalive02（backup）：192.168.67.22

1.1操作系统初始化配置

除了特别指定某一机器执行，否则全部机器都执行

1.1.1 修改主机名

hostnamectl set-hostname master01

hostnamectl set-hostname master02

hostnamectl set-hostname node01
hostnamectl set-hostname node02

1.1.2 关闭防火墙

#关闭防火墙和关闭开机自启
systemctl stop firewalld
systemctl disable firewalld
#清空防火墙规则
iptables -F && iptables -t nat -F && iptables -t mangle -F && iptables -X

1.1.3 关闭selinux

setenforce 0
sed -i 's/enforcing/disabled/' /etc/selinux/config

1.1.4 关闭swap

swapoff -a
sed -ri 's/.*swap.*/#&/' /etc/fstab

1.1.5 在master添加hosts

cat >> /etc/hosts << EOF
192.168.67.30 master01
192.168.67.11 master02
192.168.67.12 node01
192.168.67.13 node02
EOF

1.1.6 调整内核参数

cat > /etc/sysctl.d/k8s.conf << EOF
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.ipv6.conf.all.disable_ipv6=1
net.ipv4.ip_forward=1
EOF

cat > /etc/sysctl.d/k8s.conf << EOF
#开启网桥模式，可将网桥的流量传递给iptables链
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
#关闭ipv6协议
net.ipv6.conf.all.disable_ipv6=1
net.ipv4.ip_forward=1
EOF

#重新加载 /etc/sysctl.conf 配置文件中的内核参数
sysctl --system

1.1.7 时间同步

yum -y install ntpdate
timedatectl set-timezone Asia/Shanghai
ntpdate time.windows.com

一、部署 docker 引擎

1、在所有 node 节点上部署docker引擎

yum -y install yum-utils device-mapper-persistent-data lvm2
yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
yum install -y docker-ce docker-ce-cli containerd.io

#yum -y install docker-ce-20.10.* docker-ce-cli-20.10.* containerd.io

2、启动并设置开机自启

systemctl start docker.service
systemctl enable docker.service 

二、部署 etcd 集群

etcd是CoreOS团队于2013年6月发起的开源项目，它的目标是构建一个高可用的分布式键值（key-value）数据库。etcd内部采用raft协议作为一致性算法，etcd是go语言编写的。

1、etcd (服务发现系统)的特点：

简单：安装配置简单，而且提供了HTTP API进行交互，使用也很简单
安全：支持SSL证书验证
快速：单实例支持每秒2k+读操作
可靠：采用raft算法，实现分布式系统数据的可用性和一致性

etcd 目前默认使用2379端口提供HTTP API服务， 2380端口和peer通信(这两个端口已经被IANA(互联网数字分配机构)官方预留给etcd)。

etcd默认使用2379端口对外为客户端提供通讯，使用端口2380来进行服务器间内部通讯。

对内部通信：

        2379端口：通常用于 etcd 集群内部节点之间的通信。集群中的各个 etcd 节点之间会使用2379端口进行通信和同步数据。

        2380端口：用于 etcd 集群内部选举 leader 的通信端口

对外部通信：

        如果需要从集群外部访问 etcd 集群，可以通过2379端口进行通信。这种情况通常需要配置网络策略和防火墙规则，以确保安全访问

etcd 在生产环境中一般推荐集群方式部署。由于etcd 的leader选举机制，要求至少为3台或以上的奇数台

2、准备签发证书环境

CFSSL 是 CloudFlare 公司开源的一款 PKI/TLS 工具。 CFSSL 包含一个命令行工具和一个用于签名、验证和捆绑 TLS 证书的 HTTP API 服务。使用Go语言编写。
CFSSL 使用配置文件生成证书，因此自签之前，需要生成它识别的 json 格式的配置文件，CFSSL 提供了方便的命令行生成配置文件。

3、CFSSL 支持签发的三种类型的证书

CFSSL 为 etcd 提供 TLS 证书，它支持签三种类型的证书：

1、client 证书，服务端连接客户端时携带的证书，用于客户端验证服务端身份，如 kube-apiserver 访问 etcd；
2、server 证书，客户端连接服务端时携带的证书，用于服务端验证客户端身份，如 etcd 对外提供服务；
3、peer 证书，相互之间连接时使用的证书，如 etcd 节点之间进行验证和通信。
这里全部都使用同一套证书认证。

2.1 在 master01 节点上操作

2.1.1 准备cfssl证书生成工具

#下面的证书已经过期了

wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 -O /usr/local/bin/cfssl
wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 -O /usr/local/bin/cfssljson
wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 -O /usr/local/bin/cfssl-certinfo

cd /usr/local/bin/
chmod +x /usr/local/bin/cfssl*
ls

------------------------------------------------------------------------------------------
cfssl：证书签发的工具命令
cfssljson：将 cfssl 生成的证书（json格式）变为文件承载式证书
cfssl-certinfo：验证证书的信息
cfssl-certinfo -cert <证书名称>            #查看证书的信息
------------------------------------------------------------------------------------------

2.1.2 生成Etcd证书

#上传 etcd-cert.sh 和 etcd.sh 到 /opt/k8s/ 目录中

mkdir /opt/k8s
cd /opt/k8s/
#添加证书脚本
#赋予执行权限
chmod +x /opt/k8s/*
ls

#修改脚本中的host主机地址，为master01、node01、node02

vim /opt/k8s/etcd-cert.sh

2.1.3 生成CA和api的证书和密钥

#创建用于生成CA证书、etcd 服务器证书以及私钥的目录

mkdir /opt/k8s/etcd-cert
mv etcd-cert.sh etcd-cert/
cd /opt/k8s/etcd-cert/
./etcd-cert.sh
ls

#上传 etcd-v3.4.9-linux-amd64.tar.gz 到 /opt/k8s 目录中，启动etcd服务

cd /opt/k8s/
#上传 etcd-v3.4.9-linux-amd64.tar.gz 安装包
#解压
tar xf etcd-v3.4.9-linux-amd64.tar.gz
cd etcd-v3.4.9-linux-amd64/
ls

Documentation  etcd  etcdctl  README-etcdctl.md  README.md  READMEv2-etcdctl.md

------------------------------------------------------------------------------------------
etcd就是etcd 服务的启动命令，后面可跟各种启动参数
etcdctl主要为etcd 服务提供了命令行操作
------------------------------------------------------------------------------------------

2.1.4 创建用于存放 etcd 配置文件，命令文件，证书的目录

cd
mkdir -p /opt/etcd/{cfg,bin,ssl}
cd /opt/k8s/etcd-v3.4.9-linux-amd64/
mv etcd etcdctl /opt/etcd/bin/
cp /opt/k8s/etcd-cert/*.pem /opt/etcd/ssl/

#查看
ls /opt/etcd/
ls /opt/etcd/bin/
ls /opt/etcd/ssl/

2.1.5 启动master端的etcd服务

执行 etcd.sh 脚本，启动master端的etcd服务

cd /opt/k8s/
ls
./etcd.sh etcd01 192.168.67.30 etcd02=https://192.168.67.12:2380,etcd03=https://192.168.67.13:2380

#执行后会进入卡住状态等待其他节点加入；

#这里需要三台etcd服务同时启动，如果只启动其中一台后，服务会卡在那里，直到集群中所有etcd节点都已启动；可忽略这个情况

#我们可以再打开一个页面来操作

2.1.6 另外打开一个窗口查看etcd进程是否正常

ps -ef | grep etcd

2.2 拷贝Etcd证书、命令和管理文件到node节点

把etcd相关证书文件、命令文件和服务管理文件全部拷贝到另外两个etcd集群节点

ls /opt/etcd/
scp -r /opt/etcd/ root@192.168.67.12:/opt/
scp -r /opt/etcd/ root@192.168.67.13:/opt/

#注意当运行过etcd.sh 之后才会有etcd.service 这个文件
scp /usr/lib/systemd/system/etcd.service root@192.168.67.12:/usr/lib/systemd/system
scp /usr/lib/systemd/system/etcd.service root@192.168.67.13:/usr/lib/systemd/system

2.2.2 到node节点查看一下

ls /opt/etcd/

ll -d /usr/lib/systemd/system/etcd.service
cat /usr/lib/systemd/system/etcd.service

2.3在 node01 节点上操作

2.3.1 修改etcd 文件中的IP为node01

vim /opt/etcd/cfg/etcd

#[Member]
            #修改
ETCD_NAME="etcd02"
ETCD_DATA_DIR="/var/lib/etcd/default.etcd"
                                        #修改
ETCD_LISTEN_PEER_URLS="https://192.168.67.12:2380"
                                        #修改
ETCD_LISTEN_CLIENT_URLS="https://192.168.67.12:2379"

#[Clustering]
                                                #修改
ETCD_INITIAL_ADVERTISE_PEER_URLS="https://192.168.67.12:2380"
                                            #修改
ETCD_ADVERTISE_CLIENT_URLS="https://192.168.67.12:2379"
ETCD_INITIAL_CLUSTER="etcd01=https://192.168.67.30:2380,etcd02=https://192.168.67.12:2380,etcd03=https://192.168.67.13:2380"
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster"
ETCD_INITIAL_CLUSTER_STATE="new"

2.3.2 启动etcd服务

systemctl start etcd
systemctl enable etcd
##systemctl enable --now etcd
systemctl status etcd

# systemctl在enable、disable、mask子命令里面增加了--now选项(表示立即执行)，可以激活同时启动服务，激活同时停止服务等。

2.4 在 node02 节点上操作

2.4.1 修改etcd 文件中的IP为node02

vim /opt/etcd/cfg/etcd

#[Member]
ETCD_NAME="etcd03"
ETCD_DATA_DIR="/var/lib/etcd/default.etcd"
ETCD_LISTEN_PEER_URLS="https://192.168.67.13:2380"
ETCD_LISTEN_CLIENT_URLS="https://192.168.67.13:2379"

#[Clustering]
ETCD_INITIAL_ADVERTISE_PEER_URLS="https://192.168.67.13:2380"
ETCD_ADVERTISE_CLIENT_URLS="https://192.168.67.13:2379"
ETCD_INITIAL_CLUSTER="etcd01=https://192.168.67.30:2380,etcd02=https://192.168.67.12:2380,etcd03=https://192.168.67.13:2380"
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster"
ETCD_INITIAL_CLUSTER_STATE="new"

2.4.2 启动etcd服务

systemctl start etcd
systemctl enable etcd
##systemctl enable --now etcd
systemctl status etcd

2.5 到master节点操作

回到master01 可以看到已经脱离卡住的状态了（注意超时了就再运行一次）

注意：

先启动etcd服务的机器将会成为master=true；

所以一定要先执行master的etcd.sh 脚本文件(启动etcd服务)，再启动node节点的etcd服务

2.5.1 检查etcd 群集 健康状态

在master01、node01、node02，都可以查看

V3；绝对路径；-- ca和server证书以及server密钥；

--endpoints集群中的地址列表，端口：2379；

2379：用于 etcd 集群内部节点之间的通信。集群中的各个 etcd 节点之间会使用2379端口进行通信和同步数据

#查看 health 状态
ETCDCTL_API=3 /opt/etcd/bin/etcdctl --cacert=/opt/etcd/ssl/ca.pem --cert=/opt/etcd/ssl/server.pem --key=/opt/etcd/ssl/server-key.pem --endpoints="https://192.168.67.30:2379,https://192.168.67.12:2379,https://192.168.67.13:2379" endpoint health --write-out=table

#查看 etcd 集群状态
ETCDCTL_API=3 /opt/etcd/bin/etcdctl --cacert=/opt/etcd/ssl/ca.pem --cert=/opt/etcd/ssl/server.pem --key=/opt/etcd/ssl/server-key.pem --endpoints="https://192.168.67.30:2379,https://192.168.67.12:2379,https://192.168.67.13:2379" endpoint status --write-out=table

------------------------------------------------------------------------------------------
--cert-file：识别HTTPS端使用SSL证书文件
--key-file：使用此SSL密钥文件标识HTTPS客户端
--ca-file：使用此CA证书验证启用https的服务器的证书
--endpoints：集群中以逗号分隔的机器地址列表
cluster-health：检查etcd集群的运行状况

--write-out=table：以表格的形式输出显示
------------------------------------------------------------------------------------------

2.5.2 查看etcd集群成员列表

ETCDCTL_API=3 /opt/etcd/bin/etcdctl --cacert=/opt/etcd/ssl/ca.pem --cert=/opt/etcd/ssl/server.pem --key=/opt/etcd/ssl/server-key.pem --endpoints="https://192.168.67.30:2379,https://192.168.67.12:2379,https://192.168.67.13:2379" --write-out=table member list

Etcd部署完成后，将虚拟机挂起，然后做快照

运行中的快照在恢复时由于etcd有同步功能，会导致恢复时node节点的错误数据会同步到刚还原的master上

三、部署 Master 组件

master组件签发证书

3.1 在 master01 节点上操作

cd /opt/k8s/

unzip master.zip
chmod +x *.sh
ls

3.1.1 创建kubernetes工作目录

mkdir -p /opt/kubernetes/{bin,cfg,ssl,logs}
ll /opt/kubernetes/

3.1.2 创建用于生成CA证书、相关组件的证书和私钥的目录

mkdir /opt/k8s/k8s-cert
mv /opt/k8s/k8s-cert.sh /opt/k8s/k8s-cert
cd /opt/k8s/k8s-cert/
vim /opt/k8s/k8s-cert/

3.1.3 修改 k8s-cert.sh 脚本中的host主机地址

3.1.4 执行脚本生成证书

./k8s-cert.sh
ls *.pem

3.1.5复制证书和私钥到ssl目录中

复制CA证书、apiserver相关证书和私钥到 kubernetes工作目录的 ssl 子目录中

cp ca*pem apiserver*pem /opt/kubernetes/ssl/
ll /opt/kubernetes/ssl/

#上传 kubernetes-server-linux-amd64.tar.gz 到 /opt/k8s/ 目录中，解压 kubernetes 压缩包
#下载地址：https://github.com/kubernetes/kubernetes/blob/release-1.20/CHANGELOG/CHANGELOG-1.20.md
#注：打开链接你会发现里面有很多包，下载一个server包就够了，包含了Master和Worker Node二进制文件。

tar xf kubernetes-server-linux-amd64.tar.gz
ls

3.1.6复制master组件的关键命令到bin 子目录中

#复制master组件的关键命令文件到 kubernetes工作目录的 bin 子目录中

cd /opt/k8s/kubernetes/server/bin/
cp kube-apiserver kubectl kube-controller-manager kube-scheduler /opt/kubernetes/bin
ls /opt/kubernetes/bin/
ln -s /opt/kubernetes/bin/* /usr/local/bin/
ls /usr/local/bin/

3.1.7创建token 认证文件

#创建 bootstrap token 认证文件，apiserver 启动时会调用，然后就相当于在集群内创建了一个这个用户，接下来就可以用 RBAC 给他授权

vim token.sh

#获取随机数前16个字节内容，以十六进制格式输出，并删除其中空格
BOOTSTRAP_TOKEN=$(head -c 16 /dev/urandom | od -An -t x | tr -d ' ')
#生成 token.csv 文件，按照 Token序列号,用户名,UID,用户组 的格式生成
cat > /opt/kubernetes/cfg/token.csv <<EOF
${BOOTSTRAP_TOKEN},kubelet-bootstrap,10001,"system:kubelet-bootstrap"
EOF

tr -d ' '     压缩空格；tr 压缩 -d ' '指定为空格；

                用户，                     用户id，                        加入的组

3.1.8 给token.sh 添加执行权限并运行

chmod +x token.sh
./token.sh

cat /opt/kubernetes/cfg/token.csv

3.2 开启 api服务

二进制文件、token、证书都准备好后，开启 apiserver 服务

3.2.1 修改apiserver.sh 的IP地址

cd /opt/k8s/
vim apiserver.sh

./apiserver.sh 192.168.67.30 https://192.168.67.30:2379,https://192.168.67.12:2379,https://192.168.67.13:2379

用来指定 API 服务器所要绑定的网络接口或者监听的地址；

这样做可以确保 API 服务器监听在特定的 IP 地址上，而不是默认的所有网络接口上

3.2.2 检查服务是否启动成功

ps aux | grep kube-apiserver
netstat -natp | grep 6443

#apiserver的接口为：6443 ；

安全端口6443用于接收HTTPS请求，用于基于Token文件或客户端证书等认证

3.2.3 启动 scheduler 服务

修改scheduler.sh 的IP地址

cd /opt/k8s/
ls
vim scheduler.sh

./scheduler.sh
ps aux | grep kube-scheduler

3.2.4 启动 controller-manager 服务

修改controller-manager.sh  的IP地址

vim controller-manager.sh

./controller-manager.sh
ps aux | grep kube-controller-manager

3.2.5 生成kubectl连接集群的kubeconfig文件

修改admin.sh 的IP地址

vim admin.sh

./admin.sh

3.2.6 通过kubectl工具查看当前集群组件状态

kubectl get cs

3.2.7 查看版本信息

kubectl version

四、部署 Worker Node 组件

4.1在所有 node 节点上操作

4.1.1创建kubernetes工作目录

mkdir -p /opt/kubernetes/{bin,cfg,ssl,logs}
ll /opt/kubernetes/

#上传 node.zip 到 /opt 目录中，解压 node.zip 压缩包，获得kubelet.sh、proxy.sh

cd /opt/
ls

unzip node.zip
chmod +x kubelet.sh  proxy.sh
ls

4.2 node02节点

4.3 在 master01 节点上操作

4.3.1 把 kubelet、kube-proxy 拷贝到 node 节点

cd /opt/k8s/kubernetes/server/bin/
scp kubelet kube-proxy root@192.168.67.12:/opt/kubernetes/bin/
scp kubelet kube-proxy root@192.168.67.13:/opt/kubernetes/bin/
或
#scp kubelet kube-proxy root@node01:/opt/kubernetes/bin/
#scp kubelet kube-proxy root@node02:/opt/kubernetes/bin/

4.3.2 到node节点查验一下

4.3.3 上传kubeconfig.sh文件到/opt/k8s/kubeconfig目录中

#上传kubeconfig.sh文件到/opt/k8s/kubeconfig目录中，生成kubelet初次加入集群引导kubeconfig文件和kube-proxy.kubeconfig文件

kubeconfig 文件包含集群参数（CA 证书、API Server 地址），客户端参数（上面生成的证书和私钥），集群 context 上下文参数（集群名称、用户名）。

Kubenetes 组件（如 kubelet、kube-proxy）通过启动时指定不同的 kubeconfig 文件可以切换到不同的集群，连接到 apiserver。

mkdir /opt/k8s/kubeconfig
cd /opt/k8s/kubeconfig
#上传安装包
#查看确认一下
chmod +x kubeconfig.sh
vim kubeconfig.sh

./kubeconfig.sh 192.168.67.30 /opt/k8s/k8s-cert/

4.3.4 拷贝 .kubeconfig 文件到 node 节点

#把配置文件 bootstrap.kubeconfig、kube-proxy.kubeconfig 拷贝到 node 节点

scp bootstrap.kubeconfig kube-proxy.kubeconfig root@node01:/opt/kubernetes/cfg/
scp bootstrap.kubeconfig kube-proxy.kubeconfig root@node02:/opt/kubernetes/cfg/

4.4 到node节点验证

4.5 RBAC授权

#RBAC授权，使用户 kubelet-bootstrap 能够有权限发起 CSR 请求证书

kubectl create clusterrolebinding kubelet-bootstrap --clusterrole=system:node-bootstrapper --user=kubelet-bootstrap

kubelet-bootstrap：绑定

--clusterrole=：绑定的用户组

#若执行失败，可先给kubectl绑定默认cluster-admin管理员集群角色，授权集群操作权限

kubectl create clusterrolebinding cluster-system-anonymous --clusterrole=cluster-admin --user=system:anonymous

------------------------------------------------------------------------------------------
kubelet 采用 TLS Bootstrapping 机制，自动完成到 kube-apiserver 的注册，在 node 节点量较大或者后期自动扩容时非常有用。
Master apiserver 启用 TLS 认证后，node 节点 kubelet 组件想要加入集群，必须使用CA签发的有效证书才能与 apiserver 通信，当 node 节点很多时，签署证书是一件很繁琐的事情。因此 Kubernetes 引入了 TLS bootstraping 机制来自动颁发客户端证书，kubelet 会以一个低权限用户自动向 apiserver 申请证书，kubelet 的证书由 apiserver 动态签署。

kubelet 首次启动通过加载 bootstrap.kubeconfig 中的用户 Token 和 apiserver CA 证书发起首次 CSR 请求，这个 Token 被预先内置在 apiserver 节点的 token.csv 中，其身份为 kubelet-bootstrap 用户和 system:kubelet-bootstrap 用户组；想要首次 CSR 请求能成功（即不会被 apiserver 401 拒绝），则需要先创建一个 ClusterRoleBinding，将 kubelet-bootstrap 用户和 system:node-bootstrapper 内置 ClusterRole 绑定（通过 kubectl get clusterroles 可查询），使其能够发起 CSR 认证请求。

TLS bootstrapping 时的证书实际是由 kube-controller-manager 组件来签署的，也就是说证书有效期是 kube-controller-manager 组件控制的；kube-controller-manager 组件提供了一个 --experimental-cluster-signing-duration 参数来设置签署的证书有效时间；默认为10年= 8760h0m0s，将其改为 87600h0m0s，即 10 年后再进行 TLS bootstrapping 签署证书即可。

也就是说 kubelet 首次访问 API Server 时，是使用 token 做认证，通过后，Controller Manager 会为 kubelet 生成一个证书，以后的访问都是用证书做认证了。
------------------------------------------------------------------------------------------

4.6 在 node01 节点上操作

cd /opt/
#检查一下kubelet.sh 文件
vim kubelet.sh

-  表示判断，如果${2}是空值，就会写入 "-" 后面的IP地址

./kubelet.sh 192.168.67.12

ps aux | grep kubelet

4.7 在 master01 节点上操作，通过 CSR 请求

#检查到 node01 节点的 kubelet 发起的 CSR 请求，Pending 表示等待集群给该节点签发证书

#查看集群中的证书签发请求
kubectl get csr

通过运行 kubectl get csr 命令；

您可以查看当前集群中所有的证书签发请求，包括待批准、已批准或已拒绝的请求。

这些请求通常与证书颁发机构（CA）相关联，用于生成证书以进行安全通信

4.7.1 通过 CSR 请求

kubectl certificate approve node-csr-tdE9sriQ3uzw79cGxlGEoMIyiAwHYOAX2pE2mC7yt84

4.7.2 查看节点

#查看节点，由于网络插件还没有部署，节点会没有准备就绪 NotReady

kubectl get node

4.8 在 node01 节点上操作

4.8.1 加载 ip_vs 模块

for i in $(ls /usr/lib/modules/$(uname -r)/kernel/net/netfilter/ipvs|grep -o "^[^.]*");do echo $i; /sbin/modinfo -F filename $i >/dev/null 2>&1 && /sbin/modprobe $i;done

4.8.2 启动proxy服务

cd /opt/
./proxy.sh 192.168.67.12
ps aux | grep kube-proxy

4.9 添加node02

4.9.1 在node02 节点操作

#启动 kubelet 服务
./kubelet.sh 192.168.67.13
ps aux | grep kubelet

4.9.2 在master上操作 

#查看集群中的证书签发请求
kubectl get csr
#手动进行性签发
kubectl certificate approve node-csr-NFUalFZi93QAEzrKk7YrIKRllhovRL1W7X6BuNpsM3s
#再次查看
kubectl get csr

4.9.3 在node02上操作

#加载 ip_vs 模块
for i in $(ls /usr/lib/modules/$(uname -r)/kernel/net/netfilter/ipvs|grep -o "^[^.]*");do echo $i; /sbin/modinfo -F filename $i >/dev/null 2>&1 && /sbin/modprobe $i;done

#启动proxy服务
cd /opt/
./proxy.sh 192.168.67.13
ps aux | grep kube-proxy

五、部署 CNI 网络组件★★★★★

1、K8S 中 Pod 网络通信：

Service网络：clusterIP、service ip地址、虚拟IP地址

Pod网络：podIP、docker容器使用的IP地址、虚拟IP地址

节点网络：物理服务器网卡IP地址

一个pod只有一个IP地址；

pod与pod之间的通信，需要通过网络插件进行封装、解封装来进行通信

service网络是pod网络的负载均衡器

●Pod内 容器与容器之间的通信
在同一个 Pod 内的容器（Pod 内的容器是不会跨宿主机的）共享同一个网络命名空间，相当于它们在同一台机器上一样，可以用 localhost 地址访问彼此的端口

●同一个 Node 内 Pod 之间的通信
每个 Pod 都有一个真实的全局 IP 地址，同一个 Node 内的不同 Pod 之间可以直接采用对方 Pod 的 IP 地址进行通信，Pod1 与 Pod2 都是通过 Veth 连接到同一个 docker0/cni0 网桥，网段相同，所以它们之间可以直接通信

●不同 Node 上 Pod 之间的通信
Pod 地址与 docker0 在同一网段，docker0 网段与宿主机网卡是两个不同的网段，且不同 Node 之间的通信只能通过宿主机的物理网卡进行；
要想实现不同 Node 上 Pod 之间的通信，就必须想办法通过主机的物理网卡 IP 地址进行寻址和通信。因此要满足两个条件：Pod 的 IP 不能冲突；将 Pod 的 IP 和所在的 Node 的 IP 关联起来，通过这个关联让不同 Node 上 Pod 之间直接通过内网 IP 地址通信

2、Overlay Network：

叠加网络，在二层或者三层基础网络上叠加的一种虚拟网络技术模式，该网络中的主机通过虚拟链路隧道连接起来。
通过Overlay技术（可以理解成隧道技术），在原始报文外再包一层四层协议（UDP协议），通过主机网络进行路由转发。这种方式性能有一定损耗，主要体现在对原始报文的修改。目前Overlay主要采用VXLAN。

3、Flannel：

Flannel 的功能是让集群中的不同节点主机创建的 Docker 容器都具有全集群唯一的虚拟 IP 地址。
Flannel 是 Overlay 网络的一种，也是将 TCP 源数据包封装在另一种网络包里面进行路由转发和通信，目前支持 UDP、VXLAN、Host-gw 3种数据转发方式。

4、Flannel UDP 模式的工作原理：

数据从主机 A 上 Pod 的源容器中发出后，经由所在主机的 docker0/cni0 网络接口转发到 flannel0 接口，flanneld 服务监听在 flannel0 虚拟网卡的另外一端。
Flannel 通过 Etcd 服务维护了一张节点间的路由表。

源主机 A 的 flanneld 服务将原本的数据内容封装到 UDP 报文中， 根据自己的路由表通过物理网卡投递给目的节点主机 B 的 flanneld 服务，数据到达以后被解包，然后直接进入目的节点的 flannel0 接口， 之后被转发到目的主机的 docker0/cni0 网桥，最后就像本机容器通信一样由 docker0/cni0 转发到目标容器。

5、VXLAN：

将源数据包封装到UDP中；

并使用基础网络的IP/MAC作为外层报文头进行封装；

然后在以太网上传输，到达目的地；

后由隧道端点解封装并将数据发送给目标地址。

隧道模式，默认配置；利用内核

相比VLAN技术，VXLAN技术具有以下的优势:
1）24位长度的VNI字段值可以支持更多数量的虚拟网络，解决了VLAN数目上限为4094的局限性的问题。

2）VXLAN技术通过隧道技术在物理的三层网络中虚拟二层网络，处于VXLAN网络的终端无法察觉到VXLAN的通信过程，这样也就使得罗辑网络拓扑和物理网络拓扑实现了一定程度的解耦，网络拓扑的配置对于物理设备的配置的依赖程度有所降低，配置更灵活更方便。
3）VLAN技术仅仅解决了二层网络广播域分割的问题，而VXLAN技术还具有多租户支持的特性，通过VXLAN分割，各个租户可以独立组网、通信，地址分配方面和多个租户之间地址冲突的问题也得到了解决。

6、ETCD 之 Flannel 提供说明:

存储管理Flannel可分配的IP地址段资源
监控 ETCD 中每个 Pod 的实际地址，并在内存中建立维护 Pod 节点路由表

由于 UDP 模式是在用户态做转发，会多一次报文隧道封装，因此性能上会比在内核态做转发的 VXLAN 模式差。

#VXLAN 模式：
VXLAN 模式使用比较简单，flannel 会在各节点生成一个 flannel.1 的 VXLAN 网卡（VTEP设备，负责 VXLAN 封装和解封装）。
VXLAN 模式下作是由内核进行的。flannel 不转发数据，仅动态设置 ARP 表和 MAC 表项。
UDP 模式的 flannel0 网卡是三层转发，使用 flannel0 时在物理网络之上构建三层网络，属于 ip in udp ；VXLAN封包与解包的工 模式是二层实现，overlay 是数据帧，属于 mac in udp 。

7、Flannel VXLAN 模式跨主机的工作原理：

1、数据帧从主机 A 上 Pod 的源容器中发出后，经由所在主机的 docker0/cni0 网络接口转发到 flannel.1 接口
2、flannel.1 收到数据帧后添加 VXLAN 头部，通过内核封装在 UDP 报文中
3、主机 A 通过物理网卡(路由表)发送封包到主机 B 的物理网卡中
4、主机 B 的物理网卡再通过 VXLAN 默认端口 4789 转发到 flannel.1 接口(内核)进行解封装
5、解封装以后，内核将数据帧发送到 cni0，最后由 cni0 发送到桥接到此接口的容器 B 中。

六、部署 flannel

部署前可以先将前面做好的内容做个快照；最好是现将所有机器挂起后再做快照

5.1 在 node01 节点上操作

cd /opt/
#导入cni-plugins-linux-amd64-v0.8.6.tgz安装包和flannel.tar镜像包

#载入flannel.tar镜像，查看镜像
docker load -i flannel.tar
docker images

Moba添加文件的方法

5.1.1创建cni 的目录并解压到该目录

mkdir -p /opt/cni/bin
tar xf cni-plugins-linux-amd64-v0.8.6.tgz -C /opt/cni/bin/
ll /opt/cni/bin/

5.2 在 master01 节点上操作

#上传 kube-flannel.yml 文件到 /opt/k8s 目录中，部署 CNI 网络

cd /opt/k8s/
#添加kube-flannel.yml 文件

# -f  指定文件
kubectl applay -f kube-flannel.yml

# -n 全称是是namespace，指定命名空间
kubectl get pods -n kube-system

kubectl get nodes

5.3 node02载入镜像和CNI

//在node02上操作

cd /opt/
#导入cni-plugins-linux-amd64-v0.8.6.tgz安装包和flannel.tar镜像包

#载入镜像，查看镜像
docker load -i flannel.tar
docker images

#创建cni 的目录并解压到该目录
mkdir -p /opt/cni/bin
tar xf cni-plugins-linux-amd64-v0.8.6.tgz -C /opt/cni/bin/
ll /opt/cni/bin/

5.4 在master上操作

kubectl get pods -n kube-system

kubectl get nodes

六、部署 Calico

flannel和Calico部署一个就行了；我们快照回到部署fan nel 前

（这里我忘了做快照了所以就不回去了）

1、k8s 组网方案对比:

●flannel方案——封装
需要在每个节点上把发向容器的数据包进行封装后，再用隧道将封装后的数据包发送到运行着目标Pod的node节点上。目标node节点再负责去掉封装，将去除封装的数据包发送到目标Pod上。数据通信性能则大受影响。

●calico方案——路由
Calico不使用隧道或NAT来实现转发，而是把Host当作Internet中的路由器，使用BGP同步路由，并使用iptables来做安全访问策略，完成跨Host转发。
采用直接路由的方式，这种方式性能损耗最低，不需要修改报文数据，但是如果网络比较复杂场景下，路由表会很复杂，对运维同事提出了较高的要求。

calico会选择最佳的路由路径进行转发数据；

不管远近，会选择最快到达目标的路径；短路径阻塞时，就算绕一大圈也会走

2、Calico 主要由三个部分组成：

Calico CNI插件：主要负责与kubernetes对接，供kubelet调用使用。
Felix：负责维护宿主机上的路由规则、FIB转发信息库等。
BIRD：负责分发路由规则，类似路由器。
Confd：配置管理组件。

3、Calico 工作原理：

Calico 是通过路由表来维护每个 pod 的通信。Calico 的 CNI 插件会为每个容器设置一个 veth pair 设备， 然后把另一端接入到宿主机网络空间，由于没有网桥，CNI 插件还需要在宿主机上为每个容器的 veth pair 设备配置一条路由规则， 用于接收传入的 IP 包。
有了这样的 veth pair 设备以后，容器发出的 IP 包就会通过 veth pair 设备到达宿主机，然后宿主机根据路由规则的下一跳地址， 发送给正确的网关，然后到达目标宿主机，再到达目标容器。
这些路由规则都是 Felix 维护配置的，而路由信息则是 Calico BIRD 组件基于 BGP 分发而来。
calico 实际上是将集群里所有的节点都当做边界路由器来处理，他们一起组成了一个全互联的网络，彼此之间通过 BGP 交换路由， 这些节点我们叫做 BGP Peer。

目前比较常用的CNI网络组件是flannel和calico，flannel的功能比较简单，不具备复杂的网络策略配置能力，calico是比较出色的网络管理插件，但具备复杂网络配置能力的同时，往往意味着本身的配置比较复杂，所以相对而言，比较小而简单的集群使用flannel，考虑到日后扩容，未来网络可能需要加入更多设备，配置更多网络策略，则使用calico更好。

4、网络插件

常用：

        CNI

不常用：

        antree

        cannel

        kube-ovn

        weave ne

6.1在 master01 节点上操作

#上传 calico.yaml 文件到 /opt/k8s 目录中，部署 CNI 网络

cd /opt/k8s/
vim calico.yaml

#添加calico.yaml 文件
#修改3878和3879 行；取消注释，将网段改为：10.244.0.0/16

#修改里面定义 Pod 的网络（CALICO_IPV4POOL_CIDR），需与前面 kube-controller-manager 配置文件指定的 cluster-cidr 网段一样
    - name: CALICO_IPV4POOL_CIDR
      value: "10.244.0.0/16"        #Calico 默认使用的网段为 192.168.0.0/16

kubectl apply -f calico.yaml

kubectl get pods -n kube-system
#等 Calico Pod 都 Running，节点也会准备就绪（这个过程短则两三分，长则十几分）
kubectl get nodes

6.2 node02 节点部署

//在 node01 节点上操作

cd /opt/
scp kubelet.sh proxy.sh root@192.168.67.13:/opt/
scp -r /opt/cni root@192.168.67.13:/opt/

//在 node02 节点上操作

(下面的操作不用做了，前面已经做过了)

#启动kubelet服务
cd /opt/
chmod +x kubelet.sh
./kubelet.sh 192.168.67.13

//在 master01 节点上操作
kubectl get csr

NAME                                                   AGE  SIGNERNAME                                    REQUESTOR           CONDITION
node-csr-BbqEh6LvhD4R6YdDUeEPthkb6T_CJDcpVsmdvnh81y0   10s  kubernetes.io/kube-apiserver-client-kubelet   kubelet-bootstrap   Pending
node-csr-duiobEzQ0R93HsULoS9NT9JaQylMmid_nBF3Ei3NtFE   85m  kubernetes.io/kube-apiserver-client-kubelet   kubelet-bootstrap   Approved,Issued

#通过 CSR 请求
kubectl certificate approve node-csr-BbqEh6LvhD4R6YdDUeEPthkb6T_CJDcpVsmdvnh81y0

kubectl get csr

NAME                                                   AGE  SIGNERNAME                                    REQUESTOR           CONDITION
node-csr-BbqEh6LvhD4R6YdDUeEPthkb6T_CJDcpVsmdvnh81y0   23s  kubernetes.io/kube-apiserver-client-kubelet   kubelet-bootstrap   Approved,Issued
node-csr-duiobEzQ0R93HsULoS9NT9JaQylMmid_nBF3Ei3NtFE   85m  kubernetes.io/kube-apiserver-client-kubelet   kubelet-bootstrap   Approved,Issued

#加载 ipvs 模块
for i in $(ls /usr/lib/modules/$(uname -r)/kernel/net/netfilter/ipvs|grep -o "^[^.]*");do echo $i; /sbin/modinfo -F filename $i >/dev/null 2>&1 && /sbin/modprobe $i;done

#使用proxy.sh脚本启动proxy服务
cd /opt/
chmod +x proxy.sh
./proxy.sh 192.168.67.13

6.3 查看群集中的节点状态

kubectl get nodes

七、部署 CoreDNS

CoreDNS：可以为集群中的 service 资源创建一个域名 与 IP 的对应关系解析

7.1 在所有 node 节点上操作 

cd /opt/
#添加 coredns.tar 镜像包到 /opt 目录中

#载入镜像并查看
docker load -i coredns.tar
docker images

7.2 在 master01 节点上操作

7.2.1 上传 coredns.yaml 文件到 /opt/k8s 目录中，部署 CoreDNS 

cd /opt/k8s
#上传coredns.yaml 文件，查看文件，确保与node节点的coredns版本一致，再执行

kubectl apply -f coredns.yaml
kubectl get pods -n kube-system

7.2.2 DNS解析测试

kubectl run -it --rm dns-test --image=busybox:1.28.4 sh

nslookup kubernetes
exit

报错：

原因：需要添加 rbac的权限  直接使用kubectl绑定  clusteradmin 管理员集群角色  授权操作权限

解决：

八、总结

时间同步：

yum install ntpdate -y

timedatectl set-timezone Asia/Shanghai

ntpdate time.windows.com

CA证书是什么

CA其实是Certification Authority的缩写，翻译过来就是认证机构，它原意指的是一个负责签发证书、认证证书、管理已颁发证书的机构，类似于发驾照的车管所。

在接到企业的发证申请后，他们会核查申请者的信息，并给企业颁发一个数字证书，用来对文件进行加密、对材料进行签章等

做软连接

做软连接，目的是为了在任何目录都可以执行命令

1、k8s 二进制部署过程

ETCD

准备ca证书和私钥文件，首先 CA签发服务端证书和私钥文件

使用CA 证书、服务端证书和私钥文件，加上etcd集群的配置文件，来启动etcd服务

复制etcd工作目录和管理文件；到另外几个node节点上；修改etcd集群的配置文件，并启动etcd服务

使用V3版本的接口，去执行etcdctl +证书选项（endpoind、healh）| endpoint、status|member list 查看etcd 集群和节点的状态

master组件

1.准备组件相关的证书和私钥文件，

准备bootstrap token认证文件（给kubelet 启动时签发证书使用）

准备组件，来启动配置文件

启动apiserver；端口为：6443

2.启动controller-manager，scheduller

准备启动配置文件

准备相关证书和私钥文件，来生成kubeconfig 文件（来指定对接的apiserver 使用什么证书认证）启动服务

3.检查集群组件状态

需要准备kubeconfig 文件，把kubelet加入到集群中（指定对接的apiserver，使用什么证书认证）

kubectl get cs

CNI网络插件

企业使用的插件是Flannel和Calico

1.Flannel

配置方便，功能简单，基于overlay叠加(叠加二、三层网络)网络来实现，由于需要进行封装和解封装，会导致性能有一定影响，同时具备策略配置能力的三种模式(根据需求和场景，配置一种即可)

UDP

Vxlan

host-getwe

默认虚拟网段设为：10.244.0.0/16

2.Calico

功能强大，没有封装和解封装的过程，对性能影响小，具有网络策略配置的能力，但是路由表维护起来比较复杂；

默认网段：192.168.0.0/16

模式：网络BGP、IPIP

k8s里的dns解析；安装解析一下就结束了

多master架构部署

首先部署master02等其他master节点（将master01的配置文件(私钥、服务、执行文件)考培到新的master）

然后搭建nginx/haproxy + keepalived 对master节点做高可用负载均衡器

kubectl 的配置文件也要去对接VIP或者当前的节点

二进制安装步骤总结

1， 环境部署

关闭防火墙 关闭selinux 关闭swap 根据规划设置主机名

做域名映射 调整内核参数 时间同步

2，node 节点 部署 docker引擎

3，部署 etcd 集群

大体步骤是 etcd 目录下（cfg bin ssl 三个子目录）

3.1 ssl 子目录准备

下载CFSSL 工具

用etcd-cert.sh脚本 生成CA证书、etcd 服务器证书以及私钥

4个.pem 结尾的 文件 放ssl

3.2 bin 子目录准备

下载 etcd 的安装包（etcd-v3.4.9-linux-amd64.tar.gz） 解压

将可执行文件 etcd etcdctl 移动到 bin

3.3 脚本启动一台etcd01

etcd.sh

3.4 做其他的etcd

拷贝 etcd 目录下（cfg bin ssl 三个子目录）

拷贝服务管理文件

改其他etcd机器的 etcd 目录下cfg子目录的配置文件的IP

4，部署 Master 组件

大体步骤是 kubernetes目录 下 bin,cfg,ssl,logs 四个子目录

4.1 ssl 子目录准备

下载CFSSL 工具

用k8s-cert.sh 脚本 生成CA证书、apiserver相关证书和私钥

4个.pem 结尾的 文件 放ssl

4.2 bin 子目录准备

下载master的安装包（ kubernetes-server-linux-amd64.tar.gz） 解压

将可执行文件 （kube-apiserver kubectl kube-controller-manager kube-scheduler）移动到 bin

4.3 cfg 目录准备

用token.sh 脚本 在/opt/kubernetes/cfg/token.csv 生成token 令牌

4.4 启动 apiserver 服务

用 apiserver.sh 脚本

4.5 启动 scheduler 服务

用scheduler.sh 脚本 （需要在脚本指定api server 的ip）

4.6 启动 controller-manager 服务

用controller-manager.sh 脚本 （需要在脚本指定api server 的ip）

4.7 启动 kubectl 工具

用 admin.sh 脚本 （需要在脚本指定api server 的ip）

5, 部署 Worker Node 集群

大体步骤是 kubernetes目录 下 bin,cfg,ssl,logs 四个子目录

5.1 bin 子目录 准备

将master的安装包（ kubernetes-server-linux-amd64.tar.gz） 解压后的 可执行文件 kubelet kube-proxy 放入

5.2 cfg 子目录准备

在master机器 用kubeconfig.sh 脚本 生成生成kubelet初次加入集群需要的bootstrap.kubeconfig、kube-proxy.kubeconfig

把bootstrap.kubeconfig、kube-proxy.kubeconfig 放入

5.3 master 机器做RBAC授权

RBAC授权，使用户 kubelet-bootstrap 能够有权限发起 CSR 请求证书

5.4 启动 kubelet 服务

kubelet.sh 脚本

5.5 master通过 CSR 请求

因为启动了 kubelet 服务 所以会有来自node的请求

检查CSR 请求 （kubectl get csr）

并通过 CSR 请求 （kubectl certificate approve 请求编号）

5.6 启动 proxy 服务

加载 ip_vs 模块

proxy.sh 脚本 启动

6， 部署 flannel

6.1 node机器

载入 flannel 镜像

将cni 包加压到 /opt/cni/bin

6.2 master 机器

执行部署的 yaml 文件 kubectl apply -f kube-flannel.yml

7，部署 Calico

7.1 master 机器
（改ip）执行部署的 yaml 文件 kubectl apply -f calico.yaml