@xtinput 还是有影响的，还没到对大几千毫无感觉的程度

外企也有很多的

@nullyouraise 确实，v2 的专业性很弱，也没太多的在校

你这个可是大价钱

@zed1018 对的，发现了，直接访问会跳转，切成 en 之后就不了。主要还是不习惯他那种必须先填联系方式再下载的方式吧

@zed1018 排版和下载前的强制填联系方式之类的

@artnowben 我猜也是

@artnowben 昨天正好看到了你这个，ipvs 在大集群的情况下是显然优于 iptables ，又没其他可以选，测试意义不大。我倒是很期待，你们准备不准备自己维护一个对主流 gateway 的测试结果集。

冲浪冲多了，币入不敷出，多的借点给我

建议内容也 copy 下

up 下

hand2note 之类的可以先用用，GTO 的计算量导致无法实时

协作式，但是为了一些场景一直不让出控制权，后续加入了一定的抢占的场景

@JeffyChen 这条应该是 iptables 对来自非 pod 的请求，做一次 SNAT 。vxlan 到没注意，阿里云 vpc 是不需要对 来源 pod 的请求做 SNAT ，因为信息推到 vpc 了

@JeffyChen KUBE-MARK-MASQ 排除了来自 pod 的 source

iptables -t nat -L KUBE-SERVICES | column -t
Chain KUBE-SERVICES (2 references)
target prot opt source destination
KUBE-LOAD-BALANCER all -- anywhere anywhere /* Kubernetes service lb portal */ match-set KUBE-LOAD-BALANCER dst,dst
KUBE-MARK-MASQ all -- !172.30.0.0/16 anywhere /* Kubernetes service cluster ip + port for masquerade purpose */ match-set KUBE-CLUSTER-IP dst,dst
KUBE-NODE-PORT all -- anywhere anywhere ADDRTYPE match dst-type LOCAL
ACCEPT all -- anywhere anywhere match-set KUBE-CLUSTER-IP dst,dst
ACCEPT all -- anywhere anywhere match-set KUBE-LOAD-BALANCER dst,dst

- grpc 本身就是基于 http/2 的，你路子野点直接让对面用 http 调用你也行，但是不建议
- 将 json 格式的 grpc 请求转到 protobuf 格式的 grpc 请求基本是都有的功能了，可以直接选你们的反向代理对应的
- 比如 nginx: http://nginx.org/en/docs/http/ngx_http_grpc_module.html

巨硬也是骨折