小舅子以后可以自豪地卖前端炒饭了。

raw socket
DPDK

或者弄个独立的网络命名空间/虚拟机

不错

杂牌的 atx 机箱不打多就 200 以内吗？你都不嫌弃二手，不应该很好买吗。

这中国龙爪子不对啊

只在 main 函数里用 panic ，业务里不用。defer + recover 一般在协程里以防万一。

nsenter

或者把容器的网络命名空间 mount 到 /run/netns/NAME 下，然后
ip netns exec NAME cmd....

优先级不一样，没指定的时候，优先 yaml 扩展名，docker-compose v2 版本的优先用 compose.yaml 然后找 compose.yml ，找不到再继续找 docker-compose.yaml, docker-compose.yml

@dcoder #37 只能说你很幸运，不像我们有那么多翔要忍。大家的业务都不一样。不是什么都能 proxy 的。你本地发 MTU 9000 的巨型帧到测试环境试试。

@dcoder #15 远程开发当然是为了保证开发环境和运行环境尽量一致。你也不想，一次开发处处调试吧。另外，在本地把各种依赖都搭好或，mock 掉，不如直接用测试环境的现成资源。

Pod IP 互相访问，集群外的客户端通过 Pod IP 访问，都可以在上一级的网关上配静态路由规则来实现。service 的 Cluster IP 也是同理（ Service-CIDR 要不重叠）。都在内网的，没有 IP 冲突的情况的话，不需要 wiregurad 。

要 DNS 服务也能打通的话，那么最好两个集群的 cluster name 不一样，然后两边都根据 cluster name 来 forward 到对方

实在受不了，忍了几个月，最后全关了

@ahhtree #9
要不你一个人加班，吭哧吭哧全改了，让他们能用你这套替换掉原来的。要不你还是赶紧跑，换个你看得上的公司。

有硬盘多的话，拆个硬盘下来，做成引导盘，装到要重装的电脑上

你的解决方案不太适合只有两个开发的公司，感觉你在面向简历编程。别人是因为数据库不好扩容才节省数据库计算资源放到应用层来计算。你这样一弄架构复杂了，维护成本直线上升了。

service 数量，每个 service 都有自己对应的 Chain ，匹配进入对应 SVC chain 的规则都在同一个大的 Chain 下，这个东西是线性的。pod 数量多只会影响到对应 SVC chain 里面的处理能力，对其他 SVC 没影响

"For the first time, TrueNAS, the most widely deployed Open Source Software-Defined Storage, is now officially available on both FreeBSD (TrueNAS CORE & TrueNAS Enterprise) and Linux with TrueNAS SCALE. TrueNAS SCALE 22.02.0 (Angelfish) is now released on “Twosday”, 2/22/22. "

只有 TrueNAS SCALE 是 Linux 吧， 另外两个版本是 FreeBSD 的。

你这是要自建 CDN 还是自建图床啊？ CDN 的话 OpenResty 加点模块，一致性哈希确定文件归哪台服务器管，让对应服务器自己去下载到本地缓存就好了。

CPU 型号也一致？之前试过编译 dpdk 程序，默认按编译机器的指令集来构建。

除非钱够，不然优先好融资和靠近主要客户的地方吧