有一组专门用于 grpc 请求的 istio-gateway 网关，但是会被通过 HTTP1.1 的请求做漏洞扫描，istio gateway 仍然能够处理，并且会将这个请求转发给后端的服务，后端服务由于协议不匹配，会直接断开连接，istio gateway 就会返回 503。

这样会误触发告警，并且也会影响观测正常的监控。

有用户反馈新增的接口调用后返回 upstream connect error or disconnect/reset before headers. reset reason: protocol error。

但是同一个接口，在未登录时，返回未认证的 json 是正常的。只有在登录后，返回接口才不正常。

原理就是通过 iptables 劫持 DNS 查询请求到 sidecar ，由 sidecar 提供 DNS 请求的响应和转发。

对于 K8s 内部的 service 名称解析，会直接返回结果。

对于外部的域名，会转发给上游的 DNS Server 查询。

假设 K8s 集群内的服务会以串行的方式不断请求一个外部域名的 80 端口。这个域名通过 DNS 解析到一个固定 IP。当某个时间段，这个 IP 上绑定的服务突然不可用，端口无法访问。内部服务会持续的得到 HTTP 503 的响应。

此时即使将这个域名的 DNS 切到一个正常的 IP，服务仍然会得到持续的 503 错误，一直无法恢复。

kubernetes 的 controller-manager 通过 APIServer 实时监控内部资源的变化情况，通过各种操作将系统维持在一个我们预期的状态上。比如当我们将 Deployment 的副本数增加时，controller-manager 会监听到此变化，主动创建新的 Pod。

对于通过 CRD 创建的资源，也可以创建一个自定义的 controller 来管理。

Redis作为一个使用场景很高的NoSQL数据库，支持了较为丰富的数据类型，相比于其他关系型数据库在性能方面优势明显。互联网公司通常更加倾向于将一些热点数据放入Redis中来承载高吞吐量的访问。

单机Redis在普通的服务器上通常ops上限在5w左右，开启pipeline的情况下在20-30w左右。对于大多数中小公司来说，通常单机的Redis已经足够，最多根据不同业务分散到多台Redis。