- 主题:[转载]为什么现代软件让我悲伤
某些客户端 API 还是比 V2 科学
典型的如 watch
【 在 zli07 的大作中提到: 】
: 我们公司一些核心配置存储系统之前是部署在etcd2上的,后来新增的一个配置平台迁移到了etcd3。但是etcd3的客户端逻辑实在太恶心,于是又搞了一套agent,能把存储在etcd3上的配置用etcd2的接口读取。。
--
FROM 117.35.111.*
watch 很吃服务器性能的
而且 grpc server 实现有问题,并没有利用到 http2 的单连接多 stream,同时 watch 多个 key 的话需要建立多条连接。
实际使用中最方便的还是搭建 etcd2 的分布式网络,网络内部可以通过各种协议进行同步,然后客户端连接各个节点进行轮询,这样即使客户端轮询频繁点也不会拖垮整个系统
【 在 litguy 的大作中提到: 】
: 某些客户端 API 还是比 V2 科学
: 典型的如 watch
--
FROM 120.52.147.*
k8s的野心是十分庞大的,docker只是它支持的其中一种容器,除此之外还有很多,比如cgroup
另外k8s从云厂商角度看,可以实现更炫酷的裸金属容器,实现更高效的资源利用
所以k8s对于个人开发就没多大意义,它只做了一半的事,剩下的还需要云厂商自己实现
个人在自己的服务器上安装系统再安装k8s就要做太多的事
时代早变了
另外,容器+k8s是开发、发布方式的变革,
开发者只管容器,运维只管集群
这个人的感慨有他自己的角度,不过时代变了
【 在 hgoldfish 的大作中提到: 】
: etcd 是一个使用 raft 一致算法的 KV 数据库,产生于 2013 年。最早是为 CoreOS 开发的,但本文不关心这个烂货,它已经完蛋了。本文的主角,它的副产物 etcd 使用更广泛。etcd 提供了简洁的 HTTP API, 多年以来,我已经使用 etcd 开发了多个工具。
: 2015 年的时候,又诞生了另外一个与之没有关系的 Kubernetes 项目,很多人称它为 k8s. 在我看来,这是继 systemd 之后系统管理领域的最大灾难。它号称要简化集群管理,为大众带来 Google borg 集群管理软件的体验。但实际上:
: 1. 为你的软件添加了几百种出错的模式。
: ...................
--
FROM 124.65.192.*
作者感慨的不是 k8s,是 etcd 啊。
【 在 pigtracer (知心哥哥) 的大作中提到: 】
: k8s的野心是十分庞大的,docker只是它支持的其中一种容器,除此之外还有很多,比如cgroup
: 另外k8s从云厂商角度看,可以实现更炫酷的裸金属容器,实现更高效的资源利用
: 所以k8s对于个人开发就没多大意义,它只做了一半的事,剩下的还需要云厂商自己实现
: ...................
--
修改:hgoldfish FROM 112.47.122.*
FROM 112.47.122.*