上一篇布置了etcd分布式数据库、master01节点，

本篇文章布置Kubernetes集群中的 worker node 节点和 CNI 网络插件

布置node节点

一切node节点布置 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
#装置 docker-ce
yum install -y docker-ce  #docker-ce-cli、containerd.io会作为依靠包被装置
systemctl start docker.service   #发动docker
systemctl enable docker.service  #设置为开机自启

布置 Worker Node 组件

在一切 node 节点上操作

#创立kubernetes作业目录，并创立四个子目录cfg、bin、ssl、logs。cfg用于寄存装备文件，bin用于寄存履行文件，ssl用于寄存证书文件，logs用于寄存日志文件
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.44.30:/opt/kubernetes/bin/
scp kubelet kube-proxy root@192.168.44.40:/opt/kubernetes/bin/
#创立/opt/k8s/kubeconfig 目录，上传 kubeconfig.sh 文件到该目录中，生成 kubeconfig 的装备文件。
#kubeconfig文件包括集群参数(CA证书、API Server 地址)，客户端参数(上面生成的证书和私钥)，集群context上下文参数(集群名称、用户名)。Kubenetes组件(如kubelet、 kube-proxy) 经过发动时指定不同的kubeconfig 文件能够切换到不同的集群，衔接到apiserver
mkdir /opt/k8s/kubeconfig
cd /opt/k8s/kubeconfig
chmod +x kubeconfig.sh
./kubeconfig.sh 192.168.44.20 /opt/k8s/k8s-cert/ #运转脚本，生成 kubeconfig 的装备文件。脚本后边跟的参数是 master01的IP、证书目录
#把装备文件bootstrap.kubeconfig、kube-proxy.kubeconfig拷贝到node节点
scp bootstrap.kubeconfig kube-proxy.kubeconfig root@192.168.44.30:/opt/kubernetes/cfg/
scp bootstrap.kubeconfig kube-proxy.kubeconfig root@192.168.44.40:/opt/kubernetes/cfg/
#RBAC授权，运用户 kubelet-bootstrap 能够有权限建议 CSR 恳求
kubectl create clusterrolebinding kubelet-bootstrap --clusterrole=system:node-bootstrapper --user=kubelet-bootstrap
#CSR 恳求就是kublet向APIserver恳求证书的操作
#若履行失败，可先给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 参数来设置签署的证书有用时刻；默许为 8760h0m0s，将其改为 87600h0m0s，即 10 年后再进行 TLS bootstrapping 签署证书即可。
也就是说 kubelet 初次拜访 API Server 时，是运用 token 做认证，经过后，Controller Manager 会为 kubelet 生成一个证书，今后的拜访都是用证书做认证了。

在一切node节点上操作，发动kubelet服务

#node01节点履行kubelet.sh脚本文件，发动 kubelet 服务，方位参数1为node01的ip地址。
cd /opt/
./kubelet.sh 192.168.44.30 
ps aux | grep kubelet
#node02节点履行kubelet.sh脚本文件，发动 kubelet 服务，方位参数1为node02的ip地址。
cd /opt/
./kubelet.sh 192.168.44.40
ps aux | grep kubelet

在 master01 节点上操作，经过 CSR 恳求

#检查到 node01节点和node02节点的 kubelet 建议的 CSR 恳求，Pending 表明等候集群给该节点签发证书
kubectl get csr
NAME                          AGE   SIGNERNAME                   REQUESTOR      CONDITION
node-csr-BUxnASfsYjtsTElTC7Dx3PET__fh376QuJYMZrurzSw  4m39s  kubernetes.io/kube-apiserver-client-kubelet  kubelet-bootstrap  Pending
node-csr-vF25KypSyYi4yn2HaHGw-hqvsaJkLR2QkyicsFjJfII  13m   kubernetes.io/kube-apiserver-client-kubelet  kubelet-bootstrap  Pending
#经过node01节点kubelet的 CSR 恳求
kubectl certificate approve node-csr-BUxnASfsYjtsTElTC7Dx3PET__fh376QuJYMZrurzSw
#经过node02节点kubelet的 CSR 恳求
kubectl certificate approve node-csr-vF25KypSyYi4yn2HaHGw-hqvsaJkLR2QkyicsFjJfII
#Approved,Issued 表明已授权 CSR 恳求并签发证书
kubectl get csr
NAME                          AGE  SIGNERNAME                   REQUESTOR      CONDITION
node-csr-BUxnASfsYjtsTElTC7Dx3PET__fh376QuJYMZrurzSw  23m  kubernetes.io/kube-apiserver-client-kubelet  kubelet-bootstrap  Approved,Issued
node-csr-vF25KypSyYi4yn2HaHGw-hqvsaJkLR2QkyicsFjJfII  31m  kubernetes.io/kube-apiserver-client-kubelet  kubelet-bootstrap  Approved,Issued
#检查node节点，因为网络插件还没有布置，节点会没有准备就绪，所以显示NotReady
kubectl get node
NAME       STATUS   ROLES   AGE  VERSION
192.168.44.30  NotReady  <none>  11m  v1.20.11
192.168.44.40  NotReady  <none>  12m  v1.20.11

在一切 node 节点上操作，发动kube-proxy服务

##node01节点操作，加载 ip_vs 模块，发动kube-proxy服务
#加载 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
#运转脚本，发动kube-proxy服务
cd /opt/
./proxy.sh 192.168.44.30
ps aux | grep kube-proxy
##node02节点操作，加载 ip_vs 模块，发动kube-proxy服务
#加载 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
#运转脚本，发动kube-proxy服务
cd /opt/
./proxy.sh 192.168.44.40
ps aux | grep kube-proxy

附录1：kubeconfig.sh

#!/bin/bash
#example: kubeconfig.sh 192.168.44.20 /opt/k8s/k8s-cert/
#脚本后边跟的第一个方位参数是：master01的IP，第二个方位参数是：证书目录。
#创立bootstrap.kubeconfig文件
#该文件中内置了 token.csv 中用户的 Token，以及 apiserver CA 证书；kubelet 初次发动会加载此文件，运用 apiserver CA 证书建立与 apiserver 的 TLS 通讯，运用其中的用户 Token 作为身份标识向 apiserver 建议 CSR 恳求
BOOTSTRAP_TOKEN=$(awk -F ',' '{print $1}' /opt/kubernetes/cfg/token.csv)
APISERVER=$1
SSL_DIR=$2
export KUBE_APISERVER="https://$APISERVER:6443"
# 设置集群参数
kubectl config set-cluster kubernetes \
 --certificate-authority=$SSL_DIR/ca.pem \
 --embed-certs=true \
 --server=${KUBE_APISERVER} \
 --kubeconfig=bootstrap.kubeconfig
#--embed-certs=true：表明将ca.pem证书写入到生成的bootstrap.kubeconfig文件中
# 设置客户端认证参数，kubelet 运用 bootstrap token 认证
kubectl config set-credentials kubelet-bootstrap \
 --token=${BOOTSTRAP_TOKEN} \
 --kubeconfig=bootstrap.kubeconfig
# 设置上下文参数
kubectl config set-context default \
 --cluster=kubernetes \
 --user=kubelet-bootstrap \
 --kubeconfig=bootstrap.kubeconfig
# 运用上下文参数生成 bootstrap.kubeconfig 文件
kubectl config use-context default --kubeconfig=bootstrap.kubeconfig
#----------------------
#创立kube-proxy.kubeconfig文件
# 设置集群参数
kubectl config set-cluster kubernetes \
 --certificate-authority=$SSL_DIR/ca.pem \
 --embed-certs=true \
 --server=${KUBE_APISERVER} \
 --kubeconfig=kube-proxy.kubeconfig
# 设置客户端认证参数，kube-proxy 运用 TLS 证书认证
kubectl config set-credentials kube-proxy \
 --client-certificate=$SSL_DIR/kube-proxy.pem \
 --client-key=$SSL_DIR/kube-proxy-key.pem \
 --embed-certs=true \
 --kubeconfig=kube-proxy.kubeconfig
# 设置上下文参数
kubectl config set-context default \
 --cluster=kubernetes \
 --user=kube-proxy \
 --kubeconfig=kube-proxy.kubeconfig
# 运用上下文参数生成 kube-proxy.kubeconfig 文件
kubectl config use-context default --kubeconfig=kube-proxy.kubeconfig

附录2：kubelet.sh

#!/bin/bash
NODE_ADDRESS=$1
DNS_SERVER_IP=${2:-"10.0.0.2"}

#创立 kubelet 发动参数装备文件
cat >/opt/kubernetes/cfg/kubelet <<EOF
KUBELET_OPTS="--logtostderr=false \
--v=2 \
--log-dir=/opt/kubernetes/logs \
--hostname-override=${NODE_ADDRESS} \
--network-plugin=cni \
--kubeconfig=/opt/kubernetes/cfg/kubelet.kubeconfig \
--bootstrap-kubeconfig=/opt/kubernetes/cfg/bootstrap.kubeconfig \
--config=/opt/kubernetes/cfg/kubelet.config \
--cert-dir=/opt/kubernetes/ssl \
--pod-infra-container-image=registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64:3.0"
EOF

#--hostname-override：指定kubelet节点在集群中显示的主机名或IP地址，默许运用主机hostname；kube-proxy和kubelet的此项参数设置有必要完全共同
#--network-plugin：启用CNI
#--kubeconfig：指定kubelet.kubeconfig文件方位，当前为空路径，会主动生成，用于如何衔接到apiserver，里边含有kubelet证书，master授权完结后会在node节点上生成 kubelet.kubeconfig 文件
#--bootstrap-kubeconfig：指定衔接 apiserver 的 bootstrap.kubeconfig 文件
#--config：指定kubelet装备文件的路径，发动kubelet时将从此文件加载其装备
#--cert-dir：指定master颁布的kubelet证书生成目录
#--pod-infra-container-image：指定Pod根底容器（Pause容器）的镜像。Pod发动的时分都会发动一个这样的容器，每个pod之间彼此通讯需求Pause的支持，发动Pause需求Pause根底镜像


#----------------------
#创立kubelet装备文件（该文件实践上就是一个yml文件，语法非常严厉，不能出现tab键，冒号后边有必要要有空格，每行结束也不能有空格）
cat >/opt/kubernetes/cfg/kubelet.config <<EOF
kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
address: ${NODE_ADDRESS}
port: 10250
readOnlyPort: 10255
cgroupDriver: cgroupfs
clusterDNS:
- ${DNS_SERVER_IP} 
clusterDomain: cluster.local
failSwapOn: false
authentication:
  anonymous:
   enabled: false
  webhook:
   cacheTTL: 2m0s
   enabled: true
  x509:
   clientCAFile: /opt/kubernetes/ssl/ca.pem 
authorization:
  mode: Webhook
  webhook:
   cacheAuthorizedTTL: 5m0s
   cacheUnauthorizedTTL: 30s
evictionHard:
  imagefs.available: 15%
  memory.available: 100Mi
  nodefs.available: 10%
  nodefs.inodesFree: 5%
maxOpenFiles: 1000000
maxPods: 110
EOF

#PS：当命令行参数与此装备文件（kubelet.config）有相同的值时，就会掩盖装备文件中的该值。


#----------------------
#创立 kubelet.service 服务办理文件
cat >/usr/lib/systemd/system/kubelet.service <<EOF
[Unit]
Description=Kubernetes Kubelet
After=docker.service
Requires=docker.service

[Service]
EnvironmentFile=/opt/kubernetes/cfg/kubelet
ExecStart=/opt/kubernetes/bin/kubelet $KUBELET_OPTS
Restart=on-failure
KillMode=process

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable kubelet
systemctl restart kubelet

附录3：proxy.sh

#!/bin/bash
#example：proxy.sh 192.168.44.30
#脚本后跟的方位参数1是node节点的IP地址。

NODE_ADDRESS=$1

#创立 kube-proxy 发动参数装备文件
cat >/opt/kubernetes/cfg/kube-proxy <<EOF
KUBE_PROXY_OPTS="--logtostderr=true \
--v=4 \
--hostname-override=${NODE_ADDRESS} \
--cluster-cidr=172.17.0.0/16 \
--proxy-mode=ipvs \
--kubeconfig=/opt/kubernetes/cfg/kube-proxy.kubeconfig"
EOF

#--hostnameOverride: 参数值有必要与 kubelet 的值共同，否则 kube-proxy 发动后会找>不到该 Node，从而不会创立任何 ipvs 规矩
#--cluster-cidr：指定 Pod 网络运用的聚合网段，Pod 运用的网段和 apiserver 中指定的 service 的 cluster ip 网段不是同一个网段。 kube-proxy 依据 --cluster-cidr 判别集群内部和外部流量，指定 --cluster-cidr 选项后 kube-proxy 才会对拜访 Service IP 的恳求做 SNAT，即来自非 Pod 网络的流量被当成外部流量，拜访 Service 时需求做 SNAT。
#--proxy-mode：指定流量调度形式为ipvs形式，可增加--ipvs-scheduler选项指定ipvs调度算法（rr|wrr|lc|wlc|lblc|lblcr|dh|sh|sed|nq）
#--kubeconfig: 指定衔接 apiserver 的 kubeconfig 文件

#----------------------
#创立 kube-proxy.service 服务办理文件
cat >/usr/lib/systemd/system/kube-proxy.service <<EOF
[Unit]
Description=Kubernetes Proxy
After=network.target

[Service]
EnvironmentFile=-/opt/kubernetes/cfg/kube-proxy
ExecStart=/opt/kubernetes/bin/kube-proxy $KUBE_PROXY_OPTS
Restart=on-failure

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable kube-proxy
systemctl restart kube-proxy

布置网络组件

网络插件首要两种：Flannel、Calico。装置其中恣意一个即可。

办法一：布置Flannel

在 node01 节点上操作

#上传 cni-plugins-linux-amd64-v0.8.6.tgz 和 flannel.tar 到 /opt 目录中
cd /opt/
docker load -i flannel.tar
docker images

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

#传给node02节点
scp cni/ flannel.tar root@192.168.44.40:/root/
 docker load -i flannel.tar

在 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-hjtc7  1/1   Running  0      7s

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

办法二：布置 Calico

在 master01 节点上操作

#calico.yaml 文件能够直接从网上获取，运用wget下载即可
#上传 calico.yaml 文件到 /opt/k8s 目录中，布置 CNI 网络
cd /opt/k8s
vim calico.yaml
#修正里鸿沟说Pod网络（CALICO_IPV4POOL_CIDR），要与前面kube-controller-manager装备文件指定的cluster-cidr网段共同
  - name: CALICO_IPV4POOL_CIDR
    value: "10.244.0.0/16"  #默许是192.168.0.0/16，需求改成和kube-controller-manager装备文件指定的cluster-cidr网段共同

#经过calico.yaml资源清单，运用kubectl apply创立pod，-f指定清单文件
kubectl apply -f calico.yaml

#等候1~2分钟，检查pod状况，-n指定命名空间，默许是default命名空间。都是Running状况就OK了。
kubectl get pods -n kube-system
NAME                    READY  STATUS   RESTARTS  AGE
calico-kube-controllers-659bd7879c-gq5fb  1/1   Running  0      2m53s
calico-node-dd4gc             1/1   Running  0      2m53s
calico-node-rg299             1/1   Running  0      2m53s

#再次检查集群的节点信息，都是Ready状况。
#等 Calico Pod 都 Running，节点也会准备就绪
kubectl get nodes
NAME       STATUS  ROLES   AGE  VERSION
192.168.44.30  Ready   <none>  73m  v1.20.11
192.168.44.42  Ready   <none>  74m  v1.20.11


#至此，单master节点k8s集群就布置成功了

布置 CoreDNS

CoreDNS：能够为集群中的 service 资源创立一个域名与 IP 的对应联系解析。

service发现是k8s中的一个重要机制，其基本功用为：在集群内经过服务名对服务进行拜访，即需求完结从服务名到ClusterIP的解析。

k8s首要有两种service发现机制：环境变量和DNS。没有DNS服务的时分，k8s会选用环境变量的方法，但一旦有多个service，环境变量会变杂乱，为处理该问题，咱们运用DNS服务。

在一切 node 节点上操作

#上传 coredns.tar 到 /opt 目录中，之后导入镜像
cd /opt
docker load -i coredns.tar

在 master01 节点上操作

#上传 coredns.yaml 文件到 /opt/k8s 目录中，布置 CoreDNS 
cd /opt/k8s
#经过coredns.yaml资源清单，运用kubectl apply创立该pod，-f指定清单文件
kubectl apply -f coredns.yaml

#等候1~2分钟，检查pod状况，-n指定命名空间，默许是default命名空间。coredns是Running状况就OK了。
kubectl get pods -n kube-system 
NAME                READY  STATUS   RESTARTS  AGE
coredns-6954c77b9b-r4lc6     1/1   Running  0      5m21s


#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
/ #

CNI网络插件介绍

Kubernetes的三种网络

K8S 中 Pod 网络通讯

Pod 内容器与容器之间的通讯

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

同一个 Node 内 Pod 之间的通讯

每个 Pod 都有一个实在的大局 IP 地址，同一个 Node 内的不同 Pod 之间能够直接选用对方 Pod 的 IP 地址进行通讯，Pod1 与 Pod2 都是经过 Veth 衔接到同一个 docker0 网桥，网段相同，所以它们之间能够直接通讯。

不同 Node 上 Pod 之间的通讯

Pod 地址与 docker0 在同一网段，docker0 网段与宿主机网卡是两个不同的网段，且不同 Node 之间的通讯只能经过宿主机的物理网卡进行。

要想完成不同 Node 上 Pod 之间的通讯，就有必要想办法经过主机的物理网卡 IP 地址进行寻址和通讯。因而要满足两个条件：Pod 的 IP 不能冲突；将 Pod 的 IP 和地点的 Node 的 IP 关联起来，经过这个关联让不同 Node 上 Pod 之间直接经过内网 IP 地址通讯。

Overlay Network

叠加网络，在二层或者三层根底网络上叠加的一种虚拟网络技术形式，该网络中的主机经过虚拟链路地道衔接起来（类似于VPN）。

VXLAN

将源数据包封装到UDP中，并运用根底网络的IP/MAC作为外层报文头进行封装，然后在以太网上传输，到达意图地后由地道端点解封装并将数据发送给方针地址。

Flannel 插件

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

Flannel 是 Overlay 网络的一种，也是将 TCP 源数据包封装在另一种网络包里边进行路由转发和通讯，现在支持 udp、vxlan、 host-GW 3种数据转发方法。

UDP（默许方法，依据运用转发，装备简略，功用最差）
VXLAN（依据内核转发）
Host-gw（功用最好、装备麻烦）

Flannel UDP 形式（端口8285）

udp形式的作业原理：（依据运用进行转发，Flannel供给路由表，Flannel封装、解封装）

数据从 node01 上 Pod 的源容器中宣布后，经由地点主机的 docker0 虚拟网卡转发到 flannel0 虚拟网卡，flanneld 服务监听在 flannel0 虚拟网卡的另外一端。

Flannel 经过 Etcd 服务保护了一张节点间的路由表。源主机 node01 的 flanneld 服务将本来的数据内容封装到 UDP 中后依据自己的路由表经过物理网卡投递给意图节点 node02 的 flanneld 服务，数据到达今后被解包，然后直接进入意图节点的 flannel0 虚拟网卡，之后被转发到意图主机的 docker0 虚拟网卡，最终就像本机容器通讯相同由 docker0 转发到方针容器。

ETCD 之 Flannel 供给阐明：

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

vxlan 形式（官方预留端口号默许4789）（实践运用端口8472）

vxlan 是一种overlay（虚拟地道通讯）技术，经过三层网络搭建虚拟的二层网络，跟 udp 形式详细完成不太相同：

udp形式是在用户态完成的，数据会先经过tun网卡，到运用程序，运用程序再做地道封装，再进一次内核协议栈，而vxlan是在内核傍边完成的，只经过一次协议栈，在协议栈内就把vxlan包组装好。
udp形式的tun网卡是三层转发，运用tun是在物理网络之上构建三层网络，归于ip in udp，vxlan形式是二层完成， overlay是二层帧，归于mac in udp。
vxlan因为选用mac in udp的方法，所以完成起来会涉及mac地址学习，arp广播等二层常识，udp形式首要关注路由

Flannel VXLAN形式跨主机的作业原理：（Flannel供给路由表，由内核封装、解封装）

数据帧从主机A上Pod的源容器中宣布后，经由地点主机的docker0/cni0 网络接口转发到flannel.1 接口
flannel.1 收到数据帧后增加VXLAN 头部，由内核进行封装在UDP报文中
主机A经过物理网卡发送封包到主机B的物理网卡中
主机B的物理网卡再经过VXLAN 默许端口8472转发到flannel.1 接口进行解封装
解封装今后，内核将数据帧发送到Cni0，最终由Cni0 发送到桥接到此接口的容器B中。

UDP和VXLAN的差异

因为UDP形式是在用户态做转发（即依据运用进行转发，由运用程序进行封装宽和封装），会多一次报文地道封装，因而功用上会比在内核态做转发的VXLAN形式差。

UDP和VXLAN的差异：

UDP依据运用程序进行转发，由运用程序进行封装宽和封装；VXLAN由内核进行封装宽和封装，内核功率比运用程序要高，所以VXLAN比UDP要快。
UDP是数据包，VXLAN是数据帧。
UDP的网卡Flannel0，VXLAN的网卡Flannel.1。

Calico 插件

k8s组网计划比照

flannel 计划

需求在每个节点_上把发向容器的数据包进行封装后，再用地道将封装后的数据包发送到运转着方针Pod的node节点上。方针node节点再担任去掉封装，将去除封装的数据包发送到方针Pod上。数据通讯功用则大受影响。

calico计划

Calico不运用地道或NAT来完成转发，而是把Host当作Internet中的路由器，运用BGP同步路由，并运用iptables来做安全拜访战略，完结跨Host转发来。

选用直接路由的方法，这种方法功用损耗最低，不需求修正报文数据，可是假如网络比较杂乱场景下，路由表会很杂乱，对运维同事提出了较高的要求。

Calico的组成和作业原理

依据三层路由表进行转发，不需求封装宽和封装。

Calico首要由三个部分组成

Calico CNI插件：首要担任与kubernetes对接，供kubelet 调用运用。
Felix：担任保护宿主机上的路由规矩、FIB转发信息库等。
BIRD：担任分发路由规矩，类似路由器。
Confd：装备办理组件。

Calico作业原理

Calico是经过路由表来保护每个pod的通讯。
Calico 的CNI插件会为每个容器设置一个 veth pair设备，然后把另一端接入到宿主机网络空间，因为没有网桥，CNI插件还需求在宿主机上为每个容器的veth pair设备装备一条路由规矩，用于接纳传入的IP包。
有了这样的veth pair设备今后，容器宣布的IP包就会经过veth pair设备到达宿主机，然后宿主机依据路由规矩的下一跳地址，发送给正确的网关，然后到达方针宿主机，再到达方针容器
这些路由规矩都是Felix 保护装备的，而路由信息则是Calico BIRD 组件依据BGP（动态路由协议，能够选路）分发而来。
calico实践上是将集群里一切的节点都作为鸿沟路由器来处理，他们一起组成了一个全互联的网络，彼此之间经过BGP交流路由，这些节点咱们叫做BGP Peer。

flannel和calico比照

flannel

装备便利，功用简略，是依据overlay叠加网络完成的（在原有数据包中再封装一层），因为要进行封装宽和封装的进程对功用会有必定的影响，一起不具有网络战略装备才能。
三种形式：UDP、 VXLAN、HOST-GW
默许网段是：10.244.0.0/16

calico

功用强大，依据路由表进行转发，没有封装宽和封装的进程，对功用影响较小，具有网络战略装备才能，可是路由表保护起来较为杂乱。
形式：BGP、IPIP
默许网段192 .168.0.0/16

现在比较常用的CNI网络组件是flannel和calico，flannel的功用比较简略，不具有杂乱的网络战略装备才能，calico是比较超卓的网络办理插件，但具有杂乱网络装备才能的一起，往往意味着自身的装备比较杂乱，所以相对而言，比较小而简略的集群运用flannel，考虑到日后扩容，未来网络可能需求参加更多设备，装备更多网络战略，则运用calico更好。

（flannel在封装宽和封装的进程中，会有功用损耗。calico没有封装解封装进程，没有功用损耗）

总结

flannel是k8s的pod能够完成跨节点通讯的cni网络插件

形式：

UDP：最早，功用较差
VXLAN：默许，引荐，功用比UDP更好
Host-gw：功用最好，但装备繁琐

flannel的UDP形式作业原理（端口号默许8285）

运用数据从源主机的Pod宣布到cnio网桥接口，再由cnio转发到flannel0虚拟网卡接口
flanneld服务会监听flannelo接口的数据，flanneld服务会将内部数据包封装到UDP报文里
依据flannel在etcd保护的路由表经过物理网卡转发到方针主机
UDP报文送到达方针主机的flanneld服务后会被解封装，然后会经过方针主机的fl.annelo接口转发到方针主机的eni0o网桥，最终再被cni0转发到方针Pod

flannel的VXLAN形式作业原理（官方预留端口号默许4789）（实践运用端口8472）

pod将数据帧（包括IP头部与报文）转发到cni0网桥，再转发到flannel.1虚拟网卡接口，
flannel.1网卡会在数据帧上增加VXLAN头部作为标识，再将数据帧由内核进行封装到UDP报文中
依据flannel在etcd保护的路由表，封装方针主机的IP地址和MAC地址，经过物理网卡，转发到方针主机
方针主机会经过8472端口，将数据包发送到flannel.1虚拟网卡接口，flannel.1会将udp报文进行解封装，
并且解封装VXLAN头部信息，转发到网桥cni0，cni0网桥将数据帧转发到衔接在网桥上的方针pod

K8S的三种网络

节点网络（经过物理网卡通讯，如ens33）
pod网络（经过pod ip进行通讯）
service网络（经过cluster ip进行通讯）

flannel和calico 差异?

flannel运用的三种形式：udp、vxlan、host-gw
- flannel 一般运用 vxlan 形式，选用的是叠加网络，IP地道方法传输数据，能够完成跨子网进行传输。传输进程中需求进行封包宽和包的进程，对功用有必定的影响。
- 功用简略装备便利，利于办理，但不具有杂乱的网络战略规矩装备的才能
calico运用的三种形式：ipip、bgp、混合
- calico的ipip形式，同样能够完成跨子网传输，但传输进程中相同需求进行封装宽和封装的操作，对功用有必定的影响
- calico的bgp形式能够直接依据bgp路由规矩转发，并且传输进程中不需求封装宽和封装，因而功用较好，可是只能在同一子网中运用，无法进行跨网运用；bgp形式具有更丰厚的网络战略装备办理才能；可是保护起来较为杂乱

所以对于较小规模且网络要求简略的k8s集群，咱们能够选用flannel，对于集群规模较大且要求更多的网络战略时，能够选用功用更全面的calico

二进制搭建Kubernetes集群（中）——部署node节点

布置node节点

一切node节点布置 docker引擎

布置 Worker Node 组件

在一切 node 节点上操作

在 master01 节点上操作

在一切node节点上操作，发动kubelet服务

在 master01 节点上操作，经过 CSR 恳求

在一切 node 节点上操作，发动kube-proxy服务

附录1：kubeconfig.sh

附录2：kubelet.sh

附录3：proxy.sh

布置网络组件

办法一：布置Flannel

在 node01 节点上操作

在 master01 节点上操作\

办法二：布置 Calico

在 master01 节点上操作

布置 CoreDNS

在一切 node 节点上操作

在 master01 节点上操作

CNI网络插件介绍

Kubernetes的三种网络

K8S 中 Pod 网络通讯

Pod 内容器与容器之间的通讯

同一个 Node 内 Pod 之间的通讯

不同 Node 上 Pod 之间的通讯

Overlay Network

VXLAN

Flannel 插件

Flannel UDP 形式（端口8285）

udp形式的作业原理：（依据运用进行转发，Flannel供给路由表，Flannel封装、解封装）

vxlan 形式（官方预留端口号默许4789）（实践运用端口8472）

Flannel VXLAN形式跨主机的作业原理：（Flannel供给路由表，由内核封装、解封装）

UDP和VXLAN的差异

Calico 插件

k8s组网计划比照

flannel 计划

calico计划

Calico的组成和作业原理

Calico首要由三个部分组成

Calico作业原理

flannel和calico比照

总结

相关文章

Android 标准语音识别框架：SpeechRecognizer 的封装和调用

初识 Swift：创建第一个 APP —— 相框（二）

基于 Serverless+OSS 分分钟实现图片秒变素描

后端开发还不用 Java？！看完这篇文章你就知道自己错了！

作者信息