简介：11月22号半夜2点，被值班同学的电话打醒。了解下来，大概情况是，客户某一台Kubernetes集群节点重启之后，他再也无法创建Istio虚拟服务和Pod了。一来对Istio还不是那么熟悉，二来时间可能有点晚，脑子还在懵圈中，本来一个应该比较轻松解决掉的问题，花了几十分钟看代码，处理的惨不忍睹。

11月22号半夜2点，被值班同学的电话打醒。了解下来，大概情况是，客户某一台Kubernetes集群节点重启之后，他再也无法创建Istio虚拟服务和Pod了。

一来对Istio还不是那么熟悉，二来时间可能有点晚，脑子还在懵圈中，本来一个应该比较轻松解决掉的问题，花了几十分钟看代码，处理的惨不忍睹。最终还是在某位大神帮助下，解决了问题。

鉴于此问题，以及相关报错，在网上找不到对应的文章，所以这里分享下这个问题，避免后来的同学，在同样的地方踩坑。另外谨以此篇致敬工作中遇到过的大神！

不断重启的Citadel

Citadel是istio的证书分发中心。证书即某个实体的身份证明，直接代表着实体本身参与信息交流活动。Citadel作为证书分发中心，负责替服务网格中每个服务创建身份证书，方便服务之间安全交流。

这个问题的现象是，Citadel再也无法启动了，导致无法创建新的虚拟服务和Pod实例。观察Citadel，发现其不断重启，并输出以下报错信息。

2019-11-22T02:40:34.814547Z warn Neither --kubeconfig nor --master was specified. Using the inClusterConfig. This might not work.
2019-11-22T02:40:34.815408Z info Use self-signed certificate as the CA certificate
2019-11-22T02:40:34.840128Z error Failed to create a self-signed Citadel (error: [failed to create CA KeyCertBundle (cannot verify the cert with the provided root chain and cert pool)])

通过代码分析，以及最后一行报错，可以理解问题背后的逻辑：

Citadel不能启动，是因为其无法创建自签名的证书（Failed to create a self-signed Citadel）
Citadel无法创建自签名证书的原因，又是由于它不能创建秘钥和证书（failed to create CA KeyCertBundle）
而前两条的根本的原因，是因为在验证创建的自签名证书的时候，验证失败（cannot verify the cert with the provided root chain and cert pool）

一般意义上的证书验证

证书的签发关系，会把证书连接成一棵证书签发关系树。顶部是根证书，一般由可信第三方持有，根证书都是自签名的，即其不需要其他机构来对其身份提供证明。其他层级的CA证书，都是由上一层CA证书签发。最底层的证书，是给具体应用使用的证书。

验证这棵树上的证书，分两种情况：

根证书验证。因为即是签发者，又是被签发者，所以根证书验证，只需要提供根证书本身，一般肯定验证成功。

其他证书验证。需要提供证书本身，以及其上层所有CA证书，包括根证书。

自签名证书验证失败Citadel启动失败的根本原因，是其创建的自签名的证书，无法验证通过。而这一点，也是我处理问题时，卡壳的原因。左思右想，不明白为什么刚刚新建的自签名证书，都验证不通过。

大神定理

有一条定理，就是我们绞尽脑汁，耗费大量时间无法解决的问题，在大神眼里，可能就是几秒钟的事情。11月22号半夜，这条真理再次被验证。

因为实在想不通，但是用户又非常着急，所以最终还是打扰了一位大神，他只大概看了一下报错，就判断是CA证书过期问题。使用istio提供的证书验证脚本，很快证实了他的判断。相关文章见最后参考部分。

Citadel证书体系

问题解决了，这里总结下Citadel证书体系。大多数用户使用Isito的时候，都会选择使用自签名的根证书。自签名根证书，证书，以及证书使用者sidecar三种之间有三种关系：

根证书和证书之间的签发关系。这种关系，保证了信任的传递性质。
证书和sidecar之间的持有和被持有关系。某种意义上，这是给pod/sidecar和证书画上了等号。
根证书和sidecar之间的信任关系。这与前两条加起来，sidecar就信任所有根证书签发的证书。

以上三条，即可保证，在互相通信的时候，pod/sidecar之间可以完成tls双向认证成功。

犯的错

这个问题排查中，实际上犯了两个错误。一个是代码阅读不仔细，一直盯着自签名证书新建的逻辑看。因为有了这个前提，即新建证书验证失败，所以没有办法理解，为什么新建的自签名证书也会验证失败，所以倾向于认为是底层安全库出了问题；另外一个是，只盯着Citadel不能启动的报错做，忽略了另外一条线索，就是Pod和虚拟服务创建失败。实际上后来发现，pod和虚拟服务创建失败的报错，有更明显的证书过期错误信息。

virtualservices.networking.istio.io “xxxx” could not be patched: Internal error occurred: failed calling admission webhook “pilot.validation.istio.io”: Post https://istio-galley.istio-system.svc:443/admitpilot?timeout=30s: x509: certificate has expired or is not yet valid.

后记

在Istio比较早期的版本中，自签名Ca证书有效期只有一年时间，如果使用老版本Istio超过一年，就会遇到这个问题。当证书过期之后，我们创建新的虚拟服务或者pod，都会因为CA证书过期而失败。而这时如果Citadel重启，它会读取过期证书并验证其有效性，就会出现以上Cidatel不能启动的问题。

这个Ca证书在Kubernetes集群中，是以istio-ca-secret命名的secret，我们可以使用openssl解码证书来查看有效期。这个问题比较简单的处理方法，就是删除这个Secret，并重启Citadel，这时Citadel会走向新建和验证自签名Ca证书的逻辑并刷新Ca证书。或者参考以下官网处理方式。

参考

https://istio.io/docs/ops/security/root-transition/

作者简介

罗建龙（花名声东），阿里云技术专家。多年操作系统和图形显卡驱动调试和开发经验。目前专注云原生领域，容器集群和服务网格。

相关阅读

深入浅出Kubernetes 实践篇（一）：节点就绪问题之一

深入浅出Kubernetes 实践篇（二）：节点就绪问题之二

深入浅出Kubernetes 实践篇（三）：命名空间删除问题

深入浅出Kubernetes 实践篇（四）：集群安全组配置管理

深入浅出Kubernetes 实践篇（五）：二分之一活的微服务

创作场景

深入浅出 Kubernetes 实践篇 （六）：服务网格证书过期问题

深入浅出 Kubernetes 实践篇（六）：服务网格证书过期问题