OrbStack项目中Kubernetes Ingress TLS证书验证问题解析

在OrbStack 1.9.4版本中，用户在使用Kubernetes集群时遇到了一个典型的TLS证书验证问题。当从集群内部的Pod访问配置了TLS的Ingress资源时，系统会报告证书无效的错误，而有趣的是，同样的Ingress通过主机访问却能正常工作。

问题现象

当用户通过集群内部的Pod（例如使用alpine/curl镜像创建的容器）访问Ingress端点时，会收到如下错误提示：

curl: (60) SSL peer certificate or SSH remote key was not OK

更详细的错误信息表明：

x509: certificate is valid for ingress.local, not test-node.console.k8s.orb.local

技术背景分析

这个问题涉及到Kubernetes Ingress控制器和TLS证书的几个关键概念：

1. Ingress TLS配置：在Kubernetes中，Ingress资源可以通过TLS配置来提供HTTPS服务。通常需要指定包含有效证书的Secret。

2. 证书SAN（主题备用名称）：X.509证书会明确指定其有效的域名范围。当客户端访问的域名不在证书的SAN列表中时，就会触发验证失败。

3. OrbStack的特殊处理：OrbStack作为本地开发环境，可能对Ingress证书有特殊的自动生成机制。

问题根源

从错误信息可以明确看出：

• 证书是为"ingress.local"签发的
• 但客户端尝试访问的是"*.k8s.orb.local"域名
• 这种域名不匹配导致TLS握手失败

这种情况通常发生在：

1. Ingress控制器自动生成了默认证书
2. 但生成的证书没有包含实际使用的域名
3. 或者域名解析配置与证书配置不一致

解决方案

根据项目方的反馈，此问题已在OrbStack 1.9.5版本中修复。对于遇到类似问题的用户，可以考虑以下解决方案：

1. 升级到最新版本：这是最直接的解决方法。

2. 手动配置证书：

   • 创建包含正确SAN的TLS证书
   • 通过Kubernetes Secret提供给Ingress使用

3. 检查域名解析：

   • 确保集群内外的DNS解析一致
   • 验证CoreDNS或kube-dns的配置

经验总结

这个案例展示了开发环境中常见的一个TLS配置陷阱。对于本地开发环境来说，自动生成的证书虽然方便，但可能会因为域名配置不一致而导致各种连接问题。开发者在设计这类系统时需要注意：

1. 自动生成的证书应该覆盖所有可能的访问域名
2. 内部和外部访问的域名解析应该保持一致
3. 错误信息应该足够明确，帮助用户快速定位问题

OrbStack团队通过版本更新的方式快速解决了这个问题，体现了对开发者体验的重视。对于使用类似工具的用户来说，保持工具的最新版本是避免已知问题的有效方法。