- 主题:[转载]为什么现代软件让我悲伤
你把k8s面向的人群搞错了，k8s并不是为研发工程师准备的，k8s的使用对象是运维人员。未来尽量减轻运维的环境部署、系统迁移、资源调配而开发。
而对于运维来说，不关心开发的艺术，只要省心省力，不出问题就好了。所以k8s的只做调度和资源调配，而不去触碰容器和VM，容器和VM必然是留给专业的项目
【 在 hgoldfish 的大作中提到: 】
: etcd 是一个使用 raft 一致算法的 KV 数据库，产生于 2013 年。最早是为 CoreOS 开发的，但本文不关心这个烂货，它已经完蛋了。本文的主角，它的副产物 etcd 使用更广泛。etcd 提供了简洁的 HTTP API, 多年以来，我已经使用 etcd 开发了多个工具。
: 2015 年的时候，又诞生了另外一个与之没有关系的 Kubernetes 项目，很多人称它为 k8s. 在我看来，这是继 systemd 之后系统管理领域的最大灾难。它号称要简化集群管理，为大众带来 Google borg 集群管理软件的体验。但实际上：
: 1. 为你的软件添加了几百种出错的模式。
: ...................
--
FROM 114.249.193.*
改变的不是写代码方式，而是开发管理方式。传统开发和敏捷在开发阶段参与者角色是项目经理、产品人员、设计人员、开发人员。而devops主张的是全员开发，将本来位于上线阶段的运维人员前置，从项目规划阶段就参与开发。
开发管理方理念的改变，带来的是全流程的变化，写代码的方式其实没有改变，而是因为流程的变化，导致以前开发结束才考虑的环境配置放到了前边。至于server到service mesh跟云原生没有必然联系，实际上在分布式rpc开始就已经在向这个方向发展了，接着演化出服务化，一直到近些年的微服务。
而容器化是由微服务带来的需求，服务功能单一化之后，单独的物理机或者虚拟机，运行一个单一功能的服务显然是资源的巨大浪费，于是基于相同环境的新资源组织形式才有了实际的需求。
所以，显示dry原则的落地，然后是服务的单一化，之后才是容器化。不要云原生这个结果当成了原因
【 在 ilovecpp 的大作中提到: 】
: k8s生态主张以新方式（“云原生”）写代码，例如，把网络配置，服务发现等全部从server移到service mesh，server只和sidekick通讯。这显然是要改变开发写代码的方式的。
--
FROM 114.249.193.*
这个。。。学习路线是：前后端分离的开发方式->微服务->容器化
当你有几百甚至几千个微服务，运行了成千上万的容器，分布在几百台物理机上。
不管是项目leader还是运维人员，你是要亲自写脚本上，还是用k8s把容器和物理机管理起来？
【 在 ztysys 的大作中提到: 】
: k8s到底是个啥？没用过哈
: 是打包软件，就像zip那样把一堆东西压缩打包在解压？
: 还是专门做管理，在哪儿哪儿再部署一套系统？
: ...................
--
FROM 114.249.193.*
这个时代运维也分为运维开发人员和普通运维，运维开发实际上是开启了运维的一个新的上升渠道。
传统的运维受限于工作内容，只能在初、中、高、专家级的运维体系内晋升，再向上就是跨体系的体系架构师，能实现职业跨越的毕竟是少数
而到了运维开发序列，工作内容从脚本和数据收集转化为对运维系统的开发，晋升序列也并入开发人员级别，毕竟运维开发也是开发，只不过专注的方向不同。
不过对于普通运维，还是普通运维，人各有志，这个不能勉强，所以不影响传统运维恰饭，只不过未来运维的需求量会增加，而传统运维的需求会逐渐变少
【 在 xiaoju 的大作中提到: 】
: 运维不一定喜欢k8s，他们更喜欢云平台原生的方案，直接点几下鼠标什么都搞定
: k8s和docker一样是devops理念发展带来的产物
:
--
FROM 114.249.193.*