Sealos私有化部署避坑指南：从证书配置到浏览器信任的全流程解析

Sealos私有化部署避坑指南：从证书配置到浏览器信任的全流程解析

如果你正在考虑将Sealos云操作系统部署到自己的数据中心，那么恭喜你，你选择了一条既能获得公有云便利性又能完全掌控数据安全的道路。不过，私有化部署这条路并不总是平坦的，尤其是在证书配置和浏览器信任这个环节，很多有经验的运维工程师也会在这里栽跟头。我自己在多个企业级项目中部署Sealos时，就遇到过各种稀奇古怪的证书问题——从Chrome的红色警告到Safari的静默拒绝，再到Firefox的固执己见，每个浏览器都有自己独特的“脾气”。

这篇文章不是简单的操作手册，而是基于真实踩坑经验的深度解析。我会带你深入理解Sealos私有化部署中最棘手的证书信任问题，结合Chrome、Firefox、Safari三大浏览器的实操案例，提供内网域名+自签名证书场景的完整解决方案。无论你是想用nip.io这样的便捷服务，还是需要配置cert-manager进行自动化证书管理，这里都有你需要的答案。

1. 理解Sealos私有化部署的证书架构

在开始实际操作之前，我们需要先搞清楚Sealos在私有化部署时是如何处理证书的。很多人在这个环节犯的第一个错误就是没有理解整个证书链的运作机制，导致后续问题排查时一头雾水。

1.1 Sealos的证书管理策略

Sealos在设计上提供了两种主要的证书管理方式：

1. 自签名证书（默认方式） - 当你不提供外部证书时，Sealos会通过cert-manager自动生成自签名证书
2. 外部证书导入 - 你可以提供自己的商业证书或Let's Encrypt证书

这两种方式的核心区别在于信任链的建立。自签名证书最大的问题不是安全性，而是浏览器不信任。浏览器厂商维护着一个受信任的根证书颁发机构列表，自签名证书不在这个列表里，所以浏览器会显示警告。

注意：自签名证书在加密强度上并不比商业证书差，它们使用相同的加密算法。区别仅在于信任关系的建立方式。

1.2 证书域名的匹配规则

无论选择哪种证书方式，都需要确保证书能够正确匹配你的访问域名。Sealos要求证书支持两个域名模式：

• 主域名（如 cloud.yourcompany.com）
• 通配符子域名（如 *.cloud.yourcompany.com）

这个要求源于Sealos的多租户架构。每个用户的应用都会分配一个独立的子域名，所以通配符证书是必须的。如果你只配置了主域名证书，虽然能访问控制台，但应用页面会无法加载。

下面是一个证书域名配置的对比表格：

1.3 cert-manager的工作原理

当你不提供外部证书时，Sealos会调用cert-manager来管理证书生命周期。cert-manager是Kubernetes生态中事实上的证书管理标准，它的工作流程大致如下：

# cert-manager创建的Certificate资源示例
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: sealos-cert
  namespace: sealos-system
spec:
  secretName: sealos-tls-secret
  duration: 2160h # 90天
  renewBefore: 360h # 15天
  commonName: cloud.example.com
  dnsNames:
  - cloud.example.com
  - "*.cloud.example.com"
  issuerRef:
    name: sealos-selfsigned-issuer
    kind: ClusterIssuer

cert-manager会创建一个自签名的ClusterIssuer，然后基于这个Issuer为你的域名生成证书。这个证书会被存储在Kubernetes的Secret中，然后被ingress-nginx等组件使用。

2. 内网域名方案选择与配置

私有化部署最常见的使用场景是在内网环境中。这时候域名解析就成了第一个需要解决的问题。很多人在这里会选择修改每台客户机的hosts文件，但这在规模稍大的环境中几乎不可维护。

2.1 nip.io：最简单快速的内网域名方案

nip.io是我个人最推荐的内网测试和开发环境解决方案。它的工作原理极其简单：任何格式为 [任意内容].[IP地址].nip.io 的域名都会被解析到中间的IP地址。

比如你的Sealos Master节点IP是 192.168.1.100，那么：

• 192.168.1.100.nip.io → 解析到 192.168.1.100
• myapp.192.168.1.100.nip.io → 解析到 192.168.1.100
• anything.you.want.192.168.1.100.nip.io → 解析到 192.168.1.100

在Sealos安装时使用nip.io非常简单：

# 使用nip.io域名的安装命令
curl -sfL https://mirror.ghproxy.com/https://raw.githubusercontent.com/labring/sealos/main/scripts/cloud/install.sh -o /tmp/install.sh && bash /tmp/install.sh \
  --image-registry=registry.cn-shanghai.aliyuncs.com \
  --zh \
  --proxy-prefix=https://mirror.ghproxy.com

当脚本询问域名时，输入 192.168.1.100.nip.io 即可。安装完成后，你不仅能用这个域名访问控制台，所有应用也会自动获得 *.192.168.1.100.nip.io 的子域名。

提示：nip.io虽然方便，但不适合生产环境。它的解析完全依赖外部服务，如果nip.io服务不可用，你的内网服务也会受影响。

2.2 自建内网DNS：生产环境的最佳实践

对于生产环境，我强烈建议搭建内网DNS服务。这样既能保证稳定性，又能使用自定义的域名。CoreDNS是目前最流行的选择，它配置简单、性能出色，而且原生支持Kubernetes。

下面是一个针对Sealos的CoreDNS配置示例：

# CoreDNS的Corefile配置
.:53 {
    errors
    health
    ready
    
    # 缓存设置，提升性能
    cache {
        success 65536 3600 300
        denial 8192 600 60
        prefetch 1 60m 10%
    }
    
    # 为Sealos域名设置静态解析
    template IN A sealos.internal.com {
        answer "{
  
  { .Name }} 60 IN A 192.168.1.100"
        fallthrough
    }
    
    template IN A *.sealos.internal.com {
        answer "{