首页 体育 教育 财经 社会 娱乐 军事 国内 科技 互联网 房产 国际 女人 汽车 游戏

给 K8s API “做减法”:阿里巴巴云原生应用管理的挑战和实践

2020-01-17

第三部分是把上述描绘文件组合在一起的一个装备文件。 比方: “一个运用有两个组件,组件 A 需求运维才能 X 和才能 Y,组件 B 需求运维才能 X”。 所以这个装备文件,其实才是终究的“运用”。 这个装备文件,也是运维编写,而且提交给渠道去运转的,当然,渠道也能够主动生成这个文件。

下面咱们经过实例来看下以上三个部分对应的 YAML 文件终究长什么姿态? 它们终究怎样玩儿?

补白: 假如你想跟我相同实际操作体会这个流程,你只需求在 K8s 集群里装上 Rudr 项目就能够实操了。

首要咱们能够看到,Component 界说的是开发关怀的工作,没有任何运维相关的概念。

它的 Spec 首要分为两大块:

第一个参数块是运用描绘,包括 WorkloadType 字段,这个字段便是表达运用运用什么 Workload 运转;

在咱们规划里有六种默许 Workload,分别是 Server、Worker、Job 以及他们对应的单例形式,Workload 也能够扩展。 Server 代表这是一个能够主动弹性的,而且有一个端口能够拜访的形式。 接下来便是容器的镜像、发动参数之类的,这部分包括完好的 OCI spec。

第二块是 parameters 怎样运转可扩展的参数,如环境变量和端口号。

这一块参数的特点是: 它们虽然是开发界说的,可是都答应运维后续掩盖。 这儿的要害点是,重视点别离并不等于彻底分裂。 所以,咱们规划了 parameters 列表,其实便是期望开发能告知运维,哪些参数后续能够被运维人员掩盖掉。 这样的话就很好地联动起来了,开发人员能够向运维人员提出诉求,比方运维应该运用哪些参数、参数代表什么意思。

像这样一个 Component 能够直接经过 kubectl 安装到 K8s 中。

然后咱们能够经过 kubectl 东西检查到现已安装好的组件有哪些:

所以说,咱们当时的 K8s 集群,支撑两种“运用组件”。 需求指出的是,除了咱们内置支撑的组件之外,开发自己能够自在界说各式各样的组件然后提交给咱们。 Component Spec 里的 Workload Type 是能够随意扩展的,就跟 K8s 的 CRD 机制相同。

说完了开发能用的 API,咱们再来看运维用的 API 长什么样。

在规划运用的运维才能界说的过程中,咱们要点重视的是运维才能怎样发现和办理的问题。

为此,咱们规划了一个叫做 Trait 的概念。 所谓 Trait,也便是运用的“特征”,其实便是一种运维才能的声明式描绘。 咱们能经过命令行东西发现一个系统里支撑哪些 Traits。

这时候,运维要检查详细的运维才能该怎样运用,是十分简略的:

能够看到,他能够在 Trait 界说里明晰的看到这个运维才能能够效果于哪种类型的 Workload,包括能填哪些参数? 哪些必填? 哪些选填? 参数的效果描绘是什么?  

你也能够发现,OAM 系统里边,Component 和 Trait 这些 API 都是 Schema,所以它们是整个目标的字段全集,也是了解这个目标描绘的才能“终究能干吗?”的最佳途径 。

上面这些 Trait 也都是用过 kubectl apply 就能够安装到集群傍边的。

已然 Component 和 Trait 都是 Schema,那么它们怎样实例化成运用呢?

在 OAM 系统中,Application Configuration 是运维人员履行运用布置等动作的操作目标。 在 Application Configuration 里,运维人员能够将 Trait 绑定到 Component 上履行。

在 Application Configuration YAML 里边,运维能够把 Component 和 Trait 拼装起来,然后得到一个能够布置的“运用”:

在这儿咱们能够看到,运维实例化的运用里边包括了一个叫 hellowworld-python-v1 的 Component,它有两个参数: 一个是环境变量 target,一个是port。 需求留意的是,这两个参数是运维人员掩盖了原先 Component yaml 中开发界说的两个可掩盖变量。

一起,这个 Component 绑定了 2 个运维才能: 一个是水平扩容,一个是 Ingress 域名拜访。

运维人员经过 kubectl 即可把这样一个运用布置起来:

这时候在 K8s 里边,你就能够看到 OAM 插件会主动为你创立出对应的 Deployment。

一起,这个运用需求的 Ingress 也被主动创立起来了:

这儿其实是前面说到的 Rudr 插件在起效果,在拿到 OAM 的 Application Configuration 文件今后,识别出其间的 Component 和 Trait,将其映射到 K8s 上的资源并拉起,K8s 资源相应的生命周期都跟着 OAM 的装备去办理。

当然,因为 OAM 界说是渠道无关的,所以除了 K8s 自身的资源,Rudr 插件的完成中也会参加外部资源的拉起。

终究咱们能够经过像乐高积木相同拼装复用 OAM 的不同模块,实例化出一个 OAM 的运用出来。

更重要的是,这个 OAM 运用描绘文件是彻底自包括的,也便是说经过 OAM YAML,作为软件分发商,咱们就能够完好地盯梢到一个软件运转所需求的一切资源和依靠。

这就使得现在关于一个运用,咱们只需求一份 OAM 的装备文件,就能够快速、在不同运转环境上把运用随时运转起来,把这种自包括的运用描绘文件完好地交给到任何一个运转环境中。

这不只让咱们前面说到的软件交给难题得到了很好的处理,也让更多非 K8s 渠道比方 IoT、游戏分发、混合环境软件交给等场景,能享受到云原生运用办理的痛快。

OAM 是一个彻底归于社区的运用界说模型,咱们十分期望咱们都能参加进来。

一方面,假如你有任何场景感觉 OAM 无法满意的,欢迎你在社区提出 issue 来描绘你的事例;

热门文章

随机推荐

推荐文章