Kubernetes二进制单节点集群部署 _Kubernetes

花门楼前见秋草，岂能贫贱相看老。这篇文章主要讲述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 证书，它支持签三种类型的证书∶

client 证书，服务端连接客户端时携带的证书，用于客户端验证服务端身份，如 kube-apiserver 访问 etcd
server 证书，客户端连接服务端时携带的证书，用于服务端验证客户端身份，如 etcd 对外提供服务
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 二进制包地址：https://github.com/etcd-io/etcd/releases

#上传 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.iosystemctl 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可能用到的所有ipls *pem admin-key.pemapiserver-key.pemca-key.pemkube-proxy-key.pem admin.pemapiserver.pemca.pemkube-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/kubeconfigcd /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

文章图片

【Kubernetes二进制单节点集群部署】

文章图片

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 NAMEAGESIGNERNAMEREQUESTORCONDITION node-csr-DkU_wDv2Kpdivv9GV06iI2a81QJpqjG8-_HCMDVJewo17skubernetes.io/kube-apiserver-client-kubeletkubelet-bootstrapPending#通过 CSR 请求 kubectl certificate approve node-csr-DkU_wDv2Kpdivv9GV06iI2a81QJpqjG8-_HCMDVJewo#Approved,Issued 表示已授权 CSR 请求并签发证书 kubectl get csr NAMEAGESIGNERNAMEREQUESTORCONDITION node-csr-DkU_wDv2Kpdivv9GV06iI2a81QJpqjG8-_HCMDVJewo90skubernetes.io/kube-apiserver-client-kubeletkubelet-bootstrapApproved,Issued#查看节点，由于网络插件还没有部署，节点会没有准备就绪 NotReady kubectl get node NAMESTATUSROLESAGEVERSION 192.168.80.7NotReady< none> 2m57sv1.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.tarmkdir /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 NAMEREADYSTATUSRESTARTSAGE kube-flannel-ds-cjmkf1/1Running057skubectl get nodes NAMESTATUSROLESAGEVERSION 192.168.80.7Ready< none> 40mv1.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.yamlkubectl get pods -n kube-system NAMEREADYSTATUSRESTARTSAGE coredns-6954c77b9b-d9np61/1Running043s kube-flannel-ds-cjmkf1/1Running0153m kube-flannel-ds-sqck21/1Running5138m#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.localName:kubernetes Address 1: 10.0.0.1 kubernetes.default.svc.cluster.local