极客视点
极客时间编辑部
极客时间编辑部
113243 人已学习
免费领取
课程目录
已完结/共 3766 讲
2020年09月 (90讲)
时长 05:33
2020年08月 (93讲)
2020年07月 (93讲)
时长 05:51
2020年06月 (90讲)
2020年05月 (93讲)
2020年04月 (90讲)
2020年03月 (92讲)
时长 04:14
2020年02月 (87讲)
2020年01月 (91讲)
时长 00:00
2019年12月 (93讲)
2019年11月 (89讲)
2019年10月 (92讲)
2019年09月 (90讲)
时长 00:00
2019年08月 (91讲)
2019年07月 (92讲)
时长 03:45
2019年06月 (90讲)
2019年05月 (99讲)
2019年04月 (114讲)
2019年03月 (122讲)
2019年02月 (102讲)
2019年01月 (104讲)
2018年12月 (98讲)
2018年11月 (105讲)
时长 01:23
2018年10月 (123讲)
时长 02:06
2018年09月 (119讲)
2018年08月 (123讲)
2018年07月 (124讲)
2018年06月 (119讲)
时长 02:11
2018年05月 (124讲)
时长 03:16
2018年04月 (120讲)
2018年03月 (124讲)
2018年02月 (112讲)
2018年01月 (124讲)
时长 02:30
时长 02:34
2017年12月 (124讲)
时长 03:09
2017年11月 (120讲)
2017年10月 (86讲)
时长 03:18
时长 03:31
时长 04:25
极客视点
15
15
1.0x
00:00/06:01
登录|注册

Kubernetes会不会“杀死” DevOps?

讲述:丁婵大小:8.27M时长:06:01
DevOps 这个概念最早是在 2007 年提出的,它作为一种打破研发和运维之间隔阂、加快软件交付流程、提高软件交付质量的文化理念和最佳实践,逐渐普及至今。而随着云时代的到来,号称将应用与“云”天然集成在一起的 Kubernetes 让传统的 DevOps 工具和团队受到了挑战,Kubernetes 会“杀死” DevOps 吗?最近,阿里巴巴技术专家孙健波就这个问题进行了分析,并发表了自己的看法,重点内容如下。
Kubernetes 的本质是现代应用基础设施,它的目的是将“云”的最大价值发挥出来。Kubernetes 强调让基础设施能更好的配合应用、以更高效的方式为应用“输送”基础设施能力。在这个过程中,Kubernetes 、Docker、Operator 等在云原生生态中起到了关键作用的开源项目,正在在把应用管理与交付推上一个跟以前完全不一样的境况:以前,Kubernetes 的使用者只通过声明式的方式描述自己应用的终态是什么,然后一切就结束了。现在的 Kubernetes 会处理后面的所有事情。
这也是为什么 Kubernetes 非常强调声明式 API。通过这种方式,Kubernetes 本身接入的基础设施能力越强,Kubernetes 的使用者能够声明的终态就越丰富,其职责也就越单纯。现在,我们不仅能够通过 Kubernetes 声明应用的运行终态,我们还能够声明应用的很多运维终态,
这就让传统的 DevOps 工具和团队受到了挑战:如果一个业务研发自己只需要通过声明式 API 声明他的应用的所有终态甚至包括完整的 SLA,后面的一切就都会有 Kubernetes 来自动的搞定,那么他还有什么理由去对接和学习各式各样的 DevOps 流水线呢?
换句话说,长久以来,DevOps 实际上是在充当研发与基础设施之间的那一层“胶水”。而现在,Kubernetes 通过它极具生命力的声明式 API 和无限接入的应用基础设施能力,正在完美的扮演这个“胶水层”的作用。
近几年,Kubernetes 项目经常被描述成 DevOps 的“最佳拍档”。类似的观点认为, Kubernetes 跟 Docker 一样,解决的是软件运行时的问题。所以,只要能够将现有 DevOps 思想和流程对接到 Kubernetes 上来,就可以享受到容器技术带来的轻量级与弹性。这对于提倡“敏捷”的 DevOps 来说,显然是最好的组合。
不过,至少目前看来,Kubernetes 虽然关注接入底层的基础设施能力,但它本身却又不是基础设施能力的提供方。而且,相比于软件运行时,Kubernetes 似乎更关心软件的生命周期和状态流转。不仅如此,它还提供了一种叫做“控制器模型”的机制来将软件的实际状态与期望状态不断逼近,这显然都已经超出了一个“软件运行时”的范畴。
Kubernetes 项目对应用本身的“额外关注”,让它“胶水”的定位更加明显。而如果 Kubernetes 的能力足够强大,DevOps 是否还有必要存在?在所谓的云原生时代,应用研发与交付是不是真的会走向“一次声明”就可以“撒手不管”,从而让 DevOps 彻底消失呢?
至少目前看来,Kubernetes 项目距离这个愿景,还有不少困难需要克服。
首先,Kubernetes 是一个典型的 “Platform for Platform”项目,所以它的 API,距离纯研发视角还非常遥远。而且, Kubernetes API 并没有提供出对“运维能力”的描述与定义方式,这也使得声明之后的“撒手不管”变得遥不可及。这也是为什么目前 DevOps 依然被需要的原因:Kubernetes 的大多数字段,还是必须经过研发和运维共同协作的流程来进行填充。
其次,Kubernetes 的原生 API 只包含了云资源的很少一部分, 比如用 PV/PVC 表达存储,用 Ingress 表达负载均衡,但这对于一个完全声明式的应用描述来说是完全不够的。
此外,虽然 Kubernetes 的 Operator 机制是这个项目的能力能够无限增长的公开秘密,但令人遗憾的是,目前所有 Operator 之间的关系,就像是一个又一个的烟囱,互相之间没有任何交互与协作的可能。这就又需要 DevOps 的体系介入来解决问题。
显然,现在的 Kubernetes 项目,依然需要借助 DevOps 体系来真正完成软件的高效迭代与交付工作。
不过,Kubernetes 在它的关键路径上,始终保持着对研发侧 “NoOps” 的追求。这种渴望,从它第一天提出“声明式应用管理”理论的时候就已经“昭然若揭”,而 CRD 和 Operator 体系的建立,更让这种应用级别的关心终于有了落地的机会。我们已经看到很多 DevOps 流程正在“下沉”为 Kubernetes 里的声明式对象与控制循环,比如 Tekton CD 项目
如果 Kubernetes 的未来是 100% 的声明式应用管理,那么我们有理由相信 DevOps 最终会从技术领域消失然后彻底蜕变成一种文化。
以上就是今天的内容,欢迎留下你的见解,一起探讨。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
该免费文章来自《极客视点》,如需阅读全部文章,
请先领取课程
免费领取
登录 后留言

全部留言(1)

  • 最新
  • 精选
  • 明明如月🐍
    天元威武!
    1
收起评论
显示
设置
留言
1
收藏
34
沉浸
阅读
分享
手机端
快捷键
回顶部