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二进制部署
操作系统初始化配置
#关闭防火墙
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/ [email protected]:/opt/
scp -r /opt/etcd/ [email protected]:/opt/
#把etcd服务管理文件拷贝到另外两个集群节点
scp /usr/lib/systemd/system/etcd.service [email protected]:/usr/lib/systemd/system/
scp /usr/lib/systemd/system/etcd.service [email protected]:/usr/lib/systemd/system/
#在etcd集群的其他节点配置对应的服务器名和ip地址
vim /opt/etcd/cfg/etcd#启动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#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#把 kubelet、kube-proxy 拷贝到 node 节点
cd /opt/k8s/kubernetes/server/bin
scp kubelet kube-proxy [email protected]:/opt/kubernetes/bin/
scp kubelet kube-proxy [email protected]:/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 [email protected]:/opt/kubernetes/cfg/
scp bootstrap.kubeconfig kube-proxy.kubeconfig [email protected]:/opt/kubernetes/cfg/
#RBAC授权，使用户 kubelet-bootstrap 能够有权限发起 CSR 请求
kubectl create clusterrolebinding kubelet-bootstrap --clusterrole=system:node-bootstrapper --user=kubelet-bootstrapkubelet采用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生成一个证书，以后的访问都是用证书做认证了。
#启动 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#加载 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-proxyK8S中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 [email protected]:/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 don't 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