ryan4yin

cilium 需要规模够大才能体现出优势吧，否则用 flannel/calico 也挺 OK 的

个人 homelab 用的 fluxcd, 所有配置都公开的

https://github.com/ryan4yin/k8s-gitops/

赞！

#5 你 limits 跟 requests 都没配，这怎么让 k8s 调度，k8s 管理资源的核心逻辑是 HPA VPA 动态扩缩容，不是把旧的 Pod 删掉，在大机器上给你跑个新的。
建议找个 k8s 教程先学一学吧。

@cnt2ex 哇这个好啊，我可以直接把这个配置抄到我的 nixpak 配置里，这样体验是一致的，而且也能声明式。

#4

「前端加密是形式主义安全的要求，前端加密完全阻止不了被劫持或者被恶意浏览器插件直接注入 js 读取输入框里的明文密码。」

没有什么技术能解决所有问题啊，你不能因为一项技术没解决掉个别问题，就认为它完全是形式主义。
类似深信服之类的技术在你电脑里装它的证书从而监控你所有 HTTPS 流量的明文内容，而前端加密至少能保证你的明文密码不会泄漏给公司。
上面也有 v2 友提了，明文密码泄漏要比 Hash 泄漏严重得多，用户其他站点也可能因为你们前端没做 Hash ，被黑客一举攻破。

另外一点是，HTTPS 并不总是安全的，不要总觉得用了 HTTPS 就多安全，TLS 从 SSL1.0 迭代到现在 TLS1.3 ，一堆的弱密码，实际安全性还是得看客户端与服务端的两边的具体配置。

对 OP 引用的前一个帖子一些观点的反驳：

1. https + 后端加密入库足够安全：这得看具体的流量链路架构，单纯从你前后端看可能感觉都很安全，但中间是否过了 CDN 加速？是否做了 TLS 的边缘端及早截止（ https://0xffff.one/d/968 ）？即使你做这个决定时系统是够安全的，但 infra 团队不一定知道啊，他们对中间这些链路做的任何变更都可能会破坏你的安全假设。所以为了避免沟通成本，强制前端做 Hash 是很合理的选择。
2. 增加开发成本，没必要：前端对密码做个 Hash 就几行代码的事，调用个现成的库就行，这个东西很复杂吗？？？要增加多少开发成本？？？
3. 加密后导致密码强度的下降(因为密文的信息熵下降了)：所有 ASCII 字符数字符号加一起是 94 个，简单计算你的密码需要至少 40 个字符，它的排列数量才能超过 2^256 钟，我还从来没见过谁的密码有这么复杂...


如果你是在什么无所谓安全的小公司工作，公司也没啥要求，那你确实怎么折腾都无所谓，不用管什么哪里加密，想怎么写就怎么写，功能实现了就 OK. 但我个人还是建议养成一点技术上的品味。

本质上仍旧是成本跟安全的平衡，客户端弄个 Hash 就加几行代码的事，就能提升整条链路的安全性，何乐而不为呢？我不明白这事有什么可争的。

@amber0317 flatpak 主要是不够声明式，不过装个 QQ 确实 OK ，我最近在整的 nixpak 也是用了 flatpak 的 bubblewrap ，更可控些，缺点就是配置起来很麻烦。

我再折腾下吧，如果不好搞就换成 flatpak