2023 “Kubernetes 管理” 将路走何方？

Kubernetes 从 2014 年开源至今，在云原生领域的地位已经逐渐稳固。从宏观层面来看，Kubernetes 解决方案的引进路径十分清晰，在许多企业的落地实践中均得到了成功的验证。目前企业级 Kubernetes 解决方案逐渐成为大势所趋，但不少企业对此仍持观望态度。那么，2023 年 Kubernetes 管理将路走何方？

为了得到这个问题的答案，InfoQ 极客有约邀请到了一直活跃在研发一线、经历了 OpenStack 到 Kubernetes 技术变革的 Rancher 大中华研发总监张智博老师，听他跟我们聊聊 Kubernetes 在企业中的落地实践，共同探讨一下关于 K8s 的发展现状及未来趋势。

以下为直播内容整理：

InfoQ：您认为，企业为什么需要 Kubernetes？

张智博：企业不断采用 IT 变革技术，本质上它需要的是容器技术给它带来生产力的提升，而非完全依赖 K8s。实际上，容器技术也确实提升了企业应用的分发效率、打包效率以及整个生产的迭代效率。

就目前行业发展情况来看，要将容器进行整体管理，K8s 仍是最佳选择。此前虽出现过同类软件，但已经在近几年的发展过程中逐渐消亡。尽管还有其他一些小众选择，但那些选择要么缺少生态维护，要么得不到大的云厂商支持。即便想要落地，也找不到可用且相对稳固的技术工具和技术栈。因此，我们认为 K8s 可能是当前时代已有的、唯一的选择。

InfoQ：企业使用 Kubernetes，究竟是走开源自建路线，还是购买商业服务路线？Kubernetes 开源版和商业版的区别究竟在哪？为什么现在 Kubernetes 商业化是大势所趋？

张智博：对于企业而言，无论怎样选择，采用新的技术就要付出成本。而企业到底关注人员成本还是 IT 成本，不同企业有不同的选择。关注 IT 成本的企业可能会选择开源自建，在它看来企业投入资金去采购新的软件，这些费用会算在 IT 的支出费用里面，所以它更倾向于开源自建。开源自建只需满足开源的 License，便可以免费使用。而企业如果比较关注人员成本，希望把精力聚焦在企业自身业务上，选择购买商业服务就更好。

开源自建相当于把依赖新技术带来生产力变革的这些关键战略绑定到了具体的人员身上，这对企业来说存在一定的风险。开源软件并非完美无瑕，也难以一直保持稳定，它需要持续地维护。在这过程中如不能深入到开源项目里面，自建就存在长期的技术风险。在这种背景下，企业负责人就要深度评估企业是否真正具备自建的技术能力。虽然当前很多开源软件的开箱即用做得确实不错，但这并不代表它背后没有相应的技术成本。

商业服务有别于开源自建，它相当于把带来生产力变革的关键战略锁定到了外部的第三方公司。在这个过程中，一旦供应商的产品或者迭代方向发生改变，或者服务不能满足企业的使用期望，亦或者在使用过程中价格被锁定，均会影响 IT 的变革。如果企业被某个商业公司所独有的技术锁定，随之带来的风险是非常大的。

根据我的工作经验，我还是很看好 SUSE 这类公司的未来的。IT 主流的选择应该是用户去选择开源产品的商业服务，去购买开源产品的订阅，这样可以较好地屏蔽供应商锁定的问题。能够提供开源商业支持的公司很多，即使一家公司出现了问题，或者它的产品无法满足你的需求，由于你依赖的仅仅是开源的技术或产品，因此可以很容易地把供应商换掉。

即便企业未来不希望再受供应商和商业服务公司的牵制，或者企业具备技术自建能力且业务发展很好，它依然可以在之前复用的开源产品的技术底座上再往前走，甚至可以抛弃这些商业服务，因此这本质上是一种风险对冲。所以我认为真正的大势所趋就是开源产品的商业服务。

开源版和商业版的区别主要在于：你作为使用者是否愿意付费。开源产品具有 license，有的 license 允许商用，也允许二次分发。在这过程中，有的用户有意愿付费，他希望通过付费获取保障。但有的用户则认为不需要付费，因为这已经是开源了。当然，从产品功能角度两者也有区别。通常来讲，商业版本有比开源版本更稳定的产品迭代，更稳定的服务，可以使生产环境运行得到保障。至于内部功能性的差异，不同的厂商有各自的表述。总之，开源版和商业版的区别第一是付费意愿，第二在于增强的一些功能。

关于第三个问题，我个人的观点是，开源产品的商业服务是大势所趋。提到 K8s 商业化是大势所趋，我第一印象会认为这个观点是错的。K8s 本身是一个成功的开源软件，它的采用量势必会不断攀升，随着采用量的攀升，必然会产生一定数量的商业客户。商业客户增加、付费市场规模扩大，整个环境就会更好，但是真正的趋势应该是更多的用户为开源软件的商业服务付费。

InfoQ：过去一年里，企业都在优化人力成本、运营成本，都很关注降本增效，基于企业降本增效这个大目标，Kubernetes 是如何帮助企业降本增效的？ “Kubernetes 商业化”、企业级的 Kubernetes 管理软件，究竟能为企业降本增效提供多少助力？

张智博：降本增效的确是今年大家普遍在提的一个话题。需要先明确一个事实，即：通过一个软件实现降本增效是非常复杂的。究其本质，真正提升效率、降低整个迭代成本的是容器技术，容器技术助力生产力提升，效率也随之提升。因此，一定是在走完容器化改造之后，才能看到降本增效的优势。绝不是随意创建几个 K8s，再布置几个业务上去，就能实现降本增效。有的用户可能会在大量的虚拟机上跑一些纯粹的东西，导致资源利用率很低，又执意要创建 K8s，这其中的成本反而是上升的。

因此，第一步应该是有一个合理的规划，即容器化达到何种程度后再迁移到 K8s 里面。机器的使用率降低，资源利用率提高，如此才能达到降本增效。值得注意的是，容器化改造应是真正系统化的梳理、改造，而非简单建几个 K8s 就草草了事。系统改造之后，真正上到 K8s 就会发现，目前所有的云厂商都提供 K8s 服务。也就是说，一旦你的业务体系全部容器化到 K8s 上，你就拥有了面向多云使用的天然便利。面向多云使用，必然会增加议价权以及使用的多样性，这样你就可以选择成本低的地方去部署业务。

此外，我们讲基础设施，自己公司内部的基础设施就做了一个很好的抽象。以前我们讲叫 DevOps，现在可能又改头换面叫平台工程。在我们厂商看来其实没有太大区别，因为我们有的客户在没有平台工程这个概念之前就有这种理念。他把东西容器化之后放到 K8s 里面，业务就可以跟着 K8s 去走，整套环境的部署，无论是开发、测试，都可以通过 API 对接起来。依托 K8s 基础设施，包括上层应用这一整套的业务系统，可以到任意的云上去部署。这个就是我们讲基础设施即代码所具备的能力。

综合来看，企业降本增效的关键在于整套 IT 系统和业务流程能否真正实现工程化，是更多地依靠人来部署、接入，还是通过自动化的平台去做。借助 K8s，你不需要自己去抽象 API，也不需要自己去打通生态，K8s 均可实现。由此我们可以看到 K8s 助力企业降本增效的效果。

InfoQ：您认为，企业级的 Kubernetes 管理软件最关键的功能是什么？

张智博：肯定是多集群群管理。为什么是多集群管理？我们可以回看历史发展进程，针对 K8s 落地大厂之初如何引导用户。我们创建了一个超大集群，其中可能包括几千甚至上万节点。由于这些超大的集群里面涉及很多深度的技术优化、内核优化，甚至还可能会模仿 K8s,所以他们最终实现起来，资源利用率的确很高。但是这个所谓的最佳实践或是说工程经验，是没有办法复用到更多的企业用户手里面的。

原因在于大厂的人员、技术实力是绝大部分用户所不具备的。为什么开始有多集群这个概念出现，就是因为多集群的管理更适合绝大部分用户。我们说尽量不要去魔改一些开源软件，因为一旦改完之后却无法做到长期维护、长期更新、长期升级，你的这些东西跟它的生态便不再兼容，从而很容易锁定到一个版本之上。即便有了解这些功能的人，也无法避免这些人离开后技术无人维护的情况发生，最终反而变成技术负担。

在后面的发展过程中，我们看到越来越多的商业厂商开始研究 K8s 的发行版，且各具特色。但是如果你所用的管理软件不是多集群管理，你就没有办法把你需要且有特色的发行版纳入到你的管理体系当中。相当于我们本希望依托开源软件的开放性吸纳更多的生态来支撑自己的业务，但是由于没有选择这条技术路线，反而又被自己设定的牢笼锁定了，这就错失了开源生态带来的红利。

因此长期来看，多集群管理模式肯定有利于企业，也有利于 IT 行业长期的风险管理和成本控制。

InfoQ：在多云环境下运行 Kubernetes，复杂性大幅增加，企业运维难度也大大提升，目前市面上有没有企业级的 Kubernetes 管理软件已经解决了？在解决这些问题时主要会遇到哪些挑战？除此之外，有什么其他的比较好的解决方案吗？

张智博：当前，K8s 对云厂商来说已经是非常重要的基础设施了，而且变成了一种服务。每个用户只要有云的账号，就很容易拿到一些资源。但是我们要明确，对于一个企业而言，选择哪朵“云”就意味着它的业务在哪里。海外有 AWS、Azure、GCP，国内有阿里云、华为云、腾讯云，包括新近崛起的天翼云等，每朵“云”都有自己的特色。面向不同属性的客户，每朵“云”也都有自己的技术优势。

对于企业级的 K8s 管理软件来说，有这么多的云，每朵“云”都有类似的服务，该支持哪个？是聚焦海外还是专注国内，还是全都支持？每个云都有自己 K8s 发行版的生态演进计划，它并不会跟其他云相互搭配、相互沟通。虽然上游有 K8s，但是每朵“云”都有各自的版本跟踪计划，所以这个挑战很大。管理软件所支持的云越多，复杂程度会越高。

虽然云厂商有 K8s，但也有用户喜欢在云上自建。他们认为这样自由度更大，可以更多地去控制。其实，我们在很早就改变了 Rancher 这个软件的产品理念。我们本身就把云上的用户设定为第一优先级的用户，因为从整个市场份额来看，K8s 的绝大部分市场份额在公有云这一侧。虽然有人更关注私有化部署，但是绝大部分用户仍在公有云这一侧。而在公有云这一侧的又有自建的，有托管的，这给管理软件又增加了一层挑战。不仅要支持公有云的托管，还要支持面向公有云的虚拟机的服务，帮助用户自建 K8s。这就使得软件的知识矩阵变得很复杂，对软件维护者的要求也相应提高了。

具体有哪些挑战，我结合前面内容进行一下总结。第一是云有很多种，种类不同，接入生态就会很复杂。第二是知识矩阵很复杂，用户既有自建的需求，又有用托管的需求。到底有没有特别好的方案？其实，现在市面上所有的主流管理软件，都声称具备多元的 K8s 管理功能。但是要细看其到底支持多少种云，支持自建的模式还是公有云托管模式，这方面我认为 Rancher 做的比较好。

InfoQ：Rancher 有一个非常著名的开源产品 K3s，由于其轻量级的属性，很多用户将其放到边缘场景。企业级的 Kubernetes 管理软件在边缘环境下主要需要解决哪些问题？目前市面上的产品已经解决了吗？

张智博：除了 Rancher 这个软件主打的 K8s 多集群管理，K3s 确实是我们另一款发展非常好的软件。最早我们设定 K3s 是很轻量的，由于边缘计算正处于发展中，大家就开始尝试将容器化落地到边缘场景中，K3s 自然而然就开始有了一些边缘的场景。但是针对边缘的场景需求，不同厂商、不同用户的理解均不同。每个厂商都是聚焦在自己的认知之下，帮助自己的用户来解决这个问题。

K3s 的定位是比较专一的，本质上我们设定 K3s 是满足 K8s 一致性测试标准的一个发行版，意思是 CNCF 推出 K8s Conformance，你要去跑它的一系列的端到端测试才能验证这是一个标准的发行版，K3s 将永远聚焦于这个点。这也意味着 K3s 不会为了某个特定的场景去魔改，因为魔改之后会造成兼容性问题。如果强行把 K3s 落地到边缘，部分用户场景就会出现问题。因此，从产品的原生设定角度跟大家做出解释。

关于管理软件在边缘环境下解决的是什么问题，我没有办法从整个行业的角度去讲，因为每家厂商都不一样。从我们的角度来看，边缘上如果在用 K8s，或者要用 K3s 技术把你的业务打包到 K8s 这种抽象的 API 里面然后再去部署，我们认为它并不能解决全部的边缘场景，它只是在解决一个近端的边缘场景。在我们的解决范畴内，目前 K3s 就只能到这一层，因为它需要依赖于一个有一定计算能力的设备，这样才有能力在上面跑 K8s 的编排引擎和容器化组件。如果没有这个计算能力，只能供给业务，那再弄一个基础引擎上来完全是浪费资源。

我们目前先解决近端边缘场景之下的问题，因为近端边缘是具备一定算力的。通常无论是 ARM 架构还是 X86 架构，都需要一个操作系统，需要有编排引擎去承载业务，我们把它抽象成一个不可变的基础设施。相当于 OS 加上 K3s，由于 SUSE 本身就是 Linux os 厂商，所以我们做这个东西的产品化做得还是很好的。

目前，我们在边缘领域的确能够解决问题，但是边缘这个市场十分庞大，更多的内容我也讲不了。用纯粹的容器化或者 K8s，去尝试解决所有的边缘问题，包括远端的、IOT 设备管理的，其实非常复杂，起码目前从我们这边还没有看到一个特别稳定的市场机会。

InfoQ：整体来看，国内企业对于 Kubernetes 落地及管理的要求是怎样的？

张智博：国内企业我们要分开来看，有一些企业要求自主可控；有的企业要求标准的商业化生产场景，你能够解决问题就可以。其实无论是国内还是海外，都没有太大区别。对于自主可控，国内的企业更关注 ARM 的支持，因为有很多用户都在依赖 ARM 去运行 K8s。

目前，ARM 开始在公有云上普及，整个软件生态也都在支持。所以提到要求，我认为首先要支持 ARM，这样你才有机会参与到这些自主可控的企业里面。第二是自主可控更深层次的需求，即软件的供应链，它跟工业品或者其他有限制性的商品的供应链是一样的。

现在都在提软件供应链的等级，即你提供出来的软件的构建、编译是不是可溯源？你构建出来的产物，有没有软件物料清单？构建出来的东西，用户使用验证时，能否做到不被篡改？以上这些是国内当前在自主可控领域开始关注的方向。

我们确实也在进行全新的探索。比如，国内自主可控领域在操作系统层面更多地运用 openEuler 或者 openEuler 衍生系列。同时，我们也在尝试构建一个 K8s 的发行版，相当于把 openEuler 的生态变成一个生产车间，把 K8s 依赖的上游源代码全部灌入到生产车间里，通过生产车间来生产 K8s 的发行版。在发行版里面，我们可以把软件的物料清单、工程量等信息公示出来。目前，Rancher For openEuler 的发行版已经 GA。

InfoQ：从产品角度，Kubernetes 需要哪些增强来支持这一轮商业化的发展？

张智博：技术发展是有规律的。想知道今年商业化有什么新动向，就去看去年开源的领域在研究什么新东西。去年 K8s 到 1.24 版本后就开始把软件供应链相关的信息融入进自己的发布流程里面，我们不难发现今年很多 K8s 的商业化公司都在提软件供应链。上游社区技术演进涉及到的方向，商业公司绝不能错过。因为商业公司至少要把上游社区所能实现的东西呈现出来，也就是所谓的软件供应链，然后才能进一步加强。

关于如何“加强”，现在大的趋势是技术布道。K8s 已经走过了飞速发展的创新阶段，现在它要做的是企业落地，并且加速企业落地。随着越来越多的企业开始采用这个软件，安全合规也变得越来越重要，必须要有各种防护措施来保障生产环境。这其实是所有新技术走向成熟的一个客观规律。

关于如何支撑这个领域的商业化发展。我们发现，由于 K8s 上游迭代的速度非常快，云厂商包括 Rancher，虽然做了很多年 K8s 的商业供应商，依然很难完全跟得上上游的版本迭代，这就出现了碎片化严重的问题。就像安卓时代，手机多起来之后，你发现安卓最可怕的就是 4 点几和 6 点几，那个时代各种各样的版本都有。对于用户来说，有的用户可能需要不断地更新，有的用户则不需要频繁地更新，但是他用的版本已经过了生命周期。这个时候，企业在一个相对不那么新的版本上提供一个长期支持服务，是非常关键的一点。

InfoQ：这几年，国内软件供应链安全问题、容器安全问题、合规问题受到越来越多的关注，这为企业级的 Kubernetes 管理软件的研发提出了怎样的新要求？

张智博：就我个人近一年的经历来看，工程化的难度加大了很多，因此最关键的肯定是工程化。由于人力是有限的，我们要用有限的人力去支持现有版本的不断演进，就要持续地做好工程化。任何一个软件，只要有人投入就要保证效率，无论是资金还是时间总会有成本，因此最终一定要有个合理的毛利率，而非无限的投入。要解决 K8s 版本碎片化，又要确保容器安全合规，还要引入软件供应链，以上种种如果仅靠人去治理，完全消耗不起。我个人最近一年也在做产品，包括带产品研发团队做工程。我们去年一年做的工程化的量，可能比前几年加起来还要多。这些与前一年相比，可能就是一个简单的 CI，但现在的工作量比以前大很多，因此关键还是工程化。

InfoQ：您觉得 Kubernetes 商业化在 2023 年有怎样的发展趋势？将完成怎样的技术演进？为什么？

张智博：一年的时间很短，很难称得上演变到一种趋势。不过从已经过去的两个月时间来看，包括也在跟客户聊，确实得到一些反馈。企业现在对 K8s 的需求不似前几年，“K8s is everything”，那个时代大家认为新技术可以做很多事情，大家都在天马行空地设想，但现在并不这样。大家不再期望技术实现复杂的创新，而是把它作为一个高效率的工具引进并落地下来。由于容器管理确实给企业带来了生产力的提升，因此企业的根本需求就是做容器管理，即 K8s 的根本。

很多客户不再去投入一些过于前瞻性的创新，而是逐渐认识到软件究竟能做什么、不能做什么，因此商业化在今年应该会有一个比较好的发展。

InfoQ：目前市面上基于 Kubernetes 的解决方案都有哪些形式？整个市场发展处在什么阶段？

张智博老师：提到解决方案那一定是商业化，商业化形式就是公有云的托管服务，每一个云厂商只要有账号就能去建他的 K8s，就像 AWS 有 EKS，阿里云有 ACK。还有 SUSE 提供 Rancher 这种企业级的容器管理软件，你无需特别关注是私有云还是公有云，Rancher 都可以帮你把所有 K8s 资源统一管理起来。还有一些特定的发行版，在 K8s 的基础框架之上做创新，这些都是大家做商业化的形式。

市场发展正处于什么阶段，我想应该是：商业化的市场正处于上升阶段，但是技术创新的热度明显在下降。印象中我看过一个海外Gartner 报告，报告显示 2020 年全球企业采用容器化技术的比例占 5%左右，预计 2024 年可能达到 15%-20%。Gartner 采访的应该是真正有实力付费的用户，而不是纯粹的社区用户。所以商业化市场的空间和付费的空间还是非常大的，不过这也需要 K8s 不断地成熟起来。

InfoQ：在 Kubernetes 企业级解决方案供给领域，全球的竞争格局是怎样的？

张智博：SUSE 在国内与海外都有涉猎，算是一个在全球卖这种产品的公司。从我们接触到的很多客户来看，公有云应该是一个真正的赢家。关于公有云，无论是打开虚拟机还是打开任何一个服务资源，我们都默认是需要付费的。它的商业模式决定了它很容易把开源软件和 K8s 变现，因此它是真正的赢家。

从全球范围来看，我们目前在海外碰到更多的厂商是 OpenShift 这类的，国内目前竞争还是非常激烈的。我有统计，去年几乎每个月都有厂商突然要开源自己的 K8s 管理平台。随着厂商越来越多，大家开始内卷竞争，低价的情况随之出现。由于没有长期的正向收益，国内的这类软件就无法成长为有国际竞争力的产品，企业也难以在国际市场站稳脚跟。结合国内市场来看，当前的竞争格局难言乐观。

InfoQ：刚提到国内的市场形式，在 Kubernetes 领域，国内介入也是比较早的，和海外相比，出现当前状况的原因？ 

张智博：这也是我个人在这几年的职业生涯中感到非常遗憾的一点。国内对这一波技术的介入非常早，而且原先 K8s 落在国内是全球最好的一个 user case。但是，为什么在后续成长中我们没有出现具有国际竞争力的产品？

除了前面提到的厂商过多以外，还有一个原因就是我们的市场规模没有发展起来。海外虽然也有一些小众厂商，但是它的市场规模是可观的，无论是小厂商还是头部厂商都能拿到正向的收益。

我的理解是，我们没能在关键阶段制定出行业标准。对于长期从事这个领域的技术人员而言，可能认为这个东西不需要标准。但是市场要在各行各业铺开，并非只针对 IT 企业和互联网企业。如果没有一个行业标准，对于其他企业来说，采用 K8s 和容器技术可谓天方夜谭，这也就造成了市场规模发展不起来的局面。

我最近在做一些研究，发现美国的国防部从 2020 年开始大力引入 K8s，它制定了非常详细的厂商准入标准及产品标准。而且这个标准是完全公开的，公开则意味着国防部这一套基于 K8s 建设的软件交付平台，其他非 IT 行业可以直接参考。这套标准在国内并没有看到，所以市场规模一定是上不来的，大家就只能在仅有的付费客户领域里不断地相互挤压。

Rancher 在海外有很多客户，这些客户既可能是某个农业公司，也可能是某地区的一个县政府，这在国内很少能看到。行业没有标准化，就没有办法实现可复制，从而导致市场规模发展不起来。

InfoQ：SUSE 在这个领域也是关键厂商，在整个领域的发展和企业用户痛点来看，你们是否有提出相应对策？

张智博：今年，产品层面我们还是定位于多集群和多云。目前这已经是一个标配，是一个固定的基础需求。入到这个行业门槛，就得提供这个能力。

在此基础上，我们尝试扩展边缘领域的产品能力。前面我们提到 SUSE 有自己的操作系统，也有 K3s，因此我们尝试用产品化解决近端边缘领域的一些问题。这就是我们在做的 2.7 版本，它将是我们整个 2023 年运作的一个大版本。

然后再走入生产化这个大趋势，我们判断产品质量、迭代质量是非常重要的一块。为什么今年要特别提出来，确实是现在生态和 K8s 碎片化很复杂。我们前面也提到了工程化，如果不做好，Rancher 是开源软件，我们在全球非常多的用户，每个版本出来大家都会发现有一些瑕疵。不过开源软件也有好处，这些信息都是公示出来的，会有临时解决方案，发现问题了可以及时规避。

而且场景确实太多了，有的用户用 AWS，有的用户用 Azure，不同的云效果也不同。现在如果不去做更多的工程化来治理产品质量，情况就会愈发艰难。如果把软件范围限定在某个特定领域，就失去了 K8s 企业管理软件的核心。我们要让大家在不同的场景、不同的资源池里去使用它。

除了前面讲到的 2.7 版本，我们也在尝试去凸显社区版本和商业版本间的差异性。Rancher 本身开源，它相当于提供了一个社区版本，但我们也研发了一个商业版本，叫 Rancher prime。不过它完全是在社区版本的基础之上，再去为商业客户服务。它更加关注于企业付费客户看中的东西，包括安全性的增强、漏洞的及时修复、合规性、软件供应链等。

当然我们也面临着激烈的竞争，我们的策略是，在国内的生态里面用本地的研发团队去治理。国内的 IT 环境有其特殊性，因此我们要有一个独立的治理体系去做这个产品。很明显，在国内大家用的都是国内的几朵“云”，很少去用 AWS、Azure 之类的。操作系统基本选择自主可控的 Linux，而不会采用国际上主流标准的几个大的 Linux。当然也有一些想出海的企业，它们要面临海外的监管标准，那么就需要有软件帮忙辅助。针对于此我们也在积极探索，作为一个外企的软件本身具有优势，在支持国内企业出海的时候，我们也可以把这个经验复用给它。

InfoQ：Rancher Prime 目前是 V2.7 版本，下一个版本或者是说 Rancher Prime 未来的迭代方向规划是怎样的？主要会解决哪些问题？

张智博：2.7 版本是去年 10 月份发布的，2.8 版本预计在 2023 年的 11 月底或者 12 月发布。现在是 2023 年初，其实谈不上特别大的未来迭代。

不过总体思路是不会变的。我们判断现在的趋势是 K8s 向生产环境落地，所以我们所有的产品都将朝着这个方向努力。当然，除了自身的产品迭代以外，我们也会通过技术收购来围绕 Rancher 去建设整体的产品能力。

InfoQ：回溯到主题，企业想要实现降本增效的目标，企业进行 Kubernetes 落地，您有什么建议？

张智博：技术要关注其本质，即 K8s 在解决什么问题，它其实就是为企业采用容器化带来便利。容器化在真正变革企业的应用交付方式，而在这个过程中，使用 K8s 肯定是必不可少的经历。K8s 在走入生产环境后，我们要去关注它整体的稳定性，包括 K8s 整个社区 API 组件的稳定性以及管理平台的稳定性。此外就是安全问题，容器运行时的安全问题、镜像安全的治理、容器网络安全、包括现在提倡的供应链安全。

现在追求的是整体的安全性，它并不是简单几个点。容器化改造，供应链势必会更加复杂。不像以前用虚拟机只需固定一个版本，容器化打包会有多个版本。由于供应链变得愈发复杂，整个行业也急需跟进治理。

考虑完整的稳定性，前提要看清本质。你要知道依靠 K8s 不能帮你立即达成效果，而是在建设过程中，基础设施经过不断地演进，K8s 才能够跟你的业务完整地整合起来。容器化是先行，再是迁移，迁移后具备了标准化的基础设施，进而把它面向多云。

多云之后就拥有了议价权。你可以在不同的云上尝试无状态应用的多元部署，还可以去做 ARM 的实例迁移。我们知道云上 ARM 的价格比 X86 要便宜大概 30%，在这种操作之下，节省成本立竿见影。而且对业务的影响、对架构的影响均是完全可控的。

直播间互动精华整理：

Q1：对于企业级开源软件来说，他们在企业运作中扮演着重要角色，大家对于其安全性有一定的顾虑，如何解决企业用户这部分的担忧？

张智博：越来越多的企业开始采用开源软件，公有云的很多云服务也都是建立在开源软件的基础之上，这是目前全球 IT 行业的大趋势。

首先，开源软件的代码是公开的，它为我们带来便利的同时也潜藏着隐患。所有代码都公开，一些不法分子如黑客，他们也可以阅读代码。他们可以快速找到漏洞，并利用漏洞去入侵你的 IT 系统。所以，好的开源软件定期会有安全公告，它们有安全员不断地去更新公告，并提醒使用者更新版本来修复安全漏洞。所以这里涉及的是一个治理问题。采用开源软件后，如果你只锁定一个版本且永不更新，那必然会有安全风险。

第二个风险是合规性的问题。我们知道开源软件有自己的 license，现在整个业界把开源软件的 license 弄得越来越复杂，有传染性，又不能做二次商业分发。即便有商业分发，可能还会涉及分成。所以企业要用开源软件，必须要确保你所在的行业、你的公司是可以采用它的，一旦采用，就存在合规风险。

第三是开源软件的供应链安全。就像购买一件商品我们要看这个商品的成分表，其实软件也一样。现在提倡要生成一个软件物料清单，就是让使用者去看这个软件所依赖的成分，但是并不是所有开源软件都会提供这份清单，所以企业想去使用开源软件就需要多加考虑。要想在公司里长期运行，并不是改几个参数或者增加几个新功能就可以，必须要考虑到安全风险。

最后说如何解决，在我看来其实没有所谓的“银弹”，不存在一个固定策略供我们解决这个问题。一旦使用了开源软件，就需要建立一个持续治理的机制。

Q2：（Kubernetes 企业落地及管理）对企业技术管理者提出了怎样的要求？从技术布道和人员管理方面是否提出了新要求？

张智博：这要看具体是什么企业，是要求标准化商业场景的企业，还是要求自主可控的企业，不同企业间采购的需求肯定是有区别的。要说对技术管理者有怎样的要求，还是要回到我们最初的问题，用这些软件到底是要采购商业软件，然后二次整合到自己的业务里；还是要完全走开源自建路线。如果看中前者，就要看它的供应链。标准场景关注是否会被它锁定，自主可控则看它的供应链是不是满足合规需求。

如果要走开源自建，就要好好算一个成本账。虽然省下了购买商业软件的资金，但投入的人力成本绝不容忽视。自建带来的技术风险，公司的资金和业务能否支持长期的建设。一旦走入自建就很难中断，中断后前面的努力就变成零了。此外，如果你是自主可控类型的企业，你还要关注你所用的软件成分是否可用，以及能否在自己的生产车间生产，而不能下载下来直接用。

针对技术布道，我建议技术布道者应该尝试去获取一些流量眼球并传递一些新的技术理念。因为 K8s 本身已经不算是新鲜领域，现在并不是布道 K8s 的合适时间节点，去挖掘一些创新点可能更好。

Q3：除了 Rancher Prime，SUSE 在 2023 年还有什么大动作吗？

张智博：其实，我们在去年年底就已经有了对今年的预测。2023 年不会是激进扩张的一年，不止我们，包括全球许多企业也都倾向于持防御姿态，因此并没有特别夸张的大动作。目前我们的目标就是真正扎实地做好商业化的落地，在市场商业化的份额上升的时候，我们能够吃掉匹配我们现在市场地位的份额，对我们来说已经非常值得努力的一件事了。

在这个过程中，安全肯定是我们非常看重的，未来我们将继续围绕着这个点去做，在 Rancher 的基础能力上做安全扩展。

Q4：Rancher prime 有较为成熟的应用案例吗？目前已经合作的企业里面主要应用于哪些行业？

张智博： SUSE 有一个专门的站点来收集、展示客户的应用案例。大家知道，Rancher 这个软件已经存在很多年了，那么它必然积累了大量的、成熟的案例。它遍布的行业也很多，包括金融、保险、银行、制造业、汽车等。

1、关于 K3s 在边缘侧的解决方案和应用案例，请参考：

• 设备太分散？如何一站式管理边缘 OS、K8s 和应用？
  

• SUSE 助力橘盒实现能碳管理平台标准化
  

2、关于 Rancher Prime 更多信息，请下载《Rancher Prime 产品概述白皮书》进行了解；

3、了解更多 SUSE 成功案例，请点击 https://www.suse.com/zh-cn/success/查看。