Hashicorp Consul Connect注入器文件系统证书配置项错误及服务崩溃问题

看起来你的Consul集群在停机一个多月重启后，碰到了个挺棘手的问题：Consul Server副本报invalid config entry kind: file-system-certificate错误，连带着Connect注入器直接陷入CrashLoopBackOff循环崩溃，而且你试过缩容清PVC再重启的办法也没解决，我来帮你拆解下问题根源和可行的修复步骤。

问题根源先搞清楚 #

首先得明确：Hashicorp官方原生的Consul里根本没有file-system-certificate这个内置的配置项类型。出现这个错误，大概率是你的集群在停机前，可能部署了自定义的扩展组件（比如自定义的Consul配置项控制器）、启用过某个已被移除的实验性功能，或者在Injector/Server的配置里硬编码了对这个自定义配置项的引用。现在集群重启后，这些依赖的组件或配置没跟上，导致Consul Server不认识这个配置项，而Injector还在一个劲地尝试拉取它，最终引发崩溃。

具体修复步骤 #

1. 先稳住Connect注入器：检查它的配置

Injector持续崩溃是因为它一直在请求这个不存在的配置项，所以先从它的配置入手：

• 找到Consul Injector的Deployment或者关联的ConfigMap，查看它的启动参数、环境变量，或者挂载的配置文件，有没有任何和file-system-certificate相关的配置条目——比如是否指定了要监控这个类型的配置项。
• 如果找到相关配置，先暂时注释掉或者删除这部分内容，然后重启Injector的Pod，看看它能不能正常启动。

2. 检查Consul Server的启动配置

接下来看Server端的配置：

• 查看Consul Server StatefulSet的启动参数、挂载的配置文件，有没有启用过和file-system-certificate相关的自定义扩展、实验性功能开关。
• 如果找到相关配置，要么恢复对应的自定义扩展组件（如果之前是靠第三方组件支持这个配置项的话），要么直接移除这部分配置，然后重启Server Pod，观察日志里的invalid config entry kind错误是否消失。

3. 排查K8s集群里的残留CRD

如果上面两步都没找到问题，那可能是K8s集群里还残留着定义了这个配置项的自定义CRD：

• 用命令kubectl get crds | grep consul列出所有Consul相关的CRD，看看有没有和file-system-certificate相关的资源定义。
• 如果找到对应的CRD，可以先备份它的配置，然后删除这个CRD，再重启Consul Server和Injector组件，验证问题是否解决。

为啥你之前的缩容清PVC方法没用？ #

你之前缩容Server到0、清PVC再扩容的操作，本质是清除了Consul Server的Raft集群数据，但这个问题的根源根本不在Raft数据里——而是外部的配置引用（Injector的配置、Server的启动参数、K8s CRD）还在要求处理这个不存在的配置项，所以清PVC自然解决不了问题。

备注：内容来源于stack exchange，提问作者Vishwas M.R