搭 k8s 的时候跟一遍 Kubernetes the hard way ，别用 kubeadmin ，剩下的不理解的地方找着文档查漏补缺。
自然就知道怎么用了，不明白的也知道去哪查

良好设计+熟悉架构+清晰的底层逻辑理解
外加无它唯手熟尔

多锻炼自己不依赖调试器定位问题的能力，当你能把 bug 锁定在某个模块内部的时候，一般目视检查就可以发现问题。

对于技术线上的人，不写代码不 CR 代码的就让他滚

@chunkingName
你的需求本质是网段划分，结果你做成了两层 NAT ，还叠上 Port Forawrding 的 buff ，所以导致丢失了外部原始 IP 。

弄清楚自己的需求，别去乱开一些自己不了解的东西。

如果你非要保持两级 NAT ，那么确保你自己只开 IP masquerade ，同时停用 Port forwarding ，改用 DSTNAT

#10 说的方向应该是没错的，直播是组播，你需要在网关和交换机上都确认好 IGMP 的状态，保证组播可以正常使用

路走窄了，你这个要求最简单的方式是内网设备添加 123.1 的白名单

而且你用 123.1 做拨号，所以 NAT 是必须的，然后你下挂路由又做一层 nat… 属于没救的那种，把二级路由拆了用交换机吧

30M 换算速率 3.75M/s ，24 小时满速上传总数据量为 316GiB

大厂应届硬要求 985/211 ，双非的校招除非很优秀否则会被 HR challenge ，要老板出面才能保下来。

@xiaocaiji111
你的字里行间并没有让我觉得你是完整的调研过各种语言的优缺点才做出的选择

就拿延迟这一项来说，如果你无法容忍 GC 带来的毛刺，那么选择无 GC 语言才是你的出路。
退一步讲，究竟是什么场景要吃掉大量内存造成 GCspike 你也并没有解释。
2024 年了，连 JVM 都进入 ZGC 一把梭的年代下，居然还有人在纠结 GC tune ？到底是代码写的太屎导致要在 GC 擦屁股还是其他原因我持保留意见。

再拿语言层面来说，go 在 better C 这一点上我认为非常成功，跨平台，交叉编译，不依赖 glibc ，体验都是非常好的。所以，你更多的是让我觉得：你是在试图弄清楚一把黄油刀为什么没有瑞士军刀那么多功能和易用。
所以，问题又回到选型上来。

现实问题没有既要又要，如果没有，最好的办法就是你去把它写出来。哦原来你说：“别跟我说自己写一个，你去写“

那我觉得没什么好说的了。

我看到你说的：go 没有提供 gc 调整手段就已经不想看了…
ballast 在 1.19 成为 MemoryLimit 特性都不知道吗，五年就这水平？

@huazhaozhe
> 这个不能科学上网吧，需要每个虚拟机配置一遍貌似
可以啊，那不是取决于你配置么。。

而且你现在这个配置，你旁路由在独立网段无法互访，原因不就是旁路由缺少对应路由表吗。
旁路由加一条路由表把你内网区域指明不就行了。

另外，你说了一大堆都没在点子上，所有重要的东西你都没讲，下次建议直接上拓扑图。

7100 5100 005 要找这种矿老板认证的
早期型号都有 0e 问题

pve 用桥接网络默认可以 dhcp lan ，然后和一楼说的一样，这就是你局域网里的一个独立 ip ，局域网本来就可以直接访问，剩下的东西都是你网络设置，和 pve 一毛钱关系都没有

先尝试 xfs 有没有救吧。btrfs 那真的是灾难

性能严重过剩，而且纯粹旁路并不好用

家庭可以在网关可以直接劫持 UDP DNS ，管你 v6 还是 v4 ，不过现在国内 ipv6 更多是减速不是加速，所以我是直接网关 ban 了 ipv6 。。

核显本质也是 pcie 设备，理论上你可以从内核屏蔽掉。搜一下如何屏蔽指定 pcie 设备吧

你设备太烂