mh494078416

我还在同城的两个家里部署了机器，算是同城双机房，加两台同城云 vm 。通过 wireguard 组网，搭建成 k3s 集群。由 vm 里 traefik 作为流量网关，传递到 k3s 内部服务，东西向流量走 wireguard 内网通信了。
数据库、ingress 都做了主备，可以应对一个家里的断电断网，一个 vm 的故障。

2 天前

回复了 zhefanpao 创建的主题 › 生活 › 最后悔的两件事，结婚和生娃

一味忍让换不来和平

13 天前

回复了 zouzou0208 创建的主题 › 程序员 › 不知道有同样喜欢跑步的程序员么, 我写了个项目让你可以打造自己的跑步主页

niubi ，空了研究下

19 天前

回复了 go1796996750asdf 创建的主题 › 分享创造 › 肝了一个月-AI 图像视频生成网站-欢迎免费试用

牛逼
NDk0MDc4NDE2QHFxLmNvbQ==

64 天前

回复了 jqknono 创建的主题 › 阅读 › 微信读书自动打卡刷时长

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

326 天前

回复了 8eacekeep 创建的主题 › Blogger › 想看看大家的博客

https://phantomma.xyz/

332 天前

回复了 cmonkey 创建的主题 › 以太坊 › STARK 都领了吗？

Unfortunately....

348 天前

回复了 seekseat 创建的主题 › Kubernetes › 数据库等服务，到底要不要容器化？体验下来，各自真正的优劣是什么？

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

» mh494078416 创建的更多回复