12. Kubernetes网络概念和策略控制

墨蓝 2023-01-01 06:53 125阅读 0赞

> 本文由 CNCF + Alibaba 云原生技术公开课 整理而来

### Kubernetes 基本网络模型 ###

Kubernetes 的容器网络模型，就是Kubernetes 对一个容器网络是否合格做出了限制。可以把它归结为约法三章和四大目标：

约法三章：在评价容器网络或者设计容器网络时，它的准入条件。它需要满足哪三个条件才能认为它是一个合格的网络方案
    
    四大目标：在设计网络拓扑、设计网络的具体功能实现的时候，要去想清楚，能不能达成连通性等这几大指标

*  约法三章：

第一条：任意两个 Pod 之间其实是可以直接通信的，无需经过显式地使用 NAT 来接收数据和地址的转换；
    
    第二条：Node 与 Pod 之间是可以直接通信的，无需使用明显的地址转换；
    
    第三条：Pod 看到自己的 IP 跟别人看见它所用的IP是一样的，中间不能经过转换。

*  四大目标：

在设计一个 Kubernetes 的系统为外部提供服务的时候，要从网络的角度想清楚，外部如何一步一步连接到容器内部的应用？

外部和 Kubernetes 里面的 Service 之间是怎么通信的？外部用户怎么用到 Service？
    
    Service 如何与它后端的 Pod 通讯？
    
    Pod 和 Pod 之间调用是怎么做到通信的？
    
    Pod 内部的容器与容器之间如何通信？

最终要达到目标，就是外部可以连接到最里面，对容器提供服务。

*  基础约束：

对于基本约束，因为容器的网络发展复杂性就在于它其实是寄生在 Host 网络之上的。从这个角度讲，可以把容器网络方案大体分为 `Underlay/Overlay` 两大派别：

`Underlay` 的标准是它与 Host 网络是同层的，从外在可见的一个特征就是它是不是使用了 Host 网络同样的网段、输入输出基础设备、容器的 IP 地址是不是需要与 Host 网络取得协同（来自同一个中心分配或统一划分）。这就是 `Underlay`；

`Overlay` 不一样的地方就在于它并不需要从 Host 网络的 IPM 的管理的组件去申请IP，一般来说，它只需要跟 Host 网络不冲突，这个 IP 可以自由分配的。

Pod 容器网络中的核心就是 IP，IP 就是每个 Pod 对外通讯的地址基础，必须内外一致，符合 Kubernetes 的模型特征。

--------------------

### Network Namespace ###

Network Namespace 是实现网络虚拟化的内核基础，创建了隔离的网络空间：

独立的附属网络设备
    
    独立的协议栈，IP 地址和路由表
    
    iptables 规则
    
    ipvs 等

狭义上来说，`runC` 容器技术是不依赖于任何硬件的，它的执行基础就是它的内核里面，进程的内核代表就是 task，它如果不需要隔离，那么用的是主机的空间（ namespace），并不需要特别设置的空间隔离数据结构（ nsproxy-namespace proxy）。相反，如果一个独立的网络 proxy 或者 mount proxy，里面就要填上真正的私有数据。

一个隔离的网络空间，它会拥有自己的网卡或者网络设备。网卡可能是虚拟的，也可能是物理网卡，它会拥有自己的 IP 地址、IP 表和路由表、拥有自己的协议栈状态。这里面特指就是 TCP/IP 协议栈，它会有自己的 status，会有自己的 iptables、ipvs。

从整个感官上来讲，这就相当于拥有了一个完全独立的网络，它与主机网络是隔离的。当然协议栈的代码还是公用的，只是数据结构并不相同。

每个 Pod 都有着独立的网络空间，`Pod Net Container` 会共享这个网络空间。一般 Kubernetes 会推荐选用 Loopback 接口，在 `Pod Net Container` 之间进行通信，而所有的 `Container` 通过 `Pod` 的 IP 对外提供服务。另外对于宿主机上的 `Root Network Namespace`，可以把它看做一个特殊的网络空间，只不过它的 pid 是1。

--------------------

### 主流网络方案 ###

*  容器网络实现方案：

容器网络方案可能是 Kubernetes 里最为百花齐放的一个领域，它有着各种各样的实现。容器网络的复杂性，其实在于它需要跟底层 Iass 层的网络做协调、需要在性能跟 IP 分配的灵活性上做一些选择，这个方案是多种多样的。

Flannel         最为普遍的实现，提供多种网络 backend 实现，覆盖多种场景
    
    Calico          采用 BGP 提供网络直连，功能丰富，对底层网络有要求
    
    Canal           Flannel for network + Calico for firewalling
    
    Cilium          基于 eBPF 和 XDP 的高性能 Overlay 网络方案
    
    Kube-router     采用 BGP 提供网络直连，集成基于 LVS 的负载均衡能力
    
    Romana          采用 BGP 或 OSPF 提供网络直连
    
    WeaveNet        采用 UDP 封装实现 L2 Overlay，支持用户态（慢、可加密）/内核态（快、不可加密）两种实现

Flannel 是一个比较大一统的方案，它提供了多种的网络 backend。不同的 backend 实现了不同的拓扑，它可以覆盖多种场景；

Calico 主要是采用了策略路由，节点之间采用 BGP 的协议，去进行路由的同步。它的特点是功能比较丰富，尤其是对 Network Point 支持比较好，Calico 对底层网络一般是要求 mac 地址能够直通，不能跨二层域；

最后是 WeaveNet，如果大家在使用中需要对数据做一些加密，可以选择用 WeaveNet，它的动态方案可以实现比较好的加密。

*  Flannel 方案：

Flannel 是目前使用最为普遍的方案，它首先要解决的是 `Container` 的包如何到达 Host，这里采用的是加一个 Bridge 的方式。数据包如何离开 Host，是采用那种封装方式，还是不需要封装，都是可以选择的。

通过将 backend 机制独立，它目前已经支持多种数据路径，也可以适用于 `Underlay/Overlay` 等多种场景，主要的 backend 有 3 种：

1. 用户态 udp（纯用户态实现）
    
    2. 内核 Vxlan（性能好），需要内核支持 Vxlan 的特性功能
    
    3. 如果集群规模不大且处于同一个二层域，也可以选择 host-gw 方式

--------------------

### NetworkPolicy ###

*  基本概念：

`NetworkPolicy` 提供了基于策略的网络控制，用于隔离应用并减少攻击面。它使用标签选择器模拟传统的分段网络，并通过策略控制它们之间的流量以及来自外部的流量。

它采用各种选择器（`Label` 或 `Namespace`），找到一组 `Pod`，或者找到相当于通讯的两端，然后通过流的特征描述来决定它们之间是不是可以连通，可以理解为一个白名单的机制。

在使用 `NetworkPolicy` 之前，需要注意：

ApiServer 开启 extensions/v1beta1/networkpolicies
    
    网络插件要支持 Network Policy，如 Calico、Romana、Weave Net 和 trireme 等

*  配置实例：

`NetworkPolicy` 的功能就是通过使用标签选择器（包括 `namespaceSelector` 和 `podSelector`）来控制 `Pod` 之间的流量。

在设计一个 `NetworkPolicy` 时需要决定三件事：

控制对象：通过 spec 字段下 podSelector、namespaceSelector等条件筛选
    
    流方向：Ingress（入 Pod 流量）+ from，Egress（出 Pod 流量）+ to
    
    流特征：对端（podSelector、namespaceSelector），IP段（ipBlock），协议（protocol），端口（port）

test-network-policy `NetworkPolicy` yaml 文件示例：

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

文件解析：

apiVersion: networking.k8s.io/v1     表示 NetworkPolicy 当前所属的组是 networking.k8s.io，版本是 v1
    
    kind        表示 Kubernetes 资源类型是 NetworkPolicy
    
    metadata    表示 NetworkPolicy 的元数据，元数据通常包含 name、namespace、labels、annotations 等
    
    spec    表示 NetworkPolicy 的期望状态，.spec.podSelector 表示 NetworkPolicy 期望匹配的 Pod；.spec.policyTypes 表示 NetworkPolicy 的策略类型；
            .spec.ingress 表示匹配 Pod 入流量；.spec.egress 表示 表示匹配 Pod 出流量

--------------------