做微网站公司简介,免费手机网站空间,做网站没有活,河北城乡建设厅网站上 Kubernetes 有什么业务价值#xff1f;
今天要演讲的主题是跟应用管理或者说是云原生应用交付是相关的。首先我们想要先回答这么一个问题#xff1a;为什么我们要基于 Kubernetes 去构建一个应用管理平台#xff1f; 上图是一个本质的问题#xff0c;我们在落地 K8s 经…上 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。比如说业务研发这一侧他不太会暴露 PodDeployment 这样的抽象。只会暴露出来 CI/CD 流水线。或者说一个应用WordPress一个外部网站暴露出这样一个上层的概念这是第一个部分。
第二部分它也会给业务运维暴露出一组运维的 API。比如说水平扩容发布策略分批策略访问控制流量配置。这样的话有一个好处业务研发和业务运维面对的 API 不是 Kubernetes 底层的 API不是 Node不是 Service不是 Deployment不是我们的 CRD。是这样一组经过抽象经过封装后的 API。这样的业务研发和业务运维用起来会跟他所期望的 Ops 流水线它所熟悉的使用体检有个天然的结合点。
所以说只有这么做了之后我们才能够跟我们的业务老大说Kubernetes 的业务价值来了。实际上业务价值不是在 Kubernetes 这一层而是在 Kubernetes 往上的这一层--你的解决方案。所以说这样的一个系统构建出来之后呢实际上是对 Kubernetes 又做了一层封装。变成了很多公司都有的比如说 Kubernetes 应用平台。这是一个非常常见的做法。相比于我们让研发运维变成 Kubernetes 专家来说会更加实际一点。
但是我们在阿里也好在很多社区的实际场景也好它往往会伴随着这么一个问题。这个问题是今天 Kubernetes 的生态是非常非常繁荣的下图是我在 CNCF 截的图好几百个项目几千个可以让我们 Kubernetes 即插即用的能力。比如 istioKEDAPromethues 等等都是 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但是它跟专有的 ServiceKnativeOpenFaaS 也不一样。它不会把抽象程度锁定到某一种 Workload 上你的 Workload 是可以随意去定义。运维侧的能力也可以随意可插拔的去定义。这才是我们叫做一个以应用为中心的 Kubernetes。那么这么一个 Kubernetes 怎么做呢
后续我们将会在下篇文章中详细为大家解读如何构建“以应用为中心”的 Kubernetes以及构建这么一个以用户为中心的 Kubernetes需要做几个层级的事情。 原文链接 本文为阿里云原创内容未经允许不得转载。
