本文整顿自 2020 年 7 月 22 日《基于 Kubernetes 与 OAM 构建对立、标准化的利用治理平台》主题线上网络研讨会。文章共分为高低两篇，本文为上篇，次要和大家介绍上 Kubernetes 有什么业务价值，以及什么是“以利用为核心”的 Kubernetes。下篇将跟大家具体分享如何构建“以利用为核心”的 Kubernetes。
视频回顾链接：https://www.bilibili.com/video/BV1Dv411v7P4/
关注阿里巴巴云原生公众号，回复“0722”即可下载 PPT
非常感谢大家来到 CNCF 的直播，我是张磊，阿里云的高级技术专家，Kubernetes 我的项目资深维护者。同时也是 CNCF 利用交付畛域 co-chair。我明天给大家带来的分享主题是《基于 Kubernetes 与 OAM 构建对立、标准化的利用治理平台》。在封面上有个钉钉群组二维码。大家能够通过这个二维码进入线上交换群。
上 Kubernetes 有什么业务价值？
明天要演讲的主题是跟利用治理或者说是云原生利用交付是相干的。首先咱们想要先答复这么一个问题：为什么咱们要基于 Kubernetes 去构建一个利用治理平台？
上图是一个实质的问题，咱们在落地 K8s 常常遇到的一个问题。尤其是咱们的业务方会问到这么一个问题，咱们上 Kubernetes 有什么业务价值？这时候作为咱们 K8s 工程师往往是很难答复的。起因在哪里呢？实际上这跟 K8s 的定位是相干的。K8s 这个我的项目呢，如果去做一个剖析的话，咱们会发现 K8s 不是一个 PaaS 或者利用治理的平台。实际上它是一个标准化的能力接入层。什么是能力接入层呢？大家能够看一下下图。
实际上通过 Kubernetes 对用户裸露进去的是一组申明式 API，这些申明式 API 无论是 Pod 还是 Service 都是对底层基础设施的一个形象。比方 Pod 是对一组容器的形象，而 Deployment 是对一组 pod 的形象。而 Service 作为 Pod 的拜访入口，实际上是对集群基础设施：网络、网关、iptables 的一个形象。Node 是对宿主机的形象。Kubernetes 还提供了咱们叫做 CRD（也就是 Custom Resource）的自定义对象。让你本人可能自定义底层基础设施的一个形象。
而这些形象自身或者是 API 自身，是通过另外一个模式叫做控制器 (Controller) 去实现的。通过控制器去驱动咱们的底层基础设施向我的形象迫近，或者是满足我形象定义的一个终态。
所以实质来讲，Kubernetes 他的专一点是“如何标准化的接入来自于底层，无论是容器、虚机、负载平衡各种各样的一个能力，而后通过申明式 API 的形式去裸露给用户”。这就意味着 Kubernetes 理论用户不是业务研发，也不是业务运维。那是谁呢？是咱们的平台开发者。心愿平台开发者可能基于 Kubernetes 再去做下层的框架或者是平台。那就导致了明天咱们的业务研发和业务运维对 Kubernetes 间接裸露进去的这一层形象，感觉并不是很敌对。
这里的关键点在于，Kubernetes 对这些基础设施的形象，跟业务研发和业务运维对待零碎的角度是齐全不同的。这个形象水平跟业务研发和业务运维心愿的形象水平也是不一样的。语义齐全对不上，应用习惯也是有很大的鸿沟。所以说为了解决这样一个问题，都在思考一些解决办法。怎么能让我 Kubernetes 提供的基础设施的形象可能满足我业务研发和业务运维的一个诉求呢？怎么能让 Kubernetes 可能成为业务研发和业务运维喜爱的一个平台呢？
办法一：把所有人都变成 Kubernetes 专家
如果咱们所有人都是 Kubernetes 专家，那当然会喜爱 Kubernetes 对我提供的服务，这里给他发个 Kubernetes 的 PhD 博士。这里我强烈推荐阿里云和 CNCF 主办的云原生技术公开课。大家试试学完这门课程后，能不能变成 Kubernetes 专家。
这个办法门槛比拟高，因为每个人对于这个零碎自身感兴趣水平不太一样，学习能力也不太一样。
办法二：构建一个面向用户的利用治理平台
业界常见的办法，大家会基于 Kubernetes 构建一个面向用户的利用治理平台，或者说是一个 PaaS，有人间接做成一个 Serverless。
那这个具体是怎么做呢？还是在 Kubernetes 之上，会搭建一个货色叫做下层利用治理平台，这个下层利用平台对业务研发和业务运维裸露进去一个下层的 API。比如说业务研发这一侧，他不太会裸露 Pod，Deployment 这样的形象。只会裸露进去 CI/CD 流水线。或者说一个利用，WordPress，一个内部网站，暴露出这样一个下层的概念，这是第一个局部。
第二局部，它也会给业务运维暴露出一组运维的 API。比如说：程度扩容，公布策略，分批策略，访问控制，流量配置。这样的话有一个益处，业务研发和业务运维面对的 API 不是 Kubernetes 底层的 API，不是 Node，不是 Service，不是 Deployment，不是咱们的 CRD。是这样一组通过形象通过封装后的 API。这样的业务研发和业务运维用起来会跟他所冀望的 Ops 流水线，它所相熟的应用体检有个人造的结合点。
所以说只有这么做了之后，咱们才可能跟咱们的业务老大说，Kubernetes 的业务价值来了。实际上业务价值不是在 Kubernetes 这一层，而是在 Kubernetes 往上的这一层 –“你的解决方案“。所以说这样的一个零碎构建进去之后呢，实际上是对 Kubernetes 又做了一层封装。变成了很多公司都有的，比如说 Kubernetes 利用平台。这是一个十分常见的做法。相比于咱们让研发运维变成 Kubernetes 专家来说会更加理论一点。
然而咱们在阿里也好，在很多社区的理论场景也好，它往往会随同着这么一个问题。这个问题是：明天 Kubernetes 的生态是十分十分凋敝的，下图是我在 CNCF 截的图，好几百个我的项目，几千个能够让咱们 Kubernetes 即插即用的能力。比方 istio，KEDA，Promethues 等等都是 Kubernetes 的插件。正是基于这么一个扩展性十分高的申明式 API 体系才会有了这么凋敝的 Kubernetes 生态。所以能够认为 Kubernetes 能力是有限的，十分弱小。
可是这么一个有限能力，如果对接到一个十分传统的，十分经典的一个利用治理平台。比如说咱们的 PaaS 上，如 Cloud Foundry。立即就会发现一个问题，PaaS 尽管对用户提供的是很敌对的 API，然而这个 API 自身是无限的，是难以扩大的。比如说 Cloud Foundry 要给用户应用，就有 Buildpack 这么一个概念，而不是 Kubernetes 所有的能力都能给用户去应用。其实简直所有的 PaaS 都会存在这么一个问题。它往上裸露的是一个用户的 API，是不可扩大的，是个无限集。
上面一个十分宏大凋敝的 Kubernetes 生态，没方法间接给用户裸露进来。可能每应用一个插件就要从新迭代开发你的 PaaS，从新交付你的 PaaS。这个是很难承受的。
传统 PaaS 的“能力窘境”
这问题是一个普遍存在的问题，咱们叫做传统 PaaS 的“能力窘境”。
实质上来说这个窘境是什么意思呢？K8s 生态凋敝多样的利用基础设施能力，与业务开发人员日益增长的利用治理诉求，两头存在一个传统的 PaaS，他就会变成一个瓶颈。K8s 有限的能力无奈让你的研发与运维立即用到。所以传统 PaaS 就会成为一个不言而喻的瓶颈。
这样给我带来一个思考：咱们能不能摈弃传统 PaaS 的一个做法，基于 K8s 打造高可扩大的利用治理平台。咱们想方法能把 K8s 能力无缝的透给用户，同时又能提供传统 PaaS 比拟敌对的面向研发运维的应用体验呢？
其实能够从另外一个角度思考这个问题：如何基于 K8s 打造高可扩大的利用治理平台，实际上等同于 如何打造一个“以利用为核心的”的 Kubernetes。或者说能不能基于 Kubernetes 去封装下，让它可能像 PaaS 一样，去面向我的理论用户去应用呢？这个就是咱们要聊的关键点。
什么是“以利用为核心”的 Kubernetes
特色一：通过原生的申明式 API 和插件体系，裸露面向最终用户的下层语义和形象
咱们不是说要在 Kubernetes 上盖一个 PaaS，或者说是盖一个大帽子，不干这件事件。因为 K8s 自身能够扩大，能够写一组 CRD，把咱们要的 API 给装上去。比方 CI/CD 流水线，就能够像 Tektong 零碎间接应用 pipeline。利用也能够通过某些我的项目间接裸露进去。运维这一侧的公布扩容等，都能够通过装置一个 Operator 去解决问题。当然也须要一些技术将这些运维策略绑定到利用或者流水线中。
这就是咱们第一个点，以利用为核心的 K8s 首先是裸露给用户的语义和 API，而不是十分底层的，比方 Service、Node 或者是 Ingress。可能用户都不晓得什么意思，也不晓得怎么写的。
特色二：下层语义和形象可插拔，可扩大，没有形象水平锁定和任何能力限度
第二个点很重要，下层语义和形象必须是可插拔的，必须是可扩大的，是无缝兼容利用 K8s 的可扩大能力的。并且也不应该有对形象水平的锁定。
举个例子：比方一个利用自身既能够是 Deployment，这是一个比拟低水平的形象。也能够是 Knative Service，这是一个相对来说高水平的形象，绝对于 deployment 来说比较简单，只有一个 PodTemplate。甚至能够更简略，能够是一个 Service，或者是个 Function。这个时候形象水平就很高。如果基于 K8s 做一个以利用为核心的框架的话，它应该是可能裸露工作负载的多种形象水平的。而不是说独自去应用 Knative，只能暴露出 Knative Service。如果我想应用 Knative 部署一个 Statefulset，这当然是不能够的。形象水平是齐全不统一的。所以我心愿这个以利用为核心的 K8s 是没有形象水平的锁定的。
同时也不应该有能力的限度，什么叫没有能力的限度呢？比方从运维侧举个例子，运维侧有很多很多扩容策略、公布策略等等。如果我想新加一个策略能力，它应该是非常简单的，就像在 K8s 装置一个 Operator 一样非常简单，能 helm insatll 就能搞定，答案是必须的。如果须要增加一个程度扩容，间接 helm install vpa 就能解决。通过这种形式能力做一个以利用为核心的 Kubernetes。
能够看到它跟咱们的传统 PaaS 还是有很大区别的，它的可扩大能力十分十分强。它实质上就是一个 K8s，然而它跟专有的 Service，Knative，OpenFaaS 也不一样。它不会把形象水平锁定到某一种 Workload 上，你的 Workload 是能够随便去定义。运维侧的能力也能够随便可插拔的去定义。这才是咱们叫做一个以利用为核心的 Kubernetes。那么这么一个 Kubernetes 怎么做呢？
后续咱们将会在下篇文章中具体为大家解读如何构建“以利用为核心”的 Kubernetes？以及构建这么一个以用户为核心的 Kubernetes，须要做几个层级的事件。
《云原生实际公开课》
去年，CNCF 与 阿里云联结公布了《云原生技术公开课》曾经成为了 Kubernetes 开发者的一门“必修课”。明天，阿里云再次集结多位具备丰盛云原生实践经验的技术专家，正式推出《云原生实际公开课》。课程内容由浅入深，专一解说“落地实际”。还为学习者打造了实在、可操作的试验场景，不便验证学习成绩，也为之后的实际利用打下坚实基础。课程曾经正式上线，欢送大家观看。
点击链接即可收费观看课程：https://developer.aliyun.com/learning/roadmap/cloudnative2020
“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术畛域、聚焦云原生风行技术趋势、云原生大规模的落地实际，做最懂云原生开发者的公众号。”