与容器服务 ACK 发行版的深度对话第二弹：如何借助 hybridnet 构建混合云统一网络平面

简介：本次采访我将继续为大家详细讲解我的好伙伴：阿里巴巴的开源 Kubernetes 容器网络解决方案 hybridnet，以及我是如何借助它来构建混合云统一网络平面。

作者：若禾、昱晟、瑜佳

记者：各位阿里巴巴云原生的读者朋友们大家好，欢迎再次来到探究身世之谜系列专访栏目，今天邀请来的还是大家的老朋友，『阿里云容器服务 ACK 发行版』，上次的访谈中它为我们介绍了阿里巴巴开源集群镜像技术 sealer，以及它们是如何相互配合来达成阿里云 ACK 服务的快速稳定交付。错过的读者不要忘记去回顾一下哦~那么这次做客，它又会为我们介绍哪位小伙伴呢？

阿里云容器服务 ACK 发行版（简称 ACK Distro）：大家好，我们又见面了！相信经过上次的自我介绍，你们对我已经有了大概的了解，这次就不多赘述了。本次采访我将继续为大家详细讲解我的好伙伴：阿里巴巴的开源 Kubernetes 容器网络解决方案 hybridnet，以及我是如何借助它来构建混合云统一网络平面。

记者：好的，那您请先谈一下 hybridnet 是什么以及项目组成员是出于怎样的设计理念才诞生了 hybridnet。

hybridnet 的定义及其设计理念

ACK Distro：好的，首先 hybridnet 是阿里巴巴开源的一款面向混合云场景的 Kubernetes 容器网络解决方案。它可以帮助用户在物理机和虚拟机的异构环境之上，构建一层 underlay + overlay 的统一网络平面，并提供丰富的管控运维能力。同时为混合云场景下集群部署和应用交付过程中出现的容器网络部署及运维问题，提出了一种全新的解决思路。

它的基本设计准则是:

为了确定统一网络模型，降低认知与维护成本，并且保证稳定的长期演进
屏蔽底层异构基础设施，提升交付落地鲁棒性，降低生产交付、PoC 成本
在统一模型的约束下，既能提供 underlay 高性能直通网络方案，来满足网络打通和性能的双重需求，又能支持在某些性能不敏感的场景下提供 overlay 虚拟网络方案
尽量降低对于外部环境的依赖，保证数据面的简单
与 Kubernetes 深度集成，提供双栈、IP 保持、IP 固定等高阶 IPAM 能力，保证用户上云后使用习惯不变

不同于与单一 IaaS 厂商的公有云或专有云底座绑定输出的 terway、aws-cni 等容器网络方案，项目组成员希望 hybridnet 能够解决多云混合云场景下异构底座带来的一致性和适配性难题，在不同的基础网络环境上提供敏捷、通用和稳定的交付能力，并且通过统一视角的模型约束和运维管控，解决复杂场景下的网络规划、管理及运维等问题。

记者：那我是不是可以这么理解，hybridnet 力求做到“underlay/overlay 混合部署” 和“underlay/overlay 统一管理运维”。

ACK Distro：是的没错，hybridnet 也确实做到了。我可以再拓展描述下，在一个使用了 hybridnet 的 Kubernetes 集群中，同一个节点上可以同时有 underlay 和 overlay的 Pod，所有 Pod 之间的集群内部访问行为完全一致不需要任何额外感知。这样，用户可以在“纯 overlay 集群”、“纯 underlay 集群”、“underlay 混合集群” 之间进行自由选择和转化，同时享受 underlay 网络带来的高性能和网络直通能力，以及 overlay 网络的资源无限和高适配性。而且在统一模型的约束下，underlay 网络和 overlay 网络在管理、运维上也保持了概念一致。

记者：除了它的设计理念，您可以用更直观的方法让读者明白 hybridnet 可以做什么吗？

ACK Distro：当然，我从介绍它的核心模型入手阐释其功能属性吧~为了使 hybridnet 的使用者可以通过初始化不同的核心模型来对基础网络环境进行灵活多样地描述，让容器网络以不同的形态运行，项目组成员通过对经典网络中的概念进行抽象，引入了下面三个核心 CRD 模型来对网络资源进行抽象和管理。

hybridnet 的核心模型

Network

在 hybridnet 中，每个 Network 表示一个“调度域“，一个调度域表示一组具有相同网络性质的节点，Network 是环境拓扑信息传入的主要入口。一个特定的 IP 可以在其所属调度域内的各个节点间自由迁移。

Network 通过 nodeSelector 与节点相关联，对于一些特殊的 Network，比如 overlay 的 Network，nodeSelector 可能为空，这种 Network 的调度域为集群内的所有节点。

Subnet

在 hybridnet 中，Subnet 表示一个调度域内可以分配的 IP 资源，Subnet 是环境网络 IP 资源规划信息传入的主要入口。每个 Subnet 必须属于一个 Network。Subnet 具有比较灵活的属性：

支持 cidr 可分配地址范围的选择，通过 spec.range.start 和 spec.range.end 可以从一个 cidr 中再精确地划分出一个小的网段
支持保留离散的 IP 地址不分配，当网段中已经有 IP 地址被使用了的时候，可以通过将已经被使用了的 IP 填写入 spec.range.excludeIPs 的数组字段，hybridnet 将不会再将这些 IP 分配给 Pod
支持保留指定的 IP 不被使用，当网段中需要保留某些 Pod 的 IP，仅被特定的 Pod 指定使用时，可以通过将这些 IP 填写入 spec.range.reservedPs 的数组字段，hybridnet 将不会再把这些 IP 用于非指定 IP 的分配

IPInstance

IPInstance 目前只用作监控，每个 IPInstance 代表一个实际已经被分配出容器网络的 IP。能够通过 kubectl get IPInstance 看到其对应的 Pod、所属 Subnet、Pod 对应的节点等等信息。

记者：那么 hybridnet 的优势如何在您身上体现呢？换句话说，您怎样管理 hybridnet 以达到最佳实践呢？

如何在 ACK Distro 中管理 hybridnet

ACK Distro：我通过操作上述的 CRD 模型来为大家进行网络管理操作示例吧~
其中，hybridnet 会作为我唯一内置的网络插件部署。（当然啦，通过 sealer 的能力，自定义第三方的网络插件也是可行的，大家可以参考本系列第一篇文章。）

默认行为

作为我的固定行为，初始化一定会存在一个 overlay 的 Network，并且此时默认网络类型是 overlay，通过下面命令可以查看此时的 Network 和 Subnet 信息：

[root@iZf8zdygpbo4hx57g2wahaZ ~]# kubectl get network
NAME        NETID   SWITCHID
network-0   4       virtual-switch
[root@iZf8zdygpbo4hx57g2wahaZ ~]# kubectl get subnet
NAME                 VERSION   CIDR            START   END   GATEWAY      TOTAL   USED   AVAILABLE   NETID   NETWORK
subnet-0-network-0   4         100.64.0.0/16                 100.64.0.1   65533   2      65531               network-0

大家可以看到，用默认配置初始化的我会创建一个名叫 network-0 的 Network 和 subnet-0-network-0 的 Subnet，容器网段的 CIDR 为 100.64.0.0/16，此时新创建的 Pod 都会以 overlay 的方式拉起。

因为我的基础组件本身没有特别的网络诉求，这样最大的好处是，overlay 网络帮助我屏蔽了底层基础网络设施，换言之，我可以借助 hybridnet 以相同的配置在任何网络环境中一键拉起，同时并不影响后续网络扩展的可能性。

从混合云环境的交付经验来看，这种方式能将网络规划（主要是 underlay 网络）延后到“运维”的阶段，可以最小化“交付”阶段的落地成本，提升部署效率。

添加 underlay 网络

如果存在部分 underlay 网络诉求（比如出于“overlay 性能瓶颈” 或者 “Pod IP 对外直接透出能力”的考虑），underlay Pod 占比较少，特别是您不希望占用基础网络环境中的 IP 资源时，可以选择在默认行为创建的 overlay Network 之外，额外添加一个 underlay 的 Network 以及对应的 Subnet。（新旧 overlay/underlay Network 在模型上没有任何依赖顺序关系）

在这次示例的实验环境中，节点网段为 192.168.56.0/24（所有节点在一个经典二层网络中），因为节点 IP 只用了 192.168.56.1、192.168.56.2、192.168.56.3、192.168.56.4，我们考虑将未被使用的 192.168.56.100～192.168.56.150 地址范围留给容器使用，搭建一个最简单的 underlay 网络。这种情况我们只需要应用如下 yaml：

---
apiVersion: networking.alibaba.com/v1
kind: Network
metadata:name: underlay-network1
spec:netID: 0nodeSelector:network: network1type: Underlay---
apiVersion: networking.alibaba.com/v1
kind: Subnet
metadata:name: underlay-subnet1
spec:network: underlay-network1netID: 0range:version: "4"cidr: "192.168.56.0/24"gateway: "192.168.56.254"start: "192.168.56.100"end: "192.168.56.150"

因为 Network 通过 nodeSelector 关联 Node，我们需要给想要部署 underlay Pod 的节点打上对应 Network nodeSelector 的标签，这里我们只希望在节点 izf8zdygpbo4hx57g2wah8z 上有 underlay 类型的 Pod：

kubectl label node izf8zdygpbo4hx57g2wah8z network=network1

此时默认网络类型仍然是 overlay 网络，创建 underlay 的 Pod 只需要简单通过给 Pod 添加 networking.alibaba.com/network-type: Underlay 的 annotation 指定。效果如图：

[root@iZf8zdygpbo4hx57g2wahaZ ~]# kubectl get po -owide -n test
NAME                                 READY   STATUS    RESTARTS   AGE     IP               NODE                      NOMINATED NODE   READINESS GATES
curl-deployment-1-5cfb5dcb8c-65fr7   1/1     Running   0          11m     100.64.0.29      izf8zdygpbo4hx57g2wahbz   <none>           <none>
curl-deployment-1-5cfb5dcb8c-hp626   1/1     Running   0          11m     100.64.0.26      izf8zdygpbo4hx57g2wahbz   <none>           <none>
curl-deployment-1-5cfb5dcb8c-qbr6w   1/1     Running   0          11m     100.64.0.27      izf8zdygpbo4hx57g2wah7z   <none>           <none>
curl-deployment-1-5cfb5dcb8c-zclv2   1/1     Running   0          11m     100.64.0.31      izf8zdygpbo4hx57g2wahbz   <none>           <none>
curl-deployment-1-5cfb5dcb8c-zfqkp   1/1     Running   0          11m     100.64.0.28      izf8zdygpbo4hx57g2wah7z   <none>           <none>
curl-ss-0                            1/1     Running   0          6m24s   192.168.56.140   izf8zdygpbo4hx57g2wah8z   <none>           <none>
curl-ss-1                            1/1     Running   0          6m5s    192.168.56.141   izf8zdygpbo4hx57g2wah8z   <none>           <none>
curl-ss-2                            1/1     Running   0          6m1s    192.168.56.142   izf8zdygpbo4hx57g2wah8z   <none>           <none>

修改默认网络类型为 underlay

如果您 underlay 的网络诉求占绝大多数，希望默认创建出来的就是 overlay 的 Pod，也可以修改默认网络类型为 underlay，修改完之后，默认会以 underlay 的网络创建 Pod，并且仍然可以通过给 Pod 添加 annotation 的方式指定 Pod 以 overlay 的网络被创建。已经创建的 overlay Pod 不会受到影响。

修改默认网络类型需要分别 kubectl edit deploy hybridnet-webhook -n kube-system 和 kubectl edit deploy hybridnet-manager -n kube-system，修改容器启动的 DEFAULT_NETWORK_TYPE 环境变量为 Underlay：

spec:containers:- name: hybridnet-[manager|webhook]           command:- /hybridnet/hybridnet-[manager|webhook]env:- name: DEFAULT_NETWORK_TYPE# "Overlay" or "Underlay", # default "Underlay" if environment variable not configured. value: Underlay

这样修改完之后，Pod 将会默认以 underlay 的方式被创建，新的 underlay Pod 与原有 overlay Pod 的网络连通性不受影响（简单来说，相当于 underlay Pod 会有一个与其他 overlay Pod 通信的 overlay 的身份）。