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 解决方案，但是社区的发展还处于早期，还有待更多人的参与。
2025-07-09 06:48:00
在做 MetalLB 和 Calico 的一些测试时需要验证 BGP 相关的功能，然而每次测试要去联系运维团队配合网络变更是不太现实的，并且大多数情况我们只要验证 BGP 信息正常交换就可以了，不需要真的去改变物理网络。于是就找到了 GoBGP 这个软件路由器进行模拟。
GoBGP 本身有着很复杂的配置，但是如果你只是像我一样只是想有个虚拟的路由器，让客户端把 BGP 信息发送过来，检查路由表信息是否正确更新，那看这篇文章就可以了。
去 Release 制品列表里找到对应系统的制品解压即可，重要的只有两个二进制文件： gobgpd 虚拟路由器进程，gobgp命令行工具，用来查看路由对不对。
创建一个 gobgp.toml 文件，最简单的配置就照着我下面这个就好了，大部分基础的云原生领域 BGP 相关的软件测试用这个就够了。
1 |
[global.config] |
启动 gobgpd
1 |
./gobgpd -f gobgp.toml |
在另一个终端观察当前的路由表
1 |
./gobgp global rib |
这样基本上 MetalLB，Calico 的基础 BGP 能力就可以测试了。如果想更配更复杂的模式，比如 Router Reflector，EVPN 那就再去翻 GoBGP 的文档吧。
2025-07-06 21:00:10
最近打算把 Kube-OVN 的文档整理一遍，同时思考怎样的文档规范能尽可能做到：
我决定先按照下面的结构重构一下文档，来看看效果。
大家有什么其他的建议也可以一块来讨论一下。
2025-06-28 08:02:21
这篇博客是内部分享的一个提示文稿，并没有做仔细整理，大体思路就是捕获所有 Kube-OVN 的依赖：操作系统，Golang，程序依赖，环境组件（k8s,kubevirt 等），然后激进的实时更新所有依赖做到动态清零。
Kube-OVN CVEs 问题修复的流程经历了如下几个阶段：
优势：
增加工作：
优势：
只要依赖更新版本就尝试更新，不考虑是否是安全更新。尝试解决比 CVE 修复更大的一个问题，自动就解决了 CVE 问题的修复。
我们的依赖项：
ubuntu:24.04, apt-get install ....
OVS, OVN
kubernetes, kubevirt,multus, metallb, cilium, talos
要做的事情：
go.mod 里的所有依赖版本优点：
劣势：
2025-05-24 18:40:04
这两天接了个 Kube-OVN 培训的任务，事实上这已经是这几年第三次给这家公司培训相同的内容了，形式也从线上转到线下还要求手把手的敲命令，可想而知之前几次的最终效果怎样。我可以理解需求方的技术焦虑，但我认为培训这种形式是极其低效的，更多的只是培训当时能获得一些虚假的满足感，不会产生什么长期收益。
一方面培训是一种被动学习方式，完全由老师带节奏前进，那听讲的人只是被动的吸收，很难有深度的思考。另一方面需要等到培训才了解的知识大概率是实际上用不到的知识，如果每天都用的话根本来不及等这种一年一次的培训。如果实际用不到，那么哪怕当场掌握了，很快也会什么都剩不下。
我觉得这和我们一直以来的教育理念有些关系，传统上我们认为认真听老师讲课，努力记笔记，不会的问题堵着老师问，都是优秀的学习习惯。但这些都是偏被动的学习方法，我们很多年的教育过程中其实缺乏主动学习的机会。这种被动的方式早期的效果可能会很好，因为早期学校里的知识难度不大，而且我们展示学习成果的方式就是考试，而考试是可以通过过拟合的方式来提升效果的，并不能真正反映你对知识的掌握程度。
在我的经历里，到了初中阶段，最出色的那批人就不再是认真听课，努力记笔记那批人了。而是换成了那批给人感觉平时一直玩，考试成绩还很好的一批人，事实上越往后这批人的比例越高。我认为这里并不是智商的区别而是被动学习和主动学习模式的区别。主动学习的人会更多依赖自己思考来解决问题，而不是依赖老师的讲解，这个方法看似低效其实最终效果会更好。想象一下同样一道题，一个人是老师之前讲过所以考试的时候做出来了，另一个人是上课没听到但是考试的时候临场也做出来了。从考试的结果来说两个人是一样的，但两个人的实际能力是天差地别的。后者实际上拥有更好的学习方法和能力，并且在更难的问题上有更好的泛化能力，自然可以显得游刃有余。就好比前者一直在用冒泡算法去排序，后者则是不断用快排，在小规模上前者可能更简单更不容易出错，效果会比后者好，但是后者一旦调整好了，在更大规模的数据上会有指数级别的优势。
这也是为什么有些转行的程序员的表现会比科班的表现好。一方面他们采用的是主动学习这种高速方法，另一方面科班的被动学习学到的大量都是实际中毫无用处的知识，两者的基础差距本身就没那么大，用一个更高速的方法很容易短期就实现超越。
所以还是要主动学习，学点有用的。（不要再折腾供应商搞什么高级培训了
2025-04-23 18:40:43
OpenShift 作为容器平台的标杆产品，同时也是开源商业化的标杆，一直是被人试图追赶或者超越的对象。但是如果只是照着 OpenShift 的产品模仿，那么当追上 OpenShift 时只可能有一种情况，那就是 OpenShift 停止发展，过了一年后你终于追上了，然后会因同样原因被淘汰。
那么有没有什么方法能够追上甚至超越 OpenShift 呢？我认为要从 OpenShift 本身商业模式的选择和技术路线上的选择入手，从他们在这种选择下不可避免的缺点入手，做出差异化，才有超越的可能。
OpenShift 里的 Open 可能和 OpenAI 里的 Open 是同一个 Open。如果你尝试不通过 RedHat 的销售自己去部署一套 OpenShift 就会知道我在说什么了。
OpenShift 的所有组件确实是开源的，但如果你是一个纯粹的社区用户会步步受挫。一个功能你可能找不到对应组件，找到组件可能找不到对应源码，找到源码又没有文档指导如何编译使用。这些现象在那些完全是 OpenShift 自己使用的组件里已经见怪不怪了。大概 OpenShift 这部分的社区只是对客户和合作伙伴开放的。
而对于那些非 OpenShift 专属的组件，OpenShift 采取的策略会是一旦选择就大举投入，争取到对应组件的社区的主导权。所以会看到的一个现象是有些社区很出名的项目 OpenShift 的人完全不投入，而一个项目在平稳发展了几年后会突然涌入大量 OpenShift 的人。
这些都是 OpenShift 在商业化与开源之间权衡后的选择，并没有对错之分，但这会给更开放的项目留出机会。如果新的产品能够降低参与门槛，收取更广泛的反馈，让更多的贡献者来参与创新，那么我认为它的上限将会超越 OpenShift。
受限于第一点因素，OpenShift 并不能广泛的吸收整个生态的最新成果。在生态内某个组件和 OpenShift 专属的组件功能重叠情况下，OpenShift 内部的研发人员是很难有动力切换到另一个社区或者另一个公司主导的开源组件。
以我比较了解的网络为例，OpenShift 早期通过 Haproxy 实现了 Route 来打通集群外访问集群内的流量。在当时 Ingress 还不成熟，Route 是一个相比社区先进的多的方案，OpenShift 的方案在当时是绝对领先的。但是随着 Ingress 的成熟，社区生态内各种网关都在飞速发展，而 OpenShift 受限于自己早期的实现和用户用法很长时间都没有去支持 Ingress 这个在社区已经标准化的功能。现阶段 Ingress 规范已经进化到 GatewayAPI 有一段时间了，大量 AI Gateway 的新场景都在通过 GatewayAPI 进行扩展，而 OpenShift 现如今还没有支持 GatewayAPI，最近正在计划在之前的 Haproxy 上同时支持 Route，Ingress 和 GatewayAPI。
类似的案例在 OpenShift 内还有很多，早期可能还是一个优秀的方案，但由于 OpenShift 专属导致不开放，随着社区的发展，原先优势的方案反而变成了阻碍前进的障碍。就像现在在 Kubernetes 上做 Ingress Gateway 不会有人去参考 OpenShift 的实现，在很多细分领域 OpenShift 已经并不是最先进的解决方案了，尤其是在那些由 OpenShift 专属组件提供服务的领域。现在的 OpenShift 在我看来就是一个覆盖面积很广，但平庸且无趣的平台。
容器平台的生产过程其实和手机的生产很像，都是从成百上千个供应链供应商那里选择需要的配件，然后组装成一个成品。如果能够保持开放，选择供应链上最先进的那些配件，或者根据场景快速组合出一个针对特定场景的产品，那么在技术竞争力上应该会远超 OpenShift。
要想真正追赶甚至超越 OpenShift，关键不是在已有功能上亦步亦趋，而是要做到更开放、更领先。这样才能摆脱追随者路径，真正形成对 OpenShift 的差异化优势，成为下一轮技术浪潮的主导者。
