1. 项目概述为什么我们需要关注Cloudflare的Helm Charts如果你在Kubernetes上跑过生产应用大概率遇到过同一个问题如何把外部流量安全、高效、稳定地引入集群内部传统的做法可能是自己部署一个Ingress Controller比如Nginx Ingress然后手动配置SSL证书、防火墙规则、负载均衡策略甚至还要考虑DDoS防护和全球加速。这套流程下来运维成本不低而且一旦流量规模上去性能调优和安全防护就成了头疼的事。这时候Cloudflare这个全球化的网络服务商就进入了视野。它不只是一个CDN更是一个集安全、性能、可靠性于一体的边缘网络平台。而cloudflare/helm-charts这个项目就是官方提供的、用Helm这个Kubernetes包管理器来一键式部署和管理Cloudflare各种服务的工具集。简单说它让你能用几行命令就把Cloudflare强大的边缘能力“注入”到你的K8s集群里。这个仓库的价值远不止是“方便部署”。它代表了一种云原生时代的基础设施管理范式将外部SaaS服务如Cloudflare的配置通过声明式的Helm Chart进行版本化、代码化管理。无论是为内部服务配置Argo Tunnel实现零信任安全访问还是用Cloudflare Pages来托管前端应用或是通过Workers处理边缘逻辑你都可以在熟悉的K8s YAML和Helm Values文件中完成定义。这极大地统一了技术栈降低了上下文切换成本让开发和运维的边界变得更清晰。2. 核心组件与功能深度解析cloudflare/helm-charts仓库不是一个单一的Chart而是一个包含了多个独立Chart的集合。每个Chart对应Cloudflare产品线中的一个核心服务旨在解决Kubernetes环境下的特定场景问题。理解每个Chart的定位是正确使用它们的前提。2.1cloudflare-tunnelChart零信任网络访问的K8s化实践这是仓库里最常用、也最核心的Chart之一。它用于部署和管理cloudflared守护进程也就是Cloudflare Tunnel的客户端。核心原理传统上要让外部访问K8s服务你需要开放节点的端口或使用LoadBalancer Service这暴露了你的集群入口。Cloudflare Tunnel反其道而行之它在你的集群内部运行一个轻量级守护进程cloudflared这个进程会主动与Cloudflare的边缘网络建立出站连接创建一个安全的、加密的隧道。外部流量通过Cloudflare的网络到达边缘节点后再通过这个隧道被安全地转发到集群内部指定的服务全程无需在防火墙上开放任何入站端口。Chart的核心能力守护进程集DaemonSet部署默认以DaemonSet方式部署确保集群的每个节点或指定节点上都有一个cloudflared实例提供高可用性。你也可以根据需求改为Deployment。配置即代码通过Helm Values你可以直接定义Tunnel的凭证Token或JSON文件、要代理的本地服务ingress规则、甚至Tunnel本身的元数据如名称、标签。这取代了手动运行cloudflared tunnel create和cloudflared tunnel route等命令的繁琐过程。高可用与负载均衡当以DaemonSet模式部署时多个cloudflared实例可以同时为同一个Tunnel服务Cloudflare边缘会自动在这些实例间进行负载均衡和健康检查单个节点故障不影响整体服务。Secret管理集成敏感信息如Tunnel Token可以通过Kubernetes Secret注入Chart提供了完善的模板支持避免了在Values文件中硬编码密钥。注意使用Tunnel Token是最佳实践。Token包含了Tunnel的授权信息比使用证书文件更安全且易于轮换。在Cloudflare Zero Trust面板中创建Tunnel时选择“使用配置文件”方式即可获得这个Token。2.2pagesChart在K8s里管理Cloudflare Pages项目这个Chart可能让人有点意外Cloudflare Pages本身是一个托管平台为什么还需要在K8s里部署它的核心场景是管理Pages项目的构建和部署流程。工作原理这个Chart会在你的K8s集群中部署一个控制器Controller该控制器监听特定的Kubernetes资源比如一个自定义资源PagesProject。当你通过Kubectl或GitOps工具如ArgoCD声明一个Pages项目指定Git仓库、构建命令、输出目录等时这个控制器会与Cloudflare API通信触发对应Pages项目的构建和部署。它把Pages的CI/CD流程纳入了K8s的统一编排体系。适用场景内部平台团队为业务部门提供自助式的静态站点/前端应用部署能力无需让他们直接操作Cloudflare控制台。GitOps流水线将前端项目的发布定义为K8s资源与后端微服务的Helm Release一起通过ArgoCD进行同步和回滚实现全栈应用的统一发布管理。环境隔离通过K8s的命名空间Namespace轻松管理开发、预发、生产等不同环境的Pages项目。2.3workerChart将Cloudflare Workers部署流程容器化类似于Pages Chart这个Chart用于管理Cloudflare Workers无服务器函数的生命周期。它提供了一个在K8s环境中打包和部署Worker代码的标准化方式。核心流程Chart会创建一个包含wranglerCloudflare Workers CLI工具和你的Worker代码的容器镜像。通过Kubernetes Job或CronJob这个镜像被运行执行wrangler publish命令将代码部署到Cloudflare边缘网络。你可以将Worker的配置wrangler.toml和代码一起打包并通过ConfigMap或Secret管理环境变量。优势版本与回滚Worker的每次发布都对应一个特定的容器镜像Tag和一次K8s Job执行与你的容器镜像仓库和K8s部署历史集成回滚只需指向旧的镜像即可。安全合规在私有网络中构建Worker代码避免代码上传到外部CI/CD平台可能带来的安全顾虑。构建所需的所有依赖和密钥都封装在K8s环境中。统一调度可以将Worker的部署作为应用发布流水线中的一个步骤或者使用CronJob定时触发特定Worker的更新。2.4 其他Chart与未来扩展仓库中还可能包含或未来会加入其他Chart例如用于管理Access策略、Gateway设置或Stream资源的Chart。其设计哲学是清晰的为每一个可以通过API管理的、有状态的Cloudflare服务或客户端提供一个对应的、云原生友好的Helm Chart。3. 实战部署以cloudflare-tunnel为例的完整操作指南理论讲完我们上手实操。这里以部署一个Tunnel将K8s内部的Web服务安全暴露到公网为例展示从零到一的完整过程。3.1 前期准备与依赖确认在运行Helm命令之前需要确保以下环境就绪Kubernetes集群一个可用的集群Minikube Kind 或任何云厂商的托管集群均可。具备kubectl命令行工具和集群访问权限。Helm 3已安装Helm 3客户端。可以通过helm version确认。Cloudflare账户拥有一个Cloudflare账户并且已将你的域名例如example.com添加到Cloudflare进行托管即NS记录已指向Cloudflare。Cloudflare API凭证为了创建和管理Tunnel需要生成API Token。登录Cloudflare控制台进入“我的个人资料” - “API令牌”。点击“创建令牌”选择“编辑区域 DNS”模板然后根据需求调整权限至少需要包含Zone:Read和DNS:Edit。为安全起见建议将权限范围限定在特定的域名Zone。将生成的Token妥善保存我们下一步会用到。3.2 创建Tunnel并获取关键凭证我们不在集群内直接创建Tunnel而是先在Cloudflare控制台创建获取连接凭证。登录Cloudflare Zero Trust控制台或从主控制台导航至Zero Trust。进入“访问” - “隧道”点击“创建隧道”。输入一个隧道名称例如my-k8s-tunnel点击“保存隧道”。在连接器页面选择“Docker”作为环境因为K8s部署方式与Docker类似。Cloudflare会生成一个长长的命令其中包含一个--token参数。我们需要的正是这个Token。复制整个Token字符串以eyJ...开头的一长串字符。重要实操心得这个Token是Tunnel的身份凭证拥有它就能将实例接入这个Tunnel。切勿泄露。我们不会在任何命令行中明文使用它而是通过K8s Secret注入。3.3 在K8s中创建Secret存储凭证将Token存入Kubernetes Secret供Helm Chart使用。假设我们将Chart安装在名为cloudflare的命名空间。# 首先创建命名空间如果不存在 kubectl create namespace cloudflare # 创建Secret将上一步复制的Token作为值。 # 注意Token需要经过base64编码但kubectl create secret generic命令会自动处理。 # 我们将Token保存在一个文件里然后从文件创建避免在shell历史中留下记录。 echo -n 你的Tunnel_Token字符串 /tmp/tunnel-token.txt kubectl create secret generic cloudflare-tunnel-credentials \ --from-filecredentials/tmp/tunnel-token.txt \ --namespace cloudflare rm /tmp/tunnel-token.txt # 创建后立即删除临时文件现在在cloudflare命名空间下就有了一个名为cloudflare-tunnel-credentials的Secret其中credentials这个Key的值就是我们的Tunnel Token。3.4 添加仓库与定制Values文件首先将Cloudflare的Helm仓库添加到本地。helm repo add cloudflare https://cloudflare.github.io/helm-charts/ helm repo update接下来是核心步骤定制化配置。我们不直接在helm install命令中使用--set传递大量参数而是采用更可维护的Values文件方式。创建一个values.yaml文件# values.yaml image: # 建议指定一个稳定版本而非latest tag: 2024.5.0 # 使用DaemonSet确保每个节点都有连接点提供高可用 controller: type: DaemonSet # 关键配置指定我们刚才创建的Secret credentials: secretName: cloudflare-tunnel-credentials secretKey: credentials # 配置Tunnel的入口规则Ingress Rules。 # 这里定义外部流量如何路由到内部服务。 ingress: - hostname: app.example.com # 外部访问的域名 service: my-webapp-service # K8s集群内的Service名称 path: /* originRequest: noTLSVerify: true # 如果内部服务是HTTP可以跳过TLS验证。生产环境建议内部也使用HTTPS。 # 可以定义多条规则 - service: http_status:404 # 一个特例匹配未定义规则的流量返回404 # 资源限制与探针 resources: requests: memory: 64Mi cpu: 50m limits: memory: 128Mi cpu: 100m livenessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 10 periodSeconds: 30 readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 5 periodSeconds: 10这个配置文件做了几件关键事关联了凭证Secret。定义了路由规则将所有发送到app.example.com的流量转发到K8s中名为my-webapp-service的Service这个Service需要你提前部署好你的应用。设置了合理的资源限制和健康检查确保Tunnel客户端稳定运行。3.5 执行Helm安装与验证使用Helm进行安装helm install my-cloudflare-tunnel cloudflare/cloudflare-tunnel \ -f values.yaml \ --namespace cloudflare安装完成后验证部署# 查看DaemonSet和Pod状态 kubectl get daemonset,po -n cloudflare -l app.kubernetes.io/instancemy-cloudflare-tunnel # 查看Pod日志确认tunnel连接成功 kubectl logs -n cloudflare -l app.kubernetes.io/instancemy-cloudflare-tunnel --tail50在日志中你应该看到类似INF Connection ... registered connIndex0 ...的成功信息。最后回到Cloudflare Zero Trust控制台的“隧道”页面你应该能看到my-k8s-tunnel的状态变为“健康”有一个或多个连接器。现在访问https://app.example.com流量就会通过Cloudflare全球网络经由Tunnel安全地到达你的K8s内部服务。4. 高级配置、问题排查与运维心得基础部署只是开始在生产环境中我们还需要考虑更多。4.1 高可用与网络策略优化DaemonSet vs DeploymentDaemonSet默认确保每个或某些节点都有实例。优势是流量可以从最近的边缘节点直接路由到任意节点上的Tunnel客户端延迟低且单个节点故障不影响其他节点上的Tunnel连接。适合服务全局流量或节点分布在不同可用区的情况。Deployment可以指定固定数量的副本在任意节点运行。优势是更易于控制资源总量配合Pod反亲和性podAntiAffinity也能实现高可用。适合资源严格受限或服务特定命名空间内应用的情况。网络策略NetworkPolicy如果你的集群使用了Calico、Cilium等CNI插件并启用了网络策略需要确保Tunnel的Pod有权限访问它需要能访问Cloudflare的出口IP出站连接。它需要能访问你配置的ingress规则中指定的K8s Service。通常这意味着Tunnel Pod所在的命名空间需要与后端服务命名空间有互通策略或者后端Service类型为ClusterIP且允许跨命名空间访问。4.2 配置热重载与版本升级cloudflared支持配置热重载。当你修改了values.yaml中的ingress规则并执行helm upgrade时Chart会更新ConfigMap并滚动更新Pod。新的Pod启动后会加载新配置无需重建Tunnel。版本升级策略# 1. 首先更新本地仓库索引获取最新Chart版本 helm repo update # 2. 查看可升级版本 helm search repo cloudflare/cloudflare-tunnel -l # 3. 升级前最好先下载新版Chart的Values文件与你的自定义values.yaml做对比合并 helm show values cloudflare/cloudflare-tunnel --version 新版本号 new-values.yaml # 使用diff工具如diff meld对比 new-values.yaml 和你的 values.yaml # 4. 执行升级指定版本号 helm upgrade my-cloudflare-tunnel cloudflare/cloudflare-tunnel \ -f values.yaml \ --namespace cloudflare \ --version 新版本号踩坑提醒Chart的默认Values结构可能在版本间发生变化。直接升级可能导致非向后兼容的配置被应用。务必执行第3步的对比操作这是保证升级平稳的关键。4.3 常见问题排查实录问题1Pod启动失败日志显示“Invalid tunnel token”排查Token无效或过期。在Cloudflare Zero Trust面板中可以进入对应Tunnel的配置页面重新生成一个Token。解决生成新Token。更新K8s Secretkubectl create secret generic cloudflare-tunnel-credentials --from-filecredentials/tmp/new-token.txt --namespace cloudflare --dry-runclient -o yaml | kubectl apply -f -删除旧的Tunnel Pod触发重启kubectl delete pod -n cloudflare -l app.kubernetes.io/instancemy-cloudflare-tunnel问题2Tunnel状态为“健康”但访问域名返回502或503错误排查这通常是Tunnel客户端能连接到Cloudflare但无法将流量转发到后端服务。检查values.yaml中ingress规则里配置的service名称和端口是否正确。使用kubectl get svc -n 后端服务命名空间确认。检查后端服务Pod是否就绪kubectl get pods查看READY状态。检查从Tunnel Pod到后端Service的网络连通性。可以进入Tunnel Pod执行curl命令测试kubectl exec -n cloudflare tunnel-pod-name -- curl -v http://service-name.namespace.svc.cluster.local:port。检查originRequest配置。如果后端服务是HTTP但Tunnel期望HTTPS或者有证书问题可能需要调整noTLSVerify等参数。问题3DaemonSet Pod在某些节点无法调度排查可能是节点资源不足、节点有污点Taint或Pod本身有节点选择器nodeSelector限制。解决kubectl describe node 节点名查看节点资源状态和污点。查看DaemonSet配置kubectl get daemonset -n cloudflare my-cloudflare-tunnel -o yaml关注nodeSelector和tolerations字段。如果需要容忍主节点污点或调度到特定节点可以在values.yaml中配置controller: type: DaemonSet tolerations: - key: node-role.kubernetes.io/control-plane operator: Exists effect: NoSchedule nodeSelector: node-type: edge问题4如何查看Tunnel的详细连接和流量指标答案Cloudflare Zero Trust控制台的“隧道”页面提供了基本的连接状态和事件日志。但对于更详细的流量分析你需要结合Cloudflare Analytics在域名的控制台查看流量、安全事件分析。Tunnel Pod日志使用kubectl logs命令或通过集群的日志收集系统如LokiPromtail收集可以查看每个请求的转发详情需启用更详细的日志级别在values.yaml中设置extraArgs: [--loglevel, info]默认为info可调整为debug用于排错但生产环境慎用。后端应用日志最终请求会到达你的应用应用本身的日志是问题定位的终点。4.4 安全与成本考量安全最小权限原则为Tunnel创建专用的API Token权限仅限必需的Zone DNS编辑不要使用全局API Key。Secret管理使用K8s Secret并考虑集成外部Secret管理工具如HashiCorp Vault, AWS Secrets Manager。网络隔离利用K8s NetworkPolicy严格限制Tunnel Pod只能访问必要的后端服务端口。审计日志开启Cloudflare的审计日志记录所有Tunnel的创建、配置更改操作。成本Cloudflare Tunnel本身对于大多数用途是免费的但如果你使用Argo Smart Routing智能路由等高级功能或流量极大可能需要关注对应产品的定价。主要成本体现在你自己的K8s集群资源消耗Tunnel Pod运行所需的CPU/内存和可能产生的出口流量如果后端服务需要通过Tunnel访问外部资源。合理设置resources.requests/limits避免资源浪费。将cloudflare/helm-charts集成到你的Kubernetes运维体系中绝不仅仅是多了一个部署工具。它是在将边缘计算的能力和云原生的运维模式进行深度缝合。从今天起你可以像管理一个内部微服务一样去管理一个全球分布的边缘网络接入点。这种统一性带来的运维效率提升和认知负担降低才是这个项目带来的最大价值。在实际操作中我建议从一个非核心的业务开始试点熟悉整个配置、部署、问题排查的闭环然后再逐步推广到更关键的业务流。记住把Tunnel Token管好把Values文件用Git管起来剩下的就是享受这种声明式基础设施带来的秩序感了。