RabbitMQ K8s对等发现报错‘Can't make context’排查求助

问题背景 #

在某Kubernetes 1.24环境中，RabbitMQ Pod启动时返回Can't make context错误，但相同版本的另一K8s环境中该Pod可正常运行，无法定位两者差异。从Pod内部按照Kubernetes官方文档的方式连接API服务器无异常。测试过的RabbitMQ版本包括3.10.x + Erlang 1.12、3.11.x + Erlang 1.14、3.12.0 + Erlang 1.14.5（因仅特定环境报错，暂不确定与版本相关）。

报错日志详情 #

{"time":"2023-06-19 09:40:43.126541+00:00","level":"debug","msg":"rabbit_peer_discovery:lock returned {error,\n                                     \"{failed_connect,\n    [{to_address,{\"kubernetes.default.svc.cluster.local\",443}},\n     {inet,\n         [inet],\n         {eoptions,\n             {{{error,{\"evp.c\",136},\"Can't make context\"},\n               [{crypto,generate_key,3,\n                    [{file,\"crypto.erl\"},\n                     {line,1676},\n                     {error_info,#{erl_function_arg_num => undefined}}]},\n                {ssl_cipher,generate_client_shares,2,\n                    [{file,\"ssl_cipher.erl\"},{line,1267}]},\n                {ssl_gen_statem,initial_hello,3,\n                    [{file,\"ssl_gen_statem.erl\"},{line,470}]},\n                {gen_statem,loop_state_callback,11,\n                    [{file,\"gen_statem.erl\"},{line,1426}]},\n                {tls_connection,init,1,\n                    [{file,\"tls_connection.erl\"},{line,160}]},\n                {proc_lib,init_p_do_apply,3,\n                    [{file,\"proc_lib.erl\"},{line,240}]}]},\n              {gen_statem,call,[<0.442.0>,{start,2250},infinity]}}}}]}","domain":"rabbitmq","pid":"<0.230.0>"}
{"time":"2023-06-19 09:41:13.130264+00:00","level":"notice","msg":"Application mnesia exited with reason: stopped","domain":"otp"}

当前rabbitmq.conf配置 #

cluster_formation.peer_discovery_backend  = rabbit_peer_discovery_k8s
cluster_formation.k8s.host = kubernetes.default.svc.cluster.local
ssl_options.verify=verify_peer
cluster_formation.k8s.address_type = hostname
cluster_formation.node_cleanup.interval = 30
cluster_formation.node_cleanup.only_log_warning = true
cluster_partition_handling = autoheal
queue_master_locator=min-masters
loopback_users = none

排查思路 #

• 检查两个K8s环境的CA证书配置差异：RabbitMQ通过SSL连接K8s API时依赖集群CA证书，确认目标环境中Pod挂载的/var/run/secrets/kubernetes.io/serviceaccount/ca.crt是否有效，是否与正常环境的CA证书一致；也可临时设置ssl_options.verify=verify_none测试是否为证书验证问题（仅用于排查，生产环境禁用）。
• 对比Pod的网络策略/防火墙规则：虽然手动连接API无异常，但RabbitMQ的K8s发现插件的SSL上下文配置可能与手动测试不同，确认目标环境是否有针对Pod outbound 443端口的特殊拦截规则，或kubernetes.default.svc.cluster.local的端点是否存在异常。
• 检查容器内Erlang/OpenSSL版本差异：Can't make context错误来自OpenSSL的evp.c模块，对比两个环境中RabbitMQ容器内的OpenSSL版本，排查是否存在与K8s API服务器的TLS协议/加密套件兼容性问题；可尝试在目标环境的RabbitMQ配置中指定兼容的TLS版本，比如添加ssl_options.versions.1 = tlsv1.2、ssl_options.versions.2 = tlsv1.3。
• 对比K8s API服务器的TLS配置差异：检查两个环境中kube-apiserver的TLS加密套件、证书签名算法是否不同，目标环境是否禁用了RabbitMQ容器内OpenSSL支持的某些算法。
• 检查Pod的ServiceAccount权限与挂载情况：确认目标环境中RabbitMQ使用的ServiceAccount权限与正常环境一致，以及serviceaccount-token Secret是否正确挂载，包括token、ca.crt文件的权限和内容完整性。
• 检查容器的文件系统权限：确认RabbitMQ容器内是否有足够权限访问SSL相关临时文件或系统目录，比如/tmp目录的权限是否正常，Erlang生成SSL上下文时可能需要写入临时文件。

内容的提问来源于stack exchange，提问作者JungWoo Ryoo