一、常见的K8S部署方式

1、Minikube

Minikube是一个工具，可以在本地快速运行一个单节点微型K8S，仅用于学习、预览K8S的一些特性使用。

https://kubernetes.io/docs/setup/minikube

2、Kubeadmin

Kubeadmin也是一个工具，提供kubeadm init和kubeadm join，用于快速部署K8S集群，相对简单。

https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/

3、二进制安装部署

生产首选，从官方下载发行版的二进制包，手动部署每个组件和自签TLS证书，组成K8S集群，新手推荐。

https://github.com/kubernetes/kubernetes/releases

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

二、用二进制搭建Kubernetes   （1.20版本） 

1、主机规划

k8s集群master01：192.168.10.10    kube-apiserver kube-controller-manager kube-scheduler etcd

k8s集群master02：192.168.10.20

k8s集群node01：192.168.10.21    kubelet kube-proxy docker 

k8s集群node02：192.168.10.22

etcd集群节点1：192.168.80.10    etcd

etcd集群节点2：192.168.80.21

etcd集群节点3：192.168.80.22

负载均衡nginx+keepalive01（master）：192.168.10.13

负载均衡nginx+keepalive02（backup）：192.168.10.14

2、操作系统初始化配置

根据规划设置主机名

hostnamectl set-hostname master01
hostnamectl set-hostname node01
hostnamectl set-hostname node02

关闭防火墙

systemctl stop firewalld
systemctl disable firewalld
iptables -F && iptables -t nat -F && iptables -t mangle -F && iptables -X

关闭selinux

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

关闭swap

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

在master添加hosts

cat >> /etc/hosts << EOF
192.168.10.10 master01
192.168.10.21 node01
192.168.10.22 node02
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

sysctl --system

时间同步

升级内核

#配置elrepo镜像源
vim /etc/yum.repos.d/elrepo.repo
[elrepo]
name=elrepo
baseurl=https://mirrors.aliyun.com/elrepo/archive/kernel/el7/x86_64
gpgcheck=0
enabled=1

yum clean all && yum makecache

#集群升级内核
yum install -y kernel-lt kernel-lt-devel

#查看内核序号
awk -F\' '$1=="menuentry " {print i++ " : " $2}' /etc/grub2.cfg
0 : CentOS Linux (5.4.218-1.el7.elrepo.x86_64) 7 (Core)
1 : CentOS Linux (3.10.0-1160.el7.x86_64) 7 (Core)
2 : CentOS Linux (0-rescue-2eb5357177ae46d781b26d504df8ea0c) 7 (Core)

#设置默认启动内核
grub2-set-default 0

#重启操作系统
reboot

#查看生效版本
hostnamectl

#卸载旧版本包
rpm -qa | grep kernel
yum remove -y kernel-3.10.0-1160.el7.x86_64

3、部署 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

mkdir /etc/docker
cat > /etc/docker/daemon.json <<EOF
{
  "registry-mirrors": ["https://6ijb8ubo.mirror.aliyuncs.com"],
  "exec-opts": ["native.cgroupdriver=systemd"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "500m", "max-file": "3"
  }
}
EOF

systemctl start docker.service
systemctl enable docker.service 

docker info | grep "Cgroup Driver"
Cgroup Driver: systemd

4、部署 etcd 集群

etcd是一个分布式键值存储系统，用于在分布式系统中保存配置信息、元数据以及关键的共享状态。它是一个开源项目，最初由CoreOS开发并维护，现在由CNCF托管。etcd的设计目标是提供可靠的分布式存储，以支持分布式系统的一致性和高可用性。

关键特性：

●分布式存储：etcd的数据存储是分布式的，可以跨多个节点进行分布，确保高可用性和可扩展性。
●强致性：etcd提供强一致性的保证，确保在集群中的所有节点都能看到相同的数据视图。
●轻量级：etcd采用轻量级的Raft一致性算法，以确保集群中的节点之间达成一致，同时保持相对较低的性能开销。
●API支持：etcd提供简单而强大的HTTP+JSON API，使得开发人员可以轻松地与其进行交互，并集成到各种应用和工具中。
●Watch机制：etcd支持Watch机制，允许客户端监视特定键的变化，并在数据发生变更时得到通知。
●安全性：etcd支持SSL/TLS加密，以保障数据在传输过程中的安全性，并提供基于角色的访问控制。

应用场景：

●配置管理： etcd常用于存储应用程序和系统的配置信息，允许动态地更新配置而无需重启应用。
●服务发现： etcd可以用作服务发现的后端存储，帮助服务在动态环境中找到彼此。
●分布式锁： 通过etcd的分布式锁机制，可以实现分布式系统中的协同工作和资源同步。
●集群协调： etcd在构建分布式系统中，作为集群协调的关键组件，确保系统的一致性和稳定性。

总体而言，etcd在云原生应用和分布式系统中发挥着重要作用，提供了可靠的分布式存储和协调服务，为应用程序提供一致性、可靠性和高可用性的基础设施支持。
etcd 目前默认使用2379端口提供HTTP API服务， 2380端口和peer通信(这两个端口已经被IANA(互联网数字分配机构)官方预留给etcd)。 即etcd默认使用2379端口对外为客户端提供通讯，使用端口2380来进行服务器间内部通讯。
etcd 在生产环境中一般推荐集群方式部署。由于etcd 的leader选举机制，要求至少为3台或以上的奇数台。

1、准备签发证书环境

CFSSL 是 CloudFlare 公司开源的一款 PKI/TLS 工具。 CFSSL 包含一个命令行工具和一个用于签名、验证和捆绑 TLS 证书的 HTTP API 服务。使用Go语言编写。
CFSSL 使用配置文件生成证书，因此自签之前，需要生成它识别的 json 格式的配置文件，CFSSL 提供了方便的命令行生成配置文件。
CFSSL 用来为 etcd 提供 TLS 证书，它支持签三种类型的证书：
1、client 证书，服务端连接客户端时携带的证书，用于客户端验证服务端身份，如 kube-apiserver 访问 etcd；
2、server 证书，客户端连接服务端时携带的证书，用于服务端验证客户端身份，如 etcd 对外提供服务；
3、peer 证书，相互之间连接时使用的证书，如 etcd 节点之间进行验证和通信。
这里全部都使用同一套证书认证。

在 master01 节点上操作

#准备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

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

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

2、生成etcd证书

mkdir /opt/k8s
cd /opt/k8s/

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

cd /opt/k8s/etcd-cert

vim  etcd-cert.sh

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

mkdir /opt/k8s/etcd-cert
mv etcd-cert.sh etcd-cert/
cd /opt/k8s/etcd-cert/
./etcd-cert.sh			#生成CA证书、etcd 服务器证书以及私钥

ls
ca-config.json  ca-csr.json  ca.pem        server.csr       server-key.pem
ca.csr          ca-key.pem   etcd-cert.sh  server-csr.json  server.pem

4、上传 kubernetes-server-linux-amd64.tar.gz 到 /opt/k8s/ 目录中，解压 kubernetes 压缩包

5、复制master组件的关键命令文件到 etcd工作目录的 bin 子目录中

6、创建 bootstrap token 认证文件

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

cd /opt/k8s/
vim token.sh
#!/bin/bash
#获取随机数前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

chmod +x token.sh
./token.sh

cat /opt/kubernetes/cfg/token.csv

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

[root@master01 k8s]# vim etcd.sh
[root@master01 k8s]# ./etcd.sh etcd01 192.168.10.10 etcd02=https://192.168.10.21:2379,etcd03=https://192.168.10.22:2379

8、部署其他两个etcd节点

scp -r /opt/etcd/ root@192.168.10.21:/opt/
scp -r /opt/etcd/ root@192.168.10.22:/opt/

cd /usr/lib/systemd/system
scp etcd.service root@192.168.10.21:'pwd'
scp etcd.service root@192.168.10.22:'pwd'

修改配置文件

在 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.10.21:2380"			#修改
ETCD_LISTEN_CLIENT_URLS="https://192.168.10.21:2379"		#修改

#[Clustering]
ETCD_INITIAL_ADVERTISE_PEER_URLS="https://192.168.10.21:2380"		#修改
ETCD_ADVERTISE_CLIENT_URLS="https://192.168.10.21:2379"				#修改
ETCD_INITIAL_CLUSTER="etcd01=https://192.168.80.10:2380,etcd02=https://192.168.80.11:2380,etcd03=https://192.168.80.12:2380"
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster"
ETCD_INITIAL_CLUSTER_STATE="new"

#启动etcd服务

 在 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.10.22:2380"			#修改
ETCD_LISTEN_CLIENT_URLS="https://192.168.10.22:2379"		#修改

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

9、etcd的基本操作

启动etcd服务

systemctl start etcd
systemctl enable etcd
systemctl status etcd

检查etcd群集状态

ETCDCTL_API=3 /opt/etcd/bin/etcdctl --endpoints="https://192.168.10.10:2379,https://192.168.10.21:2379,https://192.168.10.22:2379" --cacert=/opt/etcd/ssl/ca.pem --cert=/opt/etcd/ssl/server.pem --key=/opt/etcd/ssl/server-key.pem  endpoint health --write-out=table

查看当前的 leader

ETCDCTL_API=3 /opt/etcd/bin/etcdctl --endpoints="https://192.168.10.10:2379,https://192.168.10.21:2379,https://192.168.10.22:2379" --cacert=/opt/etcd/ssl/ca.pem --cert=/opt/etcd/ssl/server.pem --key=/opt/etcd/ssl/server-key.pem  endpoint status --write-out=table

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

查看etcd集群成员列表

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

备份还原 etcd

备份

ETCDCTL_API=3 /opt/etcd/bin/etcdctl --endpoints="https://192.168.10.10:2379" --cacert=/opt/etcd/ssl/ca.pem --cert=/opt/etcd/ssl/server.pem --key=/opt/etcd/ssl/server-key.pem snapshot save /data/backup/etcd-snapshot.db

ETCDCTL_API=3 /opt/etcd/bin/etcdctl --endpoints="https://192.168.10.10:2379" --cacert=/opt/etcd/ssl/ca.pem --cert=/opt/etcd/ssl/server.pem --key=/opt/etcd/ssl/server-key.pem  snapshot status /data/backup/etcd-snapshot.db -wtable

还原

ETCDCTL_API=3 /opt/etcd/bin/etcdctl --endpoints="https://192.168.10.10:2379" --cacert=/opt/etcd/ssl/ca.pem --cert=/opt/etcd/ssl/server.pem --key=/opt/etcd/ssl/server-key.pem  snapshot restore /data/backup/etcd-snapshot.db

5、部署Master组件

在 master01 节点上操作

#上传 master.zip 和 k8s-cert.sh 到 /opt/k8s 目录中，解压 master.zip 压缩包
cd /opt/k8s/
上传 master.zip 和 k8s-cert.sh 
mkdir k8s-cert
mv k8s-cert.sh k8s-cert
cd k8s-cert/
chmod +x k8s-cert.sh
vim k8s-cert.sh
修改其中ip信息
cat > apiserver-csr.json <<EOF
{
    "CN": "kubernetes",
    "hosts": [
      "10.0.0.1",
      "127.0.0.1",
      "192.168.10.10",    master01
      "192.168.10.20",    master02
      "192.168.10.100",   vip
      "192.168.10.14",    负载均衡nginx+keepalive01（master）
      "192.168.10.15",    负载均衡nginx+keepalive02（backup）
      "kubernetes",
      "kubernetes.default",
      "kubernetes.default.svc",
      "kubernetes.default.svc.cluster",
      "kubernetes.default.svc.cluster.local"
    ],
 
 
./k8s-cert.sh				#生成CA证书、相关组件的证书和私钥
ls *pem

#上传 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二进制文件。
 
cd /opt/k8s/
tar zxvf kubernetes-server-linux-amd64.tar.gz
 
cd /opt
mkdir kubernetes/
cd kubernetes/
mkdir bin cfg ssl logs

cd /opt/k8s/kubernetes/server/bin/
cp kube-apiserver kube-controller-manager kube-scheduler /opt/kubernetes/bin/
cd /opt/k8s/k8s-cert/
cp apiserver-key.pem apiserver.pem ca-key.pem ca.pem /opt/kubernetes/ssl/

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

head -c 16 /dev/urandom | od -An -t x | tr -d ' '   创建一个16位随机数
cd /opt/kubernetes/cfg
vim token.csv
bad114c25d9342b56d97b6b7a36c681e,kubelet-bootstrap,10001,"system:kubelet-bootstrap"

cd /opt/k8s/
unzip master.zip
chmod +x *.sh

开启 apiserver 服务
./apiserver.sh 192.168.10.10 https://192.168.10.10:2379,https://192.168.10.21:2379,https://192.168.10.22:2379
systemctl status kube-apiserver.service

#检查进程是否启动成功
ps aux | grep kube-apiserver
netstat -natp | grep 6443   #安全端口6443用于接收HTTPS请求，用于基于Token文件或客户端证书等认证

#启动 controller-manager 服务
 
cd /opt/k8s/kubernetes/server/bin
cp kubectl /usr/local/bin/
cd /opt/k8s/
vim controller-manager.sh 
#修改60行，设置为本机IP
KUBE_APISERVER="https://192.168.10.10:6443"
 
./controller-manager.sh

#启动 scheduler 服务
 
vim scheduler.sh
#48行修改为本机ip 
KUBE_APISERVER="https://192.168.10.10:6443"
 
./scheduler.sh
systemctl status kube-scheduler.service

#生成kubectl连接集群的kubeconfig文件
vim admin.sh
#4行修改ip为本机 
KUBE_APISERVER="https://192.168.10.10:6443"

./admin.sh
ls /root/.kube/
 
#通过kubectl工具查看当前集群组件状态
kubectl get cs 
#查看版本信息
kubectl version
 
#查看当前的 leader
kubectl -n kube-system get leases kube-scheduler
kubectl -n kube-system get leases kube-controller-manager

6、部署 Worker Node 组件

//node01 节点上操作
#创建kubernetes工作目录
mkdir -p /opt/kubernetes/{bin,cfg,ssl,logs}
cd /opt
mkdir k8s
cd k8s/
#上传 node.zip 到 /opt 目录中，解压 node.zip 压缩包，获得kubelet.sh、proxy.sh
chmod +x *.sh

//在 master01 节点上操作
#把 kubelet、kube-proxy 拷贝到 node01 节点
cd /opt/k8s/kubernetes/server/bin
scp kubelet kube-proxy root@192.168.10.21:/opt/kubernetes/bin/
 
cd /opt/k8s/
#上传kubeconfig.sh文件，生成kubelet初次加入集群引导kubeconfig文件和kube-proxy.kubeconfig文件
mkdir kubeconfig
mv kubeconfig.sh kubeconfig/
cd kubeconfig/
chmod +x kubeconfig.sh
./kubeconfig.sh 192.168.10.22 /opt/k8s/k8s-cert/
scp bootstrap.kubeconfig kube-proxy.kubeconfig root@192.168.9.113:/opt/kubernetes/cfg/
 
 
#RBAC授权，使用户 kubelet-bootstrap 能够有权限发起 CSR 请求证书
kubectl create clusterrolebinding kubelet-bootstrap --clusterrole=system:node-bootstrapper --user=kubelet-bootstrap
 

node01节点
cd /opt/k8s
vim kubelet.sh 
#11行修改
--hostname-override=node01 \\
 
./kubelet.sh 192.168.10.21
systemctl status kubelet.service 

//在 master01 节点上操作，通过 CSR 请求
#检查到 node01 节点的 kubelet 发起的 CSR 请求，Pending 表示等待集群给该节点签发证书
kubectl get csr
kubectl certificat approve node-csr-_gqqiNmxKDoV0sJmwSZlaVt0lx2-0MqRYol93PGjSvI
kubectl get csr
#查看节点，由于网络插件还没有部署，节点会没有准备就绪 NotReady
kubectl get node
 
#自动批准 CSR 请求
kubectl create clusterrolebinding node-autoapprove-bootstrap --clusterrole=system:certificates.k8s.io:certificatesigningrequests:nodeclient --user=kubelet-bootstrap 
 
kubectl create clusterrolebinding node-autoapprove-certificate-rotation --clusterrole=system:certificates.k8s.io:certificatesigningrequests:selfnodeclient --user=kubelet-bootstrap

部署node02节点
node01节点操作
cd /opt/
scp -r k8s/ kubernetes/ root@192.168.9.111:/opt
 
node02节点操作
cd /opt/
cd kubernetes/
rm -rf ssl/*
rm -rf logs/*
 
cd /opt/k8s/
vim kubelet.sh 
#11行修改
--hostname-override=node02 \\
 
./kubelet.sh 192.168.10.22
ls /opt/kubernetes/ssl/

master01节点查看

kubectl get csr
kubectl get nodes

启动kube-proxy
#node01、node02两个节点加载内核模块
cd /usr/lib/modules/5.4.278-1.el7.elrepo.x86_64/kernel/net/netfilter/ipvs
for i in $(ls | awk -F. '{print $1}'); do echo $i; modprobe $i; done
 
lsmod | grep ip_vs  #查看

node01节点
cd /opt/k8s/
vim proxy.sh
#10行 修改
--hostname-override=node01 \\
 
./proxy.sh 192.168.10.21
systemctl status kube-proxy.service
 
node02节点
cd /opt/k8s/
vim proxy.sh
#10行 修改
--hostname-override=node02 \\
 
./proxy.sh 192.168.10.22
systemctl status kube-proxy.service

master01节点查看验证

kubectl get cs
kubectl get nodes

三、k8s的三种网络模式

k8s集群中pod网络通信分类

1、pod内容器之间的通信

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

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

3、不同的node节点的pod之间通信
Pod 地址与 docker0 在同一网段，docker0 网段与宿主机网卡是两个不同的网段，且不同 Node 之间的通信只能通过宿主机的物理网卡进行。
要想实现不同 Node 上 Pod 之间的通信，就必须想办法通过主机的物理网卡 IP 地址进行寻址和通信。因此要满足两个条件：

①Pod 的 IP 不能冲突；将 Pod 的 IP 和所在的 Node 的 IP 关联起来

②通过这个关联让不同 Node 上 Pod 之间直接通过内网 IP 地址通信。

关于k8s的三种网络

节点网络         nodeIP         物理网卡的IP实现节点间的通信
pod网络          podIP           pod与pod之间可通过pod的IP相互通信
service网络    clusterIP      在k8s集群内部可通过service资源的clusterIP实现对pod集群的代理转发

Overlay Network

叠加网络，在二层或者三层基础网络上叠加的一种虚拟网络技术模式，该网络中的主机通过虚拟链

路隧道连接起来。

通过Overlay技术（可以理解成隧道技术），在原始报文外再包一层四层协议（UDP协议），通过

主机网络进行路由转发。这种方式性能有一定损耗，主要体现在对原始报文的修改。目前Overlay主要采用VXLAN。

VXLAN 即 Virtual Extensible LAN（虚拟可扩展局域网）

是一种网络虚拟化技术，它使用一种隧道协议，将二层以太网帧封装在四层UDP报文中，通过三层

网络传输，组成一个虚拟大二层网络，到达目的地后由隧道端点解封装并将数据发送给目标地址。

从而实现分布在不同的宿主机上的虚拟机或者容器就像在同一个局域网（LAN）里那样自由通信。

VLAN和VXLAN的区别
（1）使用场景不同：

VLAN主要用于在交换机上逻辑划分广播域，还可以配合STP生成树协议阻塞路径接口，从而避免产生环路和广播风暴

 VXLAN用作于叠加网络，可以将数据帧封装成UDP报文，再通过网络层传输到其它网络，从而实现虚拟大二层网络的通信

（2）VXLAN支持更多的二层网络：VXLAN最多可支持 2^24 个；VLAN最多支持 2^12 个（4096-2）
（3）VXLAN可以防止物理交换机MAC表耗尽：VLAN需要在交换机的MAC表中记录MAC地址；VXLAN采用隧道机制，MAC地址不记录在交换机的MAC表中

Flannel

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

Flannel UDP 模式的工作原理

1、数据从主机A 上 Pod 的源容器中发出后，经由所在主机的 cni0/docker0 网桥转发到 flannel0 接口，flanneld 服务监听在 flannel0 接口的另外一端。
2、发送给 flannel0 接口的 IP 包信息将被 flanneld 进程接收，flanneld 进程接收 IP 包后在原有的基础上进行 UDP 封包
3、Flannel 通过 etcd 服务维护了一张节点间的路由表。目标容器所在宿主机的 IP 地址，flanneld 通过查询 etcd 很容易就能得到
4、flanneld 将封装好的 UDP 报文通过物理网卡转发出去，主机B 收到 UDP 报文后，Linux 内核通过 8285 端口将包交给正在监听的 flanneld 进程
5、运行在主机B 上的 flanneld 将 UDP 包解包后得到原始 IP 包，内核通过查询本机路由表将该 IP 包转发给 cni0 网桥
6、cni0 网桥将 IP 包转发给连接在网桥上的目标Pod。至此整个流程结束。回程报文将按照上面的数据流原路返回

VXLAN 模式

VXLAN 模式是 Flannel 默认和推荐的模式，flannel 会为每个节点分配一个 24 位子网，并在每个节点上创建两张虚机网卡：cni0 和 flannel.1 。 cni0 是一个网桥设备，类似于 docker0 ，节点上所有的 Pod 都通过 veth pair 的形式与 cni0 相连。 flannel.1 则是一个 VXLAN 类型的设备，充当 VTEP 设备（VXLAN Tunnel Endpoint）的角色，实现对 VXLAN 报文的封包解包。

在 VXLAN 模式下，flanneld 启动时先确保 VXLAN 设备已存在，如果不存在则创建，存在则跳过。并将 VTEP 设备的信息上报到 etcd 中，当 flannel 网络有新节点加入集群时并向 etcd 注册，各节点上的 flanneld 会从 etcd 得到通知。

UDP 模式的 flannel0 网卡是三层转发，使用 flannel0 是在物理网络之上构建三层网络，属于 ip in udp ；VXLAN 模式是二层实现，overlay 是数据帧，属于 mac in udp 。

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

1、数据帧从主机 A 上 Pod 的源容器中发出后，经由所在主机的 cni0 网络接口转发到 flannel.1 接口
2、flannel.1 收到数据帧后添加 VXLAN 头部，封装成 VXLAN UDP 报文
3、主机 A 通过物理网卡发送封包到主机 B 的物理网卡中
4、通过 VXLAN 8472 端口，VXLAN 包被转发到 flannel.1 接口进行解封装
5、根据解包后得到的原始报文中的目的IP，内核将原始报文发送给 cni0，最后由 cni0 发送给连接在此接口上的PodB
 

四、部署 CNI 网络组件

在 master01 节点上操作
上传flannel-v0.21.5.zip并解压
scp flannel*.tar 192.168.10.21:/opt/k8s/
scp flannel*.tar 192.168.10.22:/opt/k8s/

node两个节点操作
cd /opt/k8s/
docker load  -i flannel.tar
docker load  -i flannel-cni-plugin.tar 
docker images

master01节点操作
scp cni-plugins-linux-amd64-v1.3.0.tgz 192.168.10.21:/opt/k8s/
scp cni-plugins-linux-amd64-v1.3.0.tgz 192.168.10.22:/opt/k8s/

两个node节点操作
mkdir -p /opt/cni/bin
tar xf cni-plugins-linux-amd64-v1.3.0.tgz -C /opt/cni/bin/

master节点操作
#部署 CNI 网络
kubectl apply -f kube-flannel.yml
kubectl get pods -A
kubectl get pods -A -owide   #显示Running为正常
kubectl get nodes   #查看状态，显示ready为正常

五、Calico介绍

k8s 组网方案对比:

●flannel方案

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

●calico方案

Calico不使用隧道或NAT来实现转发，而是把每个操作系统的协议栈认为是一个路由器，然后把所有的容器认为是连在这个路由器上的网络终端，在路由器之间跑标准的路由协议——BGP的协议，然后让它们自己去学习这个网络拓扑该如何转发。

它不使用 cni0 网桥，而是通过路由规则把数据包直接发送到目标节点的网卡，所以性能高。

Calico 的模式：

●IPIP 模式：在原有 IP 报文中封装一个新的 IP 报文，新的 IP 报文中将源地址 IP 和目的地址 IP 都修改为对端宿主机 IP。Calico 默认使用 IPIP 的模式。

●BGP 模式：将节点做为虚拟路由器通过 BGP 路由协议来实现集群内容器之间的网络访问。

●cross-subnet（ipip-bgp混合模式）：IPIP 模式和 BGP 模式都有对应的局限性，对于一些主机跨子网而又无法使网络设备使用 BGP 的场景可以使用 cross-subnet 模式，实现同子网机器使用 BGP 模式，跨子网机器使用 IPIP 模式。

Calico 主要由以下几个部分组成：

Calico CNI插件：主要负责与kubernetes对接，供kubelet调用使用。
Felix：运行在每一台 Host 的 agent 进程，主要负责在宿主机上维护路由规则、网络接口管理等。
BIRD：BGP客户端，负责监听 Host 上由 Felix 注入的路由信息，然后通过 BGP 协议广播在集群里分发路由规则信息，从而实现网络互通。
etcd：分布式键值存储，主要负责网络元数据一致性，确保 Calico 网络状态的准确性。

Calico 工作原理：

IPIP 模式：

Calico 会将容器的 IP 数据包经过 veth pair 设备发送到 tunl0 设备，并被内核的 IPIP 驱动直接封装到宿主机网络的 IP 数据包中，新封装的 IP 数据包再根据 Felix 维护的路由规则发送给目标节点，目标节点通过 IPIP 驱动解包得到原始容器 IP 数据包，然后根据路由规则经过 veth pair 设备送达到目标容器。

BGP 模式：

Calico 是通过路由表来维护每个 Pod 的通信。Calico 的 CNI 插件会为每个容器设置一个 veth pair 设备， 然后把另一端接入到宿主机网络空间，由于没有网桥，CNI 插件还需要在宿主机上为每个容器的 veth pair 设备配置一条路由规则， 用于接收传入的 IP 包。
有了这样的 veth pair 设备以后，容器发出的 IP 包就会通过 veth pair 设备到达宿主机，然后根据容器要访问的IP和宿主机的路由规则，找到下一跳要到达的宿主机 IP。流量到达下一跳的宿主机后，根据当前宿主机上的路由规则，直接到达对端容器的 veth pair 插在宿主机的一端，最终进入容器。

这些路由规则都是 Felix 维护配置的，而路由信息则是 Calico BIRD 组件基于 BGP 分发而来。
Calico 实际上是将集群里所有的节点都当做边界路由器来处理，他们一起组成了一个全互联的网络，彼此之间通过 BGP 交换路由， 这些节点我们叫做 BGP Peer。

相比IPIP模式，BGP模式下不需要tunl0设备参与报文传输，报文直接通过物理网卡（比如ens33）转发到目标机器上，不会进行二次IP报文的封装，因此从性能上来看，BGP是占优势的。但是由于没有二次封包，BGP模式只能在同一个子网内使用，无法跨网段使用。

目前比较常用的CNI网络组件是flannel和calico，flannel的功能比较简单，但不具备复杂的网络策略配置能力。但Calico以其性能、灵活性而闻名。Calico的功能更为全面，不仅提供主机和pod之间的网络连接，还涉及网络安全和管理，但具备复杂网络配置能力的同时，往往意味着本身的配置比较复杂，所以相对而言，比较小而简单的集群使用flannel，考虑到日后扩容，未来网络可能需要加入更多设备，配置更多网络策略，则使用calico更好。

六、总结

K8S的三种网络

节点网络       nodeIP          物理网卡的IP实现节点间的通信
Pod网络        podIP           Pod与Pod之间可通过Pod的IP相互通信
Service网络    clusterIP     在K8S集群内部可通过service资源的clusterIP实现对Pod集群的代理转发

K8S的三种接口

CRI   容器运行时接口      docker   containerd   podman   cri-o
CSI   容器存储接口        nfs   ceph   oss   s3
CNI   容器网络接口        flannel   calico   cilium

VLAN和VXLAN的区别

1）使用场景不同：VLAN主要用于在交换机上逻辑划分广播域，还可以配合STP生成树协议阻塞路径接口，从而避免产生环路和广播风暴
                              VXLAN用作于叠加网络，可以将数据帧封装成UDP报文，再通过网络层传输到其它网络，从而实现虚拟大二层网络的通信
2）VXLAN支持更多的二层网络：VXLAN最多可支持 2^24 个；VLAN最多支持 2^12 个（4096-
3）VXLAN可以防止物理交换机MAC表耗尽：VLAN需要在交换机的MAC表中记录MAC地址；VXLAN采用隧道机制，MAC地址不记录在交换机的MAC表中

flannel的三种模式

UDP         出现最早的模式，但是性能最差，基于flanneld应用程序实现数据包的封装/解封装（ip in udp）
VXLAN       flannel的默认模式，也是推荐使用的模式，性能比UDP模式更好，基于内核实现数据帧的封装/解封装（mac in udp），且配置简单使用方便
HOST-GW     性能最好的模式，但是配置复杂，还不能跨网段通信

flannel的UDP模式

1）原始数据包从源主机的Pod容器发出到cni0网桥接口，再由cni0转发到flannel0设备
2）flanneld进程会监听flannel0设备收到的数据，并会将原始数据包封装到UDP报文里
3）flanneld进程会根据在etcd中维护的路由表查到目标Pod所在的nodeIP，并对UDP报文封装nodeIP头部、MAC头部等，再通过节点网络发往目标node节点
4）UDP报文通过8285端口送达到目标node节点的flanneld服务进程解封装获取原始数据包，数据包再根据本地路由通过flannel0发送到cni0网桥，再由cni0发送到目标Pod容器

flannel的VXLAN模式

1）原始数据包从源主机的Pod容器发出到cni0网桥接口，再由cni0转发到flannel.1设备
2）flannel.1设备收到数据包后，在内核态给数据包添加以太网头部和VXLAN头部，再将此数据帧封装到UDP报文里
3）flannel.1通过查询本机的 FDB 表获取目标节点的IP地址，再通过节点网络将UDP报文发往目标node节点
4）UDP报文通过8472端口送达到目标node节点的flannel.1设备并在内核态解封装获取原始数据包，数据包再根据本地路由发送到cni0网桥，再由cni0发送到目标Pod容器

calico的IPIP模式

1）原始数据包从源主机的Pod容器发出，经过 veth pair 设备送达到tunl0设备
2）tunl0设备收到数据包后，由内核将原始数据包封装到node节点网络的IP报文里，再根据Felix维护的路由规则通过节点网络发往目标node节点
3）IP数据包到达目标节点的tunl0设备后，由内核解封装获取原始数据包，数据报文再根据本地路由经过 veth pair 设备发送到目标Pod容器

calico的BGP模式（本质就是通过路由规则来实现Pod之间的通信）

每个Pod都有一个 veth pair 设置，一端接入Pod，另一端接入宿主机网络空间，并设置了一条路由规则
这些路由规则都是 Felix 维护的，由 BIRD(BGP Client) 基于 BGP 动态路由协议分发给其它节点

1）原始数据包从源主机的Pod容器发出，经过 veth pair 设备送达到宿主机网络空间，再根据Felix维护的路由规则通过物理网卡发往目标node节点
2）目标node节点收到数据包后，会根据本地路由经过 veth pair 设备送达到目标 Pod 容器

flannel 与 calico 的区别

flannel： UDP  VXLAN  HOST-GW
默认网段：10.244.0.0/16
通常会采用VXLAN模式，由于用的是叠加网络、IP隧道方式传输数据，传输过程中需要额外的封包和解包，对性能有一点的影响。
flannel简单易用。但是不具备复杂的网络策略配置能力，性能方面表现一般。

calico：  IPIP  VXLAN  BGP  CrossSubnet(混合模式)
默认网段：192.168.0.0/16
使用IPIP或VXLAN模式可以实现跨网段通信，但是传输过程中需要额外的封包和解包，对性能有一点的影响。
使用BGP模式会把每个节点看作成路由器，通过Felix、BIRD组件来维护和分发路由规则，可实现直接通过路由规则直接发送数据包到目标主机，传输中不需要额外的封包和解包，因此性能较好。但是不能跨网段通信。
calico性能较高，具有丰富的网络策略配置能力，还能固定IP，功能更全面。但是维护起来较为复杂。

flannel适合规模较小，网络要求简单的K8S集群。calico适合规模较大，需要设置网络策略，固定 PodIP 的K8S集群。