Kubernetes网络架构详解.docxVIP

  1. 1、本文档共27页,可阅读全部内容。
  2. 2、有哪些信誉好的足球投注网站(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  5. 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  6. 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  7. 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  8. 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
PAGE PAGE 10 Kubernetes Kubernetes 网络架构详解 容器的网络是在 CaaS 集群中无法避免的话题, 作为当下最主流的一种容器集群解决方案, Kubernetes 对网络进行了合理的抽象,并采用了开放的 CNI 模型。面对各种容器网络实现,他们有什么不同,应该如何选择?本 文将带大家回顾 Kubernetes 各种主流网络方案的发展历程,并透过现象清本质,用形象的例子展示 Weave 、 Flannel 、Calico 和 Romana 等网络解决方案背后的原理。 初入容器集群的人往往会发现,和单节点的容器运用相比,容器的网络和存储是两个让人望而却步的领域。在这些领域里,存在大量的技术名词和术语,就像是一道道拒人于门外的高门槛。 为了便于理解,我们将这些名称简单的分个类别,从简单到复杂,依次递增。今天的话题会涉及的深度大致在 为了便于理解,我们将这些名称简单的分个类别,从简单到复杂,依次递增。今天的话题会涉及的深度大致在 这个大池子的中间,希望大家看完以后会对目标线以上的内容不再陌生,目标线以下的内容我们也会依据需要 适当的提及。 此外,这个话题会按照 Kubernetes 的网络发现过程作为时间主线,其中重点介绍 CNI 标准和它的主流实现。 在 早 期 的 Kubernetes 中,对 网络 是 没 有 什 么 标 准的 。文 档 中 对 网 络的 描 述只 有 很 简 单的几 句 话 ,其 实 就 是让 用 户 在部 署 Kubernetes 之 前 ,预 先准 备 好 容 器 互 联的 网 络解 决 方 案 。Kubernetes 只 对 网 络 提 出设 计 假 设 ,这 三 条 假 设 总 结 起 来 就 是:所 有 容 器都 可 以 和集 群里 任 意 其他 容 器 或 者 主 机 通信 , 并 且通 信 双 方 看到 的 对方 IP 地 址 就 是实 际 的 地 址 ( 即 不经 过 网 络地 址 转 换 ) 。 基 于 这 样的 底 层 网 络 , Kubernetes 设 计 了 Pod - Deployment - Service 的 经 典 三 层服务 访 问 机制 。 既然 Kubernetes 不提供底层网络实现,在业界就出现了很多企业级的以及开源的第三方解决方案,其中下面这页图中展示了这个时期的主流开源方案。 我 们 将 这些 方 案 依 据 配 置 的复 杂 度 ,分 为“ 全 自动 ”和“ 半 自 动 ”两 类 ,就 像 是 汽 车 中 的自 动 挡 和手 动 挡 的 差 别 。 “ 全 自 动” 的 解 决 方 案 使 用起 来 简 单, 适 用 于 标准 网 络环 境 的 容 器跨 节 点通 信 。 “半自动”的解决方案实际上是对底层协议和内核模块功能的封装,提供了选择十分丰富的网络连接方法,但对使用者的网络原理知识有一定要求。 在 Kubernetes 的 1.1 版 本 中,发 生 了一 件 很 重要 的 变化 ,那 就 是 Kubernetes 全 面 采 纳 CNI 网 络标 准 。 CNI 诞生于 2021 年 4 月,Kubernetes 的 1.1 版本诞生于 2021 年 9 月,之间仅隔 5 个月。在这个时期, Docker 也设计了一套网络标准,称为 CNM (即 Libnetwork )。 Kubernetes 采用 CNI 而非 CNM ,这背后有很长的一段故事,核心的原因就是 CNI 对开发者的约束更少,更开放,不依赖于 Docker 工具,而 CNM 对 Docker 有非常强的依赖, 无法作为通用的容器网络标准。 在 Kubernetes 的官方博客里有一篇博文详细讨论了个中细节, InfoQ 上有一篇该博客的翻译,有兴趣的读者不妨一读。 几 乎 在 Kubernetes 宣 布 采纳 CNI 以 后 的 1 个 月 , 之 前 提 到的 “ 全 自动 ” 网络 方 案 就悉数 实 现 了 CNI 的 插 件 , 这 也 间 接说 明 了 CNI 的 简单 。 那 么 CNI 到 底有 多 简 单 呢 ? 举 几 个 数 字。 实 现 一 个 CNI 插 件 需 要 的 内容 包 括一 个 Json 配 置 文 件 和 一 个可 执 行 的文 件( 脚 本 或程 序 ), 配 置 文 件描 述 插 件 的 版 本 、 名 称 、 描述 等 基 本 信息 , 可执 行 文 件 就是 CNI 插 件 本身 会 在容 器 需 要建 立 网 络 和 需 要 销毁 容 器 的时 候 被 调 用。 当 一 个 CNI 插件 被 调 用 时 ,它 能够 通 过 6 个 环 境 变量 以 及 1 个命 令 行 参数( Js

文档评论(0)

HenleyChow + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

版权声明书
用户编号:7064030100000011

1亿VIP精品文档

相关文档