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

本文涉及的产品
应用实时监控服务-应用监控,每月50GB免费额度
云原生网关 MSE Higress,422元/月
函数计算FC,每月15万CU 3个月
简介: 本次采访我将继续为大家详细讲解我的好伙伴:阿里巴巴的开源 Kubernetes 容器网络解决方案 hybridnet,以及我是如何借助它来构建混合云统一网络平面。

作者:若禾、昱晟、瑜佳


记者:各位阿里巴巴云原生的读者朋友们大家好,欢迎再次来到探究身世之谜系列专访栏目,今天邀请来的还是大家的老朋友,『阿里云容器服务 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.3192.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)添加云原生小助手!获取更多相关资讯!


640.jpeg


相关实践学习
巧用云服务器ECS制作节日贺卡
本场景带您体验如何在一台CentOS 7操作系统的ECS实例上,通过搭建web服务器,上传源码到web容器,制作节日贺卡网页。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
8天前
|
人工智能 弹性计算 运维
ACK Edge与IDC:高效容器网络通信新突破
本文介绍如何基于ACK Edge以及高效的容器网络插件管理IDC进行容器化。
|
11天前
|
监控 NoSQL 时序数据库
《docker高级篇(大厂进阶):7.Docker容器监控之CAdvisor+InfluxDB+Granfana》包括:原生命令、是什么、compose容器编排,一套带走
《docker高级篇(大厂进阶):7.Docker容器监控之CAdvisor+InfluxDB+Granfana》包括:原生命令、是什么、compose容器编排,一套带走
141 77
|
9天前
|
人工智能 运维 监控
阿里云ACK容器服务生产级可观测体系建设实践
本文整理自2024云栖大会冯诗淳(花名:行疾)的演讲,介绍了阿里云容器服务团队在生产级可观测体系建设方面的实践。冯诗淳详细阐述了容器化架构带来的挑战及解决方案,强调了可观测性对于构建稳健运维体系的重要性。文中提到,阿里云作为亚洲唯一蝉联全球领导者的容器管理平台,其可观测能力在多项关键评测中表现优异,支持AI、容器网络、存储等多个场景的高级容器可观测能力。此外,还介绍了阿里云容器服务在多云管理、成本优化等方面的最新进展,以及即将推出的ACK AI助手2.0,旨在通过智能引擎和专家诊断经验,简化异常数据查找,缩短故障响应时间。
阿里云ACK容器服务生产级可观测体系建设实践
|
9天前
|
供应链 安全 Cloud Native
阿里云容器服务助力企业构建云原生软件供应链安全
本文基于2024云栖大会演讲,探讨了软件供应链攻击的快速增长趋势及对企业安全的挑战。文中介绍了如何利用阿里云容器服务ACK、ACR和ASM构建云原生软件供应链安全,涵盖容器镜像的可信生产、管理和分发,以及服务网格ASM实现应用无感的零信任安全,确保企业在软件开发和部署过程中的安全性。
|
9天前
|
运维 Kubernetes 调度
阿里云容器服务 ACK One 分布式云容器企业落地实践
阿里云容器服务ACK提供强大的产品能力,支持弹性、调度、可观测、成本治理和安全合规。针对拥有IDC或三方资源的企业,ACK One分布式云容器平台能够有效解决资源管理、多云多集群管理及边缘计算等挑战,实现云上云下统一管理,提升业务效率与稳定性。
|
19天前
|
存储 缓存 监控
Docker容器性能调优的关键技巧,涵盖CPU、内存、网络及磁盘I/O的优化策略,结合实战案例,旨在帮助读者有效提升Docker容器的性能与稳定性。
本文介绍了Docker容器性能调优的关键技巧,涵盖CPU、内存、网络及磁盘I/O的优化策略,结合实战案例,旨在帮助读者有效提升Docker容器的性能与稳定性。
54 7
|
21天前
|
运维 Kubernetes Docker
深入理解容器化技术:Docker与Kubernetes的协同工作
深入理解容器化技术:Docker与Kubernetes的协同工作
43 1
|
21天前
|
Kubernetes Cloud Native 持续交付
容器化、Kubernetes与微服务架构的融合
容器化、Kubernetes与微服务架构的融合
39 1
|
23天前
|
Kubernetes Cloud Native API
深入理解Kubernetes——容器编排的王者之道
深入理解Kubernetes——容器编排的王者之道
35 1
|
1月前
|
机器学习/深度学习 数据采集 Docker
Docker容器化实战:构建并部署一个简单的Web应用
Docker容器化实战:构建并部署一个简单的Web应用

相关产品

  • 容器计算服务
  • 容器服务Kubernetes版