Istio

近期的一些经验总结

December 17, 2024
技术总结
CDC, DMS, Istio, APISIX, ShardingSphere Proxy, Kafka, Kafka Connect, Doris, Pyroscope

这里不会过多的介绍软件的相关概念和架构，主要是针对实际问题的解决方案和思考。

问题汇总 #

  • CDC 相关

    • CDC kafka-connect mysql sink 侧消费积压问题
    • CDC kafka-connect mysql source 侧删除事件投递了两条事件，导致删除动作数据量被放大
    • CDC kafka-connect mongodb 数据同步任务异常（消息超过 1MB ）

  • DMS 数据同步相关

    • 数据迁移完成后，怎么对比源数据和目标数据是否一致？
    • 如果不一致怎么处理？

  • Istio 相关

    • Istio 中多个 gateway 使用相同 host，analyze 是提示错误
    • Istio 中一个服务提供了多个端口的服务，怎么配置 Virtual Service ？

  • APISIX 相关

    • 使用 APISIX 作为网关，怎么进行有条件的响应重写？
    • APISIX 插件的执行顺序是怎么样的？

  • ShardingSphere Proxy

    • HINT策略 在 ShardingSphere Proxy 中的使用

  • Kafka 相关

    • 如何将迁移kafka集群中的数据？

  • Pyroscope 相关

    • 使用 Go Pull 模式采集数据时为什么只有 cpu + gourotines + cpu samples 三个指标？

  • Doris 相关

    ...

Istio Idle Timeout问题复现和解决

March 25, 2024
Kubernetes
Istio, Sidecar, Envoy, Kubenertes, Service Mesh

更新 2024-04-01 #

通过调整 tcp_proxy 的 idle_timeout 参数后，部分中间件（redis, mongo）的异常问题不再出现，但是 mysql(sharding-spere) 和 memcached 仍然存在 “invalid connection” 错误，所以还需要找到能够解决 mysql(sharding-spere) 和 memcached 的方法。

上述描述的现象非常主观，不一定正确也不能作为最终结论，但是 idle_timeout 配置确实没有解决所有的问题。

这里，需要知道 istio 在 inject 时会通过 iptables 对应用的流量进行劫持，对于 outbound 的流量 iptables 规则拦截转发到 OUTPUT 链。OUTPUT 的链转发流量到 ISTIO_OUTPUT，这个链会决定服务访问外部服务的流量发往何处。

这样产生的效果是，除了应用自己建立的连接之外 envoy 也会创建一个代理连接。

$ netstat -notp | grep 3307
tcp         0             172.23.105.25:41030        x.x.x.x:3307         ESTABLISHED -      off(0.00/0/0)
tcp         0             172.23.105.25:41022        x.x.x.x:3307         ESTABLISHED 1/./app      keepalive(0.88/0/0)

我遇到的问题可以确定问题就出在 envoy 建立的连接上，因为应用自己建立的连接是正常的，同时还可以看到应用自己的连接开启了 keepalive, 而 envoy 建立的连接没有开启。这样可能会出现这个连接会因为超时而被关闭的情况，或者其他原因导致连接被释放。那如果可以避免将中间件的流量通过 envoy 代理，这样就可以避免这个问题。

在官方的文档中也提到，https://istio.io/latest/zh/docs/tasks/traffic-management/egress/egress-control/ 对于外部服务，可以通过配置 excludeOutboundPorts 或者 excludeOutboundIPRanges 来使得某些服务的流量不经过 istio sidecar。其背后的原理是通过 iptables 的规则中排除这些端口或者 IP 地址。

...

在istio服务网格中扩展自定义功能

November 17, 2023
Service Mesh
Istio, Service Mesh, Envoy, Kubernetes

前提 #

本文假设你已经对 Kubernetes、istio 和 Envoy 有一定的了解，如果你还不了解，可以先阅读下面的文章：

当然不仅限于知道这些，还需要对其有一定的实践经验，这样才能更好的理解本文的内容。当然本文也不会涉及太深，只是作为 istio 的一个入门扩展教程。

为什么要扩展功能？#背景 #

用通俗的话去理解 istio 的作用就是，对我们部署在 kubernetes 上的应用进行流量控制（代理），给我们提供了：流量控制、流量监控、流量安全等功能。但是在实际的使用中，我们还是会遇到一些特殊的场景，需要我们自己基于自己的业务场景去扩展一些功能，比如：ip 白名单、ip 黑名单、统一认证等。这些功能往往和具体公司的业务场景有关，因此 istio 无法直接提供这些功能，需要我们自己去扩展。

传统的扩展方式 #

在传统架构中，常常通过 API 网关这一组件来实现这一些扩展能力，常用的 API 网关有：kong、apisix、openresty，而扩展的原理就是插件，或者像 nginx/openresty 在请求链中的不同阶段提供了不同的 hook，我们可以基于这些 hook 来实现扩展功能。

就我个人的经历来说，网关要么自己定制开发，要么基于openresty来实现，又或者使用一些开源的网关，如：kong、apisix，在此基础上进行二次开发。不过这些方式都是在传统API网关中去实现的，随着 Service Mesh 的发展，API网关的某些功能也被 Sidecar 代理所取代，比如：流量控制、流量监控、流量安全等。目前 Mesh 发展的趋势也是进一步在 Sidecar 代理中实现更多的功能，而不是在 API 网关中实现。

Envoy 的扩展能力 #

envoy 提供了丰富的扩展能力，Access Logger, Access Log Filter, Clusters, Listen Filter, Network Filter, HTTP Filter 等等。这一块内容非常多，如果想要了解更多，请参考官方文档。

...

访问量 访客数