2025-12-29 16:25:00
居家办公三周后莫名其妙的得了痔疮，前几天都只能躺着了。查了下资料说现代人可能是因为长时间坐马桶导致的，可是我并没有。稍微好一些之后发现只要坐平时办工坐的椅子就会疼，仔细观察发现这个椅子由于长时间胶皮老化中间凹下去了，所以做起来就类似一个马桶两边高中间低，换成个平板椅子就好多了。
对着上周看的 Performance Hints 里的一条unnecessarily-nested-maps，拿着锤子找钉子，去 Prometheus 里看看有没有什么蹭 PR 的机会。最终发现这个优化方法还是有很多细节要考虑的，并不是完全没有副作用，尤其在 Prometheus 的场景里有时候完全不适用还会导致性能严重下降，之后可能会单写一个博客来说明。不过好在 Prometheus 里还有一处是完美适合这个优化的，提交了一个 PR perf(promql): update matchedSigs to a flat map reduce memory by 97% for GROUP_LEFT，能优化一个常见场景 13% 的 CPU 和 97% 的内存分配。
看了How uv got so fast，和第一直觉认为的 Rust 比 Python 快，所以 uv 才能这么快不同，uv 的快主要还是来自实现架构层面的选择。一方面是 Python 的包管理出了更高效的标准，另一方面 uv 选择放弃了大量的历史兼容性，专注于标准路径的优化。此外还有很多语言无关的优化，比如并行下载，硬链接等等其实是其他语言的依赖管理都有的功能，只是 pip 的历史包袱太大了，一直都没有这方面的优化。
在逛 Prometheus Issues 是发现一个 WIP: tsdb: persist series metadata to Parquet files 需要找时间看一下 Parquet 是个什么存储。
周末和孩子去了城市农场，一开始以为是个什么网红景点，去了后发现是个正经的科研机构，中国奶牛的育种就是从这里开始的。里面都是些看上去六七十年代的老房子，有科研人员专门负责讲解，体验还是很不错的。另一方面想到自己小时候没有盒装奶还都是牧场每天早上和报纸一块送的鲜牛奶要拿回家去煮。
里面有从刚出生到三四岁的奶牛，可以自己去喂，小孩抱着草料来回跑喂了快一个小时。
2025-12-22 04:43:00
最近社区的 PR 越来越多，由于 AI 的增强，每个 PR 膨胀的也很厉害，Review 的难度也越来越大。一直以来我对 PR 的合并手都比较松，现在合并一个新功能不强制有 proposal，不强制有测试，文档有时候甚至都是我后来再写的。如果从教条的开源社区规范来看，这个项目的治理，社区，文档都是乱哄哄的。代码债也到处都是，我最近初步梳理了几个文件就费了好大的劲。如果不是借助 AI 好多重构的活会更难。
不过从我的价值倾向来看，相比规范性，我更注重的还是一个项目是不是真的有用。尽管不规范会带来长期的隐患，但是保持这个项目一直有用就有机会等到后人有智慧来解决。
最近在反思之前用 AI 的一些方法，在习惯了自己不动手一把梭后，感觉自己阅读代码和复杂内容的耐心也下降了。或许以后确实 AI 可以做所有脑力劳动了，那么脑力劳动可能就变成现在的健身房了，未来人类需要和现在刻意锻炼肌肉一样才能保证脑力不流失。
happy 一个能在手机上控制开发机上 codex 和 claude code 的工具，这样不在电脑前也能抽 AI 干活了。
10kg 哑铃片到货，视觉上还是有些吓人。
全程的引体向上还是做不了，不过肩胛骨旋转的感觉找到一些了，离心可以做全程了。
连续三周上重量后，这周五的时候明显感觉硬拉拉不动了，下周打算做个减载周。
OpenShift Roadmap OpenShift 更新了未来一年的 RoadMap，公司里如果还有上了年纪的人可能会关心。
A new hash table 是 Valkey 的一个 hash table 实现变种，主要目的是为了节省内存体积和内存访问次数。这种把数组和链表组合的思路能够兼顾顺序访问的效率和链表无限扩容还是挺有意思。不过后来又看了下其他的 hash table 实现，发现这好像就是 Golang 在使用 Swiss Table 之前的实现。
kubevirtbmc 一个对接 KubeVirt 和传统物理机 BMC 协议的工具，能把 IPMI 和 Redfish API 的调用转换成 KubeVirt 的 API。这样用就能复用之前管理物理机的工具和流程来管理 KubeVirt 的虚拟机了。
Performance Hints Jeff Dean 和另一个 Google 初创时的工程师 Sanjay Ghemawat 写的性能优化手册。和大部分性能优化都是先 profile 找到热点再优化不同，这个手册介绍的主要是火焰图上看不到热点的时候如何怎么榨取性能。 因此里面介绍的全都是微操，针对 common case 做 fast path 已经算是最大块的优化方法了。里面有不少在 search 和 tensorflow 上做微操的例子，看上去还是很过瘾的。
海底捞的海螺片和鞭炮笋很好吃，推荐尝试，新出的猪肉卷就不要试了。另一个感叹是海底捞现在已经变成了个家庭聚餐的地方，满屋子都是过生日的，而在几年前我一直以为这是个工作或者同学聚餐的地方。
中午逛公园走了条平时没走的小路，上了段城墙，然后发现了传说中的“蓟门烟树”，我一直以为是什么古树，原来是个石碑，看介绍是乾隆题的字。
去了平西府地铁站新开的小站公园，公园用的一个人物形象名字是“下腰女孩（Tireless Girl）”。虽然我能勉强搞明白下腰和 Tireless 的关系，但这个翻译实在是太奇怪了。
2025-12-15 15:46:00
这是第二周远程办公，专注度相比上一周出现了很大起伏。上一周基本上能从早上起来一直拉满到晚上，这周注意力有所下降。
想了一下上周社区的问题比较多，基本是问题驱动的，自己不需要去考虑要做什么。这周问题少了空下来很多时候就没想法了。还是需要开启 Plan 模式，多做一些规划，给自己分配一些明确的任务。
这周花了些时间把卓叔增重和凯圣王Kaizen_Wang 的动作视频看了一遍。随着力量增加，一些之前看不懂的动作细节和找不到的发力感，现在渐渐能体会到了。再仔细看一遍争取每次动作都有进步。
这周做深蹲和硬拉已经能把单只 18kg 的哑铃片加满了，然后发现个问题就是这个重量做深蹲已经不太能靠手臂的力量把哑铃撑到肩上了，危险系数陡增。深蹲还能考虑换单腿，硬拉还是要加重量了。趁着双十二 pdd 了四个 10kg 哑铃片，估计能再撑几个月了。
我一直有个想法是把看到的所有东西都记录下来，然后借助 AI 的能力能不断检索一个人，甚至重建一个人。之前我的想法是感觉这个事情只能放在眼睛上来做，但是最近想法有变化，发现其实只要在我们日常接触的主要屏幕，比如电脑和手机上做记录也可以达到接近的效果。于是开始仔细的去看几个开源项目：DayFlow, ScreenPipe 和 OpenRecall。
这个过程中发现了很多我之前的知识盲区。一个是这里面有的项目是通过截图去记录屏幕信息，但是会通过视频的形式进行存储，原因是视频的压缩率会更高一些。我尝试了一下 5s 的频率截取了 120 张图片，用 zip 普通压缩一下还是有将近 400M，而用 FFmpeg 转成 1FPS 的视频后只需要 3.4M。
第二个是我才注意到 Gemini 是有视频模态的，这应该是目前主流 AI 厂商里少有的具有视频理解能力的。
这周内部同事分享了 ZCF 的六阶段工作流，我比较感兴趣它的实现方式。一般用 coding agent 使用 agent.md 其实不太好控制工作流，因为有的时候是写功能，有的时候是排查故障，有的时候是重构，不同的目标使用的工作流其实是不一样的。而 agent.md 里即使根据各种情况写了工作流，也还需要 AI 工具能自动分析出是哪种情况，并且多轮对话的时候很容易出现不一致的情况。ZCF 是通过 command 来实现，需要用户显式去说明用哪个工作流，感觉上不是太智能，但其实实际中用起来一致性应该会更好。
这周还发现 OVS+OVN Con 2025 的视频和 Slide 已经上传了，下周找时间过一下。粗看一个感兴趣的议题 Deprecating Code 看样子 OVS 要移除对 Windows 的支持了，原因是没人知道该怎么维护，甚至没人知道是不是还能正常工作，当然从我们团队同事之前的经验看在最新的 Windows 上已经不太正常了，这样我也可以顺带着清理一波代码了。
这周看了《疯狂动物城 2》，还是标准的迪士尼套路，没有啥太多的惊喜。和年初的《哪吒之魔童闹海》比，还是能看出明显的文化区别。动物城目标群体是全球用户，所以选了没啥文化背景理解需求的动物做主角，而哪吒明显是个中国文化故事，甚至能看到对《哪吒闹海》和《十万个冷笑话》的致敬。动物城是个中规中矩的工业品，而哪吒是有着很鲜明作者特色和作者表达的作品。我对动物城票房数字唯一的理解就是这一年除了哪吒就再也没有一个水平线上的电影作品了。
最近迷上了看《潜伏》的解读，主要看了 B 站 Up 弥先生碎碎念的《细讲潜伏》系列。之前只是觉得台词好，演技好，解读后才发现编剧是多么的厉害，历史背景有多么复杂。
2025-11-30 17:45:00
NetworkPolicy 作为 Kubernetes 早期的 API 看似美好，实际使用过程中就会发现它功能有限，不易扩展，不易理解且不易使用。因此 Kubernetes 成立了 Network Policy API Working Group 来制订下一代的 API 规范，而 ClusterNetworkPolicy 就是目前探讨出来的最新成果，未来可能会成为新的规范。
NetworkPolicy 是 Namespace 级资源，本质上是“应用视角”的策略。它通过 podSelector、namespaceSelector 来选中一批 Pod，然后对这些 Pod 的 Ingress、Egress 做限制。这带来了几个实际的问题：
由于策略的作用域是 Namespace，集群管理员无法定义集群级别的默认网络策略，只能在每个 Namespace 里都创建相同的网络策略。这样一方面每次更新策略需要对所有 Namespace 下的资源进行更新，另一方面，很容易和开发者创建的网络策略产生冲突。管理员设置的策略，应用侧很容易就可以通过新的策略绕过去。
本质上在于 NetworkPolicy 这种应用视角的策略和管理员集群视角的策略存在冲突，当用户的安全模型并不是应用视角的时候 NetworkPolicy 就会变得难以应用。而集群管理员管控集群整体的安全策略是个现实中很常见的场景。
NetworkPolicy 的语义有几个“坑”，新手和运维人员都容易踩：
隐式隔离。
一旦有任何 NetworkPolicy 选中了某个 Pod，那么“未被允许”的流量就会被默认拒绝。这种隐式的行为需要靠心算来推导，很难一眼看懂。
只有允许，没有显式拒绝。
标准 NetworkPolicy 只能写 allow 类型的规则，想要“拒绝某个来源”，通常要通过补充其他 allow 规则间接实现，或者依赖某些 CNI 厂商特有的扩展。
没有优先级。
多个 NetworkPolicy 选择同一批 Pod 时，规则是加法而不是覆盖关系。最终行为往往需要把所有策略合在一起看，排查问题时非常困难。
这些特点叠加在一起，就会导致 NetworkPolicy 理解起来困难，调试起来更困难。
为了解决 NetworkPolicy 固有的问题，Network Policy API 工作组提出了一个新的 API —— ClusterNetworkPolicy (CNP)，它的目标是在不破坏现有 NetworkPolicy 用法的前提下，给集群管理员提供一个更清晰、更强大的网络控制能力。
其最核心的思路是引入策略分层，在现有的 NetworkPolicy 之前和之后分别引入独立的策略层，将集群管理员的策略和应用的策略分开，提供了更丰富的视角和更灵活的使用。
一个示例如下：
1 |
apiVersion: policy.networking.k8s.io/v1alpha2 |
新引入的 ClusterNetworkPolicy 是集群级别资源，管理员可以直接选中多个 Namespace 下的 Pod 进行策略控制。同时 Admin Tier 的策略可以先于 NetworkPolicy 生效，这样集群管理员只需要少量的 Admin Tier 策略就可以控制住整个集群的红线行为。
而 Baseline Tier 的策略在所有 NetworkPolicy 都不匹配后执行，相当于提供了一个兜底策略。
简单来说：
tier: Admin 的策略用来定义绝对不能做的事情。tier: Baseline 的策略用来定义默认不建议做的事情，用户可以通过 NetworkPolicy 来放行。ClusterNetworkPolicy 中新增了 priority 字段，这样在同一个 Tier 中多个规则的范围出现重叠时，可以通过优先级清晰的界定哪个规则该生效，不会再出现 NetworkPolicy 里那种隐式覆盖，需要互相猜测的情况。
和 NetworkPolicy 只有“允许”语义不同，ClusterNetworkPolicy 的每条规则都有一个显式的 action 字段，可以取值：
Accept：允许这条规则选中的流量，并停止后续策略评估Deny：拒绝这条规则选中的流量，并停止后续策略评估Pass：在当前 tier 里跳过后续 ClusterNetworkPolicy，交给下一层继续评估同时，文档中特别强调：
结合优先级的配置，规则的理解就不再会产生模糊的情况，理解上也变得不那么困难。
ClusterNetworkPolicy 一定程度上回归了传统的分层网络策略的架构，在解决了 NetworkPolicy 问题的情况下没有带来破坏性的变化，可以说是一个很不错的设计，希望能尽快看到这个规范的成熟和落地。
2025-11-09 12:29:02
目前社区在 Kubernetes 实现网络多租户主流选型是 Kube-OVN 和 ovn-kubernetes，这两个方案本质上都是在物理网络上通过 OVS 和 OVN 的能力构建了一层 Overlay 虚拟网络。这种方案不太关心底层物理网络架构，有着比较好的兼容性，但是双层网络架构也加大了整体架构的复杂度。
最近我在调研 EVPN 这种物理网络多租户的方案，发现了 OpenPERouter 这个开源项目，他把 EVPN 的理念引入了容器网络，提供了一种新的在 Kubernetes 上实现多租户的方案。该方案不仅能统一软硬件网络架构，还在一定程度上能兼容现有 Calico 这种通过 BGP 方式发布路由的 CNI，我甚至已经看到通过少量工作就可以让 Calico 具备多租户能力的前景。虽然这个项目还在早期，但我认为这是一个相当不错的方向，未来很可能会成为构建大规模数据中心的一个有竞争力选型。
OVN 类方案的主要局限性有两个一个是集中式控制平面的规模限制，另一个就是网络复杂度。
尽管 Kube-OVN 在社区已经存在了上千节点的大规模案例，但是由于 OVN 这种集中式控制面的架构，会导致控制面存在比较大的压力，成为整个集群的瓶颈。特别是在控制面节点断电或者故障时，可能会需要较长时间网络控制面才能恢复。
这个问题主要是由 OVN 集中式控制平面的架构带来的，无法完全规避。ovn-kubernetes 中采用了每个节点一个 OVN 控制平面，多节点之间通过 OVN-IC 互联的方案来规避这个瓶颈。但是这个方案同时也会导致架构的复杂，并且相当于主动弃用了 OVN 本身的集群网络能力，使得大量的 OVN 能力无法使用。
另一个问题就在于 OVS/OVN 这套体系本身的复杂度，使用者需要重新再构建一套 OVN 规范下的网络拓扑，流表的知识体系才能保证自己面对实际问题时不会手足无措。而这套体系和底层的物理网络往往又是不同的，实际中相当于存在两套网络体系，这不仅会使问题排查变得更复杂，还会导致需要物理网络团队和容器网络团队两套人马，双方往往都无法理解彼此的工作内容，无法有效协同。
以上两个局限性更多的是选型上的取舍，如果希望能够软件集中控制，希望容器网络能不关心底层物理网络，那这样的选择必然就会带来这样的局限性。
在和 OVS 这种纯软件方案平行的另一个硬件世界，有另一套硬件版本的多租户网络方案，那就是 EVPN。
在 EVPN 的世界里，在数据平面交换机之间通过 Vxlan 对数据包做封装，通过在 Vxlan 的 Header 中设置 VNI 来区分不同租户的流量，实现了流量的隔离。
同时，交换机之间通过 BGP 在控制平面来同步 L2/L3 的路由以及 VNI 的信息，能够快速的学习整个网络拓扑中的地址，路由和租户信息。
通过这种方式，大型数据中心可以自动化分布式的实现多租户网络。这套方案在很多大型数据中心都已经落地了，主流的交换机目前也都已经支持。那么在容器领域有没有基于这种技术架构做网络的呢？这就是我最近发现的 OpenPERouter 了。
OpenPERouter 的核心理念是将 EVPN 交换机的逻辑下沉到节点，在每台机器上运行一个 FRR 通过直接和物理交换机建立 BGP 和 VXLAN 隧道，将容器网络直接打通到已有的 EVPN 架构的物理网络。
现有的容器网络想接入 OpenPERouter 也并不算复杂，基于 BGP 的 CNI 需要和 OpenPERouter 建立 BGP Peer；对于基于 veth 和网桥的 CNI，需要把原来在宿主机一侧的 veth 改为接入到 OpenPERouter 所在的 net ns 即可。
这个方案带来了一些独特的优点：
当然这个方案当前也有它的局限性：
在我看来，EVPN 会是未来容器网络里的一个极其有竞争力的技术方案，但是当下并没有很成熟的开源项目，OpenPERouter 做了很好的尝试，我也很希望看到未来有一款专门为 EVPN 架构设计的 CNI 能够大幅简化全局的网络设计。
2025-08-15 22:48:00
MetalLB 目前几乎成了私有云场景下 Kubernetes 提供 LoadBalancer 类型 Service 的事实标准。他的实现逻辑简单清晰，并且功能单一，基于 Gossip 的分布式选主也保证了 VIP 的漂移可以做到迅速且不依赖 Kubernetes 的状态。但是它在专注的情况下也缺少了一些在生产环境极为重要的功能，这也是为什么我最近在调研其他的开源项目，并发现了 LoxiLB 这个很不错的 MetalLB 替代项目。
MetalLB 虽有 LB 之名，但实际上并不处理任何转发平面的工作。严格来说它只提供了 VIP 的对外通告能力，所有转发平面的事情都是依赖 kube-proxy 或者各类的 kube-proxy 的替代 来实现。这样的好处是它可以专注在提供各种类型的 VIP 宣告方式，并且能和 Kubernetes 本身的行为保持最大的兼容性，但同时由于 kube-proxy 本身孱弱的能力，也限制了 MetalLB 本身的功能。
这是 Kubernetes 由来已久的一个问题，Service 后端的 Endpoint 健康状态依赖 Pod 本身的 ReadinessProbe/LivenessProbe，Probe 的执行依赖当前节点的 kubelet。造成的结果就是断电或类似的直接宕机情况下 kubelet 无法更新 Pod 的健康状态，需要等到触发 node not ready 的超时才会修改 Pod 监控状态，通常在大集群这个超时可能会有数分钟，导致这段时间内访问 Service 会出现失败。
严格来说这并不是 MetalLB 的问题，但是由于 MetalLB 本身对数据转发平面没有任何控制能力，无法主动探测 Pod 真实健康情况也无法修改 Pod 健康状态，只能被动接受这种机制。
虽然通过 Pod ReadinessGates 可以使用额外的 controller 主动探测来控制 Pod 健康状态，间接解决这个问题，但对于 MetalLB 来说这个也和它没有什么关系，并没有能开箱即用的方案，这对生产环境还是个很大的隐患。
这同样是依赖 kube-proxy 实现导致的一个问题，kube-proxy 的多种实现方式都没有流量层面的监控，导致的后果就是如果你看 MetalLB 提供的监控指标就会发现里面没有任何流量的指标。这种几乎没有任何数据平面监控的 LB 要上生产，就有点过于松弛了。
LoxiLB 本身是一个为电信场景的特殊需求，使用 eBPF 打造的专用 LB，它完全实现了控制平面和数据平面是一个完整的 LB 实现。LoxiLB 本身的功能十分多，尤其在 SCTP 领域有十分多专属能力，这里不赘述只是重点看一下针对 MetalLB 缺陷的补足。
LoxiLB 可以给每个 Service 配置主动健康检查，支持 ping, tcp, udp, sctp, http, https 也支持超时，重试之类的细粒度配置，虽然称不上多优秀，但 MetalLB 就是没有这个功能，这就显得很尴尬。
这一点就是 eBPF 的强项了，LoxiLB 内置了不少 Metrics 和 Grafana 面板，此外由于数据平面是自己实现的，添加各类监控指标也相对容易一些。
整体来看 LoxiLB 是一个我很喜欢的项目，甚至很多关于 SCTP 协议的理解我都是看了它的一些配置才能理解是怎么回事。但是他还是有着一些不足的地方：
MetalLB 依然是一个我很喜欢的项目，它极其精准地解决了 VIP 宣告及高可用的问题，但是如果达到生产上完备的状态还需要配合其他组件。LoxiLB 则是一套完整的 LB 解决方案，但是社区的发展还处于早期，还有待更多人的参与。
