《深入剖析kubernetes》学习笔记（5）——容器网络

32. 单机容器网络

  • 一个完整网络栈包含的内容

    • 网卡、回环设备、路由表、iptables规则

  • 容器与外界通信，有两种可选的网络栈：

    • 启动容器时，用参数-net=host声明使用宿主机的网络栈【虽然简单，但容易端口冲突】
    • 使用自己Network Namespace里的网络栈，即有自己的IP地址和端口【推荐方式】

  • Docker容器通信的基本方式

    • Docker默认会在每一个宿主机上创建一个叫docker0的虚拟网桥
      • 网桥（Bridge）设备工作在数据链路层，根据MAC地址将数据包转发到网桥不同的端口上
    • 各容器通过一个叫做Veth Pair的设备连接到docker0上
      • Veth Pair表现为两张成对出现的虚拟网卡（Veth Peer），其中一张网卡发出的数据包，会直接出现在两一张上，即使它们不在同一个Network Namespace下
      • 在容器中用ifconfig命令可以看到一个叫eth0的网卡，就是Veth Pair的一端，另一端在docker0上
      • 可以简单地将Veth Pair理解为连接不同 Network Namespace 的“网线”
    • 数据包流向
      • 容器1---->docker0------>容器2

  • 被限制在 Network Namespace 里的容器进程，实际上是通过 Veth Pair 设备 + 宿主机网桥的方式，实现了跟同其他容器的数据交换。

  • Docker的默认配置下，一台宿主机上的docker0无法和另一台宿主机上的docker0互通，即若无额外配置，无法进行跨主机容器通信

33. 容器跨主机通信

  • Flannel项目的三种实现模式：UDP、VXLAN、host-gw

Flannel的UDP模式实现思路

  • Flannel在宿主机上创建一个第三层（网络层）虚拟网络设备，即一种Tunnel设备，也叫TUN设备，默认名称为flannel0，用来在操作系统内核和用户进程之间传递IP包

  • Flannel 管理的容器网络里，一台宿主机上的所有容器，都属于一个“子网”，例如Node 1 的子网是 100.96.1.0/24，Node 2 的子网是 100.96.2.0/24，子网和Node的对应关系保存在Etcd中，由此可以通过容器的IP地址获知其运行在哪个容器上

  • 消息流：

    容器A--->docker0---->flannel0--->flanneld进程加UDP封装--->源宿主机eth0网卡---->目的宿主机eth0网卡---->目的宿主机flanneld进程解封--->...

  • Flannel UDP可以看作是三层（网络层）的Overlay网络，因为跨主机的两个容器间可以用IP直接通信，无需关注容器和宿主机的分布。

  • 性能缺点：发送IP包过程，经历3次用户态与内核态之间的数据拷贝，开销太大。

    1> 容器A--->docker0

    2> flannel0--->flanneld进程 //问题所在，即UDP封装/解封操作在用户态的flanneld进程(port: 8285)中完成

    3> flanneld进程--->eth0

Flannel的VXLAN模式实现思路

  • VXLAN，Virtual Extensible LAN（虚拟可扩展局域网），本身就是Linux内核的一部分

  • Flannel在宿主机上创建VXLAN Tunnel End Point（虚拟隧道端点），也叫VTEP设备，名字叫flannel.1设备，用于封装/解封二层数据帧，工作在内核中完成

  • VXLAN设计思想：

    • 在现有三层网络上，覆盖一个虚拟的二层网络，使该二层网络上的虚拟机/容器，可以像在同一个LAN下自由通信。

  • 当新节点接入Flannel网络时，自动的在其他所有节点上添加：

    （1）本节点上的flannel.1的IP路由规则（包含了flannel.1的IP，及其负责接收报文的网段）

    （2）本节点上的flannel.1的mac地址

  • 消息流

    容器A的IP包--->docker0--->flannel.1（封装数据帧）--->eth0---->目的主机eth0--->....

  • flannel.1上完成的数据包封装操作（均在内核态完成）：

    • 1> 内部帧 = 【目的VTEP的MAC地址】【目的容器的IP地址】+源IP包
    • 2> 外部帧 = 【目的主机MAC地址】【目的主机IP地址】【UDP头】【VNI=1】+ 内部帧

  • 数据包封装时所需信息来源：

    • 目的主机MAC地址：由宿主机网络ARP协议维护，无需flannel参与
    • 目的主机IP地址的获取 ： flanneld进程维护flannel.1作为“网桥”设备的转发数据库(Forwarding Database, FDB)，包含了目的VTEP设备所在宿主机的IP地址
    • UDP头：flannel.1封装
    • VNI=1：是VTEP设备识别某数据帧是否归自己处理的重要标识

  • VXLAN相比UDP模式的优点：

    • VXLAN本身就是LINUX内核的一部分，数据帧的封装/解封操作可以在内核中完成，故只有源容器------>docker0这一次用户态到内核态的切换。

34.kubernetes网络模型和CNI插件

  • k8s通过CNI的接口，在每个node上维护了一个单独的网桥替代docker0，叫做CNI网桥，默认名称为cni0。K8S中的网络管理方式和上述的方式几乎没有区别，只是用cni0取代了docker0。
  • 用cni0取代docker0的原因：
    • 1>k8s没有也不愿意绑定docker的网络管理模型（CNM）
    • 2>k8s自身的pod有特殊的infra容器设计，pod创建时先启动infra容器，而后k8s调用cni插件为infra容器的network namespace设置符合预期的网络栈
  • Hairpin Mode(发夹模式)
    • 在默认情况下，网桥设备是不允许一个数据包从一个端口进来后，再从这个端口发出去的。但是，它允许你为这个端口开启 Hairpin Mode，从而取消这个限制。
    • 例如：从容器中访问宿主机8080端口，则IP包经过veth端口进入docker0, 进入宿主机，有要通过docker0的veth端口返回容器，此时要开启docker0的veth端口的发夹模式。
  • 部署 Kubernetes 的时候，有一个步骤是安装 kubernetes-cni 包，它的目的就是在宿主机上安装CNI 插件所需的基础可执行文件，位于宿主机的/opt/cni/bin/目录下

35. kubernetes三层网络方案

flannel的host-gw模式

  • 基本原理：

    • 将每个目的flannel子网的“下一跳”地址设置为该子网对应的宿主机的IP地址

  • 核心在于IP包封装成帧发送出去时，根据“下一跳”地址设置目的MAC地址，因此，host-gw模式必须要求宿主机之间二层联通。（由于一般部署环境下，宿主机都在同一个子网下，影响不大）

  • host-gw模式下宿主机自身充当了网关（gateway）的作用，这是"host-gw"名称的含义。

  • Flannel子网和主机信息，保存在etcd中，flanneld进程监听其变化，实时更新路由表即可。

Calico——另一个三层网络方案

  • Calico项目与flannel的host-gw模式基本原理完全一样，不同之处在于：

    • 1>flannel由flanneld进程通过etcd维护路由信息，但Calico采用边界网关协议（Border Gateway Protocal，BGP）在集群中分发、共享路由消息。
    • 2>flannel会在宿主机上使用cni网桥，而Calico没有cni网桥，而是为每个容器创建veth pair连接到宿主机上，并配备相应路由规则。

  • 若在Calico项目下，宿主机之间二层不连通，有两类解决方法：

    • 1>打开IPIP模式，宿主机上安装tunl0（IP隧道设备），从容器发出的IP包被封装进宿主机网络的IP包中，经路由器发出
    • 2>将宿主机的网关加入BGP Mesh，避免使用IPIP，两种方案
      • 1° 所有宿主机和其网关建立BGP Peer关系
      • 2° 使用一个或多个独立组件负责搜集整个集群里的所有路由信息，然后通过 BGP 协议同步给网关【推荐方案】

  • 三层方案和二层VXLAN方案的比较：

    • 相同点：
      • 目的都是为了容器跨主机的三层互通
    • 不同点：
      • 实现方式——三层网络通过配置路由规则中IP包的“下一跳”地址实现，二层方案在IP包外额外封装一层MAC包实现
      • 性能——三层网络没有封包拆包的过程，性能更高；二层性能差一些
      • 实现工作量——三层网络实现更复杂，需要想办法维护路由规则；二层网络实现更简单，主要工作在linux内核完成

36. kubernetes的网络隔离能力NetworkPolicy

  • Kubernetes 里的 Pod 默认都是“允许所有”（Accept All）的，即：Pod 可以接收来自任何发送方的请求；或者，向任何接收方发送请求。

  • 一旦 Pod 被 NetworkPolicy 选中，那么这个 Pod 就会进入“拒绝所有”（Deny All）的状态，即：这个 Pod 既不允许被外界访问，也不允许对外界发起访问。而 NetworkPolicy 定义的规则，其实就是“白名单”。

  • policyTypes 字段，定义了这个 NetworkPolicy 的类型

    • ingress 表示会影响流入（ingress）请求
    • egress表示会影响流出（egress）请求。

  • NetworkPolicy 实际上只是宿主机上的一系列 iptables 规则。

  • 注：job，cronjob这类计算型pod不需要也不应该对外提供服务，可以拒绝所有流入流量，提高系统安全。

  • K8S中仅有“弱多租户”（soft multi-tenancy）的能力

  • 一段NetworkPolicy实例

    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978
posted @ 2021-02-04 08:41  lwjj  阅读(609)  评论(0)  编辑  收藏  举报