首页 > 其他分享 >91-云原生操作系统-Kubernetes网络通信常见架构及案例解析

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析

时间：2023-04-22 19:06:37浏览次数：41  
标签：网络通信 Kubernetes IP 报文 宿主机 MAC 91 pod port

VxLAN技术演进

VxLAN的技术演进

  • 二层通信 - 基于目标mac地址通信，不可夸局域网通信，通常是由接入交换机或汇聚交换机实现报文转发。

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_OverLay

  • VLAN（Virtual Local Area Network）- 即虚拟局域网，是将一个物理(交换机)的网络在逻辑上划分成多个广播域的通信技术，VLAN内的主机间可以直接通信，而VLAN网络外的主机需要通过三层网络设备转发才可以通信，因此一个vlan可以将服务器的广播报文限制在一个VLAN内，从而降低单个网络环境中的广播报文，vlan采用12位标识vlan ID，即一个交换机设备最多为2^12=4096个vlan。

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_Calico_02

  • 三层通信 - 服务机>局域网(一层)>接入/汇聚交换机(二层)>核心交换机(二层)>路由器(三层)

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_OverLay_03

  • VxLAN - VxLAN全称是Virtual eXtensible Local Area Network（虚拟扩展本地局域网）,主要有Cisco推出，vxlan是一个 VLAN 的扩展协议，是由IETF定义的NVO3（Network Virtualization over Layer 3）标准技术之一，VXLAN的特点是将L2的以太帧封装到UDP报文（即L2 over L4）中，并在L3网络中传输，即使用MAC in UDP的方法对报文进行重新封装, VxLAN 本质上是一种overlay的隧道封装技术，它将L2的以太网帧封装成L4的UDP数据报，然后在L3的网络中传输，效果就像L2的以太网帧在一个广播域中传输一样，实际上L2的以太网帧跨越了L3网络传输，但是缺不受L3网络的限制，vxlan采用24位标识vlan ID号，因此可以支持2^24=16777216个vlan，其可扩展性比vlan强大的多，可以支持大规模数据中心的网络需求。

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_OverLay_04

overlay架构及示例

overlay设备

  • VTEP - VTEP(VXLAN Tunnel Endpoint vxlan隧道端点),VTEP是VXLAN网络的边缘设备，是VXLAN隧道的起点和终点，VXLAN对用户原始数据帧的封装和解封装均在VTEP上进行,用于VXLAN报文的封装和解封装,VTEP与物理网络相连,分配的地址为物理网IP地址,VXLAN报文中源IP地址为本节点的VTEP地址，VXLAN报文中目的IP地址为对端节点的VTEP地址，一对VTEP地址就对应着一个VXLAN隧道，服务器上的虚拟交换机(隧道flannel.1就是VTEP)，比如一个虚拟机网络中的多个vxlan就需要多个VTEP对不同网络的报文进行封装与解封装。
  • VNI - VNI（VXLAN Network Identifier）：VXLAN网络标识VNI类似VLAN ID,用于区分VXLAN段,不同VXLAN段的虚拟机不能直接二层相互通信,一个VNI表示一个租户,即使多个终端用户属于同一个VNI,也表示一个租户。
  • NVGRE - NVGRE：Network Virtualization using Generic Routing Encapsulation，主要支持者是Microsoft，与VXLAN不同的是，NVGRE没有采用标准传输协议（TCP/UDP），而是借助通用路由封装协议（GRE），NVGRE使用GRE头部的低24位作为租户网络标识符（TNI），与VXLAN一样可以支持1777216个vlan。

overlay通信

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_Calico_05

  • 过程：
  1. VM A发送L2 帧与VM请求与VM B通信。
  2. 源宿主机VTEP添加或者封装VXLAN、UDP及IP头部报文。
  3. 网络层设备将封装后的报文通过标准的报文在三层网络进行转发到目标主机。
  4. 目标宿主机VTEP删除或者解封装VXLAN、UDP及IP头部。
  5. 将原始L2帧发送给目标VM。

overlay通信示例

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_Calico_06

总结：Overlay - 基于VXLAN、NVGRE等封装技术实现overlay叠加网络

underlay架构及示例

Underlay网络

  • Underlay网络就是传统IT基础设施网络，由交换机和路由器等设备组成，借助以太网协议、路由协议和VLAN协议等驱动，它还是Overlay网络的底层网络，为Overlay网络提供数据通信服务。容器网络中的Underlay网络是指借助驱动程序将宿主机的底层网络接口直接暴露给容器使用的一种网络构建技术，较为常见的解决方案有MAC VLAN、IP VLAN和直接路由等。

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_VxLAN_07

underlay实现模式

  • Mac Vlan模式 - 支持在同一个以太网接口上虚拟出多个网络接口(子接口)，每个虚拟接口都拥有唯一的MAC地址并可配置网卡子接口IP。（左图）
  • IP VLAN模式 - 类似于MAC VLAN，它同样创建新的虚拟网络接口并为每个接口分配唯一的IP地址，不同之处在于，所有虚拟接口共享物理接口的MAC地址。（右图）

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_Calico_08

MAC Vlan工作模式

  • Private(私有)模式 - 在Private模式下，同一个宿主机下的容器不能通信，即使通过交换机再把数据报文转发回来也不行。
  • VEPA模式 - 虚拟以太端口汇聚器（Virtual Ethernet Port Aggregator，简称VEPA），在这种模式下，macvlan内的容器不能直接接收在同一个物理网卡的容器的请求数据包，但是可以经过交换机的(端口回流)再转发回来可以实现通信。
  • passthru(直通)模式 - Passthru模式下该macvlan只能创建一个容器，当运行一个容器后再创建其他容器则会报错。
  • bridge模式 - 在bridge这种模式下，使用同一个宿主机网络的macvlan容器可以直接实现通信，推荐使用此模式。

总结：underlay- 基于Docker宿主机物理网卡的不同子接口实现多个虚拟vlan，一个子接口就是一个虚拟vlan，容器通过宿主机的路由功能和外网保持通信。

kubernetes-pod通信

CNI通用模式

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_UnderLay_09

  • Overlay网络
  • Flannel Vxlan、Calico BGP、Calico Vxlan
  • 将pod 地址信息封装在宿主机地址信息以内，实现跨主机且可跨node子网的通信报文。
  • 直接路由
  • Flannel Host-gw、Flannel VXLAN Directrouting、Calico Directrouting
  • 基于主机路由，实现报文从源主机到目的主机的直接转发，不需要进行报文的叠加封装，性能比overlay更好
  • Underlay
  • 需要为pod启用单独的虚拟机网络，直接使用宿主机物理网络，pod甚至可以在k8s环境之外的节点直接访问(与node节点的网络被打通)，相当于把pod当桥接模式的虚拟机使用，比较方便k8s环境以外的访问访问k8s环境中的pod中的服务，而且由于主机使用的宿主机网络，其性能最好。
underlay网络案例
创建underlay网络并与node节点关联
  • 为node主机添加underlay network标签 ，如果是其他网络类型，也需要添加相应的标签去配对使用
root@k8s-master1:~/hybridnet# kubectl label node k8s-node1.example.com network=underlay-nethost
node/k8s-node2.example.com labeled
root@k8s-master1:~/hybridnet# kubectl label node k8s-node2.example.com network=underlay-nethost
node/k8s-node3.example.com labeled
root@k8s-master1:~/hybridnet# kubectl label node k8s-node3.example.com network=underlay-nethost
node/k8s-node3.example.com labeled
  • create-underlay-network.yaml
---
apiVersion: networking.alibaba.com/v1
kind: Network
metadata:
  name: underlay-network1
spec:
  netID: 0
  type: Underlay
  nodeSelector:
    network: "underlay-nethost"

---
apiVersion: networking.alibaba.com/v1
kind: Subnet
metadata:
  name: underlay-network1 
spec:
  network: underlay-network1
  netID: 0
  range:
    version: "4"
    cidr: "172.31.0.0/21"
    gateway: "172.31.0.2"     # 外部网关地址
    start: "172.31.6.1"     #分配给pod使用
    end: "172.31.6.254"
  • 验证网络

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_OverLay_10

创建pod并使用overlay网络
  • tomcat-app1-overlay.yaml
  • 默认会使用overlay网络，overlay使用的是vxlan进行报文封装，会生成一个eth0.vxlan4网卡，接收报文为UDP的8472端口
kind: Deployment
apiVersion: apps/v1
metadata:
  labels:
    app: myserver-tomcat-app1-deployment-overlay-label
  name: myserver-tomcat-app1-deployment-overlay
  namespace: myserver
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myserver-tomcat-app1-overlay-selector
  template:
    metadata:
      labels:
        app: myserver-tomcat-app1-overlay-selector
    spec:
      nodeName: k8s-node2.example.com 
      containers:
      - name: myserver-tomcat-app1-container
        #image: tomcat:7.0.93-alpine 
        image: registry.cn-hangzhou.aliyuncs.com/zhangshijie/tomcat-app1:v1 
        imagePullPolicy: IfNotPresent
        ##imagePullPolicy: Always
        ports:
        - containerPort: 8080
          protocol: TCP
          name: http
        env:
        - name: "password"
          value: "123456"
        - name: "age"
          value: "18"
#        resources:
#          limits:
#            cpu: 0.5
#            memory: "512Mi"
#          requests:
#            cpu: 0.5
#            memory: "512Mi"

---
kind: Service
apiVersion: v1
metadata:
  labels:
    app: myserver-tomcat-app1-service-overlay-label
  name: myserver-tomcat-app1-service-overlay
  namespace: myserver
spec:
  type: NodePort
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 8080
    nodePort: 30003
  selector:
    app: myserver-tomcat-app1-overlay-selector
  • 使用overlay网络的Node节点会生成vxlan网卡进行流量转发并创建iptables规则

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_Flannel_11

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_OverLay_12

创建pod并使用underlay网络
  • tomcat-app1-underlay.yaml
  • underlay pod可以与overlaypod共存(混合使用)。
kind: Deployment
apiVersion: apps/v1
metadata:
  labels:
    app: myserver-tomcat-app1-deployment-underlay-label
  name: myserver-tomcat-app1-deployment-underlay
  namespace: myserver
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myserver-tomcat-app1-underlay-selector
  template:
    metadata:
      labels:
        app: myserver-tomcat-app1-underlay-selector
      annotations: #使用Underlay或者Overlay网络
        networking.alibaba.com/network-type: Underlay
    spec:
      #nodeName: k8s-node2.example.com
      containers:
      - name: myserver-tomcat-app1-container
        #image: tomcat:7.0.93-alpine 
        image: registry.cn-hangzhou.aliyuncs.com/zhangshijie/tomcat-app1:v2 
        imagePullPolicy: IfNotPresent
        ##imagePullPolicy: Always
        ports:
        - containerPort: 8080
          protocol: TCP
          name: http
        env:
        - name: "password"
          value: "123456"
        - name: "age"
          value: "18"
#        resources:
#          limits:
#            cpu: 0.5
#            memory: "512Mi"
#          requests:
#            cpu: 0.5
#            memory: "512Mi"

--- #可忽略
kind: Service
apiVersion: v1
metadata:
  labels:
    app: myserver-tomcat-app1-service-underlay-label
  name: myserver-tomcat-app1-service-underlay
  namespace: myserver
spec:
#  type: NodePort
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 8080
    #nodePort: 40003
  selector:
    app: myserver-tomcat-app1-underlay-selector
  • 通过宿主机ip访问pod

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_VxLAN_13

underlay网络模式下通过service IP访问Pod
  • 通过一个固定的方式访问Pod
  • Pod IP可以是固定的，但是很多时候会是动态变化的，SVC的IP删除再重建是不会变化的，可以把某个域名通过自建 的DNS解析到SVC，如果SVC的IP发生变化可以修改域名的A记录。
  • 注意：后期如果要访问SVC则需要在网络设备配置静态路由，打通从客户端到SVC的通信，把请求转发到具体的kubernetes node节点响应
~# route add -net 172.31.5.0 netmask 255.255.255.0 gateway 172.31.6.204
网络组件 - flannel与calico通信原理解析
Pod常见通信需求
  • pod中不同container的通信
  • sidcar模式的多容器pod
  • lnmp模式的多容器环境
  • pod与pod中间的通信
  • pod与pod在同一个node
  • pod与pod不带同一个node
  • node与node在同一个物理子网(vlan)
  • node与node不在同一个物理子网(vlan)
  • pod与外部服务的通信
  • pod中的服务主动调用node网络之外的存储、中间件等
  • pod中的服务主动调用node网络之外的存储、中间件等
  • 客户端与pod的通信
  • 来自于客户端浏览器的请求
  • 来自于客户端APP的请求
Kubernetes常见CNI
https://github.com/containernetworking/cni #github

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_OverLay_14

flannel通信架构及案例

flannel通信架构

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_Flannel_15

#官网：
https://coreos.com/flannel/docs/latest/
#文档：
https://coreos.com/flannel/docs/latest/kubernetes.html

#flannel通信原理
由CoreOS开源的针对k8s的网络服务，其目的为解决k8s集群中各主机上的pod相互通信的问题，其借助于etcd维护网络IP地址分配，并为每一个node服务器分配一个不同的IP地址段。

#都会监听一个8472端口接收流量，可以抓取流量包进行观察 tcpdump -i eth0 udp port 8472

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_Flannel_16

flannel网络模式

Flannel 网络模型 (后端模型)，Flannel目前有三种方式实现 UDP/VXLAN/host-gw

  • UDP - 早期版本的Flannel使用UDP封装完成报文的跨越主机转发，其安全性及性能略有不足。
  • VXLAN - Linux 内核在在2012年底的v3.7.0之后加入了VXLAN协议支持，因此新版本的Flannel也有UDP转换为VXLAN，VXLAN本质上是一种tunnel（隧道）协议，用来基于3层网络实现虚拟的2层网络，目前flannel 的网络模型已经是基于VXLAN的叠加(覆盖)网络，目前推荐使用vxlan作为其网络模型。
  • host-gw - Host GateWay通过在node节点上创建到达各目标容器地址的路由表而完成报文的转发，因此这种方式要求各node节点本身必须处于同一个局域网(二层网络)中，因此不适用于网络变动频繁或比较大型的网络环境，但是其性能较好。

Flannel的系统文件及目录

#运行环境
root@k8s-node2:~#  find / -name flannel
/opt/cni/bin/flannel
/run/flannel
/usr/local/bin/flannel

 #子网信息
root@k8s-node2:~# cat /run/flannel/subnet.env  
~# cat /run/flannel/subnet.env 
FLANNEL_NETWORK=10.200.0.0/16
FLANNEL_SUBNET=10.200.2.1/24
FLANNEL_MTU=1450
FLANNEL_IPMASQ=true

路由表

  • Cni0 - 网桥设备，每创建一个pod都会创建一对 veth pair，其中一端是pod中的eth0，另一端是Cni0网桥中的端口（网卡），Pod中从网卡eth0发出的流量都会发送到Cni0网桥设备的端口（网卡）上，Cni0 设备获得的ip地址是该节点分配到的网段的第一个地址。
  • Flannel.1 - overlay网络的设备，用来进行vxlan报文的处理（封包和解包），不同node之间的pod数据流量都从overlay设备以隧道的形式发送到对端。

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_Calico_17

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_Flannel_18

Flannel vxlan配置

  • 官方提供的配置模板
https://github.com/flannel-io/flannel
kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml

#需要注意的是修改模板中的IP为NodeIp
#kube-flannel.yml
...
net-conf.json: |
    {
      "Network": "10.244.0.0/16", 
      "Backend": {
        "Type": "vxlan"
      }
    }
    
#安装后会生成configmap
[root@k8s-master1 ~]# kubectl edit configmap  kube-flannel-cfg  -n kube-system 
kind: ConfigMap
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","data":{"cni-conf.json":"{\n  \"name\": \"cbr0\",\n  \"cniVersion\": \"0.3.1\",\n  \"plugins\": [\n    {\n      \"type\": \"flannel\",\n      \"delegate\": {\n        \"hairpinMode\": true,\n        \"isDefaultGateway\": true\n      }\n    },\n    {\n      \"type\": \"portmap\",\n      \"capabilities\": {\n        \"portMappings\": true\n      }\n    }\n  ]\n}\n","net-conf.json":"{\n  \"Network\": \"10.200.0.0/16\",\n  \"Backend\": {\n    \"Type\": \"vxlan\"\n  }\n}\n"},"kind":"ConfigMap","metadata":{"annotations":{},"labels":{"app":"flannel","tier":"node"},"name":"kube-flannel-cfg","namespace":"kube-system"}}


#flannel vxlan使用UDP端口8472传输封装好的报文。
root@k8s-node2:~# netstat  -tuanlp | grep 8472
udp        0      0 0.0.0.0:8472            0.0.0.0:*

Flannel vxlan架构图

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_OverLay_19

  • 生产架构案例

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_UnderLay_20

Flannel Pod通信解析

Flannel Pod通信

  • 进入pod查询当前网卡在宿主机的IP序列，从而知道pod对应的网卡名称

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_Flannel_21

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_Flannel_22

  • 抓取pod网卡通信包进行分析
#源pod发起请求，此时报文中源IP为pod的eth0 的ip,源mac 为pod的eth0的mac，目的Pod为目的Pod的IP，目的mac为网关(cni0)的MAC
node2 ~# tcpdump -nn -vvv  -i 网卡名称  -vvv -nn ! port 22 and  ! port  2379 and ! port  6443 and ! port  10250 and ! arp and ! port  53

#示例

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_UnderLay_23

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_OverLay_24

#数据报文通过veth peer发送给网关cni0，cni0进行目标IP检查,如果是同一个网桥的报文就直接转发，不是的话就发送给flannel.1, 此时报文被修改如下：
源IP: Pod IP，10.100.2.2
目的IP: Pod IP，10.100.1.6
源MAC： 源POD MAC
目的MAC：cni mAC

#抓取cni0数据包
node2 ~]# tcpdump -nn -vvv  -i cni0 -vvv -nn ! port 22 and  ! port  2379 and ! port  6443 and ! port  10250 and ! arp and ! port  53 

#到达flannel.1,检查目的mac就是发给自己的，开始匹配路由表,先实现overlay报文的内层封装(主要是修改目的Pod的对端flannel.1的 MAC、源MAC为当前宿主机flannel.1的MAC)：
[root@k8s-node2 ~]# bridge  fdb show dev flannel.1
de:34:a2:06:d3:56 dst 172.30.7.111 self permanent  #永久链路
12:d7:c9:e7:3b:46 dst 172.30.7.101 self permanent

#抓取flannel.1数据包
node2 ~]# tcpdump -nn -vvv  -i flannel.1 -vvv -nn ! port 22 and  ! port  2379 and ! port  6443 and ! port  10250 and ! arp and ! port  53 

#封装结构 - 可以参考官方vxlan报文格式
源IP: Pod IP，10.100.2.2
目的IP: Pod IP，10.100.1.6
源MAC: 9e:68:76:c4:64:0f，源Pod所在宿主机flannel.1的MAC
目的MAC：de:34:a2:06:d3:56，目的Pod所在主机flannel.1的MAC
flannel模式抓包全过程图解
  • pod发出请求

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_Calico_25

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_UnderLay_26

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_UnderLay_27

  • pod请求发送到cni0

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_VxLAN_28

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_Flannel_29

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_VxLAN_30

  • cni0将请求转发给flannel1

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_Flannel_31

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_Flannel_32

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_UnderLay_33

  • overlay模式封装后转发到目标8472端口

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_UnderLay_34

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_VxLAN_35

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_Flannel_36

  • 目标主机网卡接收数据包
#基于UDP封装Vxlan报文
VXLAN ID：1
UDP 源端口： 随机
UDP 目的端口： 8472
源IP  #源Pod所在宿主机的物理网卡IP#
目的IP   #目的Pod所在宿主机的物理网卡IP
源MAC: 00:0c:29:bc:fe:d8  #源Pod所在宿主机的物理网卡
目的MAC: 00:0c:29:56:e7:1b #目的Pod所在宿主机的物理网卡

#查看数据包报文
node1 ~]# tcpdump -nn -vvv  -i eth0  -vvv -nn ! port 22 and  ! port  2379 and ! port  6443 and ! port  10250 and ! arp and ! port  53
node1 ~]# ip -d link show flannel.1
    link/ether 52:34:52:6d:6e:6e brd ff:ff:ff:ff:ff:ff promiscuity 0 
    vxlan id 1 local 172.30.7.101 dev eth0 srcport 0 0 dstport 8472 nolearning ageing 300

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_UnderLay_37

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_OverLay_38

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_Flannel_39

  • 报文到达目的宿主机物理网卡，接开始解封装报文
  • 外层目的IP为本机物理网卡，解开后发现里面还有一层目的IP和目的MAC，发现目的IP为10.100.1.6，目的MAC为de:34:a2:06:d3:56(目的flannel.1的MAC)，然后将报文发送给flannel.1
node1 ~]# tcpdump -nn -vvv  -i eth0  -vvv -nn ! port 22 and  ! port  2379 and ! port  6443 and ! port  10250 and ! arp and ! port  53

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_VxLAN_40

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_Flannel_41

  • flannel.1接收eth0转发的报文开始解析，拿到目标pod地址
  • flannel.1检查报文的目的IP，发现是去往本机cni0的子网，将请求报文转发至cni0
node1 ~]# tcpdump -nn -vvv  -i flannel.1  -vvv -nn ! port 22 and  ! port  2379 and ! port  6443 and ! port  10250 and ! arp and ! port  53
目的IP：10.100.1.6 #目的Pod
源IP：   10.100.2.2 #源Pod
目的 MAC：de:34:a2:06:d3:56 #目的pod所在宿主机的flannel.1
源MAC：9e:68:76:c4:64:0f       #源pod所在宿主机flannel.1的MAC

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_Calico_42

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_VxLAN_43

  • flannel.1获取到具体的pod地址后转发给cni0
  • pcni0基于目的IP检查mac地址表，修改目的MAC为目的MAC后将来请求转给pod
源IP： 10.100.2.2  #源Pod
目的IP： 10.100.1.6 #目的Pod
源MAC：cni0的MAC, b2:12:0d:e4:eb:46
目的MAC: 目的Pod的MAC f2:50:98:b4:ea:01
node1 ~]# tcpdump -nn -vvv  -i cni0  -vvv -nn ! port 22 and  ! port  2379 and ! port  6443 and ! port  10250 and ! arp and ! port  53  -w 7.flannel-flannel-vxlan-cni0-in.pcap

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_VxLAN_44

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_Flannel_45

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_OverLay_46

  • 报文到达目的宿主机pod
  • cni0收到报文发现去往10.100.1.6,检查MAC地址表发现是本地接口，然后通过网桥接口发给pod
目的IP： 目的pod IP 10.100.1.6
源IP：源Pod IP 10.200.2.2
目的MAC： 目的pod MAC,f2:50:98:b4:ea:01
源MAC: cni0的MAC,b2:12:0d:e4:eb:46
node1 ~]# tcpdump -nn -vvv  -i vethf38183ee  -vvv -nn ! port 22 and  ! port  2379 and ! port  6443 and ! port  10250 and ! arp and ! port  53  -w 8.flannel-vxlan-vethf38183ee-in.acp

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_Flannel_47

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_OverLay_48

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_VxLAN_49

calico通信架构及解析

calico通信架构

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_Flannel_50

calico通信过程解析

calico模式下会维护一个路由表，跨主机通信通过tunl0,本机通信则通过目的网卡，所有虚拟网卡地址都相同ee:ee...

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_VxLAN_51

#抓包过程参考上述flannel过程，这里不详细展开
源pod：
# kubectl  exec -it net-test2  bash #进入pod
[root@net-test2 /]# ifconfig 
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.200.218.62  netmask 255.255.255.255  broadcast 10.200.218.62
# ethtool  -S eth0 #源pod确认网卡对
NIC statistics:
     peer_ifindex: 8
     rx_queue_0_xdp_packets: 0
8: cali2b2e7c9e43e@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default 
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 3
root@k8s-node1:~# tcpdump -nn -vvv  -i cali2b2e7c9e43e  -vvv -nn ! port 22 and  ! port  2379 and ! port  6443 and ! port  10250 and ! arp and ! port  53

目的pod：
/# ifconfig 
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.200.151.205  netmask 255.255.255.255  broadcast 10.200.151.205
/# ethtool  -S eth0 #目的pod网卡对
NIC statistics:
     peer_ifindex: 16
     rx_queue_0_xdp_packets: 0

16: cali32ecf57bfbe@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default 
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 7
root@k8s-node2:~# tcpdump -nn -vvv  -i cali32ecf57bfbe  -vvv -nn ! port 22 and  ! port  2379 and ! port  6443 and ! port  10250 and !
calico模式抓包全过程图解
  • 源pod发起请求, 报文到达宿主机与pod对应的网卡
  • 源pod发起请求, 报文到达宿主机与pod对应的网卡,此时报文中源IP为pod的eth0 的ip,源mac 为pod的eth0的mac，目的IP为10.200.151.205，下一跳为网关地址169.254.1.1 ,目的mac为ee:ee:ee:ee:ee:ee(默认网关169.254.1.1的MAC地址)，源端口随机产生目的端口80
root@k8s-node1:~# tcpdump -nn -vvv  -i cali2b2e7c9e43e  -vvv -nn ! port 22 and  ! port  2379 and ! port  6443 and ! port  10250 and ! arp and ! port  53

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_VxLAN_52

  • 报文到达tunl0
  • 此时报文的源IP为源pod IP，目的IP为目的pod IP。没有MAC 地址
root@k8s-node1:~# tcpdump -nn -vvv  -i tunl0 -vvv -nn ! port 22 and  ! port  2379 and ! port  6443 and ! port  10250 and ! arp and ! port  53  -w 2-tunl0.acp

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_UnderLay_53

  • 报文到达源宿主机eth0
  • 此时报文为IPinIP格式，外层为源宿主机和目的宿主机的源MAC目的MAC、源IP及目的IP，内部为源pod IP及目的pod的IP，没有使用MAC地址。
root@k8s-node1:~# tcpdump -nn -vvv  -i  eth0  -vvv -nn ! port 22 and  ! port  2379 and ! port  6443 and ! port  10250 and ! arp and ! port  53  and ! port  2380 and ! host 172.31.7.101  -w 3.eth0.acp

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_VxLAN_54

  • 报文到达目的宿主机eth0
  • 报文到达目的宿主机eth0，此时收到的是源宿主机的IPinIP报文，外层为源宿主机和目的宿主机的源MAC目的MAC、源IP及目的IP，内部为源pod IP及目的pod的IP，没有使用MAC地址，解封装后发现是去往10.200.151.205.

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_UnderLay_55

  • 报文到达目的宿主机tunl0
  • 报文到达目的宿主机tunl0，此时源IP为源pod IP，目的IP为目的pod的IP，没有MAC地址。
root@k8s-node2:~# tcpdump -nn -vvv  -i  tunl0  -vvv -nn ! port 22 and  ! port  2379 and ! port  6443 and ! port  10250 and ! arp and ! port  53  and ! port  2380 and ! host 172.31.7.101  -w 5-tunl0.acp

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_UnderLay_56

  • 报文到达目的Pod与目的宿主机对应的网卡
  • 报文到达目的宿主机网卡。此时源IP为源Pod IP，源MCA为tunl0 MAC，目的IP为目的Pod IP，目的MAC为目的Pod MAC，随后报文被转发被目的MAC(目的Pod) 。
root@k8s-node2:~# tcpdump -nn -vvv  -i  cali32ecf57bfbe  -vvv -nn ! port 22 and  ! port  2379 and ! port  6443 and ! port  10250 and ! arp and ! port  53  and ! port  2380 and ! host 172.31.7.101  -w 6-cali32ecf57bfbe.acp

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_UnderLay_57

  • 报文到达目的Pod
  • 报文到达目的pod，目的pod接受请求并构建响应报文并原路返回给源pod。
nginx-deployment-58f6c4967b-x959s:/# tcpdump  -i eth0  -vvv -nn -w 7-dst-pod.acp

91-云原生操作系统-Kubernetes网络通信常见架构及案例解析_VxLAN_58

本章结束。

我是moore,大家一起加油！！！

标签：网络通信,Kubernetes,IP,报文,宿主机,MAC,91,pod,port
From： https://blog.51cto.com/mooreyxia/6215427

相关文章

  • P9118 [春季测试 2023] 幂次
    二诊前愉快的一次测试，关键是还有奶茶喝第二题，本来直接暴力去重枚举可以的六十分的，但是。。。。。。。花了30分钟优化剪纸，优化空间后，惨变35分。考场代码：#include<bits/stdc++.h>usingnamespacestd;unsignedlonglongn;intk,cnt=1;map<longlong,int>mp;intmain(){ ......
  • NSDI 24 | 截稿在即，网络通信领域顶级会议，九名国内学者入围程序委员会成员！
    USENIXNSDI（SymposiumonNetworkSystemDesignandImplementation）是网络通信领域顶级会议，涉及网络通信领域的各方面内容。NSDI是CCFA类，H5指数65，ImpactScore10.80，在全球范围内享有盛誉。与网络领域的另一顶级学术会议SIGCOMM相比，NSDI更加侧重于网络系统的设计与实现，注重系统......
  • k3s 基础 —— 配置 kubernetes dashboard
    安装请参考部署仪表盘GITHUB_URL=https://github.com/kubernetes/dashboard/releasesVERSION_KUBE_DASHBOARD=$(curl-w'%{url_effective}'-I-L-s-S${GITHUB_URL}/latest-o/dev/null|sed-e's|.*/||')sudok3skubectlcreate-fhttps://raw.githu......
  • Linux&&网络通信
    title:Linux&&网络通信一、进程（1）什么是进程？进程是程序执行的过程，是linux的基本调度单位。（2）进程和程序的区别。程序是静态的，它是一些保存在磁盘上的指令的有序集合；而进程是一个动态的概念，它是一个运行着的程序，包含了进程的动态创建、调度和消亡的过程。（3）进程间的通信方式......
  • PCF8591 AD/DA转换基于51
    #include<reg52.h>#include<intrins.h>//内部有_nop_();//IIC模拟时序实现//注意：SCL为高电平时变化SDA数据是起始或者终止信号；所以若不是起始或者终止信号，需要在SCL为低电平时变化SDA数据sbitSDA=P2^0;sbitSCL=P2^1;sbitLED=P2^3;sbitwei=P2^6;sbitdu......
  • 29、Pipeline Job进阶之部署应用至Kubernetes集群
    PipelineJob进阶之部署应用至Kubernetes集群在jenkins上的k8s云节点，在原来maven-and-docker模板的基础之上，添加容器也可以添加pod模板，通过继承的方式来实现maven-docker-kubectl方式来定义添加podtemplate添加容器：使用kubesphere/kubectl:latest镜像安装插件用于认证到k8s集群之......
  • k3s 基础 —— 配置 kubernetes-dashboard 的 token 过期时间
    拉取配置到本地：kubectlgetdeploykubernetes-dashboard-nkubernetes-dashboard-oyaml>dashboard-deploy.yaml增加参数：spec:containers:-args:---auto-generate-certificates---namespace=kubernetes-dashboard---to......
  • 快速部署Kubernetes 1.17：使用kubeadm轻松构建强大的容器编排平台
    在上一篇我们已经初步认识了Kubernetes，在本篇我们就开始着手搭建kubernetes，具体操作如下：1.环境准备(1).环境说明节点名称机器IP系统master10.2.3.191CentOS7.7node110.2.3.192CentOS7.7node210.2.3.190CentOS7.7(2).禁止swap（三台机器上都操作）swapoff-a#临时改配置文件/etc/f......
  • Kubernetes中使用Helm2的安全风险
    参考 http://rui0.cn/archives/1573英文文章 https://blog.ropnop.com/attacking-default-installs-of-helm-on-kubernetes/集群后渗透测试资源 https://blog.carnal0wnage.com/2019/01/kubernetes-master-post.htmlHelm介绍：Kubernetes是一个强大的容器调度系统，通常我们......
  • Ubuntu操作系统纯内网环境搭建ntp时钟同步服务器//京鸿通信/www.kyohoon.com/15507589
    一、环境准备   服务器：192.168.10.181（Ubuntu操作系统）   客户端：192.168.10.82 （Ubuntu操作系统）  所有服务器均不能访问互联网二、ntp服务器端操作：   (1).现在服务器端安装ntp服务器安装包，首先需要在172.16.20.129服务器上准备好ntp安装包。并进行安装ntp......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99