Kubernetes服务冲突导致的SSL证书异常 - 完整RCA报告
2025年9月17日，linapp.fun主站发生SSL证书访问异常，用户在使用Safari等浏览器访问时被要求手动输入证书，同时HTTPS连接出现间歇性失败。该故障直接影响了网站的可访问性和用户体验，涉及SSL证书验证、Kubernetes服务冲突和端口占用等多个技术层面。故障期间，外部用户访问linapp.fun时收到的是agones-allocator服务提供的"allocation-ca"自签名证书，而不是正确的Let's Encrypt通配符证书。
当用户访问https://linapp.fun时，实际接收到的SSL证书是名为"allocation-ca"的自签名证书，而不是预期的Let's Encrypt证书。这个异常证书来自Kubernetes集群中的agones-allocator服务，该服务在用户访问网站时错误地拦截了HTTPS流量。
agones-allocator被配置为LoadBalancer类型服务，自动绑定了外部IP地址139.162.52.158的443端口。当外部流量访问这个IP的443端口时，Kubernetes的kube-proxy组件通过iptables NAT规则将流量重定向到agones-allocator Pod。
Kubernetes的LoadBalancer服务类型设计上就是为了将外部流量导入集群内部服务。当agones-allocator服务被标记为LoadBalancer类型时，集群会自动在iptables中创建KUBE-EXT-MC32CR4H2L6H7BD3规则链，这个规则链的优先级高于nginx的直接端口监听。
系统架构中存在nginx（主机级别）、traefik（Kubernetes ingress）、agones-allocator（游戏服务器分配器）三个不同的服务都需要使用443端口。这种设计缺乏统一的入口流量管理策略，各个服务独立配置HTTPS端口。
系统缺乏端口占用监控和服务依赖关系管理机制。agones-allocator和traefik作为Kubernetes负载均衡服务，它们的LoadBalancer类型配置会静默地占用外部IP端口，而现有的监控系统主要关注应用层指标，对网络层的端口冲突检测不足。
绿灯：所有网络服务正常运行且端口无冲突 | 黄灯：检测到潜在端口冲突或证书即将过期 | 红灯：服务不可用或证书验证失败
问题根源：云原生环境中缺乏统一的端口资源管理和网络流量控制策略。改进措施：建立端口资源管理规范，实施网络层监控增强，制定Kubernetes服务类型使用标准。预防机制：定期网络架构审查，SSL证书有效性检查，iptables规则变更监控。