如何在AKS/GKE/EKS托管Kubernetes服务上部署Varnish集群？

通用前置准备（三云通用） #

• 为Varnish规划独立节点池：选择计算优化型实例规格（AWS c系列、Azure F系列、GCP c2系列），给节点池打污点varnish=node:NoSchedule，避免其他业务Pod抢占资源；节点池开启自动扩缩容，最小节点数与Varnish保底副本数对齐。
• 提前安装集群基础组件：部署NGINX Ingress Controller，不推荐直接用云厂商自带七层负载对接Varnish，流量策略调整灵活度不足；安装Metrics Server，为后续扩缩容提供基础指标采集能力。

核心部署流程 #

1. 写入Varnish核心配置 #

将自定义VCL规则存入ConfigMap，挂载时用subPath方式挂载到容器内VCL路径，避免覆盖容器内其他配置文件导致启动失败。基础配置示例如下：

apiVersion: v1
kind: ConfigMap
metadata:
  name: varnish-vcl
data:
  default.vcl: |
    vcl 4.1;
    backend default {
        .host = "替换为你的业务Service集群内地址";
        .port = "业务端口";
        .probe = {
            .url = "/业务健康检查路径";
            .interval = 5s;
            .timeout = 1s;
            .window = 3;
            .threshold = 2;
        }
    }
    # 按需补充缓存规则、IP ACL、缓存 purging 逻辑

2. 部署Varnish工作负载 #

优先选用StatefulSet而非Deployment部署，稳定的Pod网络标识更方便后续做副本间缓存同步、本地缓存挂载，初始副本数设为2即可。
容器启动参数重点配置缓存容量：-s malloc,容量值，容量按节点可用内存的70%设置，避免OOM；暴露80（代理端口）、6082（管理端口，禁止对公网暴露）；资源request与limit设为相同值，避免资源抢占；配置节点亲和性与污点容忍，确保Pod调度到专属Varnish节点池。

三云存储配置差异提示：

• EKS：如需挂载本地SSD做缓存盘，选用EBS gp3或实例本地存储，对应StorageClass开启WaitForFirstConsumer卷绑定模式
• GKE：使用Local SSD做缓存的场景，创建节点池时提前勾选本地SSD挂载选项，对应StorageClass选用local-ssd
• AKS：非持久化缓存场景可选用节点本地临时盘，持久化缓存场景选用azurefile-csi-premium存储类

3. 配置流量入口 #

不要给单个Varnish Pod直接绑定公网IP，先创建内部TCP类型LoadBalancer Service（三云分别对应Azure内部LB、GKE内部TCP LB、EKS内部NLB），将流量转发到Varnish的80端口；上层再接云厂商全局流量分发服务（Azure Front Door、GCP Cloud LB、AWS CloudFront）或NGINX Ingress，做跨可用区流量负载。
如果需要解决多副本缓存不一致问题，无需部署复杂的集群发现组件，在自定义VCL中引入varnish-modules的broadcast模块，基于StatefulSet的固定DNS规则拼接所有副本地址，PURGE请求触发时广播到所有副本即可。

4. 配置自动扩缩容 #

不要仅依赖CPU、内存指标触发扩缩容，Varnish的核心瓶颈指标为单副本QPS、请求队列长度、缓存命中率。给每个Varnish Pod旁挂varnish_exporter采集运行指标，接入集群Prometheus后配置HPA规则：单副本QPS超过预设阈值（通常单Varnish实例可承载1-1.5万QPS，按实际业务压测结果调整）、缓存命中率低于90%时触发扩容；缩容冷却时间调整为15分钟以上，避免频繁缩容导致缓存冷启动、回源流量突增。

三云扩缩容注意点：

• GKE节点池开启快速扩容模式，避免流量突增时节点供给不及时
• EKS Varnish节点池配置预置实例，做好节点预热
• AKS提前确认节点池计算资源配额，开启突发扩容能力

入门阶段常见踩坑规避 #

• 不要直接用公共仓库的默认Varnish镜像上生产，提前基于官方基础镜像编译业务需要的扩展模块（广播清缓存、IP限流、WAF规则等），默认镜像功能不全。
• 必须配置网络策略限制6082管理端口的访问来源，仅允许运维网段、集群内管控Pod访问，避免被恶意发送PURGE请求清空全量缓存。
• 上线初期先切10%流量到Varnish集群，观察缓存命中率、后端回源压力，等命中率稳定在90%以上再逐步切全量，避免一开始全量上线导致回源打垮后端服务。
• HTTPS卸载放到上层全局LB或Ingress层处理，Varnish仅处理HTTP明文流量，可最大程度降低性能损耗。
• 可直接用官方维护的Varnish Helm Chart部署，不用从零编写所有YAML，部署时覆写节点调度、VCL配置、资源限制等自定义参数即可，不要直接用默认配置上线。
• 缓存规则按资源类型分层配置，静态资源设置长缓存时长，带用户登录态的动态接口直接配置pass规则不缓存，避免缓存用户敏感信息。

内容的提问来源于stack exchange，提问作者tim kelly