蚊章汇 - 穿山甲专访
type: channel
link: https://linuxcn.bwsl.wang/category/2090/
items: 一群云端的开源践行者
items: 写到世界充满爱：专访 RSSHub 作者 DIYgod
items: 专访徐亮：解密 UCloud 的工程能力
items: 酌一杯云之酒，以开源佐之 ——专访灵雀云陈恺
items: 轻舟已过万重山：专访网易云陈谔
items: 京东云郭理靖：我对云服务的一些看法
items: 大公司开源怎么做？SOFAStack 给出一个很好的例子
items: 专访青云“四爷”和他的 KubeSphere
items: 专访安全容器 Kata 项目创始人王旭：开源是一件向死而生的事情
items: UCloud 叶理灯谈：Docker、K8S 和 Serverless

一群云端的开源践行者
type: item
date: 2020-06-11T16:43:00+08:00
description: 导读：本文介绍了开源项目 KubeSphere 背后的故事，以及由它引发的对开源软件发展的思考。从一个开源项目的数据说起作为一家主要关注于开源的技术社区，我们每年都会对以中国贡献者为主的开源项目进行一次分析。而随着云计算的发展，我们对由云计算公司发起和推动的开源项目愈加重视，在研究分析过程中，我们发现了一个开源项目的数据表现亮眼，这引起了我们对这个项目背后团队的兴趣。图 1 KubeSphere Grank 指标图这个项目就是 KubeSphere。和其他同类项目相比，KubeSphere 项目的启动时间不算早，2018 年初才启动。但从启动开始，社区的活跃度就屡创新高。从上面的 Grank 指标图可以看出，其在 2019 年度的整体活跃度（红色线）相当高，并在今年有继续提升的趋势。而其平均活跃度指数 6.89 可以排入 Grank 服务端分类榜的前三十。刚好，这个项目背后的负责人我们也很熟悉，之前曾经在《穿山甲专访》栏目中接受过采访——周小四（人称“四爷”），如果你感兴趣，也可以看看之前的采访文章。如今一年过去了，为了了解现在 KubeSphere 项目有什么新的变化，我又和他约时间，再次聊聊 KubeSphere 的发展和下一步的计划，得到一些新的发现和体悟。KubeSphere：“青云”之路谈起 KubeSphere ，容我先简单介绍一下背景。随着云计算技术的发展，容器编排技术 Kubernetes 已经成为云服务商们的角逐重点。按照 Kubernetes 的理念，它定义的是一套标准、一个生态规范，因此，各个生存于其间的云服务商纷纷基于 Kubernetes 推出了各自的发行版和相关的生态软件。这其中既有 Rancher、OpenShift 这样复杂完备的的企业级平台，也有 minikube、k3s 这样简单易用的实验型工具。而今天我们提到的主角 KubeSphere就是一款开源的企业级 Kubernetes 发行版，与其外延的其它组件组成了一个完备的容器生态体系。事实上，我们可以看到，几乎所有的主流云服务商都开发了 Kubernetes 引擎（KE），比如说 TKE、RKE、AKE 等等，并以此作为其基于容器的云服务基础。当然，这些软件作为开源软件生态的一分子，都或早或晚进行了开源。而作为青云QingCloud QKE 服务的引擎，KubeSphere 也是其中的佼佼者，并且，值得注意的是，KubeSphere 从一开始就选择了开源，并以开源作为其产品迭代发展的模式。相比 Kubernetes 领域的其它厂商，KubeSphere 的进入时机不算早，因此，在这种情况下仍能推动决策立项，应该压力不小。周小四和我说，他们当时深入调研和分析了企业的市场需求，发现在该领域尚存在较大的产品空隙。固然，Kubernetes 为企业级容器应用揭晓了新的篇章，但广泛的企业用户在如何用好 Kubernetes 层面，需要突破较多的技术门槛和业务适配的阻碍。因此，他认为，在该领域仍大有可为，这一建议也得到青云QingCloud 的大力支持。而另外一方面，作为一家国内主流的企业级云服务商，青云QingCloud 也一直在密切跟进 Kubernetes 领域的技术发展和产品形态。所谓磨刀不误砍柴功，正是这一年多提前付出的预研投入，让周小四及其团队在2018 年初开始 KubeSphere 的研发时，就能迅速发布经过了精心设计的 KubeSphere，并于半年后在青云QingCloud IaaS 基础设施之上推出了 QKE——KubeSphere on QingCloud 容器服务。图 2 KubeSphere 路线图倏忽间过去了两年，KubeSphere 也即将迭代到 3.0，对于它发展至今，并取得今天的成绩，周小四认为主要得益于以下原因：天时：站在 Kubernetes 的肩膀上，处于容器技术的大时代；地利：开源为它赋予了成长为参天大树的土壤；人和：来自团队和社区贡献者对容器技术的深刻理解、对用户需求的精准把握和在产品设计上的匠心独运。KubeSphere 的天时扑面而来的云原生时代，是机遇也是挑战。这里，我们看到了 Docker 公司如荧惑一样迅速升起又快速淡去，我们也看到了谷歌力推的 Kubernetes 从天下三分到一统容器编排领域，真正揭开了云原生时代的大幕。并不是每个身处大潮之中的都是弄潮儿。说实话，这些年我看过很多云计算领域的企业或因押错注而不得不更弦易辙，或因产品没有足够的独特优势而泯然众人。对于一家国内主流的企业级云服务商，青云QingCloud 不仅一早看好 Kubernetes，又没有匆匆下场，更在局势渐明时能决然重兵压上，其实我是有些佩服和羡慕的。在和周小四的对话中，他说，在潜心研究了 Kubernetes 生态一年后…

写到世界充满爱：专访 RSSHub 作者 DIYgod
type: item
date: 2020-01-15T18:55:00+08:00
description: 拥有一个很萌的头像的 DIYgod 是一个当前任职于 B 站的年轻开发者，他是在 GitHub 拥有一万星标（本文发表时）的 RSSHub 的创始人，也是 APlayer（4.4k 星标）、DPlayer （8k 星标）等开源项目的创始人。在我所认识的开源开发者当中，DIYgod 是一个很优秀的开源社区贡献者，所以今天我们邀请到了 DIYgod 来参加我们的穿山甲专访。DIYgod 很有 B 站风格的头像问：您可以先自我介绍一下么？DIYgod：Hi，大家好，我是 DIYgod，一名爱好开源的 JavaScript 开发者 —— 写代码是热爱，写到世界充满爱。我的梦想是成为一名可以养活自己的自由职业者。问：目前你已经是自由职业状态，还是说仍然在企业工作呢？DIYgod：现在在哔哩哔哩（B 站）做前端。问：能否向读者介绍一下你的开源项目 RSSHub 呢？DIYgod：RSSHub 是一个用来生成 RSS 订阅源的工具，它可以给任何奇奇怪怪的内容生成 RSS 订阅源，实现万物皆可 RSS。RSSHub 正在借助于开源社区的力量快速发展中，目前已适配了数百家网站的上千项内容。使用时只需要简单的编辑下地址即可获得需要的订阅源。问：对于目前的很多人来说，RSS 已经鲜为人知，现在很多新生代的互联网用户已经不再使用 RSS，他们可能更习惯于使用信息流应用。你当初因为什么原因选择做了 RSSHub ，是有什么契机么？DIYgod：我本身是一个 RSS 重度用户，之前关注了几个有意思的微博博主，但经常打开微博去刷更新太麻烦了，就写了个简单的 Node.JS 脚本生成 RSS 加到自己的订阅里，后来又写了哔哩哔哩的 RSS、网易云音乐的 RSS，越来越多，最后就干脆把它们合成了一个项目，取名 RSSHub。 问：说起来，你其实是将微博的信息流推送的形式，借助于自己的编程能力，转化为 RSS 的被动拉取的形态。那对于 RSS 和 现在的信息流应用，你有什么看法么？DIYgod：信息流应用基本都有自己的一套推荐算法，受益于此，可以获得更轻松愉快的阅读体验；但另一方面来看，用户丧失了内容选择的主动权，看到的不一定是自己真正想看的，稍不注意也会消耗自己大量的时间，阅读效率更低。RSS 可以选择自己真正想看的内容，阅读效率更高，但这也导致使用门槛比信息流应用高了很多。信息流应用的另一个问题是它无法集中地收取信息，时不时地打开微博、Twitter、YouTube、哔哩哔哩，去翻看我关注的人有没有更新，实在是一件痛苦的事。最后是 RSS 可以做到没有遗漏地收取信息，而信息流应用很容易遗漏。问：可以看出来，你是一个重度的 RSS 用户，不仅仅是用户，更是为 RSS 生态添砖加瓦。你自己平时都是怎么样应用 RSS 的呢？DIYgod：大家都知道 RSS 是一种用来做消息聚合的格式规范，有着更高的阅读效率、更好的阅读体验、可以掌握主动权等等优点，但它的用途一直被大家低估，除了最常用的在 RSS 阅读器里使用，还可以通过 BT 客户端实现自动的 BT 下载用来追美剧或动漫、通过播客客户端订阅和收听播客、通过 IFTTT 与各种各样的东西联动等等。我平时除了常规的使用 RSS 阅读器订阅，还会在群晖的 BT 客户端里订阅美剧的 RSS，这样美剧更新后 BT 客户端就会自动把最新一集下载到硬盘里，晚上下班回家打开电视就可以直接看了。此外是自动下载我的 B 站投币视频，整个流程是“投币操作 -> RSS 更新 -> IFTTT 触发 Webhook -> 服务器下载”，实现方法在我的博客里有介绍：https://diygod.me/download-webhook 。然后还有我的 Telegram 频道： https://t.me/awesomeDIYgod ，它通过 IFTTT 监听了很多 RSS 更新，有 DIYgod 的博客更新、DIYgod 的 PSN 奖杯、DIYgod 的 Twitter 更新、DIYgod 喜欢的网易云音乐、DIYgod 的 bilibili 投币视频等等，几乎包括了我的全部动态。问：说起来集中在一个地方收取信息，你怎么看曾经的“即刻”应用，即刻应用也可以关注特定的人、微博之类的，在一个地方查看所有的信息。DIYgod：我非常喜欢“即刻”，在“即刻”倒闭之前也一直在使用它，早期很像一个 RSS 阅读器，甚至真的可以订阅 RSS，但后来这些功能越来越淡化直至去掉了，取而代之的都是 UGC 内容了。 问: RSSHub 里有非常多的“路由”，包括社交媒体、新媒体、论坛等。除了我们一般意义上的信息流转化 RSS 以外，RSSHub 还有非常多有意思的 Feed，比如高校教务处通知的 RSS Feed，就你自己而言，你最喜欢 RSSHub 中的哪一…

专访徐亮：解密 UCloud 的工程能力
type: item
date: 2019-12-17T18:11:00+08:00
description: 似乎每一家互联网公司都有一种属于自己的气质，我接触过很多知名互联网公司的技术专家，其中有一家公司技术专家给了非常深的印象，那就是 UCloud。在和 UCloud 技术专家的沟通中，我深深感受到这是一支极为自信、动手能力很强的技术团队。近期，我在UCloud上海办公室采访了 UCloud 虚拟网络负责人徐亮，就如同我采访过的很多一线技术领军人物一样，徐亮给我带来的直接印象就是执着、朴实和认真。说到自己擅长的网络技术领域，徐亮神采飞扬 在和他的谈话中，我听到了不少 UCloud 有趣的研发故事，让我对 UCloud 技术团队的动手能力有了更深的认识。尤其是， 当UCloud 所倡行的“客户为先”、“客户的需求就是我们的下一个产品”等理念从一个专注于前沿技术的技术领军人物的谈吐中汩汩冒出时，印象更深刻了。转化：实验室技术能力 ➡️➡️➡️ 生产能力我为什么认为 UCloud 的技术团队是一支动手能力极强，这得从他们的 25G 智能网卡项目说起。 众所周知，如何将实验室形成的技术能力转化成生产能力，需要很好的工程能力，25G 智能网卡从实验室到生产环境恰恰体现了这样的工程能力。“去年我们将 25G 智能网卡产品投入到生产环境，实际上，UCloud 从 2016 年就开始跟踪这项技术。这期间我们测试了很多厂商的智能网卡，有的智能网卡的性能相当不错。但是阻碍我们将其投入生产环境的一个重要原因是，它和公有云所要求的热迁移的能力不兼容。所以，虽然这些智能网卡的性能很好，但是没有办法应用到公有云环境。”徐亮介绍道。其实，业界一些公有云厂商很早就在借助这些智能网卡做加速，但是在处理热迁移的时候做不到用户的无感迁移，必须要用户手动修改虚机里面网络的配置。这虽然能够达到目的，但是对用户并不友好。对此，UCloud 秉持一向的态度：“我们一定要做到用户没有额外的负担，这样对用户来说才是最佳的方案，才是成熟的、用户友好的方案。”据徐亮回忆，情况在 2017 年底出现了一个转机。彼时，Linux 内核社区开始讨论智能网卡如何能够无感的支持热迁移，UCloud 技术团队第一时间进行了深入的技术追踪和研究。从社区开始讨论和开发，最后到 2018 年 5 月份时该功能趋于稳定，才被接受到 Linux 的内核主线里。“在发现该功能已经基本成熟后，我们马上就把这个补丁应用回 UCloud 的定制内核当中，跟智能网卡厂商一起研究，很快就在实验室完成了该产品。”徐亮接着谈到，“然后我们就开始在线上做公测。这个时候就非常体现我们的工程能力。”在徐亮的团队将智能网卡投入生产环境时，虽然也发生了一些问题，但是就算在连固件都升级过两次的情况下、对用户的业务并没有产生太大的影响，我想这就是 UCloud 技术团队的工程能力一个重要体现——“我的固件都升级了，而用户业务不受影响。”驱动：客户为先 ➡️➡️➡️ 工程能力在我采访的 UCloud 技术人员中，徐亮并不是第一个提到“客户为先”、“客户的需求就是我们下一个产品”等理念的，在与 UCloud 技术副总裁杨镭、私有云和容器产品线负责人叶理灯等人的采访沟通中他们都曾提及这一贯彻于 UCloud 所有技术、产品研发中的理念。他们对于“客户为先”以及在产品的研发、技术专研中的践行，让我深信他们从骨子里认可这样一个价值观。可以说，“用户为先”的理念驱动着其工程能力的形成。谈到他们的经典网络升级至 VPC 2.0 项目，也许你会理解我说的。以“客户为先”为出发点据我了解，UCloud 应该是全球唯一一家把经典网络升级到 VPC 2.0 网络的公有云厂商。在我和多位 UCloud 技术人员的接触中，这个项目被多次提及，它的实施可谓是历经周折，遇到的困难很多。“我们的出发点是‘客户是不是有这个诉求？这件事情对客户来说是不是有好处？’如果是的话，那我们为什么不做呢？“。当问及项目出发点时，徐亮谈到。显然，如果能够透明的将经典网络升级至 VPC 网络，对于用户来说无疑是有诉求和好处，不需要自行迁移或是同时维护两个架构。但，UCloud 一开始低估了这个项目的难度。徐亮说，“为什么这么难？因为一个默认的前提条件出现了变化——我们以前假设用户的 IP 是唯一的，这不光体现在网络产品上，还包括数据库产品、存储产品等，都会假设用户的 IP 是唯一的——在之前的经典网络时，该前提条件似乎是显而易见的。但在我们要升级到 VPC 2.0 时，我们突然发现这个 IP 变得不再唯一，由于不同的租户网络是完全隔离的，IP 完全是可以重复的。” 因此，这个项目不再是一个纯粹的网络项目，意味着 UCloud 平台上的所有产品都需要升级，都要支持这个重要变化，所以在工程上存在非常多的协调工作。这是一件非常、非常难的事，是一个涉及到全公司协调的能力。“客户为先”驱动产品…

酌一杯云之酒，以开源佐之 ——专访灵雀云陈恺
type: item
date: 2019-11-12T06:20:00+08:00
description: 在云原生技术实践峰会召开前夕，匆匆奔赴北京的我，见到了刚刚从美国飞回来，却毫无时差之扰的陈恺——灵雀云的 CTO。虽然我早就和灵雀云有了联系，也有好几位朋友在灵雀云任职，不过作为国内新锐云原生厂商灵雀云的创始人之一的陈恺，我之前并没有直接接触过。虽然我们是初次相识，但是在聊到了开源，聊到云技术，我们以云做老酒，以开源为佐酒菜，很快就俨然如同老友般进入了旁若无人的状态——旁边的朋友被我们暂时性忽视了，虽然这张合影就是她帮我们照的。 :D滥觞始于云计算。缘起陈恺和左玥等人在创立灵雀云之前，他们都曾在微软 Azure 从事云计算领域的专业研究。回忆起那时候，陈恺说，那时他们也在想象云里面的应用应该长什么样子，设计最早版本的“云服务模型”、“云服务运行时”，而现在回过头看，其实云计算的发展已经千差万别。2013 年 Docker 出现以后，左玥和陈恺他们第一时间就意识到容器技术会很有影响力，它重新了定义云技术之后发展的路径，这恍然在他们面前掀开了一个新的时代，于是灵雀云诞生了。云技术领域发展演变的非常快，事实上，在云计算早期并不能预见到如今的云计算格局。“早期我们尝试过很多东西，总的想法是觉得容器就像是一种轻量级虚拟机，一种新的虚拟化技术。就像虚拟机需要虚拟机平台去作为它的管理平台一样，容器也需要一个容器云平台，所以我们早期想做的就是容器云平台，这一点一直没变，现在也是在做企业级的容器平台。”陈恺说，“我们最早的技术选型是 Mesos 技术栈，经历了几次大的改变，包括从 Mesos 转到支持当时的三种主流的调度系统，然后开始倾向于Kubernetes，到最后全面转向 Kubernetes，以及最近在架构上和 Kubernetes全面对齐，把我们的平台做成一个 Kubernetes 原生的平台，技术上一直在做升级。”云原生吞噬一切，Kubernetes 编排一切不知不觉之间，云原生已经吞噬了整个世界，如今，云原生已经是技术界最时髦的词汇之一。而应运而生并推动了这一切发生的云原生计算基金会（CNCF）也在不同的时期、不同的场所，对云原生做了不同角度的解读。那么作为一家很早就涉入云计算领域的新锐力量，陈恺对云原生的理解是什么呢？陈恺说，“CNCF 旗下涵盖这么多云计算的技术、产品和服务，所以它对‘云原生’的定义必然会比较宽泛，但的确，‘云原生’不是一个特定的技术或者一种方法，很难把它精确的定义，也不应该把它和具体的技术对等，比如说把它直接跟 Kubernetes 挂钩，跟 Kubernetes 没关系就不是云原生？跟 Kubernetes 有关系就叫云原生？这两者都是不对的。”他接着补充说，“我对云原生定义的观点也是比较宽泛的，（云原生）就是让应用能够最大化的释放云计算生产力的一系列的思维方式、最佳实践和技术体系，这里的关键词是让应用去释放云计算最大的生产力。这是关键。所有的云原生我觉得都是首先应该围绕应用的。什么叫‘云原生’？主要是以应用为中心的。‘原生’这个名字看起来起的不是很好，听上去似乎是只有在云上生出来的才叫‘云原生’，或者只有在公有云上才叫‘云原生’，并不是。关键不是说你在哪里跑你的应用，而是你是不是能够释放云的生产力——广义的云的生产力。”在容器编排市场尚三分天下的时候，很多容器服务商都同时支持三种主流的编排系统，当时有一些观点认为这种三分格局会持续比较久，然而 Kubernetes 迅速崛起，很快就一家独大地统治了容器编排市场。陈恺说，“我觉得当时 Kubernetes 可以很快的从编排之争当中胜出，并没有那么让人吃惊。为什么我们比较早的时候就开始往 Kubernetes 发力？其实第一个触发的点比较偶然。那时经常会有人问起三种容器编排系统各自的优势是什么？我们做了一些研究，业界有一些对比，当时我印象比较深的是一个细节，我觉得这才是关键——有一项对比的是基于这三种技术有哪些商业版？基于 Docker Swarm 的有一个商业版 Docker EE；Mesos 有一个商业版 MesosPhere；基于 Kubernetes 有好多商业版——这是本质的区别。这一点对它们的社区的发展速度和后续影响很广，因为它是开放式的治理。Kubernetes 虽然是谷歌发明的，但是它是开放式治理，背后有很多商业版。如果从开源软件本身社区发展角度看，很关键一点是上面有多少商业版，商业版越多说明从开源软件里面可以获利的公司越多，这样就有了正向的良性循环，会有更多资源投进来，社区里面参与的人就会更多，最后的发展会更好，生态会很繁荣。当时从这一点我们就觉得这个生态肯定会赢。”Kubernetes 一统容器编排市场的今天，业界一些专家对此有所忧虑，担心这种垄断会形成市场压制。从长期来看，如果 Kubernetes 的发展会形成类似 Android 一样的…

轻舟已过万重山：专访网易云陈谔
type: item
date: 2019-08-05T16:14:00+08:00
description: 从炎热的夏日中走入到钱塘江畔清凉的网易云会客室，我见到了陈谔，开始这次“轻舟”之行。说实话，初次近距离见到陈谔时，心中有点愕然，作为网易杭研的元老之一、网易云基础服务的领头人，我竟然从他身上感到一点点腼腆和技术人员的质朴。联想到之前网易云这边作为背景信息给出的个人介绍，这样的一位领军人物，居然自谦自己“对分布式系统设计开发、云计算平台系统架构有一定的经验和理解”，我不禁有些恍然。我接触和采访过很多开源和互联网公司的技术领袖，陈谔应该是我见过的最温和而又不失自信的人之一，他的脸上总是浮现着内敛的笑容，让我们在谈话的一开始，就有了一个良好的氛围。受访者（左）：网易云陈谔，采访者（右）：老王网易云：千锤百炼终成型和很多互联网公司推出的云服务一样，网易云也是一个脱胎于内部实践的云服务。网易杭州研究院作为整个网易公司的技术攻坚力量和创新业务孵化团队，随着网易业务和规模的不断的变化，杭州研究院面临着非常大的压力去做好基础设施的相关工作。随着移动互联网的到来，原本可以很好应对博客、游戏等业务的 IT 基础设施逐渐变得捉襟见肘，原本的资源调度能力无法处理好随着新业务和新模式的快速增长和迭代而产生的需求和复杂度。IT 基础设施成为了当时网易发展业务的新瓶颈。为了能够更好的服务网易内部的业务， 2012 年，网易杭州研究院组建了专门的云平台产品部，来建设网易内部使用的云计算平台，以应对移动互联网到来而产生的更加复杂应用带来的基础设施需求。随着网易云产品对内提供服务，规模上的问题被逐渐解决，但是，产品的研发模式也在不断的迭代，网易内部开始不断地实践微服务架构。在这个过程中，陈谔感觉到，现有的 IaaS 产品和 PaaS 产品已经渐渐无法支撑来自微服务架构的复杂度，但在那时，云原生理念和技术尚未成熟的时代，对于微服务的探索只能独立践行。网易云针对性的提供了 CI/CD、分布式架构链路跟踪、服务治理的工具，帮助用户更好的去实践微服务。到了 2015 年 7 月，随着 CNCF 的成立，这时陈谔发现，网易云的很多产品和服务，和 CNCF 的理念是一致的或相似的，于是，网易云决定将自己的探索和成果更好地结合社区的发展，向社区贡献自己的努力，也吸纳来自社区的营养，将网易云的发展和开源社区的路线结合起来。也正因为拥抱社区，网易云很早就走上了 Kubernetes + Docker 的发展路线。谈起对于 Docker 和 Kubernetes 的选择，陈谔表示，网易云选择 Docker 和 Kubernetes 并不是偶然之下的决定。实际上，早在 Docker 出现之前，网易云已经开始使用 LXC 技术来进行更细粒度的资源分配，实现了类似的容器技术栈，在此过程中，陈谔及其团队亲历了 LXC 技术在实施的过程中各种问题和技术缺陷带来的困扰。而 Docker 的横空出世使得整个云计算领域眼前一亮。虽然网易云自建的技术栈已经可以满足当时及近期业务的需求，但作为具有技术远瞻力的技术负责人，陈谔知道，相比于得到业界普遍看好的 Docker，自研的专属技术栈的生态环境狭窄，技术人员的培养成本也居高不下。而另外一方面，Docker 的镜像机制、分层文件系统机制，也使得之前在 LXC 技术栈里面斩荆披棘的网易云似乎看到容器技术发展的堂皇大道，使用 Docker 也就变得顺理成章。因此，网易云十分自然的就完成了从 LXC 向 Docker 的转移。我问及 Kubernetes 的选择，陈谔笑了笑，他提到，网易云对于 Kubernetes 的支持是非常早的，在早期 Kubernetes、Swarm、Mesos 尚三足鼎立的时候，网易云就坚定的投入了 Kubernetes 生态。这一点和网易云过去在微服务、容器编排方面的实践是密不可分的。Kubernetes 解决了网易云在过去运维过程中遇到的诸多问题：如何进行弹性伸缩、如何进行服务调度、如何使用配置来进行控制。Kubernetes 所提供的配置能力，特别适合于需要解决微服务架构编排问题的网易云。对于网易云来说，他们并不是一个刻意追求新奇的团队，相比于新兴的技术，网易云更在乎什么能够解决问题。显然，对于微服务架构支持最好的 Kubernetes 成为最终之选。企业云：只为解决客户问题网易云和很多云计算公司不同，没有将目光全部投放在公有云上，而是专注于为企业提供业务云化的解决方案。网易云也和容器云厂商的定位不同，容器是网易云的产品，更是网易云的工具，因此网易云虽然很早就应用了 Docker、Kubernetes 等技术，但是并没有突出这些看起来非常时髦的技术名词，而是根据企业需求，更多的将这些作为服务于上层的微服务产品的基础。通过结合容器的网络方案、存储方案等云原生技术积累，网易云希望更好的服务自己的客户。陈谔说，网易云之所以选择了企业…

京东云郭理靖：我对云服务的一些看法
type: item
date: 2019-07-30T17:53:00+08:00
description: 本期人物介绍：郭理靖，京东云产品研发部高级总监、产品委员会主席，专注于公有云服务、Docker、API 与数据开放平台、数据库服务等领域。擅长数据库、分布式存储系统、高可用服务架构等技术。在任职期间，郭理靖研发上线了 MySQL、SQL Server、MongoDB、PostgerSQL、MariaDB、Percona、JDW（数据仓库）、DRDS（分布式数据库服务）、时序数据库、TiDB、BDS（区块链 BI 数据分析服务）等多款京东云产品 。京东云不仅是国内第一家支持 MySQL 8.0 的云厂商，也是国内第一家支持 MariaDB 的云厂商，而区块链 BI 数据分析服务也是可以代表全球区块链先进技术的创新产品，聚合了业界知名项目的核心数据，目前 BDS 已经对外开源。前言盛夏，在一家幽静的咖啡馆，我见到了匆匆赶来的郭理靖。我们深入谈了关于云计算、关于数据库方面的一些话题。我将这些谈话中的精彩内容整理出来，以飨读者。与京东云共同成长的人在谈话中，我了解到，郭理靖在京东的工作历程是伴随着京东云的发展一路走过来的。从 2006 年到现在，郭理靖一直专注于云计算领域。从 2013 年京东云作为内部的基础设施云服务开始，他亲历了京东云从内部自用到正式商用的多个阶段的发展。作为核心人员之一，郭理靖又在其中扮演了什么样的角色呢？“其实我有两层角色，”郭理靖说到，“第一层，我负责数据库相关的服务，包括 RDS、数据仓库，现在京东云还推出了时序数据库、分布式数据库等，把京东技术体系内部的各种数据库的技术拿出来。另外，我还在京东云产品委员会，负责对京东云产品进行中长期规划， 评审产品开发可行性与必要性，规范产品上线流程，跟踪竞品动态与对标，统一产品培训资料，推进内、外部培训认证机制，精心打造京东云产品。”谈到这里，我发现一个现象，根据我的了解，包括京东云在内的很多公有云服务商的产品负责人都是出身于一线技术岗位。之前也有人跟我说，“为什么云服务行业是技术人员来担任产品经理，这是因为云计算服务就是技术性的产品，不懂技术的没法制定和设计这样的产品出来。”郭理靖表示：“这种说法是比较有道理的，因为整个云计算的产品主要是给技术人员使用，要求产品经理有很强的技术功底、技术视野以及技术敏感度，不是技术背景出身的产品经理，难于理解用户诉求，很多细节没法把握。比如做时序数据库，到底是做成什么样的时序数据库，提供什么样的功能，只有做过技术支撑的产品经理，才能理解要什么样的产品和什么样的用户体验。”从私有云到公有云最初，京东云只是作为内部基础设施服务，那时候京东云的人手也比较少，最初采用的技术是 OpenStack 技术栈，从 2014 年开始全部转向了 Docker 容器技术。那个时候，京东已经把统一监控、部署、代码管理、日志服务这些技术部分都已经建设完备了，但是还缺乏一个核心的运行环境，而其时崛起的容器技术正好填补了这个空白。这个技术体系一直发展到现在。到 2016 年， 京东云平台经历内部历练和打磨后，已经有了大规模的对外开放的技术基础了。在基础架构细节梳理的比较清晰、底层的基础设施服务和中间件服务都逐渐成熟、内部的使用和运营非常顺畅之后，当时决定，可以对外做公有云了。当然，做公有云和私有云的难度不是一个量级的，私有云很多事情都是在掌控范围之内，而做公有云要改造的东西特别多的。这包括网络管控、存储结构改造等几大的难点。 然而，京东云以后来者居上的节奏，从决定要对外开放，到真正的对外开往，仅用了几个月的时间，在 2016 年的 4 月 1 号正式对外开放公有云服务。在京东云的公有云服务上线之后，逐渐往上增加各种产品和服务。产品从 20 多款已丰富至现在的 220 多款。云计算从最初一个概念的提出，到后来发展为公有云、私有云、混合云等不同的形态，关于到底哪种云服务形态才是未来，人们也有不同的看法。不过从当前阶段看起来，主流的认识是，在认可公有云的基础上，企业希望有一种“私有化”的公有云服务。那么如何看待公有云、私有云以及接下来的发展呢？郭理靖说：“这个事情我们分两方面看，一方面就是看现状，另外一方面看接下去的发展。”“当前的云服务的现状是公有云、私有云、混合云并存，而且这个阶段可能会比较长。……京东也在做私有云服务，……我们称之为 JDStack 专有云，专业服务中大型企业以及政务云 。JDStack 既能把京东云所有的能力集成起来，而又提供灵活选配的功能，除了核心的几个组件，如 SDN、RDS 等必需的产品之外，其他产品都可以选配，用户可以将京东云的能力复制一份带回家，这个产品目前的市场前景也非常好。”，同样，对于混合云，“我们可以提供的 VPN 以及专线接入，打通用户的私有云与我们的公有云，我们有完整的混合云方案，京东云的很多客户也是采用混合云的模式。”至…

大公司开源怎么做？SOFAStack 给出一个很好的例子
type: item
date: 2019-07-23T05:45:00+08:00
description: 蚂蚁金服的 SOFAStack 作为一个成功地将企业私有项目转化为开源核心模式的知名案例，我们之前对背后的思考和推动力做过专题分析，但是具体这件事是如何在蚂蚁金服内部发生的、是如何实操的，有很多读者向我们表示非常感兴趣，而我觉得这也是其它技术公司所正在探索和思考的方向。因此，上个月底，老王在参加上海举办的 KubeCon 2019 时，遇到了蚂蚁金服 SOFA 团队的余淮，他目前在蚂蚁金服中间件团队服务与框架组具体负责开发框架与 SOFAStack 的开源工作。于是，参会之余，我和余淮就 SOFA 开源的实操方面进行了深入的沟通，现将谈话所得整理给大家。SOFA 与开源2018 年，SOFAStack 开始开源之后，处于关注，我曾向蚂蚁金服中间件负责人杨冰了解过为什么要将 SOFA 开源的背后思考，以及 SOFA 发展迭代的历程。目前，SOFA 的架构已经发展到 SOFA 5 阶段，前任的 SOFA 开源负责人鲁直也向我介绍过 SOFA 5 中重点推进的方向，主要包括 Service Mesh 和 Serverless，以及分布式事务 Seata 的落地等。而在今年上半年他们又开源了分布式事务框架 Seata 和服务注册中心 SOFARegistry。作为一个成功的开源核心模式的项目，我非常关注 SOFA 开源的实操是如何进行的，是如何进行开源治理的，作为 SOFA 团队的老朋友，我们话题就直接从 SOFA 的开源治理聊起。以 SOFA 为例：公司内部软件的开源流程余淮说，从 2015 年开始，蚂蚁金服开启了金融科技对外输出的战略，SOFAStack 也走出了蚂蚁金服，甚至跨越了国界，被更多金融机构与合作伙伴所使用，如天弘基金、信美互信、南京银行、PayTM、DANA 钱包等。在与合作伙伴以及客户的沟通、合作过程中，他们发现了 SOFAStack 的理念和能力也正是很多金融行业的企业所需要的。在蚂蚁金融科技对外输出的过程中，内部已经对 SOFAStack 进行了一定程度的代码重构，例如历史兼容逻辑的剥离等，但是并未能达到直接开源的标准。 关于开源，其内部一直有开源的讨论，到 2017 年双十一结束后正式决定开源。经过了一系列的准备，2018 年 4 月，完成了对 SOFA 项目的满足了开源改造的标准后，SOFAStack 马上宣布正式开源框架中部分重要组件。SOFA 团队给开源定的策略叫「 开源核心 （ Open Core ） 」，顾名思义就是要将接口层以及核心实现都开源，以可扩展化的方式来层层构建 SOFAStack 的能力，保证 SOFAStack 的内部版本和开源的版本采用的是同一个内核。为此 SOFAStack 做了大量的改造和重构工作。 在开源的具体考量上，余淮表示，SOFAStack 的开源改造基本上有三条原则，分别是高可扩展性、对内兼容历史版本、对外兼容业界标准。 以 SOFARPC 重构为例，大概经历了这样的过程：首先需要将 SOFARPC 进行了一次核心接口和模型抽象，然后增加了扩展点机制和事件总线机制，所有的对内、对外实现都基于这些核心接口和模型去扩展，并且保证这些扩展能力都是平等的、可选的；接着将核心的处理逻辑实现迁移到这套接口和模型上来，保证 RPC 能力完整可用；然后需要将 RPC 里一些对接内部系统的、兼容历史逻辑的代码做成内部扩展，并进行全量测试验证，确保和已有线上的历史方案的兼容，发布上线；最后会调研业界的一些开源标准方案和实现，并对其进行兼容，例如 SOFARPC 不仅对接自己的 SOFARegistry 的实现，还兼容了 Zookeeper、Etcd、Nacos 等业界优秀的注册中心方案。虽然上面重构过程听上去没那么复杂，但是在实际过程中还是非常考验团队的技术能力的，特别是在抽象核心接口和模型的时候，为了做到既兼容内部又兼容外部，这需要进行大量的调研工作，才能做好这层较为通用抽象。其次在对内逻辑兼容的时候，由于内部的历史负担还是比较重的，为了能让重构的代码安全上线，团队也做了很多事情。还是举 SOFARPC 的例子，蚂蚁内部的服务路由过程比开源是要复杂很多的，特别是配合蚂蚁特有的单元化部署以及异地多活的能力，有时候需要多层路由才能找到目标地址。为了验证重构后逻辑的正确性，除了在开源代码里有单元测试用例外，SOFA 团队在内部也构建了一套非常完善的集成框架，专门用来测试已有逻辑的兼容性及正确性。基于开源核心这套思想建设 SOFAStack 以后，其实对开发人员的工作量来不会变少，反而可能是增多的。这是因为在写代码的同时，需要更多的考虑内部外部的使用情况，对代码质量也提出了更高的要求，开发流程会变得更加复杂。例如，内部新增一个特性，在以前可能直接修改代码经过测试就发布上线了，但现在的话会去思考这…

专访青云“四爷”和他的 KubeSphere
type: item
date: 2019-07-22T06:08:00+08:00
description: 在国内的云服务市场当中，青云QingCloud 一直是一个积极活跃的身影，但是我却从来没有和他们直接接触过，而在上个月刚刚结束的 KubeCon 2019 上，我见到了江湖人称“四爷”的青云QingCloud 容器平台负责人周小四。自以为尚不算健谈的我，跟人聊起技术来，居然聊得非常投机。期间，我和四爷聊起了 KubeSphere 容器平台，也对青云QingCloud 的容器战略有了一些管中窥豹的了解。我想将这些谈话整理出来分享给大家，希望可以通过我的侧写让大家也认识一下这位“四爷”和他的团队打造的 KubeSphere。谈话自然是从我所不了解的青云QingCloud 开始的。天然的企业服务提供者说起青云QingCloud，自然不能放过其背后的历史，这段与众不同的历史，造就了这家与众不同的云计算企业。谈起云计算，大家会想起国内公有云市场占有率较高的一些互联网公司旗下的云服务商，这些公司的云计算业务最初大多是从内部的云计算技术能力转化出来的，将其在内部打造的云计算能力开放给公众，从而形成了我们所熟悉的多个云计算平台。青云QingCloud 从一开始就走上了和绝大多数云计算创业企业不同的道路——自研云计算架构。“与这些云计算公司不同，青云QingCloud 从 2012 年公司创立的那一刻开始，就是一个立足于为企业服务的云计算企业，其三位创始人均有多年在 IBM 工作的深厚背景，使得他们对于企业级用户的市场和用户的需求更加敏感，也能更加准确把握企业用户的需求和痛点。”四爷介绍说，“并且，青云QingCloud 的创始人均是资深的技术研发出身，对于技术方向的发展更加敏感，也正是如此，青云从一开始就走上了和绝大多数云计算创业企业不同的道路——自研云计算架构。”说到这里，四爷眼中洋溢着自信的眼神，作为一个同样从事了多年技术工作的老兵，我对这种技术驱动型的公司更加感兴趣了。私有云成就下的青云从 2012 年开始，青云QingCloud 便开始进行自研底层云计算架构的研究。自研架构所需要付出的技术成本，使得青云的公有云服务上线花费了一年半的时间，但是，付出总有回报，在自研架构上的投入，使得青云QingCloud更加灵活和富有创造力，可以更加专心地为企业提供更优质的服务。而同时期一些使用 OpenStack 作为基础设施的云计算企业，却受制于社区的发展速度，不得不在底层基础设施的优化上花费大量的精力。说到这里，四爷表示，“这为青云争取到了宝贵的时间！”到了 2014 年，青云QingCloud 已经取得了长足的发展。这个时候他们意识到，在当时的环境下只做公有云服务是“一条腿走路”，无法获得长时间的可持续发展，而私有云服务能够更好的发挥青云QingCloud 在企业服务的能力和经验。因此，青云开始正式进军私有云市场，并在次年年初，成功拿下中国银行、招商银行等的私有云业务。随着青云QingCloud 的私有云业务的发展一路开疆拓土，他们逐渐建立起来成熟完善的公有云、私有云、托管云、混合云一体化的产品服务体系，后续不断得到越来越多客户的认可，我们耳熟能详的光大银行、泰康保险、中国太平、江苏交通控股、华润创业、本钢集团、国航、四川航空、好未来、VIPKID 等，都是青云的客户。在云业务一片向好的环境下，容器时代正在悄悄的来临了。容器时代来临，KubeSphere 应运而生容器时代的到来，让各家云服务商都开始积极布局容器服务，而在青云QingCloud，容器服务的负责人便是我们今天谈话的主角周小四——圈内亲切的称其为“四爷”。从 Docker 开始在当时，开源社区内的主流容器方案，一种是一出现就迅速风靡技术世界的 Docker 技术，另一个则是同样源自 CGroup 技术的 LXC。那个时候，看起来 LXC 的目标更远大，但是在对这两种技术方向进行分析后，最终四爷选择了 Docker 的方案。我们也曾经在容器技术初现萌芽时，对出现的各种容器技术做过跟踪，因此，我也好奇为什么四爷会在 Docker 技术初生时就押注 Docker，因为这不仅仅是社区爱好，这个决策肯定会影响到公司的技术方向和时间差优势。四爷对此的解释说，“2013 年才提出的 Docker 虽然很年轻，但是作为一个新的容器化解决方案，它所提出的解决方案适合这个面向应用、快速迭代、微服务正在兴起的大趋势，符合并适合现行的软件开发模式发展，可以让技术把更多的精力放在如何构建一个更好的应用上。”而 LXC 则延续了重型虚拟机时代的思路，将更多的精力放在了如何更好的隔离宿主环境与容器内的环境上。这很重要，但是已经不再适合如今快节奏、快迭代的开发环境了，因此，他认为 Docker 一定会是最终的胜利者，决定选择 Docker 作为青云QingCloud 容器服务平台的底层设施。虽然现在回过头看，Doc…

专访安全容器 Kata 项目创始人王旭：开源是一件向死而生的事情
type: item
date: 2019-07-04T20:11:00+08:00
description: 6 月 25 日，我代表 Linux 中国社区团队参加了本次 KubeCon 2019（上海）峰会，期间有幸和安全容器 runV 的创始人王旭做了一番长谈，就云原生技术、安全容器、开源与初创企业等话题进行了深入沟通。现将这些话题整理其精要分享给大家。互联网技术发展速度之快是所有从业者甚至非从业者都能感受到的。尤记得在世纪之交时，那时候互联网刚刚在中国开始向民用普及，不说支撑大规模的网站访问量的相关技术，就连 Linux、负载均衡甚至都没有被普遍使用。而在二十年之后，云计算已经大行其道，当今的技术人员已经言必称虚拟化、容器和 Serverless，就连刚刚准备入行互联网运维行业的新人们都已经从最初觉得考个 Linux 认证就够了到开始问询 Kubernetes 培训哪家强了。从一届届 LC3、DockerCon 到 KubeCon，蓬勃发展的云计算与容器化似乎已经称霸了互联网领域。这次我带队参加了 6 月 24 ~ 26 日的 KubeCon 大会，对此感受尤为深刻。事实上，这次在上海举办的 KubeCon 2019 距离上次在同一地点举办的同一会议才仅仅过去半年，但是我们依旧在这次大会上看到了层出不穷的大量新技术、新动态。云与容器的结合，引爆了这一切。作为容器领域的资深专家，让我们来看看王旭是如何看待容器和云原生领域当前的发展态势的，以及作为这个领域的一家初创技术企业的创始人，他是如何投身到这个领域的，开源又在其间起到了什么作用。王旭，安全容器项目 runV 的创始人，现已加入蚂蚁金服。创立于 2015 年的 runV 项目已于 2017 年和另外一个来自英特尔的 Clear 容器项目合并为 Kata 容器项目，并由 OpenStack 基金会（OSF）进行管理，它与来自谷歌的 gVisor 项目并称为目前两大安全容器技术。开源与初创要么就去加强容器，要不就是引入别的安全技术来让它像容器一样。临近 2015 年，Docker 逐渐被业界主流所接受，互联网技术已经有一个比较明显的发展趋势：第一是云，第二是容器。而云加上容器一定会产生隔离性的需求，这应该说是王旭和他的联合创始人赵鹏做安全容器最早的一个思路：要么就去加强容器，要不就是引入别的安全技术来让它像容器一样。这就是 runV 这个项目想法的起源。runV 发布的同一个星期，英特尔Clear 容器也发布了。2016 年 8 月份，在西雅图的 LinuxCon 上，王旭和 Clear 团队见面交流，双方在一些细节上面展开合作。在 2017 年 9 月份一个会议上，英特尔软件副总裁、开源技术中心总经理 Imad Sousou 提出项目合并，然后放到基金会里管理。当时大家都觉得这是很好的一个思路。对于 runV 和 Clear 来说，避免了重复开发以及花费精力在如何说明两者的不同上，同时合并之后可以共同推动发展一个社区，一起去寻找更多的用户。同时，两者合并还有更多的意义。Kata 容器的意义Kata 容器最大的意义在于推动了社区的发展。王旭认为，Kata 容器最大的意义在于推动了社区的发展。在 2018 年之前刚开始做 Kata 容器的时候，王旭他们需要很多的附加进程来模拟 runC 容器的行为，因为 runC 是事实标准，你需要兼容它。但是当 Kata 和谷歌的 gVisor 都出来之后，上游社区就注意到这一点，开始重视，于是推出新的接口，可以语义明确地直接去对话，而不需要再去模拟 runC 的底层行为，把原来的 2N+2 个辅助进程变成了一个进程。另外，既然有了不同的容器运行时，是不是可以在不同的场景下让它们转到不同容器运行时环境上去？于是就有了“ 运行时类 （ runtime class ） ”这样的结构。Kubernetes 社区做了很多这样改进，它们也在逐步变成事实标准。这样，一个小项目的引入推动了包括从用户到上下游的整个社区相关软件的变动。安全容器也让更多的业务使用容器变得可能。同时，安全容器也让更多的业务使用容器变得可能。王旭在蚂蚁金服做面向金融的一些服务往云原生方向发展，需要非常严格的安全标准，这正好和 Kata 这些安全容器项目结合在一起。增强安全性不可避免的会带来一些会性能或易用性的取舍。王旭他们的做法是，在 Kata 里面增加了一个隔离层，减少用户需要考虑的事情。举个 Docker 的例子，Docker 镜像的开发者和管理员往往不是同一个人，对于管理员来说给出的权限越少越安全，但是对于开发者来说的话，尤其开发和调试的过程中，权限的变少会让开发和调试变得非常困难。对于开发者来说，不能完全理解管理员要做的事情，所以你就会见到很多的 Docker 镜像都是要所有权限的，因为它自己也不知道需要什么权限；此外还有一些动态的情况，很难先验地用程序去完全断定它需要的权限，开…

UCloud 叶理灯谈：Docker、K8S 和 Serverless
type: item
date: 2019-06-13T19:56:00+08:00
description: 前段时间，笔者参加了 UCloud 在京举办的 TIC 2019 大会，适逢 UCloud 实验室负责人叶理灯的演讲结束，就容器计算方面和他进行了短暂沟通。叶理灯是国内在云计算方面有深入研究和实践的资深专家，我觉得他的一些观点和看法值得分享给大家了解。叶理灯，UCloud实验室负责人叶理灯，UCloud 实验室负责人。现负责 UCloud 创新产品研发，专注面向企业的云计算产品的研发及运营。叶理灯拥有 10 年以上丰富的互联网研发经验，先后任职于腾讯、盛大云等互联网公司，从事海量分布式后台系统研发及运营工作。定制违背了 K8S 初衷，提供原生 K8S 产品记者：在官方的 K8S 发行版之上，各方云厂商提供 K8S 服务时都有一些自己的定制和调整，今天大会上提及的 UCloud 的 K8S 发行版 UK8S 主要做了哪些定制，有什么特色呢？叶理灯：如果说定制 K8S 的话，其实是违背了 K8S 的初衷。我们并没有定制 K8S，我们是基于公有云给用户提供了原生的 K8S 产品。在公有云上提供原生的 K8S，其实要做很多的工作，例如与公有云的计算、网络和存储的整合，给用户提供一个开箱即用的原生K8S集群等等。我为什么说不应该定制呢？因为大家知道 PaaS 发展到今天，一直存在的一个问题就是供应商绑定的问题。而 K8S 之所以那么有生命力，之所以迅速流行，是因为它提供了一个开源的标准，让用户使用 K8S PaaS 平台，可以避免厂商绑定。也就是说你的服务在某个服务商的 K8S 上运行，可以无缝的迁移到另外一个服务商。作为云厂商其实最重要的工作是，基于我们自身云平台的体系，提供原生的 K8S 给用户使用，帮助他们减少在集群管理和资源整合方面的工作和投入。例如，我们网络能力、存储能力和计算能力的整合，就是让用户享受到原生K8S的好处，同时避免了很多运维的负担。公有云的 K8S 处在底层 IaaS 和上层应用之间，一方面向下整合IaaS能力，一方面向上托管客户的应用。在整合 IaaS 方面，不改变 K8S原生特性，因为 K8S 本身架构足够开放，例如在我们实现的网络插件，是基于我们 IaaS 的 VPC 网络，让 pod 可以和我们托管区和物理云区域打通，这是我们 IaaS 能力在 K8S 产品上的体现，算是我们的特色之一，但这是在 K8S 体系支持下的插件方式实现的，不影响我们提供原生 K8S；在应用层面，厂商也可以基于 K8S 提供一些周边的功能以帮助用户提高效率，但它和提供一个一致的 K8S 环境不矛盾。另外一方面，如果说定制的概念是指基于 K8S 本身开发体系所提供的插件机制去做二次开发，那每家厂商都要定制，因为 K8S 本身不是一个产品级就绪的环境，需要使用者去适配网络和存储还有计算，因为每个公有云厂商基于自己的 IaaS 去提供 K8S 产品，必然要去开发插件。综上，向用户应该提供原生的、标准的 K8S 产品，但底层应该基于自身 IaaS 平台去定制，本质还是为了提高用户使用 K8S 的效率，让用户开箱即用。K8S 落地挑战：改造成本和人才问题记者：你觉得目前国内云厂商提供的 K8S 集群编排服务在推广方面目前欠缺的是什么？是什么阻碍了客户进一步去使用这些容器集群服务？叶理灯：K8S 以容器技术为核心、以容器镜像为打包标准的特点，意味着如果要迁移到这个体系下，客户需要将软件做容器化打包和微服务改造，这个是有成本的。K8S 的特点决定它是运维和研发之间的桥梁，这样就要求公司的研发过程需要跟着改造。我们看到很多公司的运维人员有动力去推动，而研发人员则没有动力，因为它改变了研发的习惯和流程，增加了负担；当然也有的公司是研发希望用 K8S 管理应用，而需要运维跟着变。这样导致迁移到 K8S 的工作较重，但一旦这个阶段过去了，迁移后的效率和成本优势就体现出来了。因此，这是个新技术落地的问题，涉及到用户教育和习惯的改变，这个需要社区和商业公司一起完成。而且每家公司的技术路线和文化不一样，上 K8S 的路径也不一样，所以没有一个放之四海皆准的最佳实践，但随着容器和微服务逐渐落地，K8S 作为事实标准，会逐步普及。除了改造业务的成本，另外一方面是 K8S 人才比较缺乏，不同用户的情况不一样，有些用户的运维人员本来就很少，不可能专门抽出一两个人去做 K8S，以及用户又担心它出问题谁来帮我解决？其实，应该是云厂商再往前走一步，除了帮用户构建一个 K8S 平台，还要帮助解决很多技术上的问题。 UCloud 现在就是这么做的，一个用户进来，我们会拉一个群，他们所有技术问题我们帮他们解决。在落地方面，在人才和 K8S 本身对用户架构改造方面，我们可以多做点工作，帮助客户培养K8S的运维人员和为用户制定架构迁移的方案。但我相信随着技术的发展和普及，越来越多…