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

40次阅读

共计 6540 个字符，预计需要花费 17 分钟才能阅读完成。

作者：若禾、昱晟、瑜佳

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

阿里云容器服务 ACK 发行版（简称 ACK Distro）：大家好，咱们又见面了！置信通过上次的自我介绍，你们对我曾经有了大略的理解，这次就不多赘述了。本次采访我将持续为大家具体解说我的好搭档：阿里巴巴的开源 Kubernetes 容器网络解决方案 hybridnet，以及我是如何借助它来构建混合云对立网络立体。

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

hybridnet 的定义及其设计理念

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

它的根本设计准则是:

  1. 为了确定对立网络模型，升高认知与保护老本，并且保障稳固的长期演进
  2. 屏蔽底层异构基础设施，晋升交付落地鲁棒性，降低生产交付、PoC 老本
  3. 在对立模型的束缚下，既能提供 underlay 高性能直通网络计划，来满足网络买通和性能的双重需要，又能反对在某些性能不敏感的场景下提供 overlay 虚构网络计划
  4. 尽量升高对于外部环境的依赖，保证数据面的简略
  5. 与 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: 0
  nodeSelector:
    network: network1
  type: Underlay

---
apiVersion: networking.alibaba.com/v1
kind: Subnet
metadata:
  name: underlay-subnet1
spec:
  network: underlay-network1
  netID: 0
  range:
    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 的身份）。**

增加 / 删除网络资源

就如同下面示例中展现的，增加 Network/Subnet 的网络资源只须要利用对应 CR 的 yaml 即可，一旦 Network/Subnet 被利用，hybridnet 会认为环境中曾经实现根底网络配置，并且应用对应 CR 进行网络资源调配。

出于平安角度思考，删除 Network/Subnet 的操作是有根本束缚的。只有当 Subnet 中没有 IP 在被应用时，Subnet 自身能力被删除；同理，只用先删除 Network 中的所有 Subnet，Network 自身能力被删除。

ACK Distro：总而言之，借助 hybridnet，我能够使阿里云容器服务 ACK 在异构环境之上，构建一层 underlay + overlay 的对立网络立体，进步管控运维能力，为宽广的开发者带来更好的容器服务体验。

记者： 好的，非常感谢您这次的仔细解说，第二弹深度访谈到这里又要跟大家说再见了，期待下次与读者敌人们的相遇。

ACK Distro： 咱们下次再见！

相干链接​

[1] hybridnet 开源仓库地址

​https://github.com/alibaba/hybridnet​​

[2] hybridnet 社区文档

​https://github.com/alibaba/hybridnet/wiki​​

[3]ACK Distro 官网

​https://www.aliyun.com/product/aliware/ackdistro​​

[4] ACK Distro 官网 GitHub​[​]

​​https://github.com/AliyunContainerService/ackdistro​​

往期举荐

​​1、让翻新触手可及，阿里云容器服务 ACK 发行版凋谢收费下载​​

​​2、与阿里云容器服务 ACK 发行版的深度对话第一弹：如何借助 sealer 实现疾速构建 & 部署​​

理解更多相干信息，请扫描下方二维码或搜寻微信号（AlibabaCloud888）增加 云原生小助手！获取更多相干资讯！

​​

正文完
阿里云
发表至： 阿里云
2022-03-01
 0
关于阿里云:RocketMQ-的消费者类型详解与最佳实践
关于阿里云:一次配置设备就可实现毫秒级的全球就近接入实践类
关于阿里云:函数计算-HTTP-触发器支持异步解放双手搭建-Web-服务
关于阿里云:阿里云视频云vPaaS低代码音视频工厂极速智造万象空间