服务网格遇到的坑

最近服务在迁移到k8s+istio服务网格上，迁了之后遇到了一些问题，经过调研发现并解决了部分问题，在此记录下。

问题一：
迁移后监控发现redis时延变高。普遍增高约1-2ms
原因：
机器所在区域不同，之前ECS和redis机器同属阿里云的同一个区域，网络间调用时延很低，基本保证了redis时延在1ms一下。服务网格申请的机器在另外一个不同的区域，导致redis时延增高到了2.5ms左右，一定程度上增加了服务时延。

问题二：
某些服务突然fd暴涨，连带着内存暴涨，最后服务崩溃。
原因一：
阿里云上的ECS是网络增强型的机器，网络参数都是经过系统调优的，后面k8s上的机器都是cpu比较强悍的机器，网络参数优化不足，另外pod上的容器用的镜像也是未经网络参数调优的，结果就导致了系统中存在大量的TIME_WAIT的fd导致端口资源耗尽fd上涨。
原因二：
envoy的性能不足，在qps超过4500之后性能下降明显（envoy配置了2核cpu），从而导致服务响应延迟变高，从而有大量新请求进来占用fd端口资源。

经测试，对上述容器进行了如下调整：

      sysctl -w net.ipv4.ip_local_port_range="12000 60999"
      sysctl -w net.ipv4.tcp_max_tw_buckets=10000
      sysctl -w net.ipv4.tcp_tw_reuse=0
      sysctl -w net.core.somaxconn=4096
      sysctl -w net.ipv4.tcp_syncookies=1

destinationRules也进行了如下限制：
trafficPolicy:
connectionPool:
http:
http1MaxPendingRequests: 1000
maxRetries: 3
idleTimeout: 60s
tcp:
connectTimeout: 1s
maxConnections: 1000

envoy性能暂时没有很好的办法，就先注意着不要让服务qps过高了。