云原生DDoS防御适配容器化网站部署

容器化部署正在改变DDoS防御的底层逻辑。传统防火墙假设应用跑在固定IP和固定端口上，而Kubernetes环境里Pod随时漂移、Service动态分配ClusterIP、Ingress控制器自身成为流量入口。攻击者不再需要打穿你的源站，只要打满Ingress带宽或者耗尽kube-proxy的连接表，整个集群对外服务就会瘫痪。云原生DDoS防御必须把防护点从“边界设备”迁移到“流量路径的每一跳”，尤其是容器网络插件和Service Mesh这两层。

先看一个真实场景：某电商在K8s集群上跑了四十多个微服务，前端用Nginx Ingress暴露。一次三百Gbps的UDP反射攻击打过来，云厂商的机房级黑洞触发，把整个可用区都拉黑，同机房的数据库和消息队列全部跟着遭殃。问题不在攻击规模，而在防御粒度——传统黑洞是IP级别的，而容器化业务共享同一批出口IP，一个服务被攻击，所有服务陪葬。所以容器化网站做DDoS防御，第一件事就是拆散共享IP，给不同业务分配独立入口，或者用Anycast把攻击流量分散到多个PoP点清洗。

Ingress控制器是容器化网站的第一道门。Nginx Ingress默认配置下，单个worker进程的连接数上限、超时时间、请求体大小都没有针对DDoS做调优。攻击者发慢速POST请求，每个连接占住一个worker进程，几十万并发就能让Ingress Pod全部OOM。硬核做法是给Ingress控制器单独建一个节点池，用nodeSelector和taint隔离，保证它不跟业务Pod抢资源。同时开启proxy_protocol，让上游清洗设备能看到真实客户端IP，否则你的WAF规则全是针对内网IP做的，等于白配。

Gateway API正在取代Ingress成为标准。它的价值在于把“流量路由”和“安全策略”解耦。你可以定义一个HTTPRoute，同时挂一个RateLimitPolicy和一个DDoSRule，策略由不同的控制器执行。比如限流规则下发到Envoy sidecar，而DDoS特征匹配在边缘的云清洗中心完成。这种分层防御在容器环境里特别重要，因为攻击流量可能在到达Pod之前就已经被Service的kube-proxy转发过两次，单点检测会漏掉大量东西向流量。

很多人只防南北向流量，也就是从外部进入集群的请求。但容器化网站最大的风险是东西向流量——攻击者一旦拿下某个低权限Pod，就能在集群内部横向扫描，直接访问数据库Service的ClusterIP，绕过所有外部防火墙。Istio或Linkerd这类Service Mesh可以给每个Pod注入sidecar代理，强制所有出站流量经过mTLS加密和授权检查。这意味着即使某个容器被攻破，攻击者也无法直接访问其他服务的内部端口，因为sidecar会拒绝没有合法SPIFFE身份的对端。

但Service Mesh本身也会成为DDoS的放大器。Envoy sidecar默认的并发连接数、熔断阈值、重试策略如果配置不当，一次内部服务抖动就可能引发重试风暴，把整个Mesh打挂。建议给每个服务的DestinationRule设置connectionPool限制，比如最大连接数500、最大待处理请求100，并且关闭对幂等性不明确接口的自动重试。这些配置要写进GitOps流程，否则几十个服务手动改YAML根本不可维护。

容器化部署的优势是弹性，但DDoS防御不能只靠“扛”。攻击流量进来时，HPA（Horizontal Pod Autoscaler）看到CPU飙高就扩容，结果攻击流量把新Pod也打满，形成扩容-打挂-再扩容的恶性循环，最后账单爆炸。正确做法是把HPA的指标改成业务指标，比如“有效请求数”而不是“CPU使用率”。在Ingress层统计经过清洗后的正常请求速率，用这个速率驱动扩容。这样攻击流量不会触发扩容，正常用户突增才会。

更进一步的方案是联动云厂商的清洗API。当检测到入向流量超过阈值，自动调用云API把入口IP切换到高防线路，同时通过Kubernetes的EndpointSlice更新，把流量导到清洗后的回源地址。这个过程可以做到分钟级，比人工介入快得多。关键是要在集群内跑一个轻量级的检测服务，持续监控Ingress的access log和conntrack表，发现SYN Flood或UDP反射特征就触发切换。

Calico、Cilium、Flannel这些CNI插件在DDoS场景下的表现差异巨大。Flannel用VXLAN封装，每个包都要做一次内核态的解封装，攻击流量进来时CPU软中断会飙到100%，连正常流量都处理不了。Cilium基于eBPF，可以在网卡驱动层直接丢弃恶意包，不经过内核协议栈，性能好一个数量级。如果你的集群还在用Flannel，建议尽快迁移到Cilium，并且开启它的XDP加速模式。

还有一个常被忽略的点：kube-proxy的iptables模式在Service数量多、规则频繁变更时，连接跟踪表会膨胀到几十万条。攻击者只要制造大量短连接，就能让conntrack表溢出，导致所有新连接被丢弃。解决办法是把kube-proxy换成IPVS模式，或者直接用Cilium替代kube-proxy，用eBPF实现Service负载均衡，绕过conntrack的瓶颈。这个改动对业务无感知，但抗DDoS能力能提升数倍。

容器化环境的DDoS防御最怕“黑盒”。传统防火墙有独立的日志和告警，而K8s里流量经过Ingress、Service、CNI、sidecar多层转发，每一层都有自己的指标，但没人把它们串起来。你需要至少三套数据：Ingress层的请求速率和状态码分布、CNI层的丢包率和conntrack使用率、以及节点层的软中断和网络吞吐。用Prometheus采集这些指标，配合Grafana做一个统一的DDoS态势面板。当某个服务的入向流量突然比基线高出五倍，且源IP熵值异常，就要触发告警。

日志方面，Ingress的access log要开启采样，但不能全关。攻击期间保留全量日志用于事后分析，平时用1%采样降低存储成本。重点记录request_time、upstream_response_time、client_ip的ASN信息。很多DDoS攻击来自特定ASN的肉鸡，通过分析日志里的ASN分布，可以提前把高风险网段加入黑名单。

下面是一段Nginx Ingress的ConfigMap配置，专门针对慢速攻击和连接耗尽做了调优。这些参数不能照抄，要根据你的集群规模和正常流量基线调整。

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-ingress-controller
  namespace: ingress-nginx
data:
  worker-processes: "8"
  worker-connections: "65535"
  keep-alive: "60"
  keep-alive-requests: "10000"
  client-body-timeout: "10"
  client-header-timeout: "10"
  proxy-connect-timeout: "5"
  proxy-read-timeout: "30"
  proxy-send-timeout: "30"
  limit-req-status-code: "429"
  limit-conn-status-code: "503"
  limit-req: "50"
  limit-req-burst: "100"
  limit-conn: "200"
  limit-conn-per-ip: "20"
  enable-real-ip: "true"
  forwarded-for-header: "X-Forwarded-For"
  proxy-protocol: "true"
  use-forwarded-headers: "true"
  compute-full-forwarded-for: "true"
  ssl-ciphers: "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256"
  ssl-protocols: "TLSv1.2 TLSv1.3"

这些参数里，limit-req和limit-conn是核心。limit-req控制每秒请求速率，limit-conn控制单IP并发连接数。但要注意，如果你的业务有合法的突发流量，比如秒杀场景，burst要调大，否则正常用户会被误伤。更好的做法是在Ingress注解里针对特定路径设置不同的限流策略，而不是全局一刀切。

容器化网站经常跨云部署，或者一部分在自建机房，一部分在公有云。这种情况下，DDoS防御不能只依赖单一云厂商的清洗能力。建议用DNS轮询或BGP Anycast把流量同时分发到多个入口，每个入口独立清洗。K8s集群之间用专线或隧道打通，清洗后的流量通过内部网络回源，避免公网绕行。这种架构的成本较高，但对于金融、游戏等对可用性要求极高的行业，是值得的。

如果预算有限，至少要做到“入口分离”。把静态资源放在CDN上，动态API走云高防，WebSocket长连接走独立的入口。攻击者往往针对某个具体端口或协议，分离后即使一个入口被打挂，其他服务不受影响。在K8s里可以用多个IngressClass实现，不同的Ingress控制器绑定不同的Service，再通过DNS把不同域名解析到不同入口。

容器化DDoS防御的本质是把安全能力嵌入到云原生的控制面和数据面里，而不是在集群外面挂一个盒子。这要求安全团队懂K8s的网络模型、懂CNI的实现细节、懂Service Mesh的流量治理。门槛不低，但一旦建立起来，防御的灵活性和自动化程度是传统方案无法比拟的。攻击者也在进化，他们开始利用容器镜像里的漏洞做跳板，利用Serverless的冷启动做放大。你的防御体系必须跟业务一样，具备快速迭代和弹性伸缩的能力。