云原生【免费下载链接】external-dnsConfigure external DNS servers dynamically from Kubernetes resources项目地址https://gitcode.com/gh_mirrors/ex/external-dns点击查看免费下载本指南围绕 external-dns 在生产环境的可靠运行展开聚焦资源配置作用域scope、内存占用、集群规模扩展与可观测性四大主题系统讲解--service-type-filter、--source、--kube-api-qps、--events-emit等核心标志与真实部署场景之间的交互。读完本文你将掌握一份可直接对照的生产就绪检查清单并理解各类配置失误缺失 CRD、RBAC 权限不足、Provider 状态冲突的典型故障症状与排查路径从而在部署前发现并消除隐患。如果你有本文未覆盖的运维经验或最佳实践欢迎向社区提交 proposal PR 分享。生产就绪检查清单Production Readiness Checklist在将 external-dns 部署到生产环境之前建议逐项对照以下清单检查。每一项都对应下文中的详细章节。资源作用域Resource scope设置 [--service-type-filter](#service-source-的 informer 范围控制) 为实际需要发布的服务类型例如LoadBalancer。默认配置下 external-dns 会无谓地监听 Pods、EndpointSlices 与 Nodes。添加 [--label-filter或--annotation-filter](#缩减 informer 作用域) 进一步限制被缓存的对象集合。Source 配置只配置 CRD 已在集群中完整安装并 established 的 [--source](#source 配置与预检校验) 类型。缺失 CRD 并不总是产生清晰的报错——它可能表现为context deadline exceeded超时或 informer 静默停滞。为每个已配置 source 所需的资源类型授予 RBAClist和watch权限。缺失watch权限时 external-dns 可以正常启动但会冻结对集群的观察——DNS 记录会静默漂移既不崩溃也不打印任何日志警告。将 RBAC 收紧到仅覆盖已配置的 source。多余的权限会掩盖配置错误而不是暴露它。在多集群部署中为每个集群使用独立的 source 列表而非共享同一份配置。在镜像生产 CRD 与 RBAC 配置的 staging 环境上先做验证再推广变更。扩展Scaling在每一层都做资源收敛——服务类型、标签、注解、域名、Zone ID。参见 资源作用域。面对大型 Zone 集合或复杂 source 组合时拆分为多个实例每个实例使用独立的--txt-owner-id且域名作用域不重叠。参见 拆分实例。调整 reconcile 频率并在大集群上提高--kube-api-request-timeout。参见 [降低 reconcile 压力](#降低 reconcile 压力)。当 external-dns 被 Kubernetes API 限流或与众多其他控制器共享 API 配额时设置--kube-api-qps与--kube-api-burst。参见 [降低 reconcile 压力](#降低 reconcile 压力)。可观测性Observability对external_dns_controller_consecutive_soft_errors超过一个 reconcile 周期仍大于 0 的情况设置告警。对external_dns_source_errors_total或external_dns_registry_errors_total的持续增长设置告警。启用 [--events-emitRecordError](#面向无效端点的 Kubernetes Events)将配置错误的端点直接呈现在对应的 Kubernetes 资源上。Registry 与所有权为每个 external-dns 实例设置唯一的--txt-owner-id并避免--domain-filter作用域重叠。多个实例在无独立 owner ID 的情况下写入同一 Zone 会产生冲突错误若冲突导致硬退出则会引发 crashloop。参见 状态冲突与所有权。Provider如果管理大量或频繁变更的 Zone请为你的 Provider 配置批量变更大小与间隔。参见 DNS Provider API 速率限制 中各 Provider 的标志说明。如果 Provider 支持启用 Zone 缓存。Zone 枚举在每次 reconcile 时都会产生一次 API 调用缓存可显著降低稳定 Zone 集合下的 Provider API 压力。参见 Zone 列表缓存。将 Provider 凭据API Key、IAM Role限定到 external-dns 管理的 Zone。Zone 过滤标志表达的是意图并非执行边界——凭据才是真正的执行边界。参见 将 Provider 凭据限定到特定 Zone。资源作用域与内存Resource Scope and Memoryservice source 监听的远不止 Service默认情况下servicesource 会注册Services、Pods、EndpointSlices 与 Nodes四类 Kubernetes informer。哪些 informer 处于激活状态取决于作用域内的服务类型激活的 informer触发条件Services始终激活Pods EndpointSlices作用域内存在NodePort或ClusterIP服务Nodes作用域内存在NodePort服务从源码中可以印证这一注册逻辑在 source/service.go 中只有当sTypesFilter.isRequired(v1.ServiceTypeNodePort, v1.ServiceTypeClusterIP)为真时才会创建 EndpointSlices 与 Pods informer而 Nodes informer 仅在isRequired(v1.ServiceTypeNodePort)为真时创建。当未设置--service-type-filter默认值时所有服务类型都在作用域内四个 informer 会全部启动。在大集群上这带来两个后果稳态内存external-dns 会在内存中缓存集群中每一个 Pod、EndpointSlice 和 Node——而不仅仅是与 DNS 相关的那些。启动内存峰值经典的 Kubernetes LIST 代码路径会在 informer 初始同步时一次性把某类型的所有对象拉入内存。虽然 Pod informer 应用了 transformer见 source/service.go其中TransformKeepAnnotationPrefix只保留与注解相关的前缀字段来减小存储体积但正如源码注释所言如果不使用 watchList它无法阻止初始 informer 同步时的内存峰值。缩减 informer 作用域最有效的缓解手段是限制 external-dns 监听的 Service 类型# 大多数集群只需要 LoadBalancer——可彻底消除 Pod、EndpointSlice 与 Node informer --service-type-filterLoadBalancer再配合标签或注解过滤进一步缩小被列入的 Service 对象集合--label-filterexternal-dns/enabledtrue --annotation-filterexternal-dns.kubernetes.io/hostname下表展示了--service-type-filter会消除哪些 informer过滤值被移除的 informerLoadBalancerPods, EndpointSlices, NodesLoadBalancer,ExternalNamePods, EndpointSlices, NodesClusterIPNodesNodePort(无——所有 informer 均需保留)注意informer 作用域的缩减是类型过滤的副作用而非其主要目的。请始终根据你实际需要发布的 DNS 记录来选择过滤值内存缩减只是额外收益。--service-type-filter的取值在 pkg/apis/externaldns/types.go 中定义可选ClusterIP、NodePort、LoadBalancer、ExternalName默认全部启用可多次指定。削减启动内存峰值初始同步期间的内存峰值是client-go经典 LIST 代码路径的已知局限。一种名为WatchListWatchListClient特性开关的流式替代方案可以避免该峰值它通过带SendInitialEventstrue的 Watch 逐条接收对象而不是一次性拉取全部对象。WatchListClient特性开关在近期版本的 client-go 中默认开启true因此运行最新版 external-dns 时该峰值实际上已被消除。在旧版本上--service-type-filter是主要的缓解手段。请务必使用最新版本。注意即使启用了 WatchList所有 informer 类型上仍然需要 transformer 与 indexer 来降低稳态内存。相关工作正在各 source 之间持续推进。Source 配置与预检校验当配置的 source 无法初始化时 external-dns 会快速失败——这是有意为之。Crashloop 是配置错误的一个清晰、明确的信号。静默跳过损坏的 source 会掩盖问题使故障更难诊断。生产安全应当来自正确的配置与预检校验而非 external-dns 对用户意图的猜测。故障模式并不总是显而易见难点在于RBAC 问题与缺失 CRD 并不总以干净、显式的错误形式呈现。取决于配置错在哪里故障模式可能是超时、空结果或静默停滞而不是崩溃误配置典型症状为何隐蔽CRD 未安装约 60s 后出现context deadline exceededInformer 阻塞等待缓存同步没有 CRD not found 消息无 LIST 权限403 Forbidden→ 退出通常很清晰但错误可能引用难以映射回 source 的内部 API 路径允许 LIST、拒绝 WATCHInformer 启动但再也收不到更新DNS 记录看起来过期启动后无崩溃、无错误日志Admission Webhook 配置错误Source 初始化成功变更被静默拒绝external-dns 看不到任何错误记录永远不创建或更新LIST 而无 WATCH的情况尤其危险external-dns 干净地启动、报告健康状态但它对集群的视图冻结在最后一次成功 LIST 的时刻。DNS 记录将偏离实际集群状态而日志与指标中不会有任何提示。实践建议显式限定启用的 source。只配置目标集群完全支持的--source类型——正确的 CRD 已安装、RBAC 已授予、Admission Webhook 已配置。不要依赖任何形式的尽力而为或优雅降级。# 只配置此集群上存在且有权限的类型 --sourceservice --sourceingress先安装 CRD再启用依赖它的 source。对于依赖自定义资源的 sourceGateway API、Istio、CRD source请先安装 CRD 并确认其已 establishedkubectl get crd name显示ESTABLISHED然后才添加对应的--source标志。缺失 CRD 并不总会产生 not found 错误——它可能导致 informer 缓存同步阻塞并超时启动时表现为泛化的context deadline exceeded且不指明缺的是哪个 CRD。多集群部署使用按集群区分的 source 列表。通过 Helm 或 ArgoCD 管理 CRD 配置不同的集群时请为每个集群分别定义 source 列表而不是共享单一配置。在装有 Gateway API 的集群上可行的配置在未装的集群上会 crashloop。# values-cluster-a.yaml (已安装 Gateway API) sources: - service - gateway-httproute # values-cluster-b.yaml (未安装 Gateway API) sources: - service - ingress尽早校验配置——在 CI 中失败而非生产环境。在 CI 或部署前管道中加入启动检查在镜像生产 CRD 与 RBAC 配置的 staging 集群上运行--dry-run --once。注意--once单独使用会应用真实的 DNS 变更务必与--dry-run搭配用于校验。在 staging 中崩溃代价很小在生产中 crashloop 会影响到所有托管记录直到 Pod 重启为止。使用最小化 RBAC。只授予 external-dns 完成已配置 source 所需的最小 API 访问。多余权限是安全隐患如果某个 source 被意外加入配置external-dns 会静默开始监听它本不该管理的资源。已配置 source 的权限不足会在启动时崩溃——这正是预期的信号——但前提是 RBAC 足够收紧才能让问题暴露出来。大规模集群上的扩展扩展 external-dns 归结为三条原则的组合运用资源收敛Scope resourcesexternal-dns 监听的 Kubernetes 对象越少、管理的 DNS Zone 越少其稳态内存、API 调用量与 reconcile 耗时就越低。在每一层可用维度上应用过滤——服务类型、标签、注解、域名、Zone ID。详见 资源作用域与内存 与 Domain Filter。--domain-filter、--regex-domain-filter、--exclude-domains、--regex-domain-exclusion等标志的完整语义与匹配逻辑均可在此参考页面中找到。拆分实例Split instances管理大量 Zone 或 source 的单一 external-dns 实例会拥有巨大的 reconcile 面与漫长的 reconcile 周期。拆分为多个实例——每个实例负责不同的 Zone 集合、命名空间或 source 类型——可以降低单实例负载并使故障的爆炸半径更小。每个实例必须使用独立的--txt-owner-id且--domain-filter或--zone-id-filter作用域不得重叠以避免所有权冲突。参见 状态冲突与所有权。降低 reconcile 压力Reduce reconcile pressure让 reconcile 频率匹配实际变更速率而不是一直运行在默认间隔上。使用事件驱动的 reconcile 来快速响应真实变更同时保持低频的后台轮询。如果单个 Kubernetes API 调用在缓慢或高负载的 API Server 上超时请提高--kube-api-request-timeout默认每请求 30s见 pkg/apis/externaldns/types.go。Kubernetes API 限流。external-dns 继承了 client-go 的内置默认值Kubernetes API 调用 5 QPS / 10 burstrest.DefaultQPS与rest.DefaultBurst见 pkg/apis/externaldns/types.go。在管理大量 source 或高频 reconcile 的集群上这些默认值可能过低导致节流在与其他控制器共享 API 配额时则可能需要调低以免饿死更高优先级的控制器。# 为管理大量 source 的高吞吐实例提高上限 --kube-api-qps20 --kube-api-burst40 # 为繁忙集群上的低优先级实例降低上限 --kube-api-qps2 --kube-api-burst5当触及上限时external-dns 会打印包含consider raising --kube-api-qps/--kube-api-burst的错误日志使原因可操作。两个标志在未设置时都回落到 client-go 内置值5 QPS / 10 burst。有关批量变更大小、记录缓存与 Zone 列表缓存的各 Provider 专属标志参见 DNS Provider API 速率限制 与 Provider 注意事项。可观测性Observability关键指标以下指标是诊断运维问题时首先应该查看的指标何时告警external_dns_controller_consecutive_soft_errors超过一个 reconcile 周期仍 0external_dns_source_errors_total持续增长来自 informer 的 Kubernetes API 错误external_dns_registry_errors_total任何增长TXT / DynamoDB registry 失败external_dns_controller_verified_records意外下降记录不再归本实例所有这些指标的定义与注册可参见 controller/metrics.gosourceErrorsTotal与registryErrorsTotal分别以source与registry为子系统前缀构成external_dns_source_errors_total与external_dns_registry_errors_totalverifiedRecords统计同时存在于 source 与 registry的记录数consecutiveSoftErrors统计 reconcile 循环中连续软错误的次数并在成功 reconcile 后归零见 controller/controller.go。完整指标清单参见 Available Metrics。未来计划一个external_dns_source_invalid_endpointsgauge按record_type与source_type分区正在开发中它会在每个 reconcile 周期重置并重新填充届时无需 grep 日志即可直接对丢失的端点告警。在该指标落地之前请关注external_dns_source_errors_total并启用--events-emitRecordError见下文。面向无效端点的 Kubernetes Events无效端点——CNAME 自引用、格式错误的 MX/SRV 记录、不支持的 alias 类型——会在默认日志级别下被去重层静默丢弃仅留下一条日志警告。没有结构化可观测性时唯一发现它们的方式是 grep 日志。启用RecordError事件将无效端点直接呈现在负责的 Kubernetes 资源上--events-emitRecordError# 检查集群中的无效端点 kubectl get events --field-selector reasonRecordError # 或限定到特定资源 kubectl describe ingress my-ingress--events-emit支持多次指定可选值包括RecordReady、RecordDeleted、RecordError默认不发射任何事件见 pkg/apis/externaldns/types.go。事件的Reason如RecordReady/RecordDeleted/RecordError、TypeNormal/Warning、Action字段以及通过kubectl get events --field-selector reportingComponentexternal-dns消费事件的完整说明参见 Kubernetes Events in External-DNS。状态冲突与所有权external-dns 检测期望状态与当前状态、计算变更计划并应用它——前提是计划内部自洽。当 Provider 返回冲突错误HTTP 409 或等价错误时意味着当前 DNS 状态与 external-dns 的预期不匹配。这是一个状态问题而非软件缺陷。注解与期望状态的正确性是运维人员的责任。external-dns 无法自动纠正用户定义的配置任何自动纠正都可能删除或替换服务依赖的 DNS 记录导致这些服务不可达。因此 external-dns 尽最大努力让这些问题可见交由运维人员审慎修复。它没有通用的冲突解决策略它会丢弃一些众所周知的无效记录如 CNAME 自引用但不会应用部分变更、自动纠正任意冲突或尝试部分尽力而为行为。在不改变输入或协调外部状态的情况下重试同一请求将确定性地失败。Crashloop 放大效应。导致 external-dns 退出的硬错误会引发 crashloopkubelet 重启 Podinformer 对每种被监听资源类型Services、Pods、EndpointSlices、Nodes执行完整 LIST 重新同步然后再次尝试同一批冲突的变更。每次重启都重复该循环逐步增加对 Kubernetes API Server 的 LIST 流量。在大集群或高重启频率下这会加剧 Kubernetes API 节流波及的不只是 external-dns还有其他控制器与工作负载。需要特别注意的是杀死进程的硬错误不会递增external_dns_controller_consecutive_soft_errors——该指标只跟踪软错误。请通过kube_pod_container_status_restarts_total监控 Pod 重启并对 crashloop backoffCrashLoopBackOff状态设置告警以便尽早捕获此问题。当观察到冲突错误时请修复状态确保每个 Zone 或记录集只有一个 external-dns 实例拥有。使用 TXT 或 DynamoDB registry 时为每个实例使用独立的--txt-owner-id并避免--domain-filter作用域重叠。直接在 DNS Provider 中删除或更新冲突记录。审查注解与期望状态中的无效记录定义——例如同一主机名混用 CNAME 与 A/AAAA 记录或 CNAME 指向自身。检查是否有其他控制器或自动化脚本在向同一 Zone 写入。如果迁移或事故期间环境处于不一致状态可将 external-dns 缩容至零待状态协调一致后再扩容回来。可见性相关工作正在推进目标是在状态问题演变为事故之前尽可能使其可见。计划中的改进包括按记录类型统计被拒绝端点以及直接在负责资源上发射 Kubernetes Events使运维无需 grep 日志即可对冲突告警。如果你遇到现有指标或事件未覆盖的冲突或误配置请提交 issue 或 PR。Provider 注意事项Zone 列表缓存每次 reconcile 时external-dns 都会调用 Provider API 枚举其被允许管理的 Zone。对于拥有大量 Zone 的账号或 API 限流严格的 Provider即使没有任何 DNS 记录变更该枚举也可能构成可观的 API 流量。部分 Provider 支持 Zone 列表缓存将 Zone 列表在内存中缓存一段可配置的 TTL仅在过期后重新拉取。请将 TTL 设置为贴合你的 Zone 列表实际变更频率的值——大多数部署中 Zone 的增删很少见因此1h或更长的值是合适的。注意Zone 列表缓存不同于记录缓存--provider-cache-time后者缓存的是 Zone 内的 DNS 记录。两者可以同时使用。各 Provider 的标志参见 DNS Provider API 速率限制。从源码结构看该机制由 provider/blueprint/zone_cache.go 中的泛型ZoneCache[T]实现它提供 TTL 过期、线程安全的Get/ResetTTL 为 0 时表示禁用缓存。AWS 与 Azure 等 Provider 已集成该实现参见 provider/aws/aws.go 中的AWSZoneCacheDuration与 provider/azure/azure.go 中的 Zone 缓存对应标志在 pkg/apis/externaldns/types.go 中有默认值定义默认 0即不缓存。将 Provider 凭据限定到特定 ZoneProvider 的 API Key 或 IAM Role 应被限定到 external-dns 预期管理的 Zone。授予账号内所有 Zone 的访问权限会带来两个后果运维层面external-dns 会枚举并可能修改凭据可达的每一个 Zone。一个配置错误的过滤器或缺失的--txt-owner-id可能对预期范围之外的 Zone 造成意外变更。安全层面凭据泄露会暴露账号内的所有 Zone而不仅仅是 external-dns 管理的那些。Zone 过滤标志表达的是应用层面的意图并减少 API 调用量但它们不是执行边界——凭据才是。详见 Domain Filter。批量 APIBatch API对于变更集频繁或庞大的 Zone逐记录地调用 API 会迅速耗尽 Provider 的速率限制。在支持批量 API 的 Provider 上批量提交可以显著减少调用量。具体的缩减幅度因 Provider 而异但一般规律是方式每次同步的 API 调用数逐记录随变更记录数线性增长批量随批次数增长而非记录数当一批提交失败时例如批中某条记录配置错误Provider 通常会回退到该同步周期的逐记录调用因此单条坏记录不会阻塞 Zone 内其余 DNS 记录的更新。各 Provider 的批量标志参见 DNS Provider API 速率限制。延伸阅读Flags reference — 完整标志列表与默认值DNS Provider API 速率限制 — 批量大小、Provider 缓存与限流调优Domain Filter — 域名与 Zone 过滤以及凭据边界的区分Kubernetes Events in External-DNS — 事件类型、来源与消费方式Available Metrics — 完整指标参考赞分享云原生【免费下载链接】external-dnsConfigure external DNS servers dynamically from Kubernetes resources项目地址https://gitcode.com/gh_mirrors/ex/external-dns点击查看免费下载相关推荐docling 完整指南4 步把 PDF、Word 和图片转成 Markdown 喂给大模型docling 完整指南4 步把 PDF、Word 和图片转成 Markdown 喂给大模型 你正要搭一个 RAG 知识库桌上堆着 PDF、Word 报告和AI 应用计算机视觉OCR智能体可观测性与监控生产环境最佳实践智能体可观测性与监控生产环境最佳实践 本文详细探讨了AI智能体在生产环境中的可观测性与监控最佳实践涵盖了运行状态追踪技术、错误日志与重试机制设计、性能监控与教程文档AI Agent人工智能5步掌握ComfyUI Joy Caption插件AI图片智能描述的终极解决方案5步掌握ComfyUI Joy Caption插件AI图片智能描述的终极解决方案 还在为AI生成的图片找不到合适的描述而烦恼吗还在手动为数千张训练图片编写标上一篇彻底解决MyBatis-Plus多表查询痛点2.0新特性与Chain链式编程实战指南下一篇从0到1开发微信AI名片小程序原生架构全解析与实战指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考