Cloudflare 和 Kubernetes 对比｜附配置文件

在现代云原生架构中，Cloudflare 和 Kubernetes 都是非常常见的技术名词。很多团队在做网站加速、服务部署、负载均衡、安全防护、灰度发布、弹性伸缩时，都会接触到它们。但需要明确的是：Cloudflare 和 Kubernetes 并不是同一类产品，它们解决的问题也不完全相同。

简单来说：

• Cloudflare 更偏向于互联网入口层，主要提供 DNS、CDN、DDoS 防护、WAF、安全访问、边缘计算等能力；
• Kubernetes 更偏向于应用运行与编排层，主要用于容器化应用的部署、调度、扩缩容、服务发现、滚动更新等。

如果把一个互联网系统比作一座城市，那么 Kubernetes 更像是城市内部的建筑管理系统，负责安排每个服务运行在哪里、如何扩容、如何重启、如何互相通信；而 Cloudflare 则更像是城市外围的高速入口、安检系统、缓存节点和流量调度中心，负责让用户更快、更安全地访问这座城市。

本文将从定位、核心能力、使用场景、架构关系、优缺点以及配置示例等方面，对 Cloudflare 和 Kubernetes 进行系统对比，并附上常见配置文件，帮助你更清晰地理解二者的区别和协作方式。

一、Cloudflare 是什么？

Cloudflare 是一家提供全球网络服务的平台，最常见的能力包括：

• DNS 解析
• CDN 内容分发网络
• DDoS 防护
• Web Application Firewall，简称 WAF
• SSL/TLS 证书管理
• Zero Trust 安全访问
• Workers 边缘计算
• Tunnel 内网穿透
• Bot 管理
• 图片优化
• 缓存加速

对于普通网站来说，最常见的使用方式是：将域名托管到 Cloudflare，然后由 Cloudflare 作为用户访问网站的第一层入口。

例如用户访问：

https://www.example.com

请求流程可能是：

用户浏览器
   ↓
Cloudflare 边缘节点
   ↓
源站服务器 / Kubernetes Ingress / 负载均衡器
   ↓
后端应用服务

在这个过程中，Cloudflare 可以完成 HTTPS 终止、缓存静态资源、拦截恶意请求、隐藏源站 IP、抵御 DDoS 攻击、根据访问区域选择最近节点等工作。

二、Kubernetes 是什么？

Kubernetes，简称 K8s，是一个开源的容器编排平台，最初由 Google 开源，目前由 CNCF 维护。它的核心作用是管理容器化应用的生命周期。

Kubernetes 可以帮助团队解决以下问题：

• 应用如何部署？
• 多个副本如何调度到不同节点？
• 容器挂了如何自动重启？
• 服务如何发现彼此？
• 如何做滚动更新和回滚？
• 如何自动扩容？
• 配置和密钥如何管理？
• 如何暴露服务给外部访问？
• 如何管理存储卷？

在 Kubernetes 中，常见资源对象包括：

• Pod
• Deployment
• Service
• Ingress
• ConfigMap
• Secret
• StatefulSet
• DaemonSet
• Job
• CronJob
• HorizontalPodAutoscaler

一个典型 Kubernetes 应用访问流程可能是：

用户请求
   ↓
Ingress Controller
   ↓
Service
   ↓
Pod
   ↓
容器内应用

如果结合 Cloudflare，则访问链路可能变成：

用户请求
   ↓
Cloudflare CDN / WAF / DNS
   ↓
云厂商负载均衡器
   ↓
Kubernetes Ingress Controller
   ↓
Service
   ↓
Pod

三、Cloudflare 和 Kubernetes 的核心定位对比

从这个表可以看出，Cloudflare 和 Kubernetes 更多是互补关系，而不是竞争关系。

四、二者解决的问题不同

1. Cloudflare 解决的是“入口问题”

Cloudflare 主要解决的是用户访问应用之前的问题，例如：

• 用户访问哪个 IP？
• DNS 是否稳定？
• 静态资源是否可以就近访问？
• 是否能防止 DDoS 攻击？
• 是否能拦截 SQL 注入、XSS 等攻击？
• 是否可以自动签发 HTTPS 证书？
• 是否可以隐藏源站服务器地址？
• 是否可以根据国家、路径、请求头进行访问控制？

也就是说，Cloudflare 站在公网流量入口，关注的是请求到达源站之前的优化与防护。

2. Kubernetes 解决的是“运行问题”

Kubernetes 主要解决的是应用已经进入基础设施之后，如何稳定运行的问题，例如：

• 应用部署到哪台机器？
• 容器异常退出怎么办？
• 流量如何分发给多个 Pod？
• 新版本如何平滑发布？
• 配置如何注入？
• 服务如何扩缩容？
• 应用如何挂载存储？
• 节点故障时如何迁移工作负载？

Kubernetes 更关注的是应用自身运行状态与集群资源管理。

五、典型架构：Cloudflare + Kubernetes

在生产环境中，Cloudflare 和 Kubernetes 经常一起使用。下面是一个常见架构：

Internet 用户
   ↓
Cloudflare DNS / CDN / WAF / DDoS Protection
   ↓
云厂商 Load Balancer
   ↓
Kubernetes Ingress Controller，例如 NGINX Ingress
   ↓
Kubernetes Service
   ↓
Deployment 管理的 Pod
   ↓
业务容器

这个架构中，每一层的职责非常清晰：

这种方式能够同时获得 Cloudflare 的安全与加速能力，以及 Kubernetes 的弹性部署与容器编排能力。

六、Cloudflare 的优势与局限

Cloudflare 的优势

1. 全球 CDN 加速能力强

Cloudflare 在全球部署了大量边缘节点，可以将静态资源缓存到离用户更近的位置，减少访问延迟。对于面向全球用户的网站来说，效果非常明显。

2. 安全防护开箱即用

Cloudflare 提供 DDoS 防护、WAF、防机器人、速率限制等能力。很多防护能力只需要在控制台开启即可使用，不需要业务系统进行复杂改造。

3. DNS 管理方便

Cloudflare 的 DNS 服务速度快、稳定性高，并且支持代理模式。开启代理后，用户看到的是 Cloudflare 的 IP，而不是源站 IP，有利于隐藏真实服务器地址。

4. SSL/TLS 配置简单

Cloudflare 可以帮助网站快速启用 HTTPS，并支持多种加密模式，如 Flexible、Full、Full Strict。生产环境中更推荐使用 Full Strict。

5. 边缘能力丰富

Cloudflare Workers 可以在边缘节点执行 JavaScript 或 WebAssembly 逻辑，适合做轻量接口、请求重写、鉴权、A/B 测试、边缘聚合等。

Cloudflare 的局限

1. 不负责应用编排

Cloudflare 并不能像 Kubernetes 一样管理容器、调度 Pod、做滚动更新或处理容器重启。它更多是入口与边缘网络平台。

2. 对动态业务加速有限

CDN 对静态内容效果最好。对于高度个性化、不可缓存的动态接口，Cloudflare 仍然可以提供网络优化和安全防护，但加速效果不如静态资源明显。

3. 部分高级能力需要付费

WAF 高级规则、Bot 管理、企业级 DDoS 防护、日志分析等功能通常需要更高套餐。

七、Kubernetes 的优势与局限

Kubernetes 的优势

1. 标准化应用部署

Kubernetes 使用声明式 YAML 配置描述应用状态，适合做基础设施即代码。团队可以将配置文件纳入 Git 管理，实现 GitOps。

2. 强大的自愈能力

当 Pod 崩溃时，Kubernetes 可以自动重启；当节点故障时，可以将应用调度到其他可用节点，提高系统可用性。

3. 易于扩缩容

Kubernetes 支持手动扩容和自动扩容。通过 HorizontalPodAutoscaler，可以根据 CPU、内存或自定义指标调整副本数。

4. 滚动更新和回滚

Deployment 支持滚动发布，可以逐步替换旧版本 Pod，降低发布风险。如果新版本有问题，也可以回滚到之前版本。

5. 生态系统强大

Kubernetes 拥有丰富生态，包括 Helm、Argo CD、Prometheus、Grafana、Istio、Linkerd、cert-manager、ExternalDNS 等。

Kubernetes 的局限

1. 学习和维护成本较高

Kubernetes 概念较多，涉及网络、存储、安全、调度、监控等多个领域。对于小团队来说，直接维护一套集群可能成本偏高。

2. 不自带全球 CDN

Kubernetes 可以暴露服务，但它本身不提供全球 CDN 加速能力。如果要面向全球用户优化访问，仍然需要 Cloudflare、Akamai、Fastly 或云厂商 CDN。

3. 安全能力需要组合实现

Kubernetes 本身提供 RBAC、NetworkPolicy、Secret 等安全能力，但公网 WAF、DDoS 防护、Bot 管理等通常需要借助外部服务或网关产品。

八、配置文件示例一：Cloudflare DNS 配置说明

Cloudflare 的 DNS 通常在控制台中配置，也可以通过 Terraform 管理。下面是一个使用 Terraform 配置 Cloudflare DNS 记录的示例。

Terraform 配置 Cloudflare DNS

terraform {
  required_providers {
    cloudflare = {
      source  = "cloudflare/cloudflare"
      version = "~> 4.0"
    }
  }
}

provider "cloudflare" {
  api_token = var.cloudflare_api_token
}

variable "cloudflare_api_token" {
  type      = string
  sensitive = true
}

variable "zone_id" {
  type = string
}

resource "cloudflare_record" "www" {
  zone_id = var.zone_id
  name    = "www"
  type    = "CNAME"
  value   = "example-lb.examplecloud.com"
  proxied = true
  ttl     = 1
}

resource "cloudflare_record" "api" {
  zone_id = var.zone_id
  name    = "api"
  type    = "CNAME"
  value   = "example-lb.examplecloud.com"
  proxied = true
  ttl     = 1
}

说明：

• proxied = true 表示开启 Cloudflare 代理，也就是橙色云朵模式；
• ttl = 1 表示使用 Cloudflare 自动 TTL；
• value 可以指向云厂商负载均衡器地址；
• www.example.com 和 api.example.com 都可以转发到 Kubernetes Ingress 入口。

九、配置文件示例二：Cloudflare 页面规则配置思路

Cloudflare 的 Page Rules 或 Ruleset 可以用于缓存、重定向、HTTPS 强制跳转等。以下是逻辑示例。

规则名称：Cache Static Assets

匹配条件：
https://www.example.com/static/*

执行动作：
Cache Level: Cache Everything
Edge Cache TTL: 1 month
Browser Cache TTL: 1 day

再比如强制 HTTPS：

规则名称：Always Use HTTPS

匹配条件：
http://*example.com/*

执行动作：
Always Use HTTPS: On

实际生产中，如果使用的是新版本 Cloudflare Rules，建议优先使用：

• Redirect Rules
• Cache Rules
• Configuration Rules
• WAF Custom Rules

十、配置文件示例三：Kubernetes Deployment

下面是一个简单的 Kubernetes Deployment，用于部署一个 Nginx Web 服务。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-demo
  namespace: default
  labels:
    app: web-demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-demo
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  template:
    metadata:
      labels:
        app: web-demo
    spec:
      containers:
        - name: nginx
          image: nginx:1.25
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 5
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 15
            periodSeconds: 20

这个配置文件定义了：

• 部署名称为 web-demo；
• 副本数量为 3；
• 使用 nginx:1.25 镜像；
• 配置 CPU 和内存限制；
• 配置就绪探针和存活探针；
• 使用滚动更新策略。

十一、配置文件示例四：Kubernetes Service

Deployment 创建的 Pod IP 是动态变化的，因此需要 Service 提供稳定访问入口。

apiVersion: v1
kind: Service
metadata:
  name: web-demo-service
  namespace: default
spec:
  type: ClusterIP
  selector:
    app: web-demo
  ports:
    - name: http
      port: 80
      targetPort: 80

说明：

• type: ClusterIP 表示服务只在集群内部访问；
• selector 会选择带有 app: web-demo 标签的 Pod；
• port 是 Service 暴露的端口；
• targetPort 是容器内监听的端口。

十二、配置文件示例五：Kubernetes Ingress

如果要让外部用户通过域名访问 Kubernetes 内的服务，可以使用 Ingress。

以下示例基于 NGINX Ingress Controller：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-demo-ingress
  namespace: default
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/proxy-body-size: "20m"
spec:
  tls:
    - hosts:
        - www.example.com
      secretName: example-com-tls
  rules:
    - host: www.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-demo-service
                port:
                  number: 80

该配置表示：

• 访问 www.example.com 的请求会转发到 web-demo-service；
• 开启 HTTPS；
• TLS 证书存储在 example-com-tls 这个 Secret 中；
• 如果前面接 Cloudflare，Cloudflare 的 DNS 记录可以指向 Ingress Controller 对应的公网负载均衡器。

十三、配置文件示例六：使用 cert-manager 自动签发证书

如果 Cloudflare SSL 模式使用 Full Strict，源站也必须配置有效证书。Kubernetes 中常用 cert-manager 自动申请 Let’s Encrypt 证书。

ClusterIssuer 示例

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-http01
spec:
  acme:
    email: admin@example.com
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: letsencrypt-http01-account-key
    solvers:
      - http01:
          ingress:
            class: nginx

Certificate 示例

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: example-com-tls
  namespace: default
spec:
  secretName: example-com-tls
  issuerRef:
    name: letsencrypt-http01
    kind: ClusterIssuer
  dnsNames:
    - www.example.com

需要注意的是，如果 Cloudflare 开启代理模式，HTTP-01 校验有时会受到代理和重定向规则影响。更稳妥的方式是使用 DNS-01 校验，并通过 Cloudflare API 自动添加 TXT 记录。

十四、配置文件示例七：使用 Cloudflare API Token 做 DNS-01 校验

下面是 cert-manager 使用 Cloudflare DNS-01 校验的示例。

Cloudflare API Token Secret

apiVersion: v1
kind: Secret
metadata:
  name: cloudflare-api-token-secret
  namespace: cert-manager
type: Opaque
stringData:
  api-token: "YOUR_CLOUDFLARE_API_TOKEN"

生产环境中不要将真实 Token 明文提交到 Git 仓库，建议使用 Sealed Secrets、External Secrets 或云厂商密钥管理服务。

ClusterIssuer DNS-01 示例

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-cloudflare
spec:
  acme:
    email: admin@example.com
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: letsencrypt-cloudflare-account-key
    solvers:
      - dns01:
          cloudflare:
            apiTokenSecretRef:
              name: cloudflare-api-token-secret
              key: api-token

Certificate 示例

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: example-com-tls
  namespace: default
spec:
  secretName: example-com-tls
  issuerRef:
    name: letsencrypt-cloudflare
    kind: ClusterIssuer
  dnsNames:
    - example.com
    - "*.example.com"

使用 DNS-01 的好处是可以签发泛域名证书，例如 *.example.com，同时不依赖外部 HTTP 路径访问。

十五、Cloudflare 与 Kubernetes 如何分工？

在实际项目中，一个合理的分工方式如下：

Cloudflare 负责

• 域名 DNS 托管
• CDN 缓存
• 静态资源加速
• HTTPS 边缘证书
• DDoS 防护
• WAF 规则
• IP 黑白名单
• 访问地区限制
• Bot 防护
• Zero Trust 访问控制
• 边缘重定向和缓存规则

Kubernetes 负责

• 应用容器运行
• 服务副本管理
• 应用发布和回滚
• 服务发现
• 内部负载均衡
• 配置管理
• Secret 管理
• 自动扩缩容
• 日志采集与监控接入
• 持久化存储挂载
• 内部网络策略

这样的分工可以避免职责混乱，也有利于排查问题。例如：

• 如果用户无法解析域名，优先检查 Cloudflare DNS；
• 如果请求被 403 拦截，检查 Cloudflare WAF 或 Ingress 鉴权；
• 如果请求能到 Ingress 但后端 502，检查 Kubernetes Service 和 Pod；
• 如果 Pod 不健康，检查 Deployment、镜像、探针和应用日志。

十六、常见组合实践建议

1. Cloudflare SSL 推荐使用 Full Strict

Cloudflare SSL 有多种模式，生产环境建议使用：

Full Strict

原因是 Full Strict 会校验源站证书，避免 Cloudflare 到源站之间出现不安全连接。

不建议长期使用 Flexible，因为 Flexible 只保证用户到 Cloudflare 是 HTTPS，而 Cloudflare 到源站可能是 HTTP，容易造成安全隐患和重定向循环。

2. 源站只允许 Cloudflare IP 访问

为了避免攻击者绕过 Cloudflare 直接攻击源站，可以在云防火墙或 Kubernetes Ingress 前的负载均衡器上限制访问来源，只允许 Cloudflare IP 段。

Cloudflare 官方会公开 IP 列表，生产环境可以定期同步。

3. 静态资源尽量走 CDN 缓存

例如：

/static/*
/assets/*
/images/*
/css/*
/js/*

这些路径适合设置较长缓存时间，以降低源站压力。

4. 动态接口谨慎缓存

例如：

/api/user
/api/order
/api/profile

这类接口通常包含用户个性化数据，不应随意缓存，否则可能造成数据错乱或安全问题。

5. Kubernetes Ingress 保持清晰路由

Ingress 规则不宜过度复杂。复杂的安全策略、缓存策略、Bot 防护等可以放在 Cloudflare；Kubernetes Ingress 更适合做域名、路径到服务的转发。

十七、如何选择：只用 Cloudflare、只用 Kubernetes，还是二者结合？

适合只用 Cloudflare 的场景

如果你的网站是静态站点、博客、文档站，或者使用 SaaS 平台托管，那么可能只需要 Cloudflare：

• 静态网站托管
• 个人博客
• 公司官网
• 文档站点
• 图片资源加速
• 简单的边缘函数逻辑

此时 Kubernetes 可能过于复杂。

适合只用 Kubernetes 的场景

如果你的系统只运行在内网，或者不面向公网用户，可能不需要 Cloudflare：

• 企业内部系统
• 内网微服务
• 数据处理任务
• 私有化部署环境
• 离线计算任务

此时 Kubernetes 的部署、调度和资源管理能力更重要。

适合 Cloudflare + Kubernetes 的场景

大多数中大型互联网应用都适合二者结合：

• 面向公网的 Web 应用
• SaaS 平台
• 电商系统
• API 服务
• 全球化业务
• 需要 DDoS 防护的网站
• 需要高可用和弹性扩缩容的系统
• 微服务架构系统

这种组合既能保证外部访问安全和快速，又能保证内部应用运行稳定和可扩展。

十八、总结

Cloudflare 和 Kubernetes 经常出现在同一个技术架构中，但它们并不是同类工具。

Cloudflare 的核心价值在于网络入口、安全防护和边缘加速。它帮助应用在用户访问之前完成 DNS 解析、CDN 缓存、DDoS 防护、WAF 拦截、HTTPS 加密和边缘规则处理。

Kubernetes 的核心价值在于容器编排和应用运行管理。它帮助团队标准化部署应用、管理服务副本、实现滚动更新、自愈、服务发现、自动扩缩容和配置管理。

如果你的系统面向公网用户，尤其是访问量较大、对安全和性能有要求，那么比较推荐采用：

Cloudflare + 云负载均衡器 + Kubernetes Ingress + Service + Pod

这样的组合架构。

最终可以用一句话概括：

Cloudflare 管好“流量如何安全快速地进来”，Kubernetes 管好“应用如何稳定弹性地运行”。

二者不是替代关系，而是现代云原生架构中非常典型的互补组合。合理使用 Cloudflare 和 Kubernetes，可以显著提升系统的访问性能、安全能力、发布效率和整体稳定性。