@cdlnls 那换个角度说，既然去的包经过这些路由器能顺利到达目的端，说明路由器上有两端通信的路由，那回包理论上不是也可以按照路由信息回到源端呢？为啥反过来就不行了呢

@revelationtan 不太理解，隔着一个网段为啥就必须两边都加呢？单加一边的话，去的包中间经过的路由器不都学会了路由信息了吗？回来时候再经过这些路由器按理说不是能回来吗？

@cdlnls 对对，我记得就是你说的“路由器可以通过和其他路由器交换信息”，百科也这么说的 @billlee
https://baike.baidu.com/item/%E5%8A%A8%E6%80%81%E8%B7%AF%E7%94%B1/100533?fr=ge_ala 。这样的前提下去的包经过这些路由器学到了路由，那回包经过这些路由器不是也知道往哪走吗？

@billlee 但记得之前上学学的时候路由器之间不是会广播学习吗？

@Andim 可能有路由器，但为啥只加一个方向不行呢而是要在两个服务器上都加？

@christin 这个感觉用起来不丝滑，还得专门点开插件

Debian 系成主流了吧

@edis0n0 牛逼 随便 commit 都行？

@blackeeper 嗯这个看到过，1.1.9 太早了，现在默认多少呢

@XIU2 嗯，发现后端 k8s service 没了，nginx dns 解析 service name 还是到老的 clusterIP

@blackeeper 嗯，想知道没定义的情况下默认是多少

@Symo 嗯，之前大概了解过这个项目。如果是监听 k8s 资源变化基本都是用的 k8s client-go list-watch 机制，但跳出 k8s 资源来不知道有没有这种类似的框架

我理解楼主的意思，上头的可能没做过这块不清楚需求。其实我们在做的时候也一直面临这个问题，想获取状态无非是"推"、“拉”两种，像轮询这种就算是“拉”，但是和拉的时间间隔有关，不好把握，不一定是实时的；另一种“推”就是 k8s 所在的某个服务端直接给你推状态结果。我们现在是自己写的一套根据事件 event 来跟踪结果，达到某个状态（比如你可以定义为 pod 所有容器 started ）来”回调“（其实相当于“推”）给前端等其它模块来感知结果。但这里面也有问题，一是 k8s event 不保证一定有，也就是可能会丢（只不过我们从没遇到过），另一个就是 k8s 本身有些状态不是一次性的，可能会重试成功（比如 imagePullBackOff ），虽然出现了错误但实际内部重试几次可能还会成功，也就是中间的错误状态也会变。相对好点的方法你可以用 websocket 流来实时推 pod 状态，但需要你编写一些代码。其实 k8s client-go 里 informer 的 list-watch 机制挺好的，利用了 etcd 特性 watch 变化来推送给客户端，之前一直在找有没有类似实现机制的框架可以方便实现其它用途，因为 informer 是 k8s client-go 里的除非把它拆出来，但目前还没找到。

之前看有新闻说做了手术 20 年后眼睛还会有问题，身之发肤受之父母，像眼睛这类这么重要的身体部位感觉做手术还是谨慎好

@chuanqirenwu 加油！都挺厚😂

@detached 在哪看啊？微信读书我看后面收费😂

@gadfly3173 对，但 pr 的源分支是别人的仓库，这样只能将他的私人仓库下载下来？

@Rhilip 谢谢，插件看起来不错！