ClickHouse Operator与Istio集成时的认证问题排查指南

问题背景

在使用ClickHouse Operator部署ClickHouse集群时，当启用Istio服务网格注入后，出现了ClickHouse Operator无法正常连接ClickHouse实例的问题。从日志中可以看到，Operator不断报告"Host is NOT alive"错误，而ClickHouse服务端则显示"Authentication failed"认证失败信息。

现象分析

当Istio注入被启用时，系统表现出以下典型症状：

1. Operator日志显示连接失败：

E1113 14:29:59.532223 QueryAny():FAILED to run query on all hosts [chi-clickhouse-default-0-0-0.clickhouse-test.svc.cluster.local]
W1113 14:29:59.532280 getHostClickHouseVersion():Failed to get ClickHouse version on host: 0-0
W1113 14:29:59.532291 func1():Host is NOT alive: 0-0

2. ClickHouse服务端日志显示认证失败：

2024.11.13 14:32:14.822093 [ 75 ] {} <Error> Access(user directories): from: ::ffff:127.0.0.6, user: clickhouse_operator: Authentication failed: Code: 193. DB::Exception: Invalid credentials.

3. 手动测试验证：

• 从Operator Pod内部使用curl可以成功连接ClickHouse
• 使用clickhouse-client工具也能正常连接
• 但当Istio的mTLS模式设置为STRICT时问题出现，改为PERMISSIVE后问题消失

根本原因

深入分析后发现，问题的本质并非表面看到的认证失败，而是Operator Pod无法访问Kubernetes API Server获取必要的凭据：

error: 'Get "https://10.96.0.1:443/api/v1/namespaces/clickhouse-operator/secrets/clickhouse-operator": dial tcp 10.96.0.1:443: connect: connection refused'

当Istio注入后，Operator Pod的网络流量被重定向到Istio sidecar代理，但由于缺乏正确的网络策略配置，导致Operator无法访问Kubernetes API Server获取ClickHouse的认证凭据。因此，Operator尝试使用空的用户名和密码连接ClickHouse，自然会导致认证失败。

解决方案

1. 调整Istio配置：

   • 将PeerAuthentication策略从STRICT改为PERMISSIVE模式
   • 或者为Operator Pod添加特定的Istio网络策略，允许其访问Kubernetes API Server

2. 显式配置Operator访问权限：

   • 确保Operator ServiceAccount具有足够的权限访问必要的Secret
   • 检查NetworkPolicy是否允许Operator Pod访问API Server

3. 验证环境配置：

   • 确认Kubernetes集群的DNS解析正常工作
   • 检查Istio sidecar注入后的网络连通性

最佳实践建议

1. 分阶段启用Istio：

   • 先在PERMISSIVE模式下测试所有功能
   • 确认无误后再逐步切换到STRICT模式

2. 完善监控：

   • 为Operator添加API Server连接状态的监控
   • 设置ClickHouse认证失败的告警

3. 文档记录：

   • 记录所有网络依赖和访问需求
   • 为团队创建Istio集成检查清单

总结

ClickHouse Operator与Istio集成时出现的认证问题，往往不是简单的密码错误，而是网络访问控制导致的关键凭据获取失败。通过系统性地分析日志、验证网络连通性、理解Istio的流量拦截机制，可以有效地定位和解决这类集成问题。建议在启用服务网格时，提前规划好网络访问策略，确保关键组件间的通信不受影响。