mh494078416

微信读书 打卡、刷时长，有啥奖励？

Unfortunately....

有状态服务适不适合进 k8s ，很重要一个选择因素是 k8s 上的远程存储。云上 ebs 具有的几个特性，高性能、三副本、io burst 、attach 、deattach 等。这些特性，依赖硬件投入，如高性能网络 RDMA ，在自建 IDC 情况下不一定具备。
所以，自建 IDC 下的 k8s 和云上是有一些不同的，难度和挑战会更大。
云上，云厂商供应有状态服务的云实例，背后已经转向 k8s 化，这个方向已经发生，争议不大的。
自建 IDC 场景，有更高的难度，不过 TiDB 针对 IDC 场景也给出了解法 TiDB Operator ，依赖本地磁盘 LPV ，而非远程存储。LPV 有易失性，TiKV 内置三副本特性，正好补充这块的不足。类似的还有 Kafka 的多副本机制。但对于其它不具备三副本的基础服务，进 k8s 没那么容易了，必须面临两难选择：本地磁盘 需要自己解决多副本问题；远程磁盘 性能不高，将有很大的性能损耗。靠远程存储自身来解决这个性能问题，看起来非常难跨越。

装个个人相册 immich ，个人网盘 nextcloud ，smb 服务器，webtop 桌面。
我是这么玩的🐶

lens + 1

核心在于，你的部署方案是单机版，还是高可用版本。单机版本，放在 k8s/k3s ，还是放在 vm image ，docker compose ，都只是部署方式的差异，以及虚拟化层数带来的一些性能影响。本质上都是单机的，无法应对单机宕机这种情况。
高可用的方案，核心在于数据层的设计了。在不在 k8s 里不是关键。

体验下来，m 芯片 mac ，k3d + colima 是体验最好的。cpu 、内存占用最低。
k3d 以容器形式包装了 k3s ，colima 是 docker desktop 的替代。比同样 docker desktop 替代者的 orbstack ，内存占用还要低一些。而且，orbstack 现在开始收费了，价格还不低😭。