其实还挺有用的，右边是多媒体控制一类的，播放、暂停、上一曲、下一曲、音量、确认、返回等，主要就是听音乐、接电话用的多一些。左边是自适应巡航相关的，买车 2 年，没上过高速没用过。上高速前学了一下，还是挺好用的。不同车可能不一样，不过应该大差不差。

买车前千挑万选，价格、功能、用料、做工一通对比。买车后，啥都不是，能跑就行。

分两种情况：
第一种，心疼水费的。不要心疼，任何一种优化措施都比直接放掉更费钱。实在觉得浪费资源就拿盆接着冲厕所用。
第二种，不是心疼水费，就是想优化用户体验。要加钱，有效果，但很难说完美。

优化方案上面回答的有，基本也分两种：
第一种，全屋零冷水。基本逻辑就是不停循环，保证热水管一直有热水。优势是可以做到全屋各个用水点零冷水，劣势是这套系统要钱，已经装修完改造要钱，不停加热浪费能源也要钱。
第二种，小厨宝。基本逻辑就是在水龙头附近放一个热得快和储水箱。优势是设备成本、改造成本比较低，劣势是零冷水是单点的，不是全屋都有的。功率比较大，有安全隐患。

电热水龙头没研究过，净水有即热水龙头。不过自来水的流量比净水大多了，即热应该很难有效果。

一般来说，不是住别墅的，还是直接放水实在。

“等额本息(20 年)每月还款额比等额本金(30 年)首月还款额还低,而且利息更是低了 25%.”

你是说你发现了租房子，租 2 个月比租 3 个月总价更低吗？不管你贷了 200 万还是 300 万，把你的房贷当做一个物品，利息当做租金。你租一个物品 20 年和 30 年的租金能一样吗？

金融搞复杂一点还是有用的，绕来绕去简单的常识都能把一部分人绕进去。

到目前的讨论似乎有点混乱，需要准确定义一下“容器部署”，是 kind 这种整个集群在容器中的情况还是 kubeadm 集群组件使用 static pod 的情况。
kubeadm 是官方支持的部署方案，稳定性肯定没问题的。二进制部署有点过于 old school 的感觉，我个人没有用过，不认为能提供额外的稳定性，并且维护复杂。

另外，虚拟机上使用 kubeadm 标准部署，并没有特别的套娃。公有云应该是类似的结构，甚至托管的控制平面都是虚拟的。kind 类似方案有点套娃，但用于开发测试环境没有什么问题。

停车非常影响生活体验，该花钱花钱，算算一年多少钱，就当在游戏里氪金了。

@eephee 使用 kubeadm 部署的标准 k8s 集群，稳定性没有遇到特别大的问题，可能是规模比较小，稳定性要求也不高。使用 local pv 的话最好使用独立的磁盘，避免存储空间不足导致 Pod 调度异常。尽量避免在 k8s 集群上部署维护有状态应用集群，sts 集群在节点故障时处理起来很烦人。

大部分回复基于理想情况，最佳实践来评价这样做的坏处，的确没有错，说的风险也的确都存在。但实际做项目部署往往一言难尽，用户可能规模很小，或者只是初步的试用意向。如果要 k8s 集群 3master3worker ，MySQL 单机 1 台，minio 单机 1 台，Redis 单机 1 台等等，随随便便就小十台服务器是很难和人谈的。用户甚至希望服务器配置高一些，数量少一些都能接受。所以一个很自然的需求就是同一台高配服务器即部署基础组件，又能当做 k8s 工作节点。这个时候用 k8s 统一资源管理，也是一个选择。

几乎一样的场景，给客户部署的就是 MySQL 、mongodb 、redis 、minio 都部署在 k8s 集群中。尽量使用 helm 而不是 operator ，存储使用 local pv ，配合 node selector 强制绑定。
肯定不是最佳实践，但还要看具体场景。小规模客户，没有太多资源，在主应用必须部署到 k8s 的情况下，把其它组件拉到集群部署也是一种选择。本身也不是追求高可用、弹性调度，只是借助 k8s 部署和管理。实际上，客户规模够大，有能力的话，也不会同意这样的方案，直接把基础组件甩给客户基础设施团队是最好的。

还是有一些应用场景的，不过一般情况下更倾向通用的技术，这个场景下 devcontainer 、docker/docker-compose 是很好的解决方案。容器虽然臃肿一些，但隔离度很好，特别适合维护多个项目多种版本的情况。

感谢分享。
可重现似乎还是用 gitops 那一套好一些，不过 docker 生态里没有太好的实践，据说 portainer 有一个 gitops 工作流，还没有用过。k8s 生态的 gitops 实践相对多一些，不过复杂度又高了一些。注重可重现、IaC 的话，homelab 场景 k3s+gitops 感觉是个不错的选择。
容器工具更倾向 nerdctl+containerd ，虽然现阶段 docker 的 UI/UX 还是有一定优势的，但总有一些小地方让你想折腾一下的时候很难受，比如还是不支持第三方 registry 的 mirror ，要用 ghcr 一类的 registry 就不得不在 daemon 上挂代理，或者本地网络有透明网关整体解决网络问题。

- 阿里云免费次数不用担心。免费证书一年期不好找，3 个月的随便一个 acme 客户端都可以签，比如#1 推荐的。
- 一般签发证书不考虑国内国外问题，即常规业务场景一般不用考虑证书的影响。除非有老旧设备证书链兼容、ocsp 优化等场景，可以自行研究。

云厂商免费证书的最大优势是一年期，没有了一年期自己搞 acme 好了，愿意的话还可以在生产环境配置自动签发，完全免运维了。

家用场景不太考虑冗余高可用，多节点不是必须的。单节点跑 k8s 或 k3s 都是可行的，k8s 生态里的东西都能玩。

当然，如果是要练习或折腾着玩，多节点要求也不高，虚拟机、小主机、退役的手机、平板都可以加到集群里折腾。

如果不是特别需要练手裸金属场景，不建议入手多个低性能硬件，更建议入手单个高性能硬件。

一直在 autodl 租 GPU ，容器实例就是在容器里部署 sshd 端口映射到公网，当做一个虚拟机使用。所以你这里容器部署 sshd ，nodeport 批量暴露出来应该是没有问题的。虽然不符合所谓的最佳实践，但业务上的东西一般都是各种情况的 trade-off ，不能强制追求完美。autodl 也算正经商业化的业务，举例是说明这样实现肯定不能说是很差的选择。

不嫌重的话，开发环境按项目配置 devcontainer ，配合 vscode 也能实现挺不错的工作区。

可能高了，建议尽早出。

刚出了一个 iPhone 12 完美成色，前后不到 10 天，官网 trade-in 掉了 200 ，且不说官网最近刀的厉害。爱回收上门比官网低 100 ，不想折腾直接给爱回收了。

二手苹果电子产品价格的坚挺程度差了很多，除了经济形势不好，应该和苹果品牌影响力下降也有关系。

比如部署 kube-vip ，给控制平面高可用提供 VIP

根据有限的人生经验，我把我接触的人对事物认知能力从上到下分为三层：
- 人教人就能教会的。即可以正常的从人类已有的知识获取经验，包括但不限于读书学习、看文档看手册、与人沟通等
- 事教人才能教会的。即必须要自己做一遍才能获取基本认知的。事实上，所有人在实践后都有会有收获，区别在于实践前有的人可通过人教人获取充分的预置经验，有的人则无法获取，只能实践后建立认知。
- 事教人也教不会的。这种很少见，但的确存在。人有趋利避害的本能，也有观察归纳总结的本能。一次教不会，多次总会有进步。但的确有些人完全毫无进步迹象，我个人暂时不太理解这种情况的成因。

回到主题，书读的好一般定义为受过良好教育，形成了人教人的思维模式，能够利用人类已有的经验积累。所以这个感觉应该是对的。

另外，个人认为形成这样分类的重要因素是实践，或者说动手能力。能够主动动手整理这个世界的人都有探索这个世界运行逻辑的动力。

刚想说你可能看了假的天梯。你上面发的 7900x 也没被吊打吧。

非桌面场景，个人不喜欢大小核，另外，AM5 还能战未来。当然全平台 TOC 最重要，DIY 的乐趣之一就是搞性价比。

我这里 PDD 甚至有可以“刷”的趋势，像刷微博刷 X 那样。
其它购物平台打开-搜索-确认-下单-关闭，PDD 有点不一样，一旦打开搜索或买点东西，它总是能给你推荐点奇奇怪怪的小玩意，不管你买不买，总是会让你惊奇一下，还有这种东西，然后就有一种刷一刷的冲动。很多时候小玩意都不贵，很容易就顺手下单了。
很难说这是好事还是坏事，不过的确说明商业上的成功需要对人性的充分挖掘。