TMC控制平面详解 - VMware Tanzu显露王者风范 (3)

 

题图摄于北京奥利匹克森林公园

感谢伟大祖国生日的长假期，笔者终于抽空完成了 Tanzu 系列文章第三篇，对催更的读者有个交代了。之前除了工作繁忙耽误了进度外，写文章其实挺花精力的。笔者常和朋友提到写作的 1:10 原则，为了传达给读者详实和准确的信息，作者需要阅读或整理资料通常是最终成文字数的10倍以上。如果觉得本文对您有帮助，请点赞转发，谢谢。

（本文仅代表作者个人意见）

相关文章：

前面两期谈到 VMware Tanzu 组合拳的第一式：构建（Build）和第二式：运行（Run）。本期和大家聊聊 Tanzu 第三式：管理（Manage）。

背景

早在2013年，dotCloud 公司（后改名为 Docker 公司）发布了容器工具 Docker，点燃了容器革命的熊熊大火，至今仍未熄灭。

图片来自Docker博客

由于 Docker 简单易用，开发者可直接交付容器到运行环境，Docker 迅速在开发者中流传开来，成为史上的传播最快和最受欢迎的开发工具之一。Docker 容器问世已经6年多，容器亦成为青菜萝卜般的基础技术，全球有数十亿的容器运行在各种云或者数据中心里。

尽管 Docker 公司在开发技术上取得了压倒性的胜利，但在商业领域却没能延续辉煌，一直未能实现盈利，近日还传出经营困难的消息。个中原因很多，其中之一就是 Docker 缺乏容器应用管理的有力平台。用户在实践中逐渐发现 Docker 的方案只涵盖了软件从 “BUILD” 到 “RUN” 的过程，而对生产系统的可管理性却涉及甚少，这恰恰是企业用户愿意为之买单的强需求。

现今，Kubernetes 已成为云基础设施的实施标准，用户可把现代应用运行于私有云、公有云、混合云或者边缘端的 Kubernetes 上。这给运维管理人员带来了新的课题：如何配置应用的权限和用户的身份信息？如何设置安全策略？如何备份和恢复应用？诸如此类。

此外，虽然 Kubernetes 本身提供了 namespace 等方式隔离应用，但出于隐私保护、政策法规、业务需求等方面，用户往往还拥有多个 Kubernetes 实例，可能分布在若干公有云或数据中心里面，并由多个团队分别管理。

对于企业 IT 管理人员来说，当上述 n 个维度的需求交织在一起，问题的复杂度空间变得巨大无比，光想着就令人头痛，迫切需要一种行之有效的管理手段。

VMware 的 Tanzu 的第三式---管理，就是要致力于解决用户管理 Kubernetes 的各类问题。和前两式一起，勾画出 Tanzu 的精髓思想：Build – Run – Manage。虽与 Docker 的口号仅一词之差，但突出了管理的份量，给用户带来了决然不同的含义和价值。

VMware Tanzu 的 构建 - 运行 - 管理

Tanzu 管理部分的主体是 TMC（Tanzu Mission Control，Tanzu 任务控制），其主要负责人是另一位大神 Craig McLuckie ， Kubernetes 的联合创始人之一。他和前两期介绍过 Joe Beda 一起创建了 Heptio 公司，在 VMware 收购了Heptio 之后，Craig 目前担任 VMware 云原生部门的副总裁。

笔者和 Craig 交流过，他在 TMC 的设计思路挺清晰，就是为用户提供一个基于SaaS 的 Kubernetes 集中控制平面，既可供开发人员通过 API 使用云中的 Kubernetes，也能让管理人员统一设置各种策略实现管控。

TMC 同时兼顾着开发者和运维人员的需求，和上一篇的太平洋项目很像。不同之处在于，TMC 是云服务，可实现 Kubernetes 多云的管控；太平洋项目是基于 vSphere 的平台，以私有云以及支持 vSphere 的公有云为主。

TMC 纳管的 Kubernetes 实例不仅可处于公有云中（如 AKS，GKE，EKS 等），也可以是私有云中部署的实例，支持多种云、多团队或多集群管理，颇有“运筹帷幄，决胜千里”的味道。

资源管理模型

先来说下 TMC 的资源管理模型。TMC 采用了层次模型，每个租户（用户）会对应一个组织，组织里面包含两个视图：集群组（cluster group）和工作空间（workspace）。

在集群组视图里看到的是组织所有的 Kubernetes 集群，可以理解为管理员视图；工作空间视图则包含若干个 Kubernetes 的命名空间（namespace），这些命名空间可以位于相同或不同的集群中，命名空间代表着应用，因此工作空间可以理解为开发人员的应用视图。

用户可以在资源模型的节点上设置管理策略（如网络、备份等），TMC 自动把策略传播到下层的所有子节点中。当然，子节点也可以定义自己的策略来覆盖从上游节点继承过来的策略。     

TMC 的资源管理模型大大化简了管理员的负担，特别是在企业中集群数量较大的场景，因为策略可便捷地施加到所有相关的集群中，省却了逐一配置的繁琐过程。

TMC 的资源模型设计再次体现了管理员和开发人员分工协作的思路，和太平洋项目有异曲同工之妙。

 

基于上述资源模型，TMC 提供了主要的管理功能如下图所示：

 

集群生命周期管理

TMC 可直接在各种云平台上管控 Kubernetes 集群，例如部署、升级、扩展和删除等操作，可支持 AWS，Azure、 vSphere 等公有云或私有云平台。TMC 采用了开源项目 Cluster API （CAPI）来提供生命周期管理功能，CAPI 对主要的云厂商都能支持。

CAPI支持的云厂商

 

CAPI 是 Kubernetes  社区集群生命周期特别兴趣组（SIG）维护的项目，它给核心 Kubernetes 提供了可选的附加功能，以 Kubernetes 风格的声明式 API 引入集群的创建，配置和管理的能力。

Cluster API的部署架构

 

CAPI 的组件本身部署在一个的 Kubernetes 管理集群中，定义了 CR（Custom Resources）来记录目标集群的元数据，用户可通过声明式 API 在云中创建和管理目标 Kubernetes 集群。

借助 CAPI，TMC 的界面可让用户在云中创建并运维 Kubernetes 实例。在部署新的 Kubernetes 实例时，用户可选择的类型是开发集群或者生产集群。若是生产集群，TMC 将创建 3 个 Kubernetes 控制平面节点（可处于不同的区域中），实现高可用能力。

TMC 创建 Kubernetes 集群的界面

有没有发现基于 CAPI 的 TMC 和上期的太平洋项目在架构上有相像之处？不错，两者都是把服务的控制平面部署在一个 Kubernetes 集群里面，然后再管理其他的目标 Kubernetes 集群。太平洋项目在管理 Guest 集群生命周期时也用到了 CAPI，CAPI 是部署在主管集群 （supervisor cluster）里面的管理服务。

 

纳管现有的集群

用户的环境中往往还有已部署并正在使用的 Kubernetes 集群，TMC 可以接入（attach）这些集群并进行管理。具体方法就是管理员在目标集群安装一个代理（agent），用以联络TMC。因为要穿过防火墙的原因，agent 采取 pull（拉取）方式 TMC 中设定的策略和指令，并且应用到其所在的集群中。

TMC 把纳管后的集群加到资源列表里面，和自建（Provisioned）的集群一同管理，提高了管理效率和便利性。

纳管集群和自建集群无差别的管理

也就是说，只要是能连通 TMC 的服务、符合一致性规范的 Kubernetes 实例，管理员向它发送一条 kubectl 命令，在“对上眼神”之后（通过 token 验证），它就能融入TMC 的怀抱。

统一的身份和访问管理

在拥有多个集群的企业里面，管理员需要追踪哪些团队有权访问哪些集群以便实施细粒度的管理。TMC 能帮助管理员团队统一管理所有 Kubernetes集群的访问，管理员可把 AD 里的身份数据导入 TMC，然后用同一套身份信息定义各个集群或工作空间的访问策略。

安全和配置管理

TMC 可集中定义安全策略和全局的配置。安全策略包括网络策略、Pod策略和镜像策略等。

网络策略定义了 Pod 之间是否可以访问以及是否能够连接其他网络地址。Pod 策略控制对安全敏感的 Pod 权限，如禁止 Pod 访问宿主机文件系统和网络等。镜像策略则可阻挡从不安全的镜像源拉取镜像。

TMC的镜像策略

审计和合规

TMC 运用并扩展了开源项目 Sonobuoy 来测试集群，是十分强大的工具，可检查（inspect）集群是否满足特定的规范要求。例如，集群是否满足 Kubernetes 上游一致性（conformant）的要求，是否符合安全最佳实践、是否可以升级到新版本等等。

数据保护

在任何生产系统中，最重要的数据保护策略莫过于备份和恢复。TMC 借助VMware 的开源项目 Velero，帮助管理员从 Kubernetes 集群备份重要数据，如集群和应用的状态和持久化的存储卷（PV），并能够根据策略一次备份多个集群。在需要的时候，可以恢复备份数据。

 

在备份的基础上，TMC 还能够在集群之间迁移数据。这个功能很好理解，把数据备份之后，可以在需要的集群上再现出来（数据恢复），从而实现了迁移的目的。迁移功能在升级 Kubernetes 版本，清空开发测试环境等情况下有较大作用。在 DevOps 流程中，还可以创建临时集群（为测试等目的）。

 

TMC 的备份可设置不同的策略，例如根据 RTO （Recovery Time Objective）设定备份间隔，根据命名空间、标签和集群等做选择性备份和恢复等等。

 

集成其他云服务

 

TMC 还可以连接 Wavefront 做监控和数据分析，利用 CloudHealth 优化资源、成本和系统性能，给用户提供完整的管理能力。

 

结语

 

作为 VMware Tanzu 组合的一部分，Tanzu Mission Control 是一个 SaaS 云服务，提供面向 Kubernetes 的统一控制平面，让用户可全面深入地管控各种 Kubernetes 的环境，无论是在公有云或者私有云里，自建或纳管的多个集群，大大简化了访问控制和确保了策略实施。

 

随着 Tanzu 组合 Build - Run - Manage 的推出，VMware 正在改变企业在 Kubernetes上构建软件的方式。管理员可保持对 Kubernetes 集群的控制，可实施访问控制、安全、备份等策略。开发人员获得使用 Kubernetes 的自由度，在管理员划出的一方天地里面，自如地访问资源和顺畅地开展协作。

 

最后提一下，Tanzu 积极拥抱开源技术生态，集成了很多开源项目，其中有 VMware 主导的云原生项目：Sonobuoy （诊断），Velero（备份恢复），Octant （可视化管理）等，这些项目会逐步纳入 Github 的 vmware-tanzu 组织里面，目前已经包括了3个项目，感兴趣的读者可访问：

https://github.com/vmware-tanzu

要想深入了解更多 Tanzu 和云原生技术原理，请立即长按以下二维码，关注本公众号亨利笔记，以免错过更新。欢迎点赞转发。

（全文完）

---

VMware招聘云原生开发工程师

（北京）

VMware中国研发中心一直致力于前沿领域的创新工作，成功创立并开发了用户广泛使用的 Harbor 容器镜像仓库等开源项目，在国内云原生领域有着深远的影响力。

为满足项目发展需要，现招聘资深开发工程师一名，需熟悉 Kubernetes 平台，开发云原生技术为主的开源项目，涉及多个业界热门和超前的技术领域，和业界大咖合作、待遇优厚、不加班，出国学习交流机会，欢迎大家踊跃投递简历或转发给需要的朋友！

职位要求：

• 计算机科学或相近专业本科以上学历

• 6年以上应用代码开发经验

• 熟悉至少一门现代编程语言，如 Go, Python, Java, C++

• 对云原生技术，如容器，K8s等有较多的项目经验

• 具有机器学习方面经验者优先

• 熟悉开源软件社区运作，参与过开源项目贡献者优先

• 良好的英语沟通能力，可以和国际团队协作。

 

请发简历：harbor @ vmware.com

注明：云原生职位