可观测性(Observability)并不是一个新词，而在几十年前被广泛地用于控制理论，用它来描述和理解⾃我调节系统。随着容器技术、微服务、⽆服务器迅速流行，使得系统间的访问越来越复杂，在云上、本地或两者上可能会运⾏数千个进程， 使用传统的监控技术和⼯具很难跟踪这些分布式架构中的通信路径和相互依赖关系。系统内部的可见性就变得非常重要。

那可观测性到底在说什么呢?

使用kubernetes遇到最多的70%问题都可以归于网络问题，最近发现如果内核参数: bridge-nf-call-iptables设置不当的话会影响kubernetes中Node节点上的Pod通过ClusterIP去访问同Node上的其它pod时会有超时现象，复盘记录一下排查的前因后因.

最近排查了一个kubernetes中使用了hostport后遇到比较坑的问题，奇怪的知识又增加了.

最近发生一件很诡异的事情, 某个ns下的pods会莫名其妙地被删了, 困扰了好一阵子，排查后发现问题的起因还是挺有意思。

AI场景跟大多数的业务不太一样的是: 网络端需要尽可能地靠近，对于大多数业务来说，为了保证其可用性，一般副本都会分散地部署在不同node，而AI业务通常伴随着海量的数据交换，一个job中的多个pod需要协同处理，如果分散在多个node上，task间的任务交换的快慢就得依赖于网络的传输的快慢，而如果是在一台node上的话，那就没有这部分的消耗，一个job中的pods如何做到尽可能地调度在同一台机器上呢, kube-batch除了能够支持poggroup外，也是能够支持的podaffinit的.

前面记录的都是在现有的集群中如何基于infiniband实现集群中的pod同时能够拥有两个网络, 其中一些实现细节并没有展开，个人觉得还是有必要再总结总结.

这次把sriov+infinitband部署期间遇到的问题做一个总结，给有需要的同学做个参考.

上回简单介绍了下技术背景，这次真正进入实践阶段,之前提到过，sriov是需要硬件支持, 一般开启sriov需要在IBOS中进行设置，这个根据服务器型号不同而操作不同, 具体可参考官网.

在HPC场景下，底层网络的性能直接影响最终的结果，HPC往往会伴随海量的数据交换，特别是在跨Node之间，10Gb的以太网网络传输肯定要比100Gb的IB网络传输慢，本人所负责的训练平台也是如此，在一次训练过程中，GPU存在海量数据交换，虽然是在GPU之间，但本质还是通过网络进行传输，但是以太网的传输在HPC场景下往往显得不那么高效，因此可以通过RDMA或者如果预算够的话，通过硬件IB实现数据交换，能大大提高训练质量

kong在v1.3的版本原生支持了grpc协议, 这里说说使用kong来代理多个grpc请求.