佛山网站优化推广方案,建筑方案设计步骤,没人做网站了吗,js音乐网站模板戳蓝字“CSDN云计算”关注我们哦#xff01;前情回顾#xff1a;《Kubernetes API 与 Operator#xff1a;不为人知的开发者战争#xff08;上#xff09;》2016 年秋天#xff0c;原 CoreOS 公司的工程师邓洪超像往常一样#xff0c;来到了同事位于福斯特城#xff08… 戳蓝字“CSDN云计算”关注我们哦前情回顾《Kubernetes API 与 Operator不为人知的开发者战争上》2016 年秋天原 CoreOS 公司的工程师邓洪超像往常一样来到了同事位于福斯特城Foster City的公寓进行结对编程。每周四相约在这里结对是这两位工程师多年来约定俗成的惯例。CoreOS 当年开发 etcd 所在的车库不过与以往不同的是相比于往常天马行空般的头脑风暴这一次这两位工程师的脑子里正在琢磨着的是一个非常“接地气”的小项目。我们知道Kubernetes 项目实现“容器编排”的核心在于一个叫做“控制器模式”的机制即通过对 etcd 里的 API 对象的变化进行监视WatchKubernetes 项目就可以在一个叫做 Controller 的组件里对这些变化进行响应。而无论是 Pod 等应用对象还是 iptables、存储设备等服务对象任何一个 API 对象发生变化那么 Kubernetes 接下来需要执行的响应逻辑就是对应的 Controller 里定义的编排动作。所以一个自然而然的想法就是作为 Kubernetes 项目的用户我能不能自己编写一个 Controller 来定义我所期望的编排动作呢比如当一个 Pod 对象被更新的时候我的 Controller 可以在“原地”对 Pod 进行“重启”而不是像 Deployment 那样必须先删除 Pod然后再创建 Pod。这个想法其实是很多应用开发者以及 PaaS 用户的强烈需求也是一直以来萦绕在 CoreOS 公司 CEO Alex Polvi 脑海里的一个念头。而在一次简单的内部讨论提及之后这个念头很快就激发出了两位工程师的技术灵感成为了周四结对编程的新主题。而这一次他们决定把这个小项目起名叫做Operator。所以顾名思义Operator 这个项目最开始的初衷是用来帮助开发者实现运维Operate能力的。但 Operator 的核心思想却并不是“替开发者做运维工作”而是“让开发者自己编写运维工具”。更有意思的是这个运维工具的编写标准或者说编写 Operator 代码可以参考的模板正是 Kubernetes 的“控制器模式Controller Pattern”。前面已经说过 Kubernetes 的“控制器模式”是围绕着比如 Pod 这样的 API 对象在 Controller 通过响应它的增删改查来定义对 Pod 的编排动作。而 Operator 的设计思路就是允许开发者在 Kubernetes 里添加一个新的 API 对象用来描述一个分布式应用的集群。然后在这个 API 对象的 Controller 里开发者就可以定义对这个分布式应用集群的运维动作了。举个例子 假设下面这个 YAML 文件定义的是一个 3 节点 etcd 集群的描述apiVersion: etcd.database.coreos.com/v1beta2kind: EtcdClustermetadata: name: example-etcd-clusterspec: size: 3 version: 3.2.13有了这样一个 etcdCluster 对象那么开发者接下来要做的事情就是编写一个 etcdCluster Controller使得当任何用户提交这样一个 YAML 文件给 Kubernetes 之后我们自己编写的 Controller 就会响应 etcdCluster “增加”事件为用户创建出 3 个节点的 etcd 集群出来。然后它还会按照我们在 Controller 编写的事件响应逻辑自动的对这个集群的节点更新、删除等事件做出处理执行我定义的其他运维功能。像这样一个 etcdCluster Controller就是 etcd Operator 的核心组成部分了。而作为 etcd 的开发者CoreOS 的两位工程师把对 etcd 集群的运维工作编写成 Go 语言代码一点都不困难。可是要完成这个 Operator 真正困难在于Kubernetes 只认识 Pod、Node、Service 等这些 Kubernetes 自己原生的 API 对象它怎么可能认识开发者自己定义的这个 etcdCluster 对象呢在当时 Kubernetes 项目允许用户自己添加 API 对象的插件能力叫做 Third Party Resource简称TPR。TPR 允许你提交一个 YAML 文件来定义你想要的的新 API 对象的名字比如etcdCluster也允许你定义这个对象允许的合法的属性比如int 格式的 size 字段 string 格式的 version 字段。然后你就可以提交一个具体的 etcdCluster 对象的描述文件给 Kubernetes等待该对应的 Controller 进行处理。而这个 Controller就是 Operator 的主干代码了。所以接下来CoreOS 的两位工程师轻车熟路在 Operator 里对 etcdCluster 对象的增、删、改事件的响应位置写上了创建、删除、更新 etcd 节点的操作逻辑。然后调试运行看着一个 etcd 集群按照 YAML 文件里的描述被创建起来。大功告成就这样在一个普通的周四下午世界上第一个 Operator 诞生在了湾区的一所公寓当中。而对于 CoreOS 的两位工程师来说编写这个小工具的主要目的就是借助 Kubernetes 的核心原理来自动化的管理 etcd 集群更重要的是不需要使用 Kubernetes 里自带的 StatefulSet。你可能已经知道Kubernetes 里本身就内置了一个叫做 StatefulSet 的功能是专门用来管理有状态应用的。而 StatefulSet 的核心原理其实是对分布式应用的两种状态进行了保持分布式应用的拓扑状态或者说节点之间的启动顺序分布式应用的存储状态或者说每个节点依赖的持久化数据。可是为了能够实现上述两种状态的保持机制StatefulSet 的设计就给应用开发者带来了额外的束缚。比如etcd 集群各节点之间的拓扑关系并不依赖于节点名字或者角色比如 Master 或者 Slave来确定而是记录在每个 etcd 节点的启动参数当中。这使得 StatefulSet 通过“为节点分配有序的 DNS 名字”的拓扑保持方式实际上没有了用武之地反而还得要求开发者在节点的启动命令里添加大量的逻辑来生成正确的启动命令非常不优雅。类似的对于存储状态来说etcd 集群对数据的备份和恢复方法也跟 StatefulSet 依赖的的远程持久化数据卷方案并没有太大关系。不难看到 StatefulSet 其实比较适用于应用本身节点管理能力不完善的项目比如 MySQL。而对于 etcd 这种已经借助 Raft 实现了自管理的分布式应用来说 StatefulSet 的使用方法和带来的各种限制其实是非常别扭的。而带着工程师特有的较真儿精神邓洪超和他的同事借助 Kubernetes 原生的扩展机制实现的正是一个比 StatefulSet 更加灵活、能够把控制权重新交还给开发者的分布式应用管理工具。他们把这个工具起名叫做 Operator并在几个月后的 KubeCon 上进行了一次 Demo 推荐大家尝试使用 Operator 来部署 etcd 集群。没有人能想到的是这个当时还处于 PoC 状态的小项目一经公布就立刻激发起了整个社区的模仿和学习的热潮。很快大量的应用开发者纷纷涌进 Kubernetes 社区争先恐后的宣布自己的分布式项目可以通过 Operator 运行起来。而敏锐的公有云提供商们很快看出了这其中的端倪Operator 这个小框架已然成为了分布式应用和有状态应用“上云”的必经之路。PrometheusRook伴随着越来越多的、以往在容器里运行起来困难重重的应用通过 Operator 走上了 Kubernetes 之后Kubernetes 项目第一次出现在了开发者生态的核心位置。这个局面已经远远超出了邓洪超甚至 CoreOS 公司自己的预期。更重要的是不同于 StatefulSet 等 Kubernetes 原生的编排概念Operator 依赖的 Kubernetes 能力只有最核心的声明式 API 与控制器模式Operator 具体的实现逻辑则编写在自定义 Controller 的代码中。这种设计给开发者赋予了极高的自由度这在整个云计算和 PaaS 领域的发展过程中都是非常罕见的。此外相比于 Helm、Docker Compose 等描述应用静态关系的编排工具Operator 定义的乃是应用运行起来后整个集群的动态逻辑。得益于 Kubernetes 项目良好的声明式 API 的设计和开发者友好的 API 编程范式Operator 在保证上述自由度的同时又可以始终如一的展现出清晰的架构和设计逻辑使得应用的开发者们可以通过复制粘贴就快速搭建出一个 Operator 的框架然后专注于填写自己的业务逻辑。在向来讲究“用脚投票”的开发者生态当中Operator 这样一个编程友好、架构清晰、方便代码复制粘贴的小工具本身就已经具备了某些成功的特质。然而Operator 的意外走红并没有让 CoreOS 公司“一夜成名”反而差点将这个初出茅庐的项目扼杀在萌芽状态。在当时的 Kubernetes 社区里跟应用开发者打交道并不是一个非常常见的事情。而 Operator 项目的诞生却把 Kubernetes 项目第一次拉近到了开发者的面前这让整个社区感觉了不适应。而作为 Kubernetes 项目 API 治理的负责人Google 团队对这种冲突的感受最为明显。对于 Google 团队来说Controller 以及控制器模式应该是一个隐藏在 Kubernetes 内部实现里的核心机制并不适合直接开放给开发者来使用。退一步说即使开放出去这个 Controller 的设计和用法也应该按照 Kubernetes 现有的 API 层规范来进行最好能成为 Kubernetes 内置 Controller Manager 管理下的一部分。可是 Operator 却把直接编写 Controller 代码的自由度完全交给了开发者成为了一个游离于 Kubernetes Controller Manager 之外的外部组件。带着这个想法社区里的很多团队从 Operator 项目诞生一开始就对它的设计和演进方向提出了质疑甚至建议将 Operator 的名字修改为 Custom Kubernetes Controller。而无巧不成书就在 Google 和 CoreOS 在 Controller 的话语权上争执不下的时候 Kubernetes 项目的发起人之一 Brendan Burns 突然宣布加入了微软这让 Google 团队和 Operator 项目的关系一下子跌倒了冰点。你可能会有些困惑Brendan Burns 与 Kubernetes 的关系我是清楚的但这跟 Operator 又有什么瓜葛吗实际上你可能很难想到Brendan Burns 和他的团队才是 TPR Third Party Resource这个特性最初的发起人。所以几乎在一夜之间Operator 项目链路上的每一个环节都与 Google 团队完美的擦肩而过。眼睁睁的看着这个正冉冉升起的开发者工具突然就跟自己完全没了关系这个中滋味确实不太好受。于是在 2017年初Google 团队和 RedHat 公司开始主动在社区推广 UASUser Aggregated APIServer也就是后来 APIServer Aggregator 的雏形。APIServer Aggregator 的设计思路是允许用户编写一个自定义的 APIServer在这里面添加自定义 API。然后这个 APIServer 就可以跟 Kubernetes 原生的 APIServer 绑定部署在一起统一提供服务了。不难看到这个设计与 Google 团队认为自定义 API 必须在 Kubernetes 现有框架下进行管理的想法还是比较一致的。紧接着RedHat 和 Google 联盟开始游说社区使用 UAS 机制取代 TPR并且建议直接从 Kubernetes 项目里废弃 TPR 这个功能。一时间社区里谣言四起不少已经通过 TPR 实现的项目也开始转而使用 UAS 来重构以求自保。 而 Operator 这个严重依赖于 TPR 的小项目还没来得及发展壮大就被推向了关闭的边缘。面对几乎要与社区背道而驰的困境CoreOS 公司的 CTO Brandon Philips 做出了一个大胆的决定让社区里的所有开发者发声挽救 TPR 和 Operator。2017 年 2月Brandon Philips 在 GitHub 上开了一个帖子Gist 号召所有使用 TPR 或者 Operator 项目的开发者在这里留下的自己的项目链接或者描述。这个帖子迅速的成为了当年容器技术圈最热门的事件之一登上了 HackerNews 的头条。有趣的是这个帖子直到今天也仍然健在甚至还在被更新你可以点击这个链接去感受一下当时的盛况。https://gist.github.com/philips/a97a143546c87b86b870a82a753db14c而伴随着 Kubernetes 项目的迅速崛起短短一年时间不到夹缝中求生存的 Operator 项目开始对公有云市场产生了不可逆转的影响也逐步改变了开发者们对“云”以及云上应用开发模式的基本认知。甚至就连 Google Cloud 自己最大的客户之一 Snapchat 也成为了 Operator 项目的忠实用户。在来自社区的巨大压力下在这个由成千上万开发者们自发维护起来的 Operator 生态面前Google 和 RedHat 公司最终选择了反省和退让。有意思的是这个退让的结果再一次为这次闹剧增添了几分戏剧性。就在 Brandon Phillips 的开发者搜集帖发布了不到三个月后RedHat 和 Google 公司的工程师突然在 Kubernetes 社区里宣布TPR 即将被废弃取而代之的是一个名叫 CRDCustom Resource Definition 的东西。于是开发者们开始忧心忡忡的按照文档将原本使用 TPR 的代码都升级成 CRD。而就在这时他们却惊奇的发现这两种机制除了名字之外好像并没有任何不同。所谓的升级工作其实就是将代码里的 TPR 字样全局替换成 CRD 而已。难道这只是虚惊一场其实很少有人注意到在 TPR 被替换成 CRD 之后Brendan Burns 和微软团队就再也没有出现在“自定义 API”这个至关重要的领域里了。而 CRD 现在的负责人都是来自 Google 和 RedHat 的工程师。在这次升级事件之后不久CoreOS 公司在它的官方网站上发布了一篇叫做TPR Is Dead! Kubernetes 1.7 Turns to CRD 的博客https://coreos.com/blog/custom-resource-kubernetes-v17旨在指导用户从 TRP 升级成 CRD。不过现在回头再看一眼这篇文章平淡无奇的讲述背后你能否感受到当年这场“开发者战争”的蛛丝马迹呢其实Operator 并不平坦的晋级之路只是 Kubernetes API 生态风起云涌的冰山一角。几乎在每个星期甚至每一天都有太多围绕着 Kubernetes 开发者生态的角逐在这个无比繁荣的社区背后以不为人知的方式开始或者谢幕。而这一切纷争的根本原因却无比直白。Kubernetes 项目已经被广泛认可为云计算时代应用开发者们的终端入口。这正是为何无论是 Google、微软还是 CoreOS 以及 Heptio所有这个生态里的大小玩家都在不遗余力的在 Kubernetes API 层上捍卫着自己的话语权以期在这个未来云时代的开发者入口上争取到自己的一席之地。而在完成了对收 CoreOS 的收购之后RedHat 终于在这一领域拿到了可以跟 Google 和微软一较高低的关键位置。2018年RedHat 不失时机的发布了 Operator Framework希望通过 Operator 周边工具和生态的进一步完善把 Operator 确立成为分布式应用开发与管理的关键依赖。而伴随着 Operator 越来越多的介入到应用开发和部署流程之后 Kubernetes API 一定会继续向上演进进一步影响开发者的认知和编程习惯。这已经成为了云计算生态继续发展下去的必然趋势。而作为这个趋势坚定不移的贯彻者无论是 Istio还是 Knative都在用同样的经历告诉我们这样的道理只有构建在 Kubernetes 这个云时代基础设施事实标准上的开发者工具才有可能成为下一个开发者领域的 “Operator” 。推荐阅读关于云原生这是最详细的技术知识用“AI”给吴秀波测面相发现……程序员一毕业就年薪 110 万竟然是靠……程序员锁死服务器失踪公司解散 600 万项目彻底黄了史上最全新媒体运营工具121种一年省下1000亿? 原来零售玩的是闷声发大财SparkAlluxio性能调优十大技巧从云计算到AINetApp的数据网络转型之道1.微信群添加小编微信color_ld备注“进群姓名公司职位”即可加入【云计算学习交流群】和志同道合的朋友们共同打卡学习2.征稿投稿邮箱liudancsdn.net微信号color_ld。请备注投稿姓名公司职位。喜欢就点击“好看”吧
