云原生集群管理运维IaC【免费下载链接】kopsKubernetes Operations (kOps) - Production Grade k8s Installation, Upgrades and Management项目地址https://gitcode.com/gh_mirrors/kop/kops点击查看免费下载kOpsKubernetes Operations内置了一套完整的 Addon 管理机制分为由 kOps 负责升级与配置的Managed addons通过 Cluster Spec 配置和以清单文件原样应用的Static addons通过spec.addons配置两大类。本文以 docs/addons.md 为核心脉络逐一讲解 AWS Load Balancer Controller、Cluster Autoscaler、Cert-manager、Karpenter、Metrics Server、Node Local DNS Cache、Node Termination Handler、Node Problem Detector、Pod Identity Webhook、Snapshot Controller 等托管 Addon 的完整配置项并结合pkg/apis/kops中的 Spec 定义与upup/pkg/fi/cloudup/bootstrapchannelbuilder的实现细节讲透自定义 Addon 的清单格式、版本管理原理与 S3 部署实践帮助读者在 kOps 集群中按需启用、正确配置并自主维护 Addon。两类 Addon 体系Managed 与 StatickOps 支持两种类型的 AddonManaged addons通过 Cluster Spec 配置。这类 Addon 由 kOps 托管会跟随 kOps 与 Kubernetes 的生命周期一起升级并根据集群 Spec 中的配置包括 Addon 自身配置以及你配置的其他相关设置自动生成部署清单。Static addons也称 Custom addons通过spec.addons配置每条记录指向一个控制平面可以读取的清单文件kOps 将清单中的资源原样应用as-is。从源码实现看Managed Addon 的清单并不是写死的静态文件而是由 BootstrapChannelBuilder 在构建集群模型时动态组装它根据 Cluster Spec 中各个 Addon 配置段如ClusterAutoscaler、MetricsServer、NodeTerminationHandler等逐一生成带k8s-addon: name选择器的channelsapi.AddonSpec最终汇总为一个addons/bootstrap-channel.yaml通道文件由channels工具负责应用与版本跟踪。因此Managed的本质是配置入口在 Cluster Spec渲染与升级逻辑由 kOps 掌握。Managed Addons 逐一详解以下 Addon 均通过编辑集群 Spec 中的对应配置段启用。修改后执行kops update cluster并配合--yes应用即可生效。AWS Load Balancer ControllerAWS Load Balancer Controller 为 AWS 上的 ELBALB/NLB提供增强的编排能力例如基于 Ingress 自动创建 ALB、管理目标组与安全组等。该 Addon 自 kOps 1.20 起默认可用spec: awsLoadBalancerController: enabled: true cpuRequest: 100m cpuLimit: 200m memoryRequest: 200Mi memoryLimit: 500Mi对应源码结构体 LoadBalancerControllerSpec 显示CPU/Memory 的 request 与 limit 默认值分别为100m、200m、200Mi、500Mi即示例中的数值即默认值此外还支持version字段覆盖容器镜像 tag。集成 AWS WAF 与 Shield虽然该控制器可以集成 AWS WAF 与 Shield 服务到 ALB但 kOps 默认禁用这些能力。自 kOps 1.24 起可以通过以下字段启用 WAF / WAF Classic 与 WAFv2均为 beta 特性接受的配置与涉及的 AWS 资源未来可能变化spec: awsLoadBalancerController: enabled: true enableWAF: true enableWAFv2: true cpuRequest: 100m cpuLimit: 200m memoryRequest: 200Mi memoryLimit: 500Mi启用 Shield Advancedspec: awsLoadBalancerController: enabled: true enableShield: true需要注意控制器一次只能为一个 ALB 关联一个 WAF。即使在同一个 Ingress 对象上同时填写alb.ingress.kubernetes.io/waf-acl-id与alb.ingress.kubernetes.io/wafv2-acl-arn注解也只有一个会生效。Cluster AutoscalerCluster Autoscaler自 kOps 1.19 起默认可用根据 Pod 调度需求自动调整集群节点数量。启用并配置spec: clusterAutoscaler: enabled: true expander: least-waste balanceSimilarNodeGroups: false emitPerNodegroupMetrics: false awsUseStaticInstanceList: false scaleDownUtilizationThreshold: 0.5 skipNodesWithCustomControllerPods: true skipNodesWithLocalStorage: true skipNodesWithSystemPods: true newPodScaleUpDelay: 0s scaleDownDelayAfterAdd: 10m0s scaleDownUnneededTime: 10m0s scaleDownUnreadyTime: 20m0s image: the latest supported image for the specified kubernetes version cpuRequest: 100m memoryRequest: 300Mi各字段的默认值与语义可从 ClusterAutoscalerConfig 的源码注释中确认字段默认值说明expanderleast-waste决定扩容时选择哪个实例组。支持least-waste、most-pods、random、price、priority其中price仅 GCE 支持balanceSimilarNodeGroupsfalse将相似的节点组视为一个整体emitPerNodegroupMetricsfalse是否发布每个节点组的 min/max 指标awsUseStaticInstanceListfalse是否使用静态定义的 AWS EC2 实例列表scaleDownUtilizationThreshold0.5缩容利用率阈值skipNodesWithCustomControllerPodstrue跳过含自定义控制器 Pod 的节点skipNodesWithSystemPodstrue跳过含 kube-system 非 DaemonSet Pod 的节点skipNodesWithLocalStoragetrue跳过含本地存储的节点newPodScaleUpDelay0s不可调度 Pod 需存活多久才触发扩容scaleDownDelayAfterAdd10m0s扩容后多久恢复缩容评估scaleDownUnneededTime10m0s节点不再需要多久后才可缩容scaleDownUnreadyTime20m0s未就绪节点被视为不需要的时长image与 K8s 版本匹配的最新受支持镜像容器镜像 tagcpuRequest/memoryRequest100m/300Mi容器资源请求此外源码中还定义了ignoreDaemonSetsUtilization忽略 DaemonSet Pod 的利用率计算、cordonNodeBeforeTerminating缩容终止前先 cordon 节点、maxNodeProvisionTime等待节点加入集群的最长时间、podAnnotations注入到 CA Pod 的注解等可选字段。Expander 策略Priority 配置自 kOps 1.26 起priorityexpander 需要额外的 ConfigMap 配置。当在 Cluster Spec 中设置expander: priority时kOps 会基于 InstanceGroup Spec 自动生成该 ConfigMap你只需在 InstanceGroup 中设置优先级spec: autoscale: true autoscalePriority: 100autoscalePriority未设置时默认为0。需要更复杂的匹配例如用正则匹配 InstanceGroup 名称时可在 Cluster Spec 中提供自定义配置——一旦设置InstanceGroup 上的优先级将被忽略clusterAutoscaler: customPriorityExpanderConfig: 100: - .*foo.* 50: - .*bar.* 0: - .*对应源码字段为CreatePriorityExpenderConfig默认true控制 kOps 是否生成该 ConfigMap与CustomPriorityExpanderConfigmap[string][]string覆盖默认 ConfigMap 内容。关闭自动生成 priority ConfigMap如果你希望完全在 kOps 之外管理 priority expander 的 ConfigMap可关闭 kOps 的生成逻辑clusterAutoscaler: createPriorityExpanderConfig: false针对单个 InstanceGroup 禁用 Autoscaler自 kOps 1.20 起可以在 InstanceGroup Spec 中单独关闭自动扩缩容spec: autoscale: false注意与autoscalePriority配合使用autoscale: true表示该实例组参与扩缩容autoscalePriority决定扩容顺序优先级。Cert-managerCert-manager自 kOps 1.20 起要求 K8s 1.16负责为集群签发与管理 x509 证书spec: certManager: enabled: true defaultIssuer: yourDefaultIssuer警告cert-manager 每个集群只支持安装一份。如果集群中已经运行了 cert-manager必须在启用该 Addon 之前移除现有安装或将其标记为不由 kOps 管理见下文。只要使用的是 cert-manager v1 版本的资源先删除旧安装再替换为该 Addon 是安全的。从 CertManagerConfig 源码看defaultIssuer用于设置一个默认的 ClusterIssuerimage可覆盖镜像featureGates可开关实验特性另外还有managed、nameservers、hostedZoneIDs三个重要配置项。自托管Self-provisionedcert-manager自 kOps 1.20.2 起可让 cert-manager 由外部自己部署同时仍让 kOps 上所有依赖它的插件正常部署注意在 cert-manager 真正部署完成前相关 Addon 可能报错spec: certManager: enabled: true managed: false源码中Managed字段注释明确说明置为false时 kOps 将跳过 cert-manager 的部署。cert-manager Pod 的 DNS nameserver 配置自 kOps 1.23.3 起支持为 cert-manager Pod 指定一组 DNS nameserver IP。当同一域名同时存在公有与私有 DNS 区域时这可以确保 cert-manager 始终能访问 Ingress 或 DNS01 challenge 的 TXT 记录spec: certManager: enabled: true nameservers: - 1.1.1.1 - 8.8.8.8启用 DNS-01 Challenge自 kOps 1.25.0 起通过给 cert-manager 授予必要的 IAM 权限可以解决 DNS-01 challenge。这要求启用 ServiceAccount 的外部权限IRSA即 service-account-issuer-discovery-and-aws-iam-roles-for-service-accounts-irsaspec: certManager: enabled: true hostedZoneIDs: - ZONEID iam: useServiceAccountExternalPermissions: truehostedZoneIDs是需要允许 cert-manager 做 DNS-01 校验的 Route53 hosted zone ID 列表。KarpenterKarpenter Addon自 kOps 1.24 起启用由 Karpenter 管理的 InstanceGroup即实例组由 Karpenter 动态供给节点而非直接对应 ASGspec: karpenter: enabled: true从源码看KarpenterConfig 还支持logFormat、logLevel、image、featureGates、memoryLimit、memoryRequest、cpuRequest等字段而new_cluster.go中的setupKarpenterNodes会为 Karpenter 集群创建Spec.Manager InstanceManagerKarpenter的节点组见 new_cluster.go 与其测试 new_cluster_test.go。同时 populate_instancegroup_spec.go 显示Karpenter v1 期望其节点注册时带一个 taint 作为竞态防护Karpenter 接管后会移除该 taint。详细的 Karpenter 配置方法见 kOps Karpenter 文档。Metrics ServerMetrics Server自 kOps 1.19 起为 Kubernetes 内置的自动扩缩容管道提供可扩展的容器资源指标源spec: metricsServer: enabled: true对应 MetricsServerConfig 包含image与insecure默认true字段。安全的 TLS 校验自 kOps 1.20 起默认情况下 API Server不会校验 Metrics Server 的 TLS 证书。要启用 TLS 校验要求集群已安装 cert-managerspec: certManager: enabled: true metricsServer: enabled: true insecure: false原理是insecure: false让 API Server 验证 Metrics Server 证书而该证书由 cert-manager 签发因此两者必须同时启用。Node Local DNS CacheNodeLocal DNSCache自 kOps 1.18 起要求 K8s 1.15在使用 CoreDNS 时可启用它通过在每个节点上以 DaemonSet 形式运行 DNS 缓存代理来提升集群 DNS 性能。node-local-dnsPod 的memoryRequest与cpuRequest可配置未设置时默认分别为5Mi与25m。若启用forwardToKubeDNS则默认上游使用 kubednsspec: kubeDNS: provider: CoreDNS nodeLocalDNS: enabled: true memoryRequest: 5Mi cpuRequest: 25mNodeLocalDNSConfig 还提供了更多进阶字段localIP本地监听 IP可在169.254.20.0/16内任选或选择不会冲突的 IP、image覆盖镜像、externalCoreFile完全自定义 CoreFile将忽略其他 CoreFile 相关配置、additionalConfig在 kOps 生成的 CoreFile 基础上追加配置、podAnnotations。其实现位于 bootstrapchannelbuilder 的buildAddons中仅当kubeDNS.Provider CoreDNS且nodeLocalDNS.enabled时才生成对应条目见 bootstrapchannelbuilder.go。Node Termination HandlerNode Termination Handler自 kOps 1.19 起确保 Kubernetes 控制平面能妥善响应可能导致 EC2 实例不可用的事件如 EC2 维护事件、Spot 中断、实例 Rebalance 建议。若不处理应用可能无法优雅停止、恢复可用性变慢或把任务调度到即将宕机的节点上spec: nodeTerminationHandler: cpuRequest: 200m enabled: true enableRebalanceMonitoring: true enableSQSTerminationDraining: true managedASGTag: aws-node-termination-handler/managed prometheusEnable: true webhookURL: https://hooks.slack.com/services/YOUR/SLACK/URLNodeTerminationHandlerSpec 是参数最丰富的托管 Addon 之一关键字段与默认值如下字段默认值说明enabledtrue是否启用 NTHenableSpotInterruptionDrainingtrue收到 Spot 中断通知时排空节点队列模式下不可关闭enableScheduledEventDrainingtrue维护窗口开始前排空节点队列模式下不可关闭enableRebalanceMonitoringfalse收到 Rebalance 建议时 cordon 节点enableRebalanceDrainingfalse收到 Rebalance 建议时排空节点enableOutOfServiceTaintfalse非优雅停机时打node.kubernetes.io/out-of-servicetaint让 K8s 快速分离卷并重调度 PodprometheusEnablefalse暴露/metrics端点enableSQSTerminationDrainingtrue启用队列处理模式SQS 终止排空excludeFromLoadBalancerstruecordon 前将节点标记为从负载均衡器排除managedASGTag-决定 NTH 可对哪些节点采取行动现映射到--managed-tag实际检查 EC2 实例而非 ASG 的标签podTerminationGracePeriod-1每个 Pod 的优雅终止时间秒负值用 Pod 自身默认值taintNodefalse中断事件发生时给节点打 taintmemoryRequest/cpuRequest64Mi/50m容器资源请求webhookURL/webhookTemplate无中断动作时向 URL 投递事件数据 / 替换默认 webhook 消息模板deleteSQSMsgIfNodeNotFoundfalse队列模式下目标节点找不到时删除 SQS 消息队列处理模式Queue Processor Mode自 kOps 1.21 起只要enableSQSTerminationDraining不为falseNTH 就以Queue Processor 模式运行。相比默认的 IMDS 模式队列模式还能处理 ASG Scale-In、AZ-Rebalance、不健康实例、通过 API 或控制台发起的 EC2 实例终止等事件。kOps 会为你预置所需基础设施SQS 队列、EventBridge 规则和 ASG Lifecycle Hooks。managedASGTag可用于在多个集群间区分资源归属。由于 kOps CLI 需要管理这些 EventBridge 规则与 SQS 队列需要额外的 IAM 权限{ Version: 2012-10-17, Statement: [ { Effect: Allow, Action: [ events:DeleteRule, events:ListRules, events:ListTargetsByRule, events:ListTagsForResource, events:PutEvents, events:PutRule, events:PutTargets, events:RemoveTargets, events:TagResource, sqs:CreateQueue, sqs:TagQueue, sqs:DeleteQueue, sqs:GetQueueAttributes, sqs:ListQueues, sqs:ListQueueTags ], Resource: * } ] }警告在已有集群上切换两种运行模式时旧资源必须手动清理。从 IMDS 模式切换到 Queue Processor 模式需删除 Kubernetes 的 NTH DaemonSet从 Queue Processor 切回 IMDS 模式需删除 NTH Deployment 以及 AWS 侧的 SQS 队列、EventBridge 规则与 ASG Lifecycle Hooks。源码中 IsQueueMode 方法即用于判定当前是否处于队列模式enabled为真且enableSQSTerminationDraining未显式关闭即为队列模式。实现侧kOps 会据此条件在 apply_cluster.go 挂载NodeTerminationHandlerBuilder来构建对应 AWS 资源。Node Problem DetectorNode Problem Detector自 kOps 1.22 起运行在每个节点上检测节点问题并上报给 apiserver使各种节点故障对集群管理栈的上层可见spec: nodeProblemDetector: enabled: true memoryRequest: 32Mi cpuRequest: 10mNodeProblemDetectorConfig 的默认值为memoryRequest: 80Mi、cpuRequest: 10m、memoryLimit: 80Mi另有image与cpuLimit字段。Pod Identity Webhook使用 IAM roles for Service AccountsIRSA 时Pod 需要额外的 token 来与 AWS API 认证SDK 还需要特定的环境变量才能使用这些 token。Pod Identity Webhook自 kOps 1.23 起会自动变更mutate配置了 IRSA 的 Pod免去手动配置Cluster Spec 中所有配置了 AWS 权限的 ServiceAccount 都会自动被变更以承担对应角色spec: certManager: enabled: true podIdentityWebhook: enabled: true注意示例中同时启用了 cert-manager——EKS Pod Identity Webhook 通常需要 cert-manager 提供证书。EKS 风格的 ServiceAccount 注解一般不需要因为 kOps 会用 Cluster Spec 中的全部 ServiceAccount→角色映射来配置 webhook但若需特殊配置仍可在 ServiceAccount 上打注解覆盖 kOps 配置。对应源码为 PodIdentityWebhookSpec支持enabled与replicas两个字段。Snapshot ControllerSnapshot controller自 kOps 1.21 起要求 K8s 1.20实现了 CSI 的卷快照Volume Snapshot功能。启用方式spec: snapshotController: enabled: trueSnapshotControllerConfig 还包含installDefaultClass字段用于安装默认的 VolumeSnapshotClass。需要留意树内in-tree卷驱动不支持快照功能。在 AWS 上运行集群时需同时启用 EBS CSI 驱动spec: cloudConfig: awsEBSCSIDriver: enabled: true自管理 aws-ebs-csi-driver自 kOps 1.25 起支持自管理self-managed的 aws-ebs-csi-driver。如果使用 Amazon EBS 卷则必须安装 Amazon EBS CSI driver否则卷操作会失败spec: cloudConfig: awsEBSCSIDriver: enabled: true managed: false权限模型分为两种情况若未启用 IRSA控制平面拥有供给节点的权限自管理的 controller 应运行在控制平面若启用了 IRSAkOps 会创建对应的 AWS IAM Role、绑定策略并建立信任关系允许 ServiceAccount 承担该 IAM Role。要让 Pod 承担这些角色需启用 Pod Identity Webhook否则需要自行修改 Pod Spec。Custom Addons通过 spec.addons 安装静态清单Static addons 通过spec.addons配置每条记录指向一个控制平面可读取的清单文件spec: addons: - manifest: https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.4.0/standard-install.yaml对应源码 AddonSpec 非常简单仅包含Manifest一个字段——这也印证了静态 Addon 原样应用的定位。普通 Kubernetes 资源清单自 kOps 1.36 起spec.addons中的manifest可以是常规的 Kubernetes 资源清单kOps 会原样应用。例如上面的 manifest 会安装 Gateway API 的 CRD。这种方式适合单文件、无版本管理诉求的场景。Addons 索引manifest-of-manifests当spec.addons中的一条记录需要指向多个带版本的清单时应使用 kOps 的Addons索引格式。Addons是一个清单的清单允许在一个索引下描述多个可用版本的 manifestkOps 借此管理 Addon 的版本更新。其 API 定义位于 channels/pkg/api/channel.go。下面是最小化的Addons索引示例安装两个 Addonkind: Addons metadata: name: example spec: addons: - name: foo.addons.org.io version: 0.0.1 selector: k8s-addon: foo.addons.org.io manifest: foo.addons.org.io/v0.0.1.yaml - name: bar.addons.org.io version: 0.0.1 selector: k8s-addon: bar.addons.org.io manifest: bar.addons.org.io/v0.0.1.yaml对应文件结构应为addon.yaml foo.addons.org.io v0.0.1.yaml bar.addons.org.io v0.0.1.yamlfoo/bar目录下的 YAML 可以是任意 Kubernetes 资源清单。通常这个文件结构会上传到 S3 或其他受支持的存储后端再在spec.addons中引用。如果 master 节点需要访问存放 Addon 清单的 S3 bucket可通过spec.additionalPolicies添加 IAM 策略spec: additionalPolicies: master: | [ { Effect: Allow, Action: [ s3:GetObject ], Resource: [arn:aws:s3:::my-kops-addons/*] }, { Effect: Allow, Action: [ s3:GetBucketLocation, s3:ListBucket ], Resource: [arn:aws:s3:::my-kops-addons] } ]master 节点会轮询 bucket 中的变更持续保持 Addon 更新。版本管理与升级规则channels 工具原理kOps 使用channels工具同时管理系统 Addon 与用户 Addon两者可并存管理。其版本管理细节在 docs/contributing/addons.md 中有完整说明核心规则如下version字段解释为 semver 版本号。channels 工具通过kube-system命名空间上的注解跟踪当前已安装版本见 addon.go 等实现。触发升级的三个条件详见 docs/contributing/addons.md清单声明的版本大于当前已安装版本版本号相同但id不同版本与id都相同但清单内容的 hash 已变化。这意味着你手动编辑已部署的 Addon 后不会被覆盖直到安装新版本。长期方向是 Addon 主要通过 ConfigMap/Secret 配置且管理器不会替换 ConfigMap。selector字段决定 Addon 包含哪些对象用于构造--prune参数使升级时移除旧版本中存在而新版本中不存在的对象prune 规格见 channel.go 的PruneSpec。kubernetesVersion字段一个针对 Kubernetes 版本的 semver 范围说明符。目标 K8s 版本不匹配时该 Addon 版本会被忽略从而可以为 K8s API 的重大变化提供不同版本的清单。注意kOps 会移除 Kubernetes semver 的pre-release部分因此1.6.0-beta.1也会匹配1.6.0。id字段用于打破 semver 平局。典型场景是集群从 K8s 1.5 升级到 1.6 再降级回 1.5 时1.6 的 manifest 版本号更大、总是优先导致无法回退引入id后版本相同但id不同的 Addon 会被视为需要更新从而正确安装匹配当前 K8s 版本的清单。示例- version: 1.6.0 selector: k8s-addon: kube-dns.addons.k8s.io manifest: pre-k8s-16.yaml kubernetesVersion: 1.6.0 id: pre-k8s-16 - version: 1.6.0 selector: k8s-addon: kube-dns.addons.k8s.io manifest: k8s-16.yaml kubernetesVersion: 1.6.0 id: k8s-16实践建议version尽量贴近上游版本号manifest 文件名最好包含id便于维护。更新引导bootstrapAddon如需查看并更新 kOps 自带的 bootstrap Addon可运行 channels 命令查看哪些需要更新追加--yes实际应用channels apply channel s3://KOPS_S3_BUCKET/CLUSTER_NAME/addons/bootstrap-channel.yamlkOps 在集群创建时会生成该bootstrap-channel.yaml其中按k8s-addon选择器列出了 coredns、kube-dns、dns-controller、cluster-autoscaler、metrics-server、node-problem-detector、aws-load-balancer-controller、eks-pod-identity-webhook 等系统 Addon见 bootstrapchannelbuilder.go 中的buildAddons实现。由于系统 Addon 与用户 Addon 使用同一套 channels 机制kOps 引导安装的 Addon 可以与用户自行添加的 Addon 并存管理——不过要注意引导 Addon 在 kOps 升级时被替换的概率更高。实践要点总结Managed vs Static 的选择官方管理的场景优先用 Managed AddonCluster Spec 配置跟随 kOps 生命周期升级社区自定义或第三方组件用spec.addons静态清单需要多版本管理时用Addons索引。配置生效流程编辑 Cluster Spec →kops edit cluster或直接修改 spec →kops update cluster --yes应用变更。依赖关系Metrics Server 的安全 TLSinsecure: false、Pod Identity Webhook、cert-manager 的 DNS-01 都依赖 cert-manager 或 IRSA 的先行启用务必按依赖顺序规划。升级安全channels 的版本管理保证已部署 Addon 不会被意外覆盖切换运行模式如 NTH 的 IMDS↔Queue Processor时必须手动清理旧资源。如需深入了解版本化 Addon 索引的完整语义可继续阅读 Addon 管理文档想查看当前集群生成的 bootstrap 通道内容可从状态存储中读取addons/bootstrap-channel.yaml对照本文所述的各 Addon 配置段逐项核对。赞分享云原生集群管理运维IaC【免费下载链接】kopsKubernetes Operations (kOps) - Production Grade k8s Installation, Upgrades and Management项目地址https://gitcode.com/gh_mirrors/kop/kops点击查看免费下载相关推荐kOps kops toolbox addons apply 命令完全指南Channel 驱动的 Addon 应用与更新管理kOps kops toolbox addons apply 命令完全指南Channel 驱动的 Addon 应用与更新管理 导读 本文围绕 kOpsKu云原生集群管理运维IaCOAuth2 Proxy 会话存储完全指南Cookie 与 Redis 两种后端的原理、选型与实战配置OAuth2 Proxy 会话存储完全指南Cookie 与 Redis 两种后端的原理、选型与实战配置 导读 会话Session是 OAuth2 Prox后端API网关认证鉴权Cloudflare Tunnel 配置完全指南config.yml、ingress 规则与两种配置源实战Cloudflare Tunnel 配置完全指南config.yml、ingress 规则与两种配置源实战 本指南以 Cloudflare Tunnel 的配人工智能AI 技能AI 插件上一篇Infinite Scroll 安装与配置指南下一篇开源项目oapi-codegen安装与配置指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考