ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

GKE 上使用 nginx-ingress-controller 部署 ExternalDNS:从节点 Scopes 到 Workload Identity 的完整实战指南

2026/9/25 3:39:40 拓冰建站 浏览量
GKE 上使用 nginx-ingress-controller 部署 ExternalDNS:从节点 Scopes 到 Workload Identity 的完整实战指南 云原生【免费下载链接】external-dnsConfigure external DNS servers dynamically from Kubernetes resources项目地址https://gitcode.com/gh_mirrors/ex/external-dns点击查看免费下载本教程对应仓库 docs/tutorials/gke-nginx.md讲解如何在 Google Kubernetes EngineGKE集群中部署 ExternalDNS使其基于 Kubernetes Ingress 资源自动管理 Google Cloud DNS 记录——前提是不使用 Google 默认的 ingress-gce 控制器而是改用社区广泛使用的 nginx-ingress-controller。读完本文你将掌握 GKE 集群创建与 DNS Zone 委派、nginx ingress controller 的两种部署形态、ExternalDNS 的 RBAC 与核心参数配置以及基于节点 Scopes 与基于 Workload Identity 两套授权方案的完整落地步骤与清理流程。教程背景与两条主线ExternalDNS 的作用是“把 Kubernetes 资源本教程中是 Ingress翻译成 DNS 记录”并同步到指定的 DNS 提供商。其数据流可以概括为source发现资源与主机名→ registry记录记录所有权→ provider读写 DNS 提供商 API。本教程给出两条并行的部署主线GKE Node Scopes 方案把 Google Cloud DNS 的读写权限直接挂在 GKE 节点实例上集群内所有 Pod 都继承该权限适合测试环境。GKE Workload Identity 方案通过 GCP 服务账号GSA与 Kubernetes 服务账号KSA的映射把 DNS 权限精确授予 ExternalDNS 这一个工作负载是 Google 官方推荐的面向生产的方式。两条主线共享同一套 DNS Zone 创建、父域 NS 委派、示例应用与验证手段只是“授权”环节与 ExternalDNS 的部署形态略有差异。环境准备gcloud 配置开始之前先用 gcloud 把本地环境指向目标 GCP 项目与计算区域。请按实际值替换例如目标项目gcloud config set project zalando-external-dns-test gcloud config set compute/region europe-west1 gcloud config set compute/zone europe-west1-d方案一基于 GKE 节点 Scopes 部署创建集群不使用默认 ingress 控制器本方案把 DNS 权限与 GKE 节点实例绑定因此集群内所有 Pod 都会拥有这些权限只适合测试环境不适合生产。创建集群时通过--scopes传入 Google Cloud DNS 的读写 scope$ gcloud container clusters create external-dns \ --num-nodes 1 \ --scopes https://www.googleapis.com/auth/ndev.clouddns.readwrite创建托管 DNS Zone创建用于存放 ExternalDNS 管理记录的公网托管 Zone$ gcloud dns managed-zones create external-dns-test-gcp-zalan-do \ --dns-name external-dns-test.gcp.zalan.do. \ --description Automatically managed zone by ExternalDNS记录新 Zone 的 Nameserver 并做父域委派托管 Zone 创建后Google 会为其分配一组 NS 记录查询确认$ gcloud dns record-sets list \ --zone external-dns-test-gcp-zalan-do \ --name external-dns-test.gcp.zalan.do. \ --type NS NAME TYPE TTL DATA external-dns-test.gcp.zalan.do. NS 21600 ns-cloud-e1.googledomains.com.,ns-cloud-e2.googledomains.com.,ns-cloud-e3.googledomains.com.,ns-cloud-e4.googledomains.com.本例中是ns-cloud-{e1-e4}.googledomains.com.不同 Zone 可能略有差异例如{a1-a4}、{b1-b4}等。必须在父域即gcp.zalan.do所属的托管 Zone中添加指向子 Zone 的 NS 记录DNS 解析才会生效。假设父域 Zone 名为gcp-zalan-do同样托管在 Google执行$ gcloud dns record-sets transaction start --zone gcp-zalan-do $ gcloud dns record-sets transaction add ns-cloud-e{1..4}.googledomains.com. \ --name external-dns-test.gcp.zalan.do. --ttl 300 --type NS --zone gcp-zalan-do $ gcloud dns record-sets transaction execute --zone gcp-zalan-do连接 kubectl 并绑定集群管理员$ gcloud container clusters get-credentials external-dns $ kubectl create clusterrolebinding cluster-admin-me \ --clusterrolecluster-admin --user$(gcloud config get-value account)部署 nginx ingress controllernginx ingress controller 有两种常见部署形态ExternalDNS 对两者都支持因为它只关心 Ingress 的status中最终暴露的地址详见下文 Ingress source 如何生成端点。默认后端Default Backendnginx 控制器在没有匹配的 Ingress 规则时会回落到一个“默认后端”。它可以是独立部署的 Service这里使用与其他 ingress 控制器一致的默认后端清单apiVersion: v1 kind: Service metadata: name: default-http-backend spec: ports: - port: 80 targetPort: 8080 selector: app: default-http-backend --- apiVersion: apps/v1 kind: Deployment metadata: name: default-http-backend spec: selector: matchLabels: app: default-http-backend template: metadata: labels: app: default-http-backend spec: containers: - name: default-http-backend image: gcr.io/google_containers/defaultbackend:1.3模式 A无独立 TCP 负载均衡器hostPort默认情况下控制器会把运行 nginx 实例的节点公网 IP写入 Ingress 对象的 status。为了应对 Pod 或节点故障应当运行多个副本——控制器会做 leader election并在 Ingress 的 targets 中放入多个 IP也可以考虑以 DaemonSet 方式运行。本教程只跑单个副本。由于流量直接打到节点端口需要先在 worker 节点上放行 80/443 端口gcloud compute firewall-rules create allow-http --allow tcp:80 --source-ranges 0.0.0.0/0 --target-tags gke-external-dns-9488ba14-node gcloud compute firewall-rules create allow-https --allow tcp:443 --source-ranges 0.0.0.0/0 --target-tags gke-external-dns-9488ba14-node--target-tags要改成你节点的实际标签可以通过gcloud compute instances describe查看实例或直接查看 GKE 为集群创建的默认防火墙规则。然后部署控制器。注意它通过--default-backend-service引用默认后端并监听 hostPort某些环境还需加hostNetwork: trueapiVersion: apps/v1 kind: Deployment metadata: name: nginx-ingress-controller spec: selector: matchLabels: app: nginx-ingress-controller template: metadata: labels: app: nginx-ingress-controller spec: containers: - name: nginx-ingress-controller image: gcr.io/google_containers/nginx-ingress-controller:0.9.0-beta.3 args: - /nginx-ingress-controller - --default-backend-servicedefault/default-http-backend env: - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace ports: - containerPort: 80 hostPort: 80 - containerPort: 443 hostPort: 443模式 B独立 TCP 负载均衡器LoadBalancer Service推荐更可靠的做法是让控制器通过一个 Kubernetes Service 暴露即用typeLoadBalancer的四层负载均衡器兜住 nginx 代理。这会指示控制器把该 Service 的外部 IP作为 Ingress 的外部 IP。这样 nginx 副本数量可以任意伸缩也不依赖节点端口与防火墙规则是本教程更推荐的方式。注意与模式 A 的差异控制器多了--publish-service参数指明哪个 Service 是它的公网入口同时不再需要 hostPortapiVersion: v1 kind: Service metadata: name: nginx-ingress-controller spec: type: LoadBalancer ports: - name: http port: 80 targetPort: 80 - name: https port: 443 targetPort: 443 selector: app: nginx-ingress-controller --- apiVersion: apps/v1 kind: Deployment metadata: name: nginx-ingress-controller spec: selector: matchLabels: app: nginx-ingress-controller template: metadata: labels: app: nginx-ingress-controller spec: containers: - name: nginx-ingress-controller image: gcr.io/google_containers/nginx-ingress-controller:0.9.0-beta.3 args: - /nginx-ingress-controller - --default-backend-servicedefault/default-http-backend - --publish-servicedefault/nginx-ingress-controller env: - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace ports: - containerPort: 80 - containerPort: 443说明上面两份清单中的nginx-ingress-controller:0.9.0-beta.3是教程撰写时期的镜像。当前生产环境请使用 ingress-nginx 项目的最新稳定版清单与镜像部署思路完全一致。部署 ExternalDNS应用下面的清单创建 ServiceAccount、ClusterRole、ClusterRoleBinding 与 DeploymentapiVersion: v1 kind: ServiceAccount metadata: name: external-dns --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: external-dns rules: - apiGroups: [] resources: [services,pods] verbs: [get,watch,list] - apiGroups: [discovery.k8s.io] resources: [endpointslices] verbs: [get,watch,list] - apiGroups: [extensions,networking.k8s.io] resources: [ingresses] verbs: [get,watch,list] - apiGroups: [] resources: [nodes] verbs: [list] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: external-dns-viewer roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: external-dns subjects: - kind: ServiceAccount name: external-dns namespace: default --- apiVersion: apps/v1 kind: Deployment metadata: name: external-dns spec: strategy: type: Recreate selector: matchLabels: app: external-dns template: metadata: labels: app: external-dns spec: serviceAccountName: external-dns containers: - name: external-dns image: registry.k8s.io/external-dns/external-dns:v0.23.0 args: - --sourceingress - --policyupsert-only # prevents ExternalDNS from deleting any records, set --policysync to enable full synchronization (including deletions) - --domain-filterexternal-dns-test.gcp.zalan.do - --providergoogle - --google-projectzalando-external-dns-test - --registrytxt - --txt-owner-idmy-identifier逐个拆解这些参数定义与默认值均可从仓库 pkg/apis/externaldns/types.go 中查到--sourceingress必选参数app.Flag(source, ...).Required()。声明数据来源为 Ingress 资源。Ingress source 的实现见 source/ingress.go它列出所有命名空间的 Ingress、按 ingressClass 过滤、读取spec.rules[].host作为主机名、读取 Ingress 的status.loadBalancer作为目标地址从而生成 endpoint。--policyupsert-only同步策略可选值sync、upsert-only、create-only定义见 pkg/apis/externaldns/types.go。upsert-only只新增/更新记录、绝不删除改成--policysync则做全量同步含删除。首轮上线建议先用upsert-only兜底。--domain-filterexternal-dns-test.gcp.zalan.do限定只管理后缀匹配的域名与目标 Zone可多次指定见 pkg/apis/externaldns/types.go。这也是“只碰自己 Zone、不影响他人记录”的关键护栏。--providergoogle必选参数指定 Google Cloud DNS 作为提供商。--google-projectzalando-external-dns-testGoogle provider 运行在 GCP 上时会自动探测当前项目指定它则强制使用该 GCP 项目见 pkg/apis/externaldns/types.go在 GCP 之外运行或跨项目管理时必须有此参数。该值最终传入newProvider(ctx, cfg.GoogleProject, ...)参见 provider/google/google.go。Google provider 还支持--google-batch-change-size、--google-batch-change-interval、--google-zone-visibility等可选调优参数。--registrytxt记录所有权的登记方式默认就是txt可选aws-sd、crd、dynamodb、noop、txt见 pkg/apis/externaldns/types.go。TXT 模式会在每条记录旁写入一条带所有者标识的 TXT 记录供 ExternalDNS 判断“哪些记录是我管的”。--txt-owner-idmy-identifier与--registrytxt配合标识“这一实例”的 ID默认值default见 pkg/apis/externaldns/types.go。多套 ExternalDNS 共管同一 Zone 时务必为每套设置不同的 owner id避免互相“抢记录”。RBAC 部分ClusterRole 授予了services、pods、endpointslicesdiscovery.k8s.io、ingressesextensions/networking.k8s.io的get/watch/list以及nodes的list——这些正是 Ingress source 发现端点所需的最小权限集。如果首跑想更谨慎可加上--dry-run。注意 dry-run 模式下不会真正创建任何记录你只能从日志里观察 ExternalDNS“原本会做什么”该参数的语义见 pkg/apis/externaldns/types.go。部署示例应用并验证创建下面的示例应用验证链路Ingress 的 host 指向via-ingress.external-dns-test.gcp.zalan.do后端是一个 nginx Service。apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: nginx spec: ingressClassName: nginx rules: - host: via-ingress.external-dns-test.gcp.zalan.do http: paths: - path: / backend: service: name: nginx port: number: 80 pathType: Prefix --- apiVersion: v1 kind: Service metadata: name: nginx spec: ports: - port: 80 targetPort: 80 selector: app: nginx --- apiVersion: apps/v1 kind: Deployment metadata: name: nginx spec: selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - image: nginx name: nginx ports: - containerPort: 80大约两分钟后在托管 Zone 中确认 A 记录已创建$ gcloud dns record-sets list \ --zone external-dns-test-gcp-zalan-do \ --name via-ingress.external-dns-test.gcp.zalan.do. \ --type A NAME TYPE TTL DATA via-ingress.external-dns-test.gcp.zalan.do. A 300 35.187.1.246再用 dig 直接向该 Zone 的 nameserver 发起解析验证$ dig short ns-cloud-e1.googledomains.com. via-ingress.external-dns-test.gcp.zalan.do. 35.187.1.246最后用 curl 验证整条 HTTP 链路$ curl via-ingress.external-dns-test.gcp.zalan.do !DOCTYPE html html head titleWelcome to nginx!/title ... /head body ... /body /html清理先删除 Service 与 Ingress确保负载均衡器和 DNS 条目被正确回收kubectl delete service nginx-ingress-controller kubectl delete ingress nginx给 ExternalDNS 一点时间清理它管理的 DNS 记录然后删除托管 Zone 与集群gcloud dns managed-zones delete external-dns-test-gcp-zalan-do gcloud container clusters delete external-dns最后从父域 Zone 移除刚才添加的 NS 记录$ gcloud dns record-sets transaction start --zone gcp-zalan-do $ gcloud dns record-sets transaction remove ns-cloud-e{1..4}.googledomains.com. \ --name external-dns-test.gcp.zalan.do. --ttl 300 --type NS --zone gcp-zalan-do $ gcloud dns record-sets transaction execute --zone gcp-zalan-do方案二基于 GKE Workload Identity 部署Workload Identity 是 Google 推荐的、把 GCP API 权限授予 GKE 工作负载的方式不再把权限挂在节点上而是通过“GCP 服务账号GSA↔ Kubernetes 服务账号KSA”的绑定关系让 ExternalDNS 这一工作负载单独获得 Cloud DNS 权限。创建启用 Workload Identity 的集群创建集群时启用 Workload Identity并且不使用 HttpLoadBalancing add-on因为我们用 ingress-nginx 而非 GCE 默认控制器$ gcloud container clusters create external-dns \ --workload-metadata-from-nodeGKE_METADATA_SERVER \ --identity-namespacezalando-external-dns-test.svc.id.goog \ --addonsHorizontalPodAutoscaling创建 GCP 服务账号GSA为 ExternalDNS 创建专用 GSA并保存其邮箱地址供后续步骤使用$ sa_nameKubernetes external-dns $ gcloud iam service-accounts create sa-edns --display-name$sa_name $ sa_email$(gcloud iam service-accounts list --formatvalue(email) \ --filterdisplayName:$sa_name)给 GSA 绑定 DNS 管理员角色$ gcloud projects add-iam-policy-binding zalando-external-dns-test \ --memberserviceAccount:$sa_email --roleroles/dns.admin建立 GSA 与 KSA 的映射关系将 GSA 与 ExternalDNS 将要运行于其下的 Kubernetes 服务账号即external-dns命名空间中的external-dnsKSA关联起来。roles/iam.workloadIdentityUser授权 GSA 接受来自该命名空间服务账号的身份交换$ gcloud iam service-accounts add-iam-policy-binding $sa_email \ --memberserviceAccount:zalando-external-dns-test.svc.id.goog[external-dns/external-dns] \ --roleroles/iam.workloadIdentityUser创建 DNS Zone 并做父域委派步骤与方案一相同创建托管 Zone$ gcloud dns managed-zones create external-dns-test-gcp-zalan-do \ --dns-nameexternal-dns-test.gcp.zalan.do. \ --descriptionAutomatically managed zone by ExternalDNS记录其 nameserver$ gcloud dns record-sets list \ --zoneexternal-dns-test-gcp-zalan-do \ --nameexternal-dns-test.gcp.zalan.do. \ --type NS NAME TYPE TTL DATA external-dns-test.gcp.zalan.do. NS 21600 ns-cloud-e1.googledomains.com.,ns-cloud-e2.googledomains.com.,ns-cloud-e3.googledomains.com.,ns-cloud-e4.googledomains.com.同样在父域 Zonegcp-zalan-do中添加指向该子 Zone 的 NS 记录$ gcloud dns record-sets transaction start --zonegcp-zalan-do $ gcloud dns record-sets transaction add ns-cloud-e{1..4}.googledomains.com. \ --nameexternal-dns-test.gcp.zalan.do. --ttl 300 --type NS --zonegcp-zalan-do $ gcloud dns record-sets transaction execute --zonegcp-zalan-do连接 kubectl 并绑定管理员$ gcloud container clusters get-credentials external-dns $ kubectl create clusterrolebinding cluster-admin-me \ --clusterrolecluster-admin --user$(gcloud config get-value account)部署 ingress-nginx参照 ingress-nginx 官方文档的 GKE/GCE 安装说明部署控制器。教程原始文件使用的是 controller-v0.35.0 的云环境部署清单应用该清单即可建议使用与集群兼容的最新稳定版清单$ kubectl apply -f ingress-nginx 官方提供的 GKE/GCE 部署清单部署 ExternalDNS独立命名空间 Workload IdentityWorkload Identity 方案的清单与方案一相比有三个变化放入独立的external-dns命名空间通过securityContext以非 root 用户UID 65534即nobody运行Deployment 不再携带--google-project因为身份由 Workload Identity 提供、项目会自动解析若需跨项目仍可按需保留该参数。apiVersion: v1 kind: Namespace metadata: name: external-dns --- apiVersion: v1 kind: ServiceAccount metadata: name: external-dns namespace: external-dns --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: external-dns rules: - apiGroups: [] resources: [services, pods] verbs: [get, watch, list] - apiGroups: [discovery.k8s.io] resources: [endpointslices] verbs: [get,watch,list] - apiGroups: [extensions, networking.k8s.io] resources: [ingresses] verbs: [get, watch, list] - apiGroups: [] resources: [nodes] verbs: [list] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: external-dns-viewer roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: external-dns subjects: - kind: ServiceAccount name: external-dns namespace: external-dns --- apiVersion: apps/v1 kind: Deployment metadata: name: external-dns namespace: external-dns spec: strategy: type: Recreate selector: matchLabels: app: external-dns template: metadata: labels: app: external-dns spec: containers: - args: - --sourceingress - --policyupsert-only # prevents ExternalDNS from deleting any records, set --policysync to enable full synchronization (including deletions) - --domain-filterexternal-dns-test.gcp.zalan.do - --providergoogle - --google-projectzalando-external-dns-test - --registrytxt - --txt-owner-idmy-identifier image: registry.k8s.io/external-dns/external-dns:v0.23.0 name: external-dns securityContext: fsGroup: 65534 runAsUser: 65534 serviceAccountName: external-dns最后把 GSA 通过注解挂到 KSA 上完成 Workload Identity 的最后一步绑定教程原文此处误写为 cert-manager 的服务账号实际注解的对象是external-dns命名空间下的external-dns服务账号$ kubectl annotate serviceaccount --namespaceexternal-dns external-dns \ iam.gke.io/gcp-service-account$sa_email部署示例应用并验证示例 Ingress/Service/Deployment 与方案一完全相同apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: nginx spec: ingressClassName: nginx rules: - host: via-ingress.external-dns-test.gcp.zalan.do http: paths: - path: / backend: service: name: nginx port: number: 80 pathType: Prefix --- apiVersion: v1 kind: Service metadata: name: nginx spec: ports: - port: 80 targetPort: 80 selector: app: nginx --- apiVersion: apps/v1 kind: Deployment metadata: name: nginx spec: selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - image: nginx name: nginx ports: - containerPort: 80约两分钟后确认 A 记录已创建$ gcloud dns record-sets list \ --zone external-dns-test-gcp-zalan-do \ --name via-ingress.external-dns-test.gcp.zalan.do. \ --type A NAME TYPE TTL DATA via-ingress.external-dns-test.gcp.zalan.do. A 300 35.187.1.246用 dig 直接向该 Zone 的 nameserver 发起解析$ dig short ns-cloud-e1.googledomains.com. via-ingress.external-dns-test.gcp.zalan.do. 35.187.1.246再用 curl 验证$ curl via-ingress.external-dns-test.gcp.zalan.do !DOCTYPE html html head titleWelcome to nginx!/title ... /head body ... /body /html清理kubectl delete service --namespaceingress-nginx ingress-nginx-controller kubectl delete ingress nginx等待 ExternalDNS 清理完 DNS 记录后删除托管 Zone 与集群gcloud dns managed-zones delete external-dns-test-gcp-zalan-do gcloud container clusters delete external-dns并从父域移除 NS 记录$ gcloud dns record-sets transaction start --zone gcp-zalan-do $ gcloud dns record-sets transaction remove ns-cloud-e{1..4}.googledomains.com. \ --nameexternal-dns-test.gcp.zalan.do. --ttl 300 --type NS --zonegcp-zalan-do $ gcloud dns record-sets transaction execute --zonegcp-zalan-do两种授权方案对比维度节点 Scopes 方案Workload Identity 方案授权对象节点实例集群内所有 Pod 继承单个 Kubernetes 服务账号权限粒度粗无法细分到工作负载细可精确到命名空间/工作负载适用场景测试/快速验证生产符合最小权限原则额外 GCP 对象无GSA、两条 IAM Policy Binding、KSA 注解外部访问非 GCP 内需额外配置服务账号密钥依赖集群内的元数据服务器从源码结构看两套方案最终落到 ExternalDNS 的同一套参数模型上--providergoogle--domain-filter--registrytxt--txt-owner-id的组合决定了“写哪些 Zone、由谁认领”而权限获取方式只影响进程能拿到的凭证——这正是 ExternalDNS 把“发现/计划/执行”与“鉴权”解耦的设计。Ingress source 如何生成端点原理补充从 source/ingress.go 可以看到 Ingress source 的核心逻辑Endpoints()会列出所有命名空间的 Ingress 资源并通过filterByIngressClass按 ingressClass 过滤对应示例 Ingress 中的ingressClassName: nginx对每个 Ingress取spec.rules[].host作为主机名如果 host 缺失还可以走 FQDN 模板引擎生成主机名endpointsFromTemplate目标地址优先取注解指定的 targets否则回落到targetsFromIngressStatus(ing.Status)——即读取 Ingress 的status.loadBalancer.ingress[].ip。这正是教程两种 nginx 控制器部署形态都能工作的原因无论地址来自节点 IPhostPort 模式还是 LoadBalancer Service 的外部 IP--publish-service模式只要写入了 Ingress statusExternalDNS 就能读到最后把每个“主机名 × 目标地址”组合封装为 endpoint并交给后续的 registry 与 provider 处理。常见问题与调试建议记录迟迟不出现先确认--dry-run是否被误开启dry-run 不会创建任何记录再用kubectl logs -f deployment/external-dns观察日志同时确认 Ingress 的status.loadBalancer是否已有地址kubectl get ingress nginx -o wide。dig 解析失败优先排查父域 NS 委派是否正确添加、TTL本例 300 秒与dig short zone 的 nameserver是否指向了正确服务器DNS 是分层的全局递归生效需要时间。多套 ExternalDNS 互相干扰给每套实例设置不同的--txt-owner-id并用--domain-filter明确划分各自负责的域名后缀。误删风险控制生产环境建议先用--policyupsert-only运行并观察确认无误后再切换--policysync。Zone 太多想收敛可以叠加--google-zone-visibilitypublic之类的过滤参数让 Google provider 只处理公网 Zone。延伸阅读本教程是 ExternalDNS 众多云上实战之一。若需深入可继续阅读仓库内的 docs/tutorials/aws.md、docs/tutorials/azure.md 等同类云厂商教程以及 docs/tutorials/webhook-provider.md 了解如何以 webhook 方式接入自定义 DNS 提供商关于 TXT registry 的运作细节可参考 docs/registry/txt.md。社区也有用户分享的《Kubernetes, ingress-nginx, cert-manager external-dns》实战博客演示了在 GKE 上以 Workload Identity 方式运行 ExternalDNS 的完整流程可与本教程互为印证。赞分享云原生【免费下载链接】external-dnsConfigure external DNS servers dynamically from Kubernetes resources项目地址https://gitcode.com/gh_mirrors/ex/external-dns点击查看免费下载相关推荐用 npx skills 给 Kimi Code CLI 装技能5 分钟上手的完整实战教程用 npx skills 给 Kimi Code CLI 装技能5 分钟上手的完整实战教程 面向新手开发者的实操教程按 npx skills add、lisAI 技能CLI开发工具人工智能YARP Kubernetes Ingress Controller 部署实战从 Ingress 资源注解到集群路由的完整指南YARP Kubernetes Ingress Controller 部署实战从 Ingress 资源注解到集群路由的完整指南 本文档以开源仓库 revers后端API网关网络从 Ingress NGINX Controller 迁移到 Traefik零停机迁移完整实战指南从 Ingress NGINX Controller 迁移到 Traefik零停机迁移完整实战指南 本文基于 Traefik 官方迁移文档《Migrate f后端API网关负载均衡微服务网络云原生上一篇终极指南wifite2中的无线网络信道与频率筛选技巧下一篇Folium地图渲染引擎完全指南从Python数据到交互式地图的魔法转换创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考