上 K8s，研发团队如何从容一点？

容器作为一种先进的虚拟化技术，是云原生时代软件开发和运维不可或缺的部分。k8s 是目前最流行的容器编排管理工具，但很多企业在拥抱 k8s 的过程中，遇到了难题。

今天就来聊聊上 K8s，研发团队如何从容一点？

关于容器技术

容器技术呱呱坠地到如今，在国内经历了如下 3 个阶段：

• 婴儿期：2014-2016 年的技术探索期

• 少儿期：2017-2018 年的行业试水期

• 少年期：2019 年以后的规模应用期

容器技术带来的价值，通过它的广泛使用已经不言而喻，现在大致介绍容器技术的现状和趋势。

• Kubernetes(K8s)已成为容器技术的事实标准

• 大量企业已经在使用或者计划使用容器云

• K8s 从 CO 走向 OS

K8s 一直以来被当做容器编排工具（Container Operation, CO），而这些年的发展，K8s 已经成了云原生领域事实的操作系统（Operation System, OS）。

难以驾驭的 K8s

K8s 功能固然强大，但同时从 K8s 目前的定位——操作系统，就能看出它最大的特征：复杂，这就会衍生一系列问题：

• 上手 k8s 绝非易事，用一个高级点的说法，叫学习曲线陡峭。并且容器技术的更新迭代非常快，Kubernetes 衍生出的新概念新工具也在蓬勃发展（有兴趣的朋友可以搜索一下“Kubernetes 生态”）。然而更有挑战性的点在于，如果想在实际的工作中用上 K8s，整个研发团队都需要学，包括开发人员、测试人员、运维人员；

• 市场上，K8s 相关人才不多；

• 项目使用 K8s 的不确定性高，可能会导致失败；

• 项目切换到 K8s 的成本太大，导致你的老板可能会叫停这样的变革；

• 需要适应 K8s 的工作模式，软件研发本来就是一个复杂的体系，包括了很多人使用很多工具分工合作，而使用 K8s，很多工作方式与原来不一样。下面罗列一下，以供参考：

• 在实际使用中，还有很多非常棘手的问题，比如：

K8s yaml 的配置一部分是开发关注的，一部分是运维关注的，如何分工协作？

ConfigMap/Secret 不支持版本控制，参数多时配置起来很麻烦；

集群如何给外部暴露端口？

如何做热更新？

多 K8s 集群如何管理？

K8s 集群本身如何备份和恢复？

如何对 K8s 集群进行升级而不影响业务？

K8s 集群如何做资源规划？

K8s 是所有人的良药吗？

K8s 很好，然而用 Ta 很困难，是不是让人又爱又恨？怎么办？

建议你冷静下来，仔细分析一下更重要的事情——K8s 是否适合你、你的项目、你的团队？

建议考虑如下内容：

• 你的应用是否需要微服务？微服务带来便利的同时，也会给开发人员带来巨大负担，除了维护多个服务之外，可能需要一整套工具来分析解决微服务的问题。还要考虑分布式的一致性问题、服务通信带来的性能问题和安全问题等。如果不需要微服务，大概率也不需要 K8s。

• 你的应用需要扩展吗？Kubernetes 的一个关键特性是能对应用程序的各个部分进行横向扩展。流量会自动在各个 Pod 间路由和分配，如果配置完成，Kubernetes 甚至可以自动为你缩放 Pod 。如果你的应用有一个或多个热点组件需要处理突发事件，那这个特性就非常有价值。

如果你的答案是你不需要 K8s，那么恭喜你，你可以中止阅读了，你花费了 10 分钟不到的时间，得到了一个有价值的答案。

如果你的答案是：你需要 K8s，请继续阅读，也许对你有些许帮助。上面列的困难只是战术上的困难，是有办法解决的。

我的团队该如何上 K8s?

关于 how 的问题，有大有小：大如我该如何度过这一生，小则有我该如何学习 10 以内的加法。而团队该如何上 K8s，这就是一个宏大的问题。一般而言，大问题可以拆分为小问题，逐个求解得到答案。

言归正传，团队如何上 K8s，从大面上，答案包含 2 点，二者缺一不可：

渐进式上K8s人员分工 + 第三方产品解决复杂性

渐进式上 K8s

• 特定项目。选择即将要开发的新项目，简单一点的项目，没有迁移成本。

• 特定完整团队。项目的 leader 需要有新技术的探索精神，项目中核心成员也有新技术的探索精神。关于特定团队，团队中的研发人员、测试人员、运维人员都需要从一开始就直接或间接使用 K8s。直接是上原生 K8s，间接是指通过第三方平台上 K8s。

• 测试环境。项目先在测试环境以 K8s 方式部署。

取得成功之后，再扩展至生产环境、其他项目、其他团队。这样的方式，有利于团队积累对 K8s 的自信心。取得一定的广度成功的同时，在深度上也可以做一定的探索。比如，使用 K8s 配套的测试工具、运维工具，甚至采用一些开源项目的 CRD，比如 Open Kruise。甚至编写自己公司特有的 CRD。

人员分工 + 封装

人类解决复杂性有 2 个非常重要的手段：分工、封装。在 IT 领域，这两个手段的例子俯拾皆是。具体到上 K8s 体现为：

人员分工是指不需要整个团队的人都懂 K8s，只需要特定的一两个人懂 K8s，研发人员、测试人员只需配合相关的工作，由这一两个人来编写 Dockerfile、K8s yaml，也可以由这一两个人写好脚本，开发人员和测试人员直接调用脚本，传递合适参数。

封装。有如 5 种方式封装，第 1 条是穷人专用，第 5 条是土豪专用，第 2、3、4 条是经济适用条款。

• 可以采用脚本或者模板的方式，对开发人员、测试人员屏蔽 K8s 的复杂性；

• 采用开源的工具来封装操作复杂性，提供了 Web UI，比如：OKD、Rancher 等；

• 购买商业化的容器云产品来封装操作复杂性，公有云或私有云的产品都可以，比如 AWS/阿里云/腾讯云/华为云上的容器云产品；

• 购买商业化的产品来封装操作复杂性、以及理解复杂性。市面上，既封装了操作复杂性、又封装了理解复杂性的产品不多，比如StarOS-官网，StarOS 都封装了 K8s 的概念，无需懂 K8s 即可使用。StarOS 是一站式云原生开发平台，可视化服务编排，操作简单直接；

• 自己团队开发容器云平台来封装操作复杂性、以及理解复杂性，土豪适用。