基于 F5 和 Cilium 的 Kubernetes 集群网络架构设计-技术圈

Kubernetes 的重要性和火爆程度已无需多言，但各公司风格迥异的 IT 基础环境必然催生出各式各样的 Kubernetes 集群架构方案，这对整个生态的发展未尝不是一件好事。今天我们主要聊聊网络，集群网络系统是 Kubernetes 的核心部分，得益于 Kubernetes 灵活的接口设计，现在已有许多成熟方案和使用案例，比如 Calico，Flannel，Kube-router等。

Cilium 是一款为大规模和高度动态的容器环境而设计，基于 eBPF 的灵活、高性能网络插件，相比更流行的 Calico 和 Flannel，Cilium 出现的时间相对较晚，大规模应用案例也比前两者少。但是，由于 Cilium 基于 eBPF 和 XDP 设计，其处理数据包的速度更快，配置灵活度也更高。具体可查看 https://cilium.io/blog/2020/11/10/ebpf-future-of-networking/

在传统数据中心网络中，F5（本文特指 F5 BIG-IP LTM 设备）是非常重要的网络设备，其优秀的性能和超高的稳定性可以很好的保证服务质量（当然也很贵）。近几年，云原生发展迅速，原来主要为传统数据中心服务的 F5 公司也是紧跟时代脚步，推出了 F5 BIP-IP 云版本，还收购了软件负载均衡的大哥 Nginx，当然还有本文要介绍的 F5 Container Ingress Services（CIS)。

接下来就具体介绍下如何基于 F5 和 Cilium 构建 Kubernetes 集群网络系统（适合对 F5 有一定了解的朋友阅读）。

Cilium

无论有没有 F5, Cilium 都可以作为 CNI 插件部署到 Kubernetes 集群中。Cilium 支持 Overlay 和 Native Routing 两种网络模型：Overlay 基于 VXLAN 或者 Geneve 格式的封装，这种模式对网络基础设施的要求最低，只需要节点之间可以相互通信即可，Native Routing 支持 Cilium 节点通过 BIRD 运行 BGP 路由协议，将 Pod 的 IP 网段宣告到数据中心网络中。为了与 F5 直接通信，这里我们选择 Native Routing 模型。

网络接口

Cilium 会在主机网络空间创建三个虚拟接口：cilium_host，cilium_net 和 cilium_vxlan。cilium agent 在启动时会创建一个名为 "cilium_host -- cilium_net" 的虚拟链接对，并将 CIDR 的第一个 IP 地址分配给 cilium_host，之后该节点上的 Pod 都以 cilium_host 的地址作为网关。创建 Pod 时，在主机网络空间上创建带有 "lxc-xx" 的 veth 接口，另一端连接到 Pod 名称空间，cilium agent 安装所需的 BPF 程序以回复 ARP 请求，lxc-xx 接口的 MAC 地址用于 ARP 应答。Pod 生成的流量的下一个 L3 跳是cilium_host，而 Pod 生成的流量的下一个 L2 跳是 veth 对的主机端，cilium_vxlan 接口用于跨节点的 Pod 间的通信，cilium 使用 BPF 进行 LWT（轻型隧道）封装，将Pod跨节点通信的所有网络数据包都封装在标头中，该标头可以由 VXLAN 或 Geneve 帧组成，并通过标准 UDP 数据包标头进行传输。如果想要禁用 vxlan，在 helm 部署 cilium 时加上--set global.tunnel=disabled参数即可。

部署命令

helm install cilium cilium/cilium --version 1.8.4 \
--namespace kube-system \
--set config.ipam=kubernetes \
--set native-routing-cidr= \
--set global.ipMasqAgent.enabled=true \
--set global.kubeProxyReplacement=strict \
--set global.k8sServiceHost= \
--set global.k8sServicePort=6443

参数说明：

config.ipam=kubernetes：使用 kubeadm 定义的 Pod 和 Service 网段
native-routing-cidr=：指定不做 Masquerade 的网段
global.ipMasqAgent.enabled=true：可以通过配置 ConfigMap 动态更改 Cilium 的 Masquerade 策略
global.k8sServiceHost：指定API Server 的 IP ，在禁用 kube-proxy 的情况下显式指定
global.k8sServicePort：指定API Server的端口
global.kubeProxyReplacement=strict：在缺少底层 Linux 内核支持的情况下，cilium agent 将会退出，而不会使用 kube-proxy 来代替

这里详细介绍下 Cilium Masquerade 策略。

默认情况下，Pod 发往集群外的流量（不管是 Pod 主动发起的，还是集群外部主动发起的流量）都会通过 Cilium 进行地址伪装（Masquerade)，将 Pod 地址转换为节点地址，而想要让 F5 直接发送流量给 Pod，则需要设置 Cilium 转发给 F5 SNAT Pool、相关的核心交换机和 F5 健康检查地址的流量不使用地址伪装。

使用 agent-config/config 文件配置与native-routing-cidr作用相同:

nonMasqueradeCIDRs:
# LinkLocal地址
- 
#F5 SNAT Pool地址
-
#核心交换机地址
-
# F5健康检查地址
-
masqLinkLocal: false

BIRD 配置

Bird 是一个类 UNIX 系统的动态路由守护进程，它支持当代互联网中所有路由协议，如 BGP、OSPF、RIP 等。在集群所有节点以守护进程形式部署 BIRD 动态路由软件，使用 BIRD 和核心交换机建立 BGP 全互联邻居，从而将 Pod 的 IP 网段的路由宣告给核心交换机，F5通过核心交换机学到 Pod 网段的路由，从而可以将流量直接转发给 Pod，达到了流量分发的目的。

BIRD 配置：

log syslog all;

router id <节点IP>;

protocol device {
        scan time 10;           # Scan interfaces every 10 seconds
}

# Disable automatically generating direct routes to all network interfaces.
protocol direct {
        disabled;               # Disable by default
}

# Forbid synchronizing BIRD routing tables with the OS kernel.
protocol kernel {
        ipv4 {                    # Connect protocol to IPv4 table by channel
                import none;      # Import to table, default is import all
                export none;      # Export to protocol. default is export none
        };
}

# Static IPv4 routes.
protocol static {
      ipv4;
      route  via "cilium_host"; 
}

# BGP peers
protocol bgp uplink0 {
      description "BGP uplink 0";
      local <节点IP> as ;
      neighbor <核心交换机IP> as ;
      ipv4 {
              import filter {reject;};
              export filter {accept;};
      };
}

protocol bgp uplink1 {
      description "BGP uplink 1";
      local <节点IP> as ;
      neighbor <核心交换机IP> as ;
      ipv4 {
              import filter {reject;};
              export filter {accept;};
      };
}

核心交换机配置：

核心交换机和每个节点建立全互联BGP邻居

router bgp 
  neighbor <节点IP> remote-as 
    update-source loopback0
    address-family ipv4 unicast
.....

正常情况下交换机可以学到Pod网段的路由

# show ip route bgp 
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%' in via output denotes VRF 

23.3.0.0/24, ubest/mbest: 1/0
    *via 11.8.38.43, [200/0], 3w4d, bgp-64512, internal, tag 64512, 
23.3.1.0/24, ubest/mbest: 1/0
    *via 11.8.37.57, [200/0], 3w4d, bgp-64512, internal, tag 64512, 
23.3.2.0/24, ubest/mbest: 1/0
    *via 11.8.36.66, [200/0], 3w4d, bgp-64512, internal, tag 64512, 
23.3.3.0/24, ubest/mbest: 1/0
    *via 11.8.83.11, [200/0], 3w4d, bgp-64512, internal, tag 64512, 
23.3.4.0/24, ubest/mbest: 1/0
    *via 11.8.84.13, [200/0], 3w4d, bgp-64512, internal, tag 64512, 
23.3.5.0/24, ubest/mbest: 1/0
    *via 11.8.84.12, [200/0], 3w4d, bgp-64512, internal, tag 64512,

F5 BIG-IP Container Ingress Services(CIS)

对于有外部访问的服务，需要在 Kubernetes 集群中以 Deployment 形式部署 F5 官方提供的插件 k8s-bigip-ctlr 作为 F5 在集群中的 agent。CIS 作为一个重要控制平面，监控着 API Server 并根据配置信息自动的配置 F5 BIG-IP，CIS 以 Pod 的方式运行在集群环境中，完美地融合进集群网络，让F5 Service 类似一个原生的 Kubernetes Service 监控着 Pod 资源并对外提供服务。

BIG-IP Controller Modes

--pool-member-type选项决定了 CIS 运行的模式，有两种模式可选：NodePort 和 Cluster。

NodePort 模式是 CIS 默认运行的模式，该模式更容易设置，只需要 BIG-IP 与集群节点能够通信即可，但是该模式有几点限制：

Kubernetes Service 必须使用 NodePort 模式
F5 BIG-IP 无法对隐藏在 Service 后的 Pod 做感知和健康检查
增加网络延迟

由此我们选择了 CIS 的 Cluster 模式，让 F5 BIG-IP 可以直接对 Pod 做健康检查和流量转发，使用Cluster 模式的前提是需要打通 BIG-IP 到集群中 Pod 的通信。

默认情况下，CIS 使用 BIG-IP Automap SNAT 为所有通过 CIS 创建的 Virtual Service 做客户端的源地址转换，通过--vs-snat-pool-name=K8S-SNAT-POOL为 K8S 集群单独指定 SNAT POOL。

CIS 部署

部署之前在 F5 BIG-IP 上为 K8S 集群新建一个名为 K8S 的 partition，通过 PodAntiAffinity 将主备两台 F5 BIG-IP 对应的 F5 CIS 调度到不同的节点中，使用 SNAT-vlan130 地址池中的地址作为负载均衡时 F5 SNAT 的地址。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: k8s-bigip-ctlr-standby-clusterip
  namespace: kube-system
spec:
  # DO NOT INCREASE REPLICA COUNT
  replicas: 1
  selector:
    matchLabels:
      app: k8s-bigip-ctlr-standby
  template:
    metadata:
      name: k8s-bigip-ctlr-standby
      labels:
        app: k8s-bigip-ctlr-standby
    spec:
      affinity:
          PodAntiAffinity:
             preferredDuringSchedulingIgnoredDuringExecution:
             - weight: 1
               PodAffinityTerm:
                 labelSelector:
                     matchExpressions:
                      - key: app
                        operator: In
                        values:
                        - k8s-bigip-ctlr-active
                 topologyKey: "kubernetes.io/hostname"
      # Name of the Service Account bound to a Cluster Role with the required
      # permissions
      serviceAccountName: bigip-ctlr
      containers:
        - name: k8s-bigip-ctlr-standby
          image: f5networks/k8s-bigip-ctlr:latest
          env:
            - name: BIGIP_USERNAME
              value: F5 BIG-IP用户名
            - name: BIGIP_PASSWORD
              value: F5 BIG-IP密码
          command: ["/app/bin/k8s-bigip-ctlr"]
          args: [
            # See the k8s-bigip-ctlr documentation for information about
            # all config options
            # https://clouddocs.f5.com/products/connectors/k8s-bigip-ctrl/latest
            "--bigip-username=F5 BIG-IP用户名",
            "--bigip-password=F5 BIG-IP密码",
            "--bigip-url=F5地址",
            "--bigip-partition=K8S",
            "--pool-member-type=cluster",
            "--insecure=true",
            "--vs-snat-pool-name=SNAT-vlan130"
            ]

服务暴露

CIS 可以关联 K8S 原生的 Service ，通过 ConfigMap（L4）或者 Ingress（L7）对 Pod 的服务暴露提供配置。

ConfigMap（L4）

配置 Configmap 资源，关联 Service，做4层服务发布，可以指定相应的健康检查规则和负载均衡方法。

kind: ConfigMap
apiVersion: v1
metadata:
  name: sugar-cmdb-v2-vs
  labels:
    f5type: virtual-server
data:
  schema: "f5schemadb://bigip-virtual-server_v0.1.7.json"
  data: |
    {
      "virtualServer": {
        "backend": {
          "servicePort": 80,
          "serviceName": "myservice",
          "healthMonitors": [{
            "interval": 5,
            "protocol": "http",
            "send": "GET /health.html HTTP/1.1\r\nHost:1.1.1.1\r\n\r\n",
            "recv": "server is ok",
            "timeout": 16
          }]
        },
        "frontend": {
          "virtualAddress": {
            "port": 80,
            "bindAddr": ""
          },
          "partition": "K8S",
          "balance": "least-connections-member",
          "mode": "http"
        }
      }
    }

CIS 关联到 Service 后端的 Pod 信息，并在 F5 上创建了一个 Pool，并且使用了我们配置的 Least-Connections 负载均衡算法。

并且为 Pool member 关联了相应的健康检查规则。

最后根据我们分配的IP和端口号创建出对应的 Virtual Service。

Ingress（L7）

配置 Ingress 资源，关联2个 Service，做7层的服务发布，基于访问域名转发给不同 Service 下的 Pod。

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: nginx-l7-domain-ingress
  namespace: default
  annotations:
    virtual-server.f5.com/ip: "" 
    virtual-server.f5.com/http-port: "80" 
    virtual-server.f5.com/partition: "Cilium" 
    virtual-server.f5.com/balance: "round-robin" 
    virtual-server.f5.com/health: | 
      [
        {
          "path":     "mysite1.example.com/",
          "send":     "HTTP GET /",
          "interval": 5,
          "timeout":  10
        }, {
          "path":     "mysite2.example.com/",
          "send":     "HTTP GET /",
          "interval": 5,
          "timeout":  10
        }
      ]
spec:
  rules:
  - host: mysite1.example.com
    http:
      paths:
      - path: /
        backend:
          serviceName: nginx
          servicePort: 80
  - host: mysite2.example.com
    http:
      paths:
      - path: /
        backend:
          serviceName: tomcat
          servicePort: 80

CIS 会根据 Ingress 规则在 F5 上创建一个 Virtual Service 并且关联一条 Published Policy。

F5 动态感知容器服务变化

通过部署在 K8S 集群内的 F5 CIS 动态感知容器服务的变化，解析服务的创建以及销毁事件，动态更新 F5 配置，实现服务自动发现，动态感知能力，以此来支持应用弹性伸缩能力。这部分就留给大家自己验证吧。

参考文献

Cilium Doc: Using BIRD to run BGP
Cilium Doc: Masquerading
民生银行：基于 F5 技术实现 Kubernetes 生产环境最佳实践
F5 Doc:Using the BIG-IP Controller as an Ingress controller
F5 Doc:Manage your BIG-IP virtual servers
最Cool Kubernetes网络方案Cilium入门

点击屏末 | 阅读原文 | 即刻学习