面向多域名NGINX站点的K8s集群部署方案选型咨询

阿华AIGC实验室

2026-5-12

适配数千站点的K8s NGINX部署方案分析

针对你这种数千个独立域名站点的K8s部署需求，咱们先拆解现有两个场景的适配性，再聊聊更贴合实际的替代思路：

一、现有场景的优劣势复盘

场景1：每个站点独立Namespace+Service+Deployment

适配性亮点：完全的Pod级隔离，单个站点的故障、资源波动不会影响其他站点，扩容缩容也能针对单个站点精细化调整，适合对隔离性要求极高的场景。
致命短板：数千个站点意味着要创建数千套Service、Deployment、Namespace，这会给K8s API Server带来极大的压力（资源对象数量爆炸），同时运维成本直线上升——批量更新、监控告警、故障排查都要处理海量资源，而且每个Pod哪怕只分配极小的CPU/内存配额，总资源开销也会非常不划算。

场景2：单Pod承载所有虚拟主机

适配性亮点：资源占用极低，仅需一套Service和Deployment，无状态Pod扩容简单。
致命短板：新增站点时需要修改共享ConfigMap/Secret，然后手动（或半自动化）重载所有Pod里的NGINX，这个操作在数千站点规模下风险极高——一次重载失败可能导致所有站点不可用，而且配置冲突、权限问题很容易引发全局故障，隔离性几乎为零。

二、更适配的替代方案

1. 基于NGINX Ingress Controller的多租户方案（首推）

这是目前最适合大规模虚拟主机场景的方案，核心思路是让Ingress Controller承担虚拟主机路由和SSL终止的核心工作，共享一套NGINX服务处理所有站点内容：

只需要部署一套NGINX Deployment和Service，用来挂载所有站点的静态内容（比如用PVC或共享存储，每个站点对应一个子目录，如/var/www/html/example.com）。
每个站点仅需创建3类资源：
- Ingress：定义虚拟主机规则、SSL配置，通过注解指定该站点的根目录（比如nginx.ingress.kubernetes.io/root-path: /var/www/html/example.com）。
- Secret：存储该站点的SSL证书。
- PersistentVolumeClaim：绑定该站点的内容存储（如果是静态内容，也可以用ConfigMap挂载，但PVC更适合大文件场景）。
优势：
- 资源开销极低：每个站点仅3个轻量资源对象，API Server压力小。
- 运维简单：新增站点只需创建上述3类资源，Ingress Controller会自动更新NGINX配置，无需手动重载Pod。
- 隔离性可控：Ingress的路由规则天然实现流量隔离，单个站点的配置错误只会影响自身。
- 扩容灵活：可以通过扩容Ingress Controller或共享NGINX Deployment来承载更高流量。

示例Ingress配置：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: site-example-com
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/root-path: /var/www/html/example.com
spec:
  tls:
  - hosts:
    - example.com
    secretName: example-com-tls
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: shared-nginx-service
            port:
              number: 80

2. 自定义Operator实现自动化管理

如果站点数量持续增长到上万级，手动创建Ingress/Secret/PVC会变得繁琐，可以通过K8s Operator+自定义CRD来自动化：

定义一个自定义资源Website，包含域名、SSL证书路径、内容存储路径等字段。
Operator监听Website资源的创建/更新/删除事件，自动生成对应的Ingress、Secret、PVC资源。
优势：进一步降低运维成本，只需提交Website资源即可完成站点部署，适合超大规模的自动化运维场景。

3. 带自动重载的共享NGINX方案（次选）

如果不想依赖Ingress Controller的虚拟主机能力，可以优化场景2：

用ConfigMap存储所有站点的NGINX配置文件（每个站点一个.conf文件，挂载到NGINX的conf.d目录），用Secret存储所有SSL证书。
给NGINX Pod添加一个Sidecar容器（比如jimmidyson/configmap-reload），监听ConfigMap/Secret的变化，自动触发nginx -s reload。
优势：保留了单Deployment的低资源开销，同时实现配置变更的自动重载；劣势是隔离性仍较弱，配置冲突可能影响全局。