网站开发平面设计师岗位要求,关键词推广和定向推广,网站制作如皋,石材网站模板简介#xff1a; K8s 取其精华去其糟粕#xff0c;是我们程序员应该做的事情。 K8s设计模式 Kubernetes是一个具有普遍意义的容器编排工具#xff0c;它提供了一套基于容器构建分布式系统的基础依赖#xff0c;其意义等同于Linux在操作系统中的地位#xff0c;可以认为是…简介 K8s 取其精华去其糟粕是我们程序员应该做的事情。 K8s设计模式 Kubernetes是一个具有普遍意义的容器编排工具它提供了一套基于容器构建分布式系统的基础依赖其意义等同于Linux在操作系统中的地位可以认为是分布式的操作系统。 自定义资源 K8s提供了Pod、Service、Volume等一系列基础资源定义为了更好提供扩展性CRD 功能是在1.7 版本被引入。 用户可以根据自己的需求添加自定义的 Kubernetes 对象资源CRD。值得注意的是这里用户自己添加的 Kubernetes 对象资源都是 native 的都是一等公民和 Kubernetes 中自带的、原生的那些 Pod、Deployment 是同样的对象资源。在 Kubernetes 的 API Server 看来它们都是存在于 etcd 中的一等资源。同时自定义资源和原生内置的资源一样都可以用 kubectl  来去创建、查看也享有 RBAC、安全功能。用户可以开发自定义控制器来感知或者操作自定义资源的变化。 Operator 在自定义资源基础上如何实现自定义资源创建或更新时的逻辑行为K8s Operator提供了相应的开发框架。Operator通过扩展Kubernetes定义Custom Controllerlist/watch 对应的自定义资源在对应资源发生变化时触发自定义的逻辑。 Operator 开发者可以像使用原生 API 进行应用管理一样通过声明式的方式定义一组业务应用的期望终态并且根据业务应用的自身特点进行相应控制器逻辑编写以此完成对应用运行时刻生命周期的管理并持续维护与期望终态的一致性。 通俗的理解 CRD是K8s标准化的资源扩展能力以java为例int、long、Map、Object是java内置的类用户可以自定义Class实现类的扩展CRD就是K8s中的自定义类CR就是对应类的一个instance。 Operator模式 自定义类 观察者模式Operator模式让大家编写K8s的扩展变得非常简单快捷逐渐成为面向K8s设计的标准。 Operator提供了标准化的设计流程 使用 SDK 创建一个新的 Operator 项目通过添加自定义资源CRD定义新的资源 API指定使用 SDK API 来 watch 的资源自定义Controller实现K8s协调reconcile逻辑 有了锤子看到的只有钉子 我们团队KubeOne团队一直在致力于解决复杂中间件应用如何部署到K8s自然也是Operator模式的践行者。经历了近2年的开发初步解决了中间件在各个环境K8s的部署当前中间也走了很多弯路踩了很多坑。 KubeOne内核也经历3个大版本的迭代前2次开发过程基本都是follow Operator标准开发流程进行开发设计。遵循一个标准的、典型的Operator的设计过程看上去一切都是这么的完美但是每次设计都非常痛苦践行Operator模式之后最值得反思和借鉴的就是”有了锤子看到的只有钉子“简单总结一下就是4个一切 一切设计皆yaml一切皆合一一切皆终态一切交互皆cr误区1 一切设计皆yaml K8s的API是yaml格式Operator设计流程也是让大家首先定义crd所以团队开始设计时直接采用了yaml格式。 案例 根据标准化流程团队面向yaml设计流程大体如下 先根据已知的数据初步整理一个大而全的yaml做一下初步的分类例如应用大概包含基础信息依赖服务运维逻辑监控采集等每个分类做一个子部分开会讨论具体的内容是否能满足要求结果每次开会都难以形成共识因为总是有新的需求满足不了在讨论A时就有人提到B、C、D不断有新的需求每个部分的属性非常难统一因为不同的实现属性差异较大理解不一致相同名字但使用时每个人的理解也不同 由于工期很紧只能临时妥协做一个中间态后面再进一步优化后续优化升级相同的流程再来一遍还是很难形成共识这是第2个版本的设计 apiVersion: apps.mwops.alibaba-inc.com/v1alpha1 kind: AppDefinition metadata:labels:app: Aname: A-1.0 //chart-namechart-versionnamespace: kubeone spec:appName: A  //chart-nameversion: 1.0 //chart-versiontype: apps.mwops.alibaba-inc.com/v1alpha1.argo-helmworkloadSettings:   //注 workloadSettings 标识type应该使用的属性- name: deployToK8SNamevalue: - name: deployToNamespacevalue: ${resources:namespace-resource.name}parameterValues:   //注 parameterValues标识业务属性- name: enableTenantvalue: 1- name: CPUvalue: 1- name: MEMvalue: 2Gi- name: jvmvalue: flag;gc- name: vip.fileserver-edas.ipvalue: ${resources:fileserver_edas.ip}- name: DB_NAMEvalueFromConfigMap:name: ${resources:rds-resource.cm-name}expr: ${database}- name: DB_PASSWORDvalueFromSecret:name: ${instancename}-rds-secretexpr: ${password}- name: object-storage-endpointvalue: ${resources:object-storage.endpoint}- name: object-storage-usernamevalueFromSecret:name: ${resources:object-storage.secret-name}expr: ${username}- name: object-storage-passwordvalueFromSecret:name: ${resources:object-storage.secret-name}expr: ${password}- name: redis-endpointvalue: ${resources:redis.endpoint}- name: redis-passwordvalue: ${resources:redis.password}resources:- name: tolerationstype: apps.mwops.alibaba-inc.com/tolerationsparameterValues:- name: keyvalue: sigma.ali/is-ecs- name: keyvalue: sigma.ali/resource-pool- name: namespace-resourcetype: apps.mwops.alibaba-inc.com/v1alpha1.namespaceparameterValues:- name: namevalue: edas- name: fileserver-edastype: apps.mwops.alibaba-inc.com/v1alpha1.database.vipparameterValues:- name: portvalue: 21,80,8080,5000- name: src_portvalue: 21,80,8080,5000- name: typevalue: ClusterIP- name: check_typevalue: - name: urivalue: - name: ipvalue: - name: test-dbtype: apps.mwops.alibaba-inc.com/v1alpha1.database.mysqlhaparameterValues:- name: namevalue: test-db- name: uservalue: test-user- name: passwordvalue: test-passwd- name: secretvalue: test-db-mysqlha-secret- name: service-slbtype: apps.mwops.alibaba-inc.com/v1alpha1.slbmode: post-createparameterValues:- name: servicevalue: serviceA- name: annotationsvalue: app:a,version:1.0- name: external-ipvalue: - name: service-resource2type: apps.mwops.alibaba-inc.com/v1alpha1.serviceparameterValues: - name: second-domainvalue: edas.console- name: portsvalue: 80:80- name: selectorsvalue: app:a,version:1.0- name: typevalue: loadbalance- name: service-dnstype: apps.mwops.alibaba-inc.com/v1alpha1.dnsparameterValues:- name: domainvalue: edas.server.${global:domain}- name: vipvalue: ${resources:service-resource2.EXTERNAL-IP}- name: dns-resourcetype: apps.mwops.alibaba-inc.com/v1alpha1.dnsparameterValues:- name: domainvalue: edas.console.${global:domain}- name: vipvalue: “127.0.0.1”- name: cni-resourcetype: apps.mwops.alibaba-inc.com/v1alpha1.cniparameterValues:- name: countvalue: 4- name: ip_listvalue: - name: object-storagetype: apps.mwops.alibaba-inc.com/v1alpha1.objectStorage.minioparameterValues:- name: namespacevalue: test-ns- name: usernamevalue: test-user- name: passwordvalue: test-password- name: storage-capacityvalue: 20Gi- name: secret-namevalue: minio-my-store-access-keys- name: endpointvalue: minio-instance-external-service- name: redistype: apps.mwops.alibaba-inc.com/v1alpha1.database.redisparameterValues:- name: cpuvalue: 500m- name: memoryvalue: 128Mi- name: passwordvalue: i_am_a_password- name: storage-capacityvalue: 20Gi- name: endpointvalue: redis-redis-cluster - name: accesskeytype: apps.mwops.alibaba-inc.com/v1alpha1.accesskeyparameterValues:- name: namevalue: default- name: userNamevalue: ecs_testaliyun.comexposes:- name: dnsvalue: ${resources:dns-resource.domain}- name: db-endpointvalueFromConfigmap:name: ${resources:rds-resource.cm-name}expr: ${endpoint}:3306/${database}- name: ip_listvalue: ${resources:cni-resource.ip_list}- name: object-storage-endpointvalue: ${resources:object-storage.endpoint}.${resource:namespace-resource.name}- name: object-storage-usernamevalueFromSecret:name: ${resources:object-storage.secret-name}expr: ${username}- name: object-storage-passwordvalueFromSecret:name: ${resources:object-storage.secret-name}expr: ${password}- name: redis-endpointvalue: ${resources:redis.endpoint}.${resource:namespace-resource.name}- name: redis-passwordvalue: ${resources:redis.password} 反思 这样的痛苦难以用语言表达感觉一切都脱离了掌控没有统一的判断标准设计标准公说公有理婆说婆有理内容一直加字段一直改。事不过三第三次设计时我们集体讨论反思为什么这么难形成共识为什么每个人理解不同为什么总是在改 结论很一致没有面向yaml的设计只有面向对象的设计设计语言也只有UML只有这些历经考验、成熟的设计方法论才是最简单也是最高效的。 从上面那个一个巨大无比的yaml大家可以体会我们设计的复杂但是这还是不是最痛苦的。最痛苦的是大家抛弃了原有的设计流程及设计语言试图使用一个开放的Map来描述一切。当设计没有对象也没有关系只剩下Map里一个个属性也就无所谓对错也无所谓优劣。最后争来争去最后不过是再加一个字段争了一个寂寞。 适用范围 那Operator先设计CRD再开发controller的方式不正确吗 答案部分正确 适用场景 与Java Class相同简单对象不需要经过复杂的设计流程直接设计yaml简单高效。 不适用场景 在设计一个复杂的体系时例如应用管理包含多个对象且对象之间有复杂的关系有复杂的用户故事UML和面向对象的设计就显得非常重要。 设计时只考虑UML和领域语言设计完成后CRD可以认为是java的Class或者是数据库的表结构只是最终要实现时的一种选择。而且有很多对象不需要持久化也不需要通过Operator机制触发对应的逻辑就不需要设计CRD而是直接实现一个controller即可。 yaml是接口或Class声明的一种格式化表达常规yaml要尽可能小尽可能职责单一尽可能抽象。复杂的yaml是对简单CRD资源的一种编排结果提供类似一站式资源配套方案。 在第3个版本及PaaS-Core设计时我们就采取了如下的流程 UML 用例图梳理用户故事基于用户故事对齐Domain Object确定关键的业务对象以及对象间关系需要Operator化的对象每个对象描述为一个CRD当然CRD缺乏接口、继承等面向对象的能力可以通过其他方式曲线表达不需要Operator化的对象直接编写Controller误区2 一切皆合一 为了保证一个应用的终态或者为了使用gitops管理一个应用是否应该把应用相关的内容都放入一个CRD或一个IAC文件根据gitops设计每次变更时需要下发整个文件 案例 案例1: 应用WordPress需要依赖一个MySQL终态如何定义? apiVersion: apps.mwops.alibaba-inc.com/v1alpha1 kind: AppDefinition metadata:labels:app: WordPressname: WordPress-1.0 //chart-namechart-versionnamespace: kubeone spec:appName: WordPress  //chart-nameversion: 1.0 //chart-versiontype: apps.mwops.alibaba-inc.com/v1alpha1.argo-helmparameterValues:   //注 parameterValues标识业务属性- name: enableTenantvalue: 1- name: CPUvalue: 1- name: MEMvalue: 2Gi- name: jvmvalue: flag;gc- name: replicasvalue: 3- name: connectstringvalueFromConfigMap:name: ${resources:test-db.exposes.connectstring}expr: ${connectstring}- name: db_user_namevalueFromSecret:....resources:- name: test-db //创建一个新的DBtype: apps.mwops.alibaba-inc.com/v1alpha1.database.mysqlhaparameterValues:- name: cpuvalue: 2- name: memoryvalue: 4G- name: storagevalue: 20Gi - name: usernamevalue: myusername- name: passwordvalue: i_am_a_password- name: dbnamevalue: wordPressexposes:- name: connectstring- name: username- name: passwordexposes:- name: dnsvalue: ... 上方的代码是wordPress应用的终态吗这个文件包含了应用所需要的DB的定义和应用的定义只要一次下发就可以先创建对应的数据库再把应用拉起。 案例2每次变更时直接修改整个yaml的部分内容修改后直接下发到K8s引起不必要的变更。例如要从3个节点扩容到5个节点修改上面yaml文件的replicas之后需要下发整个yaml。整个下发的yaml经过二次解析成底层的StatefulSet或Deployment解析逻辑升级后可能会产生不符合预期的变化导致所有pod重建。 反思 先回答第一个问题上方yaml文件不是应用的终态而是一个编排此编排包含了DB的定义和应用的定义。应用的终态只应该包含自己必须的依赖引用而不包含依赖是如何创建的。因为这个依赖引用可以是新创建的也可以是一个已有的也可以是手工填写的依赖如何创建与应用终态无关。 apiVersion: apps.mwops.alibaba-inc.com/v1alpha1 kind: AppDefinition metadata:labels:app: WordPressname: WordPress-1.0 //chart-namechart-versionnamespace: kubeone spec:appName: WordPress  //chart-nameversion: 1.0 //chart-versionname: WordPress-testtype: apps.mwops.alibaba-inc.com/v1alpha1.argo-helmparameterValues:   //注 parameterValues标识业务属性- ....resources:- name: test-db-secretvalue: wordPress1Secret //引用已有的secret  exposes:- name: dnsvalue: ... 创建一个应用就不能先创建db再创建应用吗 可以的多个对象之间依赖是通过编排实现的。编排有单个应用创建的编排也有一个复杂站点创建的编排。以Argo为例。 apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata:generateName: wordPress- spec:templates:- name: wordPresssteps:# 创建db- - name: wordpress-dbtemplate: wordpress-dbarguments:parameters: [{name: wordpress-db1}]# 创建应用- - name: template: wordpressarguments:parameters: [{db-sercet: wordpress-db1}] 针对第2个案例是否每次交互都需要下发全部完整的yaml 答案 编排是一次性的配置编排文件下发一次之后后续操作都是操作单个对象例如变更时只会单独变更wordPress或单独变更wordPressDB而不会一次性同时变更2个对象。单独变更应用时是否需要下发整个终态yaml这个要根据实际情况进行设计值得大家思考。后面会提出针对整个应用生命周期状态机的设计里面有详细的解释。适用范围 适用场景 CRD或Iac定义时单个对象的终态只应该包含自身及对依赖的引用。与面向对象的设计相同我们不应该把所有类的定义都放到一个Class里面。 不适用场景 多个对象要一次性创建并且需要按照顺序创建存在依赖关系需要通过编排层实现。 误区3 一切皆终态 体验了K8s的终态化之后大家在设计时言必称终态仿佛不能用上终态设计不下发一个yaml声明对象的终态就是落伍就是上一代的设计。 案例 案例1应用编排 还是以WordPress为例将WordPressDB和WordPress放在一起进行部署先部署DB再创建应用。示例yaml同上。 案例2应用发布 应用第一次部署及后续的升级直接下发一个完整的应用yaml系统会自动帮你到达终态。但为了能够细粒度控制发布的流程努力在Deployment或StatefulSet上下功夫进行partition的控制试图在终态里增加一点点的交互性。 反思 说到终态必然要提到命令式、声明式编程终态其实就是声明式最终的执行结果。我们先回顾一下命令式、终态式编程。 命令式编程 命令式编程的主要思想是关注计算机执行的步骤即一步一步告诉计算机先做什么再做什么。 比如如果你想在一个数字集合 collection(变量名) 中筛选大于 5 的数字你需要这样告诉计算机 1. 第一步创建一个存储结果的集合变量 results 2. 第二步遍历这个数字集合 collection 3. 第三步一个一个地判断每个数字是不是大于 5如果是就将这个数字添加到结果集合变量 results 中。 代码实现如下 List results new List(); foreach(var num in collection) { if (num 5) results.Add(num); } 很明显这个样子的代码是很常见的一种不管你用的是 C, C 还是 C#, Java, Javascript, BASIC, Python, Ruby 等等你都可以以这个方式写。 声明式编程 声明式编程是以数据结构的形式来表达程序执行的逻辑。它的主要思想是告诉计算机应该做什么但不指定具体要怎么做。 SQL 语句就是最明显的一种声明式编程的例子例如 SELECT * FROM collection WHERE num 5 除了 SQL网页编程中用到的 HTML 和 CSS 也都属于声明式编程。 通过观察声明式编程的代码我们可以发现它有一个特点是它不需要创建变量用来存储数据。 另一个特点是它不包含循环控制的代码如 for while。 换言之 • 命令式编程命令“机器”如何去做事情(how)这样不管你想要的是什么(what)它都会按照你的命令实现。 • 声明式编程告诉“机器”你想要的是什么(what)让机器想出如何去做(how)。 当接口越是在表达“要什么”就是越声明式越是在表达“要怎样”就是越命令式。SQL就是在表达要什么数据而不是表达怎么弄出我要的数据所以它就很“声明式”。 简单的说接口的表述方式越接近人类语言——词汇的串行连接一个词汇实际上是一个概念——就越“声明式”越接近计算机语言——“顺序分支循环”的操作流程——就越“命令式”。 越是声明式意味着下层要做更多的东西或者说能力越强也意味着效率的损失。越是命令式意味着上层对下层有更多的操作空间可以按照自己特定的需求要求下层按照某种方式来处理。 简单的讲Imperative Programming Language (命令式语言)一般都有control flow, 并且具有可以和其他设备进行交互的能力。而Declarative Programming language (声明式语言) 一般做不到这些。 基于以上的分析编排或工作流本质是一个流程性控制的过程一般是一次性的过程无需强行终态化而且建站编排执行结束后不能保持终态因为后续会根据单个应用进行发布和升级。案例1是一个典型的编排只是一次性的创建了2个对象DB和应用的终态。 应用发布其实是通过一个发布单或工作流控制2个不同版本的应用节点和流量的终态化的过程不应该是应用终态的一部分而是一个独立的控制流程。 适用范围 声明式或终态设计 适用场景 无过多交互无需关注底层实现的场景即把声明提供给系统后系统会自动化达到声明所要求的状态而不需要人为干预。 不适用场景 一次性的流程编排有频繁交互的控制流程 命令式和声明式本就是2种互补的编程模式就像有了面向对象之后有人就鄙视面向过程的编程现在有了声明式就开始鄙视命令式编程那一屋 误区4 一切交互皆cr 因为K8s的API交互只能通过yaml导致大家的设计都以cr为中心所有的交互都设计为下发一个cr通过watch cr触发对应的逻辑。 案例 调用一个http接口或function需要下发一个cr应用crud都下发完整cr反思 案例1 是否所有的逻辑都需要下发一个cr 下发cr其实做了比较多的事情流程很长效率并不高流程如下 通过API传入crcr 保存到etcd触发informercontroller接收到对应的事件触发逻辑更新cr状态清理cr否则会占用etcd存储如果需要频繁的调用对应的接口尽量通过sdk直接调用。 案例2 K8s 对yaml操作命令有 create、apply、patch、delete、get等但一个应用的生命周期状态机不只是这几个命令可以涵盖我们比较一下应用状态机上和yaml状态机下 不同的有状态应用在收到不同的指令需要触发不同的逻辑例如MQ在收到stop指令时需要先停写检查数据是否消费完成。如果只是通过yaml状态机是无法涵盖应用状态机相关的event所以我们必须打破下发cr的模式。对于应用来说理想的交互方式是通过event driven 应用状态机的变化状态发生变换时触发对应的逻辑。 适用范围 适用场景 需要持久化保持终态的数据 不适用场景 高频的服务调用无需持久化的数据 复杂状态机的驱动 总结 K8s给我们打开了一扇门带给了我们很多优秀的设计优秀的理念但是这些设计和理念也是有自己的适用的场景并不是放之四海而皆准。我们不应该盲从试图一切都要follow k8s的设计和规则而抛弃之前的优秀设计理念。 软件设计经历了10多年的发展形成了一套行之有效的设计方法论k8s也是在这些设计方法论的支持下设计出来的。取其精华去其糟粕是我们程序员应该做的事情。 参考文章: 揭秘Kubernetes Operator http://www.dockone.io/article/8769声明式编程和命令式编程有什么区别 https://www.zhihu.com/question/22285830如何在Kubernetes中编写自定义控制器 https://www.sohu.com/a/363619791_198222 原文链接 本文为阿里云原创内容未经允许不得转载。