Kubernetes二进制单节点集群部署

Posted Richard_Chiang

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Kubernetes二进制单节点集群部署相关的知识，希望对你有一定的参考价值。

Kubernetes二进制单节点集群部署

常见的K8S按照部署方式

●Mini kube
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集群，新手推荐。https://github.com/kubernetes/kubernetes/releases

Kubernetes二进制部署

服务器 IP地址 安装工具
K8s集群master01（ectd节点1） 192.168.80.21 kube-apiserver kube-controller-manager kube-scheduler etcd
K8s集群node01（etcd节点2） 192.168.80.7 kubelet kube-proxy docker flannel
K8s集群node02（etcd节点3） 192.168.80.8 kubelet kube-proxy docker flannel

操作系统初始化配置

#关闭防火墙
systemctl stop firewalld
systemctl disable firewalld
iptables -F && iptables -t nat -F && iptables -t mangle -F && iptables -X

#关闭SE安全中心
setenforce 0
sed -i s/enforcing/disabled/ /etc/selinux/config 

#关闭swap 
swapoff -a                                   #临时关闭
sed -ri s/.*swap.*/#&/ /etc/fstab          #永久关闭，&符号代表前面匹配的所有

#根据规划设置主机名
hostnamectl set-hostname master01 
hostnamectl set-hostname node01 
hostnamectl set-hostname node02

#在master添加hosts
cat >> /etc/hosts << EOF 
192.168.80.21 master01 
192.168.80.7 node01 
192.168.80.8 node02 
EOF

#将桥接的IPv4流量传递到iptables的链
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
sysctl --system

#时间同步，可以加入计划任务定时执行减小偏差
yum install ntpdate -y
ntpdate time.windows.com

部署 etcd 集群

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

Etcd 作为服务发现系统，有以下的特点：

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

etcd 目前默认使用2379端口提供HTTP API服务，2380端口和peer通信（这两个端口已经被IANA（互联网数字分配机构）官方预留给etcd）。即etcd默认使用2379端口对外为客户端提供通讯，使用端口2380来进行服务器间内部通讯。etcd 在生产环境中一般推荐集群方式部署。由于etcd 的leader选举机制，要求至少为3台或以上的奇数台。

准备签发证书环境

CFSSL是CloudFlare 公司开源的一款 PKI/TLS 工具。CFSSL包含一个命令行工具和一个用于签名、验证和捆绑 TLS 证书的 HTP API 服务。使用Go语言编写。

CESSL 使用配置文件生成证书，因此自签之前，需要生成它识别的 json 格式的配置文件，CESSL提供了方便的命令行生成配置文件。

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

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

在 master01 节点上操作下载证书制作工具

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 
或
curl -L https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 -o /usr/local/bin/cfssl
curl -L https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 -o /usr/local/bin/cfssljson
curl -L https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 -o /usr/local/bin/cfssl-certinfo 

chmod +x /usr/local/bin/cfssl*                       #提前下载好拉入/usr/local/bin/目录并授权    
字段解析
cfssl：证书签发的工具命令
cfssljson：将 cfssl 生成的证书（json格式）变为文件承载式证书
cfssl-certinfo：验证证书的信息

cfssl-certinfo-cert <证书名称>                        #查看证书的信息
#创建k8s工作目录
mkdir /opt/k8s 
cd /opt/k8s/

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

#创建用于生成CA证书、etcd 服务器证书以及私钥的目录
mkdir /opt/k8s/etcd-cert 
mv etcd-cert.sh etcd-cert/
cd /opt/k8s/etcd-cert/
./etcd-cert.sh                                       #生成CA证书、etcd 服务器证书以及私钥

启动etcd服务

#上传 etcd-v3.3.10-linux-amd64.tar.gz 到 /opt/k8s/ 目录中，解压 etcd 压缩包
cd /opt/k8s/
tar zxvf etcd-v3.4.9-linux-amd64.tar.gz
ls etcd-v3.4.9-linux-amd64
#etcd就是etcd 服务的启动命令，后面可跟各种启动参数
#etcdctl主要为etcd 服务提供了命令行操作

#创建用于存放 etcd 配置文件，命令文件，证书的目录
mkdir -p /opt/etcd/cfg,bin,ssl

#移动etcd和etcdctl文件到自定义的命令文件中
mv /opt/k8s/etcd-v3.4.9-linux-amd64/etcd /opt/k8s/etcd-v3.4.9-linux-amd64/etcdctl /opt/etcd/bin/             
cp /opt/k8s/etcd-cert/ *.pem /opt/etcd/ssl/

#启动etcd服务
/opt/k8s/etcd.sh etcd01 192.168.80.21 etcd02=https://192.168.80.7:2380,etcd03=https://192.168.80.8:2380
#进入卡住状态等待其他节点加入，这里需要三台etcd服务同时启动，如果只启动其中一台后，服务会卡在那里，直到集群中所有etcd节点都已启动，可忽略这个情况

#另外打开一个窗口查看etcd进程是否正常
ps -ef | grep etcd

#把etcd相关证书文件和命令文件全部拷贝到另外两个etcd集群节点
scp -r /opt/etcd/ root@192.168.80.7:/opt/
scp -r /opt/etcd/ root@192.168.80.8:/opt/

#把etcd服务管理文件拷贝到另外两个集群节点
scp /usr/lib/systemd/system/etcd.service root@192.168.80.7:/usr/lib/systemd/system/
scp /usr/lib/systemd/system/etcd.service root@192.168.80.8:/usr/lib/systemd/system/

#在etcd集群的其他节点配置对应的服务器名和ip地址
vim /opt/etcd/cfg/etcd

  • 在etcd集群的其他节点配置对应的服务器名和IP地址

#启动etcd服务
systemctl start etcd
systemctl enable etcd
systemctl status etcd

#在master01节点（etcd01）上操作检查etcd群集状态
ln -s /opt/etcd/bin/etcd* /usr/local/bin 
#检查etcd群集状态
cd /opt/etcd/ssl 
/opt/etcd/bin/etcdctl \\
--ca-file=ca.pem \\
--cert-file=server.pem \\
--key-file=server-key.pem \\
--endpoints="https://192.168.80.21:2379,https://192.168.80.7:2379,https://192.168.80.8:2379" \\
cluster-health
字段解析
--ca-file∶使用此CA证书验证启用https的服务器的证书
--cert-file∶识别HTTPS端使用SSL证书文件
--key-file∶使用此SSL密钥文件标识HTTPS客户端
--endpoints∶集群中以逗号分隔的机器地址列表
cluster-health∶检查etcd集群的运行状况

#检查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.80.21:2379,https://192.168.80.7:2379,https://192.168.80.8:2379" endpoint health --write-out=table
或
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.80.21:2379,https://192.168.80.7:2379,https://192.168.80.8:2379" --write-out=table member list

部署docker引擎

  • 所有 node 节点部署docker引擎
yum install -y yum-utils device-mapper-persistent-data lvm2 
yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo 
yum install -y docker-ce docker-ce-cli containerd.io

systemctl start docker.service
systemctl enable docker.service

部署 master节点组件

  • 在 master01 节点上操作

启动apiserver组件

上传 master.zip 和 k8s-cert.sh 到 /opt/k8s 目录中，解压 master.zip压缩包
cd /opt/k8s/
unzip master.zip    #解压出压缩包里三种组件的启动脚本
apiserver.sh 
scheduler.sh
controller-manager.sh                                            
chmod +x *.sh       #给执行脚本权限
#创建kubernetes工作目录
mkdir -p /opt/kubernetes/bin,cfg,ssl,logs
#创建用于生成CA证书、相关组件的证书和私钥的目录
mkdir /opt/k8s/k8s-cert
mv /opt/k8s/k8s-cert.sh /opt/k8s/k8s-cert 
cd /opt/k8s/k8s-cert/
./k8s-cert.sh       #生成CA证书、相关组件的证书和私钥，需要在文件中添加apiserver可能用到的所有ip

ls *pem
admin-key.pem  apiserver-key.pem  ca-key.pem  kube-proxy-key.pem
admin.pem      apiserver.pem      ca.pem      kube-proxy.pem
#controller-manager和kube-scheduler设置为只调用当前机器的apiserver，使用127.0.0.1:8080通信，与apiserver在同一台机器上，因此不需要签发证书

#复制CA证书、apiserver相关证书和私钥到kubernetes工作目录的ssl子目录中
cp ca*pem apiserver*pem /opt/kubernetes/ssl/

#上传 kubernetes-server-linux-ama64.tar.gz 到 /opt/k8s/ 目录中，解压 kubernetes 压缩包
cd /opt/k8s/
tar zxvf kubernetes-server-linux-amd64.tar.gz

#复制master组件的关键命令文件到 kubernetes工作目录的 bin 子目录中
cd /opt/k8s/kubernetes/server/bin
cp kube-apiserver kubectl kube-controller-manager kube-scheduler /opt/kubernetes/bin/
ln -s /opt/kubernetes/bin/* /usr/local/bin/

#创建 bootstrap token 认证文件，apiserver 启动时会调用，然后就相当于在集群内创建了一个这个用户，接下来就可以用 RBAC 给他授权（注意文件token.csv内文件格式，如果格式问题可能后续证书无法正常对接）
cd /opt/k8s/
vim token.sh 
#!/bin/bash
#获取随机数前16个字节内容，以十六进制格式输出，并删除其中空格，/dey/urandom为生成随机数的设备，head -c 可以指定字节
BOOTSTRAP_TOKEN=$(head -c 16 /dev/urandom | od -An -t x | tr -d   )
#生成 token.csv 文件，按照 Token序列号，用户名，UID，用户组的格式生成，
cat > /opt/kubernetes/cfg/token.csv <<EOF
$BOOTSTRAP_TOKEN,kubelet-bootstrap,10001,"system:kubelet-bootstrap"
EOF
chmod +x token.sh 
./token.sh
cat /opt/kubernetes/cfg/token.csv

#二进制文件token证书都准备好后，开启apiserver服务
cd /opt/k8s/
./apiserver.sh 192.168.80.21 https://192.168.80.21:2379,https://192.168.80.7:2379,https://192.168.80.8:2379 
#检查进程是否启动成功
ps aux | grep kube-apiserver

  • 使用head -c 16 /dev/urandom | od -An -t x | tr -d 可以随机生成序列号,并创建token.csv文件，也可以使用脚本创建

#k8s通过kube-apiserver这个进程提供服务，该进程运行在单个master节点上。默认有两个端口6443和8080 
#安全端口6443用于接收HTTPS请求，用于基于Token文件或客户端证书等认证
netstat -natp | grep 6443

#查看版本信息（必须保证apiserver启动正常，不然无法查询到server的版本信息）
kubectl version

#启动 scheduler 服务
./scheduler.sh
ps aux | grep kube-scheduler

#启动 controller-manager 服务
./controller-manager.sh
ps aux | grep kube-controller-manager

#生成kubectl连接集群的证书
./admin.sh
#绑定默认cluster-admin管理员集群角色，授权kubectl访问集群
kubectl create clusterrolebinding cluster-system-anonymous --clusterrole=cluster-admin --user=system:anonymous

#查看master节点状态
kubectl get cs

部署 Worker node节点组件

  • 在所有 node 节点上操作
#创建kubernetes工作目录
mkdir -p /opt/kubernetes/bin,cfg,ssl,logs

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

  • 在 master01 节点上操作
#把 kubelet、kube-proxy 拷贝到 node 节点
cd /opt/k8s/kubernetes/server/bin
scp kubelet kube-proxy root@192.168.80.7:/opt/kubernetes/bin/
scp kubelet kube-proxy root@192.168.80.8:/opt/kubernetes/bin/

#上传kubeconfig.sh文件到/opt/k8s/kubeconfig目录中，生成kubeconfig的配置文件
mkdir /opt/k8s/kubeconfig

cd /opt/k8s/kubeconfig
chmod +x kubeconfig.sh
./kubeconfig.sh 192.168.80.21 /opt/k8s/k8s-cert/

scp bootstrap.kubeconfig kube-proxy.kubeconfig root@192.168.80.7:/opt/kubernetes/cfg/
scp bootstrap.kubeconfig kube-proxy.kubeconfig root@192.168.80.8:/opt/kubernetes/cfg/

#RBAC授权，使用户 kubelet-bootstrap 能够有权限发起 CSR 请求
kubectl create clusterrolebinding kubelet-bootstrap --clusterrole=system:node-bootstrapper --user=kubelet-bootstrap

kubelet采用TLS Bootstrapping机制，自动完成到kube-apiserver的注册，在node节点量较大或者后期自动扩容时非常有用。

Master apiserver启用TLS认证后，node节点kubelet组件想要加入集群，必须使用CA签发的有效证书才能与apiserver通信，当node节点很多时，签署证书是一件很繁琐的事情。因此Kubernetes引入了TLS bootstraping机制来自动颁发客户端证书，kubelet会以一个低权限用户自动向apiserver申请证书，kubelet的证书由apiserver动态签署。

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

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

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

  • 在 node01 节点上操作
#启动 kubelet 服务
cd /opt/
./kubelet.sh 192.168.80.7
ps aux | grep kubelet

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

==注意==：在使用虚拟机的情况下，在所有配置文件和执行脚本前千万要对应各个配置文件中的IP地址，否则会因为虚拟机本身的BUG出现错误导致前功尽弃，在配置过程中切勿关机或重启以免发生意外，我对此深有体会干费了两个IP地址。

#检查到 node01 节点的 kubelet 发起的 CSR 请求，Pending 表示等待集群给该节点签发证书
kubectl get csr
NAME                                                   AGE   SIGNERNAME                                    REQUESTOR           CONDITION
node-csr-DkU_wDv2Kpdivv9GV06iI2a81QJpqjG8-_HCMDVJewo   17s   kubernetes.io/kube-apiserver-client-kubelet   kubelet-bootstrap   Pending

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

#Approved,Issued 表示已授权 CSR 请求并签发证书
kubectl get csr
NAME                                                   AGE   SIGNERNAME                                    REQUESTOR           CONDITION
node-csr-DkU_wDv2Kpdivv9GV06iI2a81QJpqjG8-_HCMDVJewo   90s   kubernetes.io/kube-apiserver-client-kubelet   kubelet-bootstrap   Approved,Issued

#查看节点，由于网络插件还没有部署，节点会没有准备就绪 NotReady
kubectl get node
NAME           STATUS     ROLES    AGE     VERSION
192.168.80.7   NotReady   <none>   2m57s   v1.20.11

  • 在 node01 节点上操作
#加载 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.80.7
ps aux | grep kube-proxy

部署网络组件

K8S中Pod网络通信

  • Pod内容器与容器之间的通信
    在同一个Pod内的容器(Pod内的容器是不会跨宿主机的)共享同一个网络命令空间，相当于它们在网一台机器上一样，可以用localhost地址访间彼此的端口
  • 同一个Node内Pod之间的通信
    每个Pod 都有一个真实的全局IP地址，同一个Node 内的不同Pod之间可以直接采用对方Pod的IP 地址进行通信，Pod1 与Pod2都是通过veth连接到同一个docker0 网桥，网段相同，所以它们之间可以直接通信
  • 不同Node上Pod之间的通信
    Pod地址与docker0 在同一网段，dockor0 网段与宿主机网卡是两个不同的网段，且不同Nodo之间的通信贝能通过宿主机的物理网卡进行要想实现不同Node 上Pod之间的通信，就必须想办法通过主机的物理网卡IP地址进行寻址和通信。因此要满足两个条件：
    • Pod 的IP不能冲突，将Pod的IP和所在的Node的IP关联起来，通过这个关联让不同Node上Pod之间直接通过内网IP地址通信。

==Overlay Network==

叠加网络，在二层或者三层基础网络上叠加的一种虚拟网络技术模式，该网络中的主机通过虚拟链路隧道连接起来(类似于VPN)

==VXLAN==

将源数据包封装到UDP中，并使用基础网络的IP/MAC作为外层报文头进行封装，然后在以太网上传输，到达目的地后由隧道端点解封装并将数据发送给目标地址

vxlan模式：
vxlan是一种overlay（虛拟隧道通信）技术，通过三层网络搭建虚拟的二层网络，跟udp模式具体实现不太一样：
1. udp模式是在用户态实现的，数据会先经过tun网卡，到应用程序，应用程序再做隧道封装，再进一次内核协议栈，而vxlan是在内核当中实现的，只经过一次协议栈，在协议栈内就把vxlan包组装好
2. udp模式的tun网卡是三三层转发，使用tun是在物理网络之上构建三三层网络，属于ip in udp，vxlan模式是二层实现，overlay是二层帧，属于mac in udp
3. vxlan由于采用mac in udp的方式，所以实现起来会涉及mac地址学习，arp广 播等二层知识，udp模式主要关注路由

==Flannel==

Flannel的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址

Flannel是Overlay 网络的一种，也是将TCP 源数据包封装在另一种网络 包里而进行路由转发和通信，目前己经支持UDP、VXLAN、AwS VPC等数据转发方式

Flannel工作原理
node1上的pod1要和node2上的pod1进行通信
1.数据从node1上的Pod1源容器中发出，经由所在主机的docker0虚拟网卡转发到flannel0虚拟网卡；
2.在flannel0网卡有个flanneld服务把podip封装到udp中（里面封装的是源pod IP和目的pod IP);
3.根据在etcd保存的路由表信息，通过物理网卡发送给目的node2节点，数据包到达目标node2节点会被flanneld服务来进行解封装暴露出udp里的podIP;
4.最后根据目的podIP经flannel0虚拟网卡和docker0虚拟网卡转发到目的pod中，最后完成通信

==ETCD之Flannel 提供说明==

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

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

Flannel vxlan模式的工作原理：

vxlan在内核当中实现，当数据包使用vxlan设备发送数据时，会打上vlxan的头部信息，在发送出去，对端解包，flannel.1网卡把原始报文发送到目的服务器。

部署Calico

k8s组网方案对比：

  • Flannel方案

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

  • Calico方案

    Calico不使用隧道或NAT来实现转发， 而是把Host当作Internet中的路由器，使用BGP同步路由，并使用iptables来做安全访问策略，完成跨Host转发来。

Calico主要由三个部分组成：

Calico CNI插件：主要负责与kubernetes对接， 供kubelet调用使用。

Felix：负责维护宿主机.上的路由规则、FIB转发信息库等。

BIRD：负责分发路由规则，类似路由器。

Confd：配置管理组件。

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

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

Flannel网络配置

  • 在 node01 节点上操作
#上传 cni-plugins-linux-amd64-v0.8.6.tgz 和 flannel.tar 到 /opt 目录中
cd /opt/
docker load -i flannel.tar

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

  • 在 master01 节点上操作
#上传 kube-flannel.yml 文件到 /opt/k8s 目录中，部署 CNI 网络
cd /opt/k8s
kubectl apply -f kube-flannel.yml 

kubectl get pods -n kube-system
NAME                    READY   STATUS    RESTARTS   AGE
kube-flannel-ds-cjmkf   1/1     Running   0          57s

kubectl get nodes
NAME           STATUS   ROLES    AGE   VERSION
192.168.80.7   Ready    <none>   40m   v1.20.11

  • 在 node02 节点上操作
#启动kubelet
cd /opt/
./kubelet.sh 192.168.80.8
ps aux | grep kubelet

  • 在 master01 节点上操作
#检查到 node02 节点的 kubelet 发起的 CSR 请求，Pending 表示等待集群给该节点签发证书
kubectl get csr

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

#Approved,Issued 表示已授权 CSR 请求并签发证书
kubectl get csr

  • 在 node02 节点上操作
#加载 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/
./proxy.sh 192.168.80.8

#把node01节点的/opt/cni/目录传输到node02的opt目录中
scp -r cni root@192.168.80.8:/opt

#在master01节点上查看群集中的节点状态
kubectl get nodes

部署 CoreDNS

  • 在所有node节点上操作
#上传coredns.tar到/opt目录中
cd /opt
docker load -i coredns.tar

  • 在 master01 节点上操作
#上传 coredns.yaml 文件到 /opt/k8s 目录中，部署 CoreDNS 
cd /opt/k8s
kubectl apply -f coredns.yaml

kubectl get pods -n kube-system 
NAME                       READY   STATUS    RESTARTS   AGE
coredns-6954c77b9b-d9np6   1/1     Running   0          43s
kube-flannel-ds-cjmkf      1/1     Running   0          153m
kube-flannel-ds-sqck2      1/1     Running   5          138m

#DNS解析测试
kubectl run -it --rm dns-test --image=busybox:1.28.4 sh
If you dont see a command prompt, try pressing enter.
/ # nslookup kubernetes
Server:    10.0.0.2
Address 1: 10.0.0.2 kube-dns.kube-system.svc.cluster.local

Name:      kubernetes
Address 1: 10.0.0.1 kubernetes.default.svc.cluster.local

以上是关于Kubernetes二进制单节点集群部署的主要内容，如果未能解决你的问题，请参考以下文章

Kubernetes二进制部署 单节点master

Kubernetes二进制部署 单节点master

Kubernetes二进制部署 单节点master

Kubernetes 集群 之 二进制安装部署（单Master节点）

Kubernetes 集群 之 二进制安装部署（单Master节点）

Kubernetes多Master节点集群二进制部署