首页 > 其他分享> 文章详细

k8s---网络

2021-10-26 18:33:08 阅读：247 来源： 互联网

标签：kubectl ## 网络 --- yaml 网卡 pod k8s calico

k8s网络通信

k8s通过CNI接口接入其他插件来实现网络通讯，目前比较流行的插件有flannel、calico等。CNI插件存放位置：/etc/cni/net.d/

插件使用的解决方案如下：

虚拟网桥，虚拟网卡，多个容器共用一个虚拟网卡进行通信；
多路复用：MacVLAN，多个容器共用一个物理网卡进行通信；
硬件交换：SR-LOV，一个物理网卡可以虚拟出多个接口，这个性能最好。

容器间通信：同一个pod内的多个容器间的通信，通过lo即可实现。

pod之间的通信：同一节点的pod之间通过cni网桥转发数据包；不同节点的pod之间的通信需要网络插件支持。

pod和service通信：通过iptables或ipvs实现通信，ipvs取代不了iptables，因为ipvs只能做负载均衡，而做不了nat转换。

pod和外网通信：iptables的MASQUERADE。

Service与集群外部客户端的通信：ingress、nodeport、loadbalancer。

flannel网络

名词

VXLAN：即Virtual Extensible LAN（虚拟可扩展局域网），是Linux本身支持的一网种网络虚拟化技术。VXLAN可以完全在内核态实现封装和解封装工作，从而通过“隧道”机制，构建出覆盖网络（Overlay Network）。
VTEP：VXLAN Tunnel End Point（虚拟隧道端点），在Flannel中 VNI的默认值是1，这也是为什么宿主机的VTEP设备都叫flannel.1的原因。
Cni0: 网桥设备，每创建一个pod都会创建一对 veth pair。其中一端是pod中的eth0，另一端是Cni0网桥中的端口（网卡）。
Flannel.1: TUN设备(虚拟网卡)，用来进行 vxlan 报文的处理（封包和解包）。不同node之间的pod数据流量都从overlay设备以隧道的形式发送到对端。
Flanneld：flannel在每个主机中运行flanneld作为agent，它会为所在主机从集群的网络地址空间中，获取一个小的网段subnet，本主机内所有容器的IP地址都将从中分配。同时Flanneld监听K8s集群数据库，为flannel.1设备提供封装数据时必要的mac、ip等网络数据信息。

原理

当容器发送IP包，通过veth pair 发往cni网桥，再路由到本机的flannel.1设备进行处理。
VTEP设备之间通过二层数据帧进行通信，源VTEP设备收到原始IP包后，在上面加上一个目的MAC地址，封装成一个内部数据帧，发送给目的VTEP设备。
内部数据桢，并不能在宿主机的二层网络传输，Linux内核还需要把它进一步封装成为宿主机的一个普通的数据帧，承载着内部数据帧通过宿主机的eth0进行传输。
Linux会在内部数据帧前面，加上一个VXLAN头，VXLAN头里有一个重要的标志叫VNI，它是VTEP识别某个数据桢是不是应该归自己处理的重要标识。
flannel.1设备只知道另一端flannel.1设备的MAC地址，却不知道对应的宿主机地址是什么。在linux内核里面，网络设备进行转发的依据，来自FDB的转发数据库，这个flannel.1网桥对应的FDB信息，是由flanneld进程维护的。
linux内核在IP包前面再加上二层数据帧头，把目标节点的MAC地址填进去，MAC地址从宿主机的ARP表获取。
此时flannel.1设备就可以把这个数据帧从eth0发出去，再经过宿主机网络来到目标节点的eth0设备。目标主机内核网络栈会发现这个数据帧有VXLAN Header，并且VNI为1，Linux内核会对它进行拆包，拿到内部数据帧，根据VNI的值，交给本机flannel.1设备处理,flannel.1拆包，根据路由表发往cni网桥，最后到达目标容器。

Flannel vxlan模式跨主机通信原理图

flannel支持多种后端

Vxlan：报文封装，默认
host-gw：主机网关，性能好，但只能在二层网络中，不支持跨网络。如果有成千上万的Pod，容易产生广播风暴，不推荐
UDP：性能差，不推荐

更改后端模式为host-gw

当前后端模式为默认的Vxlan

可见每个节点间通信，需要通过flannel.1（虚拟网卡）。隧道机制

kubectl -n kube-system edit cm kube-flannel-cfg ##编辑

kubectl get pod -n kube-system | grep flannel | awk '{system("kubectl -n kube-system delete pod "$1"")}' ##删除pod，自动拉起，相当于重启，使改动生效

再次查看网关

后端模式切换成功，不通过“隧道”，直接使用真实网卡

calico网络

官网： Install Calico networking and network policy for on-premises deployments

简介

flannel实现的是网络通信，calico的特性是在pod之间的隔离。
通过BGP路由，但大规模端点的拓扑计算和收敛往往需要一定的时间和计算资源。
纯三层的转发，中间没有任何的NAT和overlay，转发效率最好。
Calico 仅依赖三层路由可达。Calico 较少的依赖性使它能适配所有 VM、Container、白盒或者混合环境场景。

安装calico

以免网络冲突，需要先删除flannel插件

master:

kubectl delete -f kube-flannel.yml ##回收

master与nodes:

rm -fr /etc/cni/net.d/10-flannel.conflist ##删除插件

开始安装

mkdir calico

cd calico/

wget https://docs.projectcalico.org/manifests/calico.yaml --no-check-certificate ##下载清单文件

vim calico.yaml

4040           image: calico/kube-controllers:v3.20.2      ##镜像路径都改为私有仓库
3742           image: calico/cni:v3.20.2
3769           image: calico/cni:v3.20.2
3810           image: calico/pod2daemon-flexvol:v3.20.2
3821           image: calico/node:v3.20.2
3851             # Enable IPIP
3852             - name: CALICO_IPV4POOL_IPIP
3853               value: "off"                            ##关闭IPIP

kubectl apply -f calico.yaml ##应用

网络架构

Felix：监听ECTD中心的存储获取事件，用户创建pod后，Felix负责将其网卡、IP、MAC都设置好，然后在内核的路由表里面写一条，注明这个IP应该到这张网卡。同样如果用户制定了隔离策略，Felix同样会将该策略创建到ACL中，以实现隔离。

BIRD：一个标准的路由程序，它会从内核里面获取哪一些IP的路由发生了变化，然后通过标准BGP的路由协议扩散到整个其他的宿主机上，让外界都知道这个IP在这里，路由的时候到这里来。

网络策略

网站：网络策略 | Kubernetes

NetworkPolicy策略模型：控制某个namespace下的pod的网络出入站规则

示例：

先创建一个副本为3的控制器和一个svc，用于展示效果

注意：网络策略控制哪些pod，是由spec.podSelector.matchLabels决定的。即一份策略只会适用于拥有指定标签的pod。

这些pod标签为app=nginx，则若想控制这些pod的连接，策略里的标签指定需保持一致。

1. 通过podSelector指定

vim policy_1.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: access-nginx 
spec:
  podSelector:
    matchLabels:
      app: nginx          ##与所控制的pod保持一致
  ingress:
  - from:
    - podSelector:        ##允许默认ns下带有 "access=true"标签的Pod
        matchLabels:
          access: "true"

重新打开一个bash，并运行一个可交互容器

kubectl run demo -it --image=busyboxplus --restart=Never

访问该svc

可以连接得到

我们运行策略，再次访问试试

kubectl apply -f policy_1.yaml

连接不到

我们给该pod加上标签，再访问

kubectl label pod demo access=true

连接成功

kubectl delete -f policy_1.yaml ##回收策略

kubectl delete pod demo ##回收pod

2. 通过namespaceSelector指定

vim policy_2.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: access-nginx
spec:
  podSelector:
    matchLabels:
      app: nginx
  ingress:
  - from:
    - namespaceSelector:    ##允许带有 "project=test" 标签的所有ns中的Pod
        matchLabels:
          project: test

创建一个ns

kubectl create ns test

和上个示例相同，继续在另一个bash中再运行一个可交互容器（在test这个ns中）

kubectl run demo -it --image=busyboxplus --restart=Never -n test

可以连接的到

应用策略后访问

kubectl apply -f policy_2.yaml

连接失败

给该ns加上标签，再访问

kubectl label ns test project=test

连接成功

kubectl delete -f policy_2.yaml

kubectl delete pod demo -n test

3. 通过ipBlock指定

vim policy_3.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: access-nginx
spec:
  podSelector:
    matchLabels:
      app: nginx
  ingress:
  - from:
    - ipBlock:                  ##允许除了 172.25.56.0/24 之外的所有 172.25.0.0/16
        cidr: 172.25.0.0/16
        except:
        - 172.25.56.0/24

修改该svc的类型为LoadBalancer，分配给其一个集群外部ip

kubectl edit svc web-service

分配的ip为172.25.56.150

客户端ip如图

访问该svc

连接成功

应用策略，再次访问

kubectl apply -f policy_3.yaml

连接失败，策略将172.25.56.0/24网段的连接拒绝掉

标签：kubectl,##,网络,---,yaml,网卡,pod,k8s,calico
来源： https://blog.csdn.net/qq_45737059/article/details/120957864

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

ICode9

k8s---网络

k8s网络通信

flannel网络

calico网络