如何在K8s环境中模拟Cassandra超时（不可修改Cassandra集群）

以下是几个无需修改业务Pod或Cassandra集群的可行方法：

1. 利用K8s网络插件的流量管控能力 #

主流K8s网络插件大多自带流量整形功能，直接通过配置就能添加延迟：

• Calico：创建带TrafficPolicy的NetworkPolicy，指定匹配Cassandra集群的源IP/服务，给目标Web API Pod的入站流量加延迟。比如在Policy里配置delay: 200ms，精准控制来自Cassandra的响应延迟。
• Cilium：用CiliumNetworkPolicy的trafficControl字段配置入站延迟，通过Pod标签定位目标Web API Pod，针对Cassandra的流量规则添加固定延迟，用cilium-cli就能快速生效。

2. 注入轻量代理Sidecar（无需改业务镜像） #

如果集群允许自动Sidecar注入，给目标Pod加个代理Sidecar，通过代理规则添加延迟：

• Envoy：配置fault_injection过滤器，在代理处理Cassandra响应的链路中加入延迟。把Envoy配置存在ConfigMap里，Sidecar负责转发Cassandra流量，返回时自动注入延迟，业务Pod只需将Cassandra地址指向localhost的代理端口。
• HAProxy：在HAProxy配置里使用http-request delay <ms>指令，针对来自Cassandra的响应添加延迟。Sidecar作为反向代理，业务Pod通过localhost访问，代理转发请求到Cassandra，返回时加上设定的延迟。

3. 节点层面用tc工具（如果能操作节点） #

如果有权限访问Web API Pod所在的K8s节点，直接在节点上用tc给Pod的入站流量加延迟：
先拿到目标Pod的IP，然后执行节点层面的tc命令：

# 添加根队列规则
tc qdisc add dev eth0 root handle 1: prio
# 添加netem延迟队列，示例设为200ms
tc qdisc add dev eth0 parent 1:3 handle 30: netem delay 200ms
# 将发往Pod IP的流量导向延迟队列
tc filter add dev eth0 protocol ip parent 1:0 prio 3 u32 match ip dst <你的Pod IP> flowid 1:3

这样所有到该Pod的流量（包括Cassandra响应）都会被延迟，完全不用修改Pod内部内容。

4. 调整Cassandra客户端的模拟延迟配置 #

之前调超时参数没效果，可以试试客户端自带的模拟延迟功能：

• DataStax Java驱动支持advanced.simulated-latency参数，直接在客户端配置里设置固定延迟（比如200ms），驱动会在请求或响应阶段自动注入延迟，无需修改任何网络配置。
• 也可以调大客户端的read-timeout配合负载测试，或者修改重试策略，让超时场景更容易触发。

内容的提问来源于stack exchange，提问作者Igor Țurcanu