大家有没有搞过有状态应用上 K8S

• 資深大佬 : stevefan1999

  ??? StatefulSet*啊 你重學下 k8s 吧

  *雖然就算有 statefulset 也不一定能一勞永逸
  畢竟會有狀態同步問題
  這時候就是應用層面處理了
  你需要做簡單的 HA 譬如 JBoss/Vertex/DNS

• 資深大佬 : forbxy

  网络存储都是垃圾，不适合这种存储应用，个人觉得这种东西就不适合上 k8s，statefulset 限制也很多的

• 資深大佬 : buliugu

  k8s 原生只有 StatefulSet，正常用大家当然是等大厂放出官方的 operator 啦（逃

• 資深大佬 : fuis

  俺弄了重型有状态应用的移植。自己写了 operator，依赖一个 local pv provisioner
  上说的 statefulset 其实本身也有各种问题，比如默认的 rollingupdate 策略不能指定某个 pod，等等。不过总体来说我觉得还是比较容易的。

• 資深大佬 : liuzhaowei55

  又不需要敏捷开发，多次发布，负载均衡也有自己的解决方案，为啥要用 k8s 呢

• 資深大佬 : CallMeReznov

  刚好,中午吃饭的时候阅读到的
  mysql 主备上 k8s:https://mp.weixin.qq.com/s/D3WI2JnhV4Bilb9DEkcOTA

• 主 資深大佬 : zhoudaiyu

  @liuzhaowei55 #5 领导的意思这种玩意都尽可能上上去（除了 mysql ）

• 資深大佬 : wingoo

  有状态应用的问题是出了问题你能不能解决, 不能解决的话就不要上 k8s

• 資深大佬 : root01

  我都现在都不明白有状态和无状态的区别

• 資深大佬 : wellsc

  staefulset 也是个坑

• 資深大佬 : catchexception

  一言难尽，无状态全上 K8s，有状态编排各有各的难点。负载均衡有时自己要在应用内实现，或者加 ClientIP 与 Pod 亲和。
  Redis 我记得有主从镜像的，可以直接拿来用。

• 資深大佬 : avastms

  云计算只有 CPU 内存和网络实现了动态分配。

  存储一直都是阵列提供的。

  数据库这种存储应用，不要考虑云计算，按传统部署来。

• 資深大佬 : KaynW

  搞过

• 資深大佬 : XiaoxiaoPu

  @avastms 存储早就云化了啊，对象存储、块存储、文件存储等等，很多了

• 資深大佬 : avastms

  @XiaoxiaoPu 对象存储不算存储， 快存储就是 iSCSI，阵列提供的, 文件存储就 smb/nfs，还是阵列。
  里外都是阵列，没那么灵活。

• 資深大佬 : XiaoxiaoPu

  @avastms 对象存储怎么不是存储了，能存能读能持久化。块存储、文件存储早就有分布式的解决方案了，不依赖硬件。

• 資深大佬 : avastms

  @XiaoxiaoPu 能放数据库吗对象存储，就那个 IO 性能，歇了吧。

  我说存储没有云化，不是说它底层依赖单一硬件阵列，而是说它没法像 CPU 和内存那样动态放缩，灵活调配，它还是一块盘，不是一种资源。

  你是云提供商，你可以说像 ceph 这种东西完成了存储的云化，但对使用者来讲，你这个块设备是阵列给你的还是 ceph 给你的，对你来讲有差吗，不分区格式化能行吗？
  这块盘能多挂载多写吗，读写事件能都收到吗？
  那不还是阵列吗？

  所以说存储这一块它没有云化，像数据库这种东西，还是老样子啊，要想真正云化，需要普及一种高性能分布式文件系统先，能动态放缩的那种。

  存储的灵活性现在是数据库应用这层提供的，不是存储盘这层提供的。

  你可以说云数据库，这是真云， 云存储，得了吧，就是别人计算机上的盘而已。

• 資深大佬 : monsterxx03

  @avastms 块设备很成熟了啊, aws ebs, gce pv, aws 自己的 rds 和 aurora 也是基于 ebs 的, 动态扩容一直可以, 缩不行, 但就我经验, 大多数业务缩容并不是一个刚需. 多挂载算是个痛点, NFS 这种太弱了, 但大多数应用也不是刚需. 现有的 sds 块设备方案基本能解决我碰到的 90%问题, iops 性价比也算是个问题.

• 資深大佬 : crclz

  @avastms 还真有你说的那种完全“云化”的数据库）。
  对象储存勉强算一种。此外，还有如下的：
  AWS DynamoDB, Azure CosmosDB, Google FireStore, 阿里云 Lindom Serverless

• 資深大佬 : XiaoxiaoPu

  @XiaoxiaoPu 对象存储还真能放数据库，Snowflake 的数据仓库就是构建在对象存储之上。

  不分区不格式化、不能挂载多写一样用啊，数据库直接使用裸的块设备就是了

• 資深大佬 : vivisidea

  有些应用存储不适合走网络，非得 cephfs 来部署 mysql 不蛋疼么，随机读写性能得多差
  本地磁盘还好一点

  rancher 有个 local-path provisioner 可以简化 pv 管理 https://github.com/rancher/local-path-provisioner

• 資深大佬 : vivisidea

  @CallMeReznov 这个例子眼熟，就是官方的教程 https://kubernetes.io/zh/docs/tasks/run-application/run-replicated-stateful-application/

• 資深大佬 : zhujq

  @zhoudaiyu 有状态应用还是用 operator 来做好，这上面有很多 database operator，可以看一下

• 資深大佬 : zhujq

  @zhoudaiyu
  https://operatorhub.io/?category=Database

• 資深大佬 : ch2

  @XiaoxiaoPu 性能差很多

• 資深大佬 : XiaoxiaoPu

  @ch2 性能并不差 fivetran.com/blog/warehouse-benchmark

• 資深大佬 : twl007

  需要 operator 来辅助 纯靠 k8s 自己还是蛮有挑战性的

• 資深大佬 : thet

  @zhujq +1 k8s 部署服务最好是用 operator 来做，好管理，我就是在做 operator 这块的

• 資深大佬 : zhujq

  @thet

• 資深大佬 : ldimple

  @forbxy 我正想上来提问这个问题呢，就看到您说不合适了，那 redis 部署 k8s 有什么好处吗

• 資深大佬 : ldimple

  @thet 那 k8s 部署 redis 集群有必要吗，或者说有什么好处呢

• 資深大佬 : thet

  @ldimple #31 好处还是很多的，比如
  1. 部署方便很多，一个 cr 就可以了
  2. 扩展方便

  可以参考的 redis operator

  https://github.com/spotahome/redis-operator

  https://github.com/ucloud/redis-cluster-operator

• 資深大佬 : ldimple

  @thet 您平时做 operator 开发这块的话目的是为了方便 K8s 部署吗，刚开始入门 k8s，不太清楚开发 operator 是为了啥

• 資深大佬 : thet

  @ldimple #33 是的，operator 是用来管理应用的整个生命周期的。你如果想在 k8s 部署 redis 是完全可以的，毕竟 redis 是内存型的。简单部署甚至用个 pod 就可以了，如果是管理大量实例，operator 还是比较方便的。

• 資深大佬 : ldimple

  @thet 谢谢您的回复，我搞着玩的，并不是真的生产应用