Istio GRPC Gateway 禁用 HTTP1.1 请求

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

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





Istio sidecar TCP 空闲连接 1 小时自动断开

部分服务连接 redis 会经常出现连接被断开,导致从连接池中取出连接发送请求时会失败。

从 istio accesslog 中观测到到 redis 的连接,断开时间通常是 3600s 即一个小时。


Istio 服务请求外部域名持续出错,切换 DNS 后也无法恢复

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

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



减少 Istio 控制面下发的配置

默认情况下,istiod 会 watch 集群中所有的 namespace,生成对应的配置,实时的通过 xDS 协议,推送给所有实例的 sidecar 容器。

业务实例会被分发到大量不相关的配置,根本用不到,不仅增加 istiod 分发配置的时效性,也增加了 sidecar 的资源消耗。



macos 上如何实现类似 iptables 的防火墙规则

Linux 上调试开发的时候,经常需要模拟网络断开,端口无法访问等场景。

mac 上开发也有类似的需求,例如禁用掉所有到 192.168.100.2 的 80 端口的流量。可以通过 PF 防火墙来实现。


Istio 1.9 升级 1.10 ExternalAuthorization 失效的问题

近期在将 Istio 1.9.1 升级到 1.10.4。发现原来在 1.9 版本中生效的 ExternalAuthorization 的功能在控制面升级到 1.10,数据面保持在 1.9 版本时,会失效。所有的请求都不需要鉴权就能访问到后端服务。


Istio sidecar 容器启动停止问题

由于引入了 sidecar,会通过 iptables 规则将流量劫持到 sidecar 中的进程。但是 K8s 上并没有精确控制 sidecar 的能力,导致由于 sidecar 与主容器的启停顺序问题会引起一些非预期的行为。



Istio 对 Service port name 的要求

由于 Istio 需要在七层解析流量,所以劫持服务流量后需要知道协议类型才能用合适的协议规则来解析。


Kubernetes 中支持 Pod 定向迁移

原生的 K8s 并不支持将指定的 Pod 从当前节点迁移到另外一个指定的节点上。但是我们可以基于 K8s 提供的扩展能力来实现对这一功能的支持。