如果用户找不到应用程序,那么应用就无法发挥其作用。 域名系统 (DNS) 是一种通过将域名转换为 IP 地址来“查找”应用程序和网站的互联网技术。 DNS 无处不在,而且非常可靠,大多数时候你甚至都不会想到它。 但是当出现 DNS 问题时,一切都会停止。 确保 DNS 正常工作对于现代应用至关重要,特别是在服务不断启动和关闭的微服务架构中。
在之前的文章中,我们讨论了为两个子域定义 DNS 记录,这两个子域对应于在同一集群中运行的应用(营销应用程序为unit-demo.marketing.net ,工程应用程序为unit-demo.engineering.net )并解析到同一个集群入口点 – 即集群的 NGINX 入口控制器的外部 IP 地址。 NGINX Ingress Controller 上配置了服务器名称指示 (SNI) 路由,以根据用户请求的域名对连接进行身份验证并将其路由到适当的应用。
但许多组织需要扩展该用例并在多个 Kubernetes 集群中部署应用,这些集群可能分布在不同的云提供商区域。 为了使外部流量到达新的集群区域,您需要创建解析到这些区域的 DNS 区域。
过去,此过程需要使用第三方提供商(例如 GoDaddy 或 DNSExit)手动创建域名注册并适当更新主机记录。 现在, ExternalDNS Kubernetes 项目通过公共 DNS 服务器使 Kubernetes 资源可发现,从而实现了该过程的自动化。 这意味着您使用 Kubernetes API 来配置 DNS 提供商列表。
通过 ExternalDNS 与NGINX Ingress Controller的集成,您可以管理 DNS A
记录,以便 DNS 名称源自标准 Kubernetes Ingress 资源或 NGINX VirtualServer自定义资源中声明的主机名。 开发人员和 DevOps 团队可以在他们的 CI/CD 管道中利用这种集成来自动发现不同集群中的应用,而无需 NetOps 团队(通常拥有 DNS)的参与。
在本文中,我们展示了如何使用来自GitHub 存储库的示例配置文件将 ExternalDNS 与 NGINX Ingress Controller 集成。
为了使用 NGINX Ingress Controller 实现 ExternalDNS,我们从基本情况开始,即开发人员配置一个 Ingress 控制器来向外部公开 Kubernetes 应用程序。 在配置的域名解析为 Kubernetes 集群的公共入口点之前,客户端无法连接到应用程序。
NGINX Ingress Controller 通过中介 ExternalDNS Kubernetes 部署与 DNS 提供商交互,从而实现使用外部 DNS 记录自动发现 Kubernetes应用。 图中黑线表示外部用户访问 Kubernetes 集群中应用的数据路径。 紫色线表示应用程序所有者使用 NGINX Ingress Controller 配置中的 VirtualServer 资源管理外部 DNS 记录以及外部 DNS 访问 DNS 提供商的控制路径。
执行以下部分中的步骤来集成 ExternalDNS 和 NGINX Ingress Controller。
<我的域名>
请按照以下步骤操作。 (关于如何注册域名的文章有很多,包括PCMag 的这份指南。)使用清单或Helm 图表部署 NGINX Ingress Controller。 在部署规范中添加这些命令行参数的等效项:
-enable-external-dns
– 启用与 ExternalDNS 的集成。-external-service=nginx-ingress
– 告诉 NGINX Ingress Controller 宣传其公共入口点,以便在 DNS 提供商管理的A
记录中进行记录。 公共入口点的主机名解析为外部服务nginx-ingress
。如果有必要,请在ExternalDNS 支持的提供商中创建 DNS 区域。 此命令适用于示例部署中使用的提供商 Google Cloud DNS。
$ gcloud dns managed-zones 创建“external-dns-<我的域名>“--dns-name” 外部 DNS。<我的域名>“--description”区域由 ExternalDNS 自动管理”
克隆示例部署的GitHub 存储库并部署 NGINX Ingress Controller。
$ git clone https://github.com/nginxinc/NGINX-Demos.git && cd NGINX-Demos/external-dns-nginx-ingress/ $ kubectl apply -f nginx-ingress.yaml && kubectl apply -f loadbalancer.yaml
更新 ExternalDNS 部署规范中的以下参数(示例部署的external-dns-gcloud.yaml中的第 59-62 行):
--域过滤器
– 创建的域名 步骤 4 上一节(在示例部署中, 外部 DNS。<我的域名>
)。 删除任何现有值,以便仅使用此域。--provider
– DNS 提供商(在示例部署中,请搜索
Google DNS)。--google-project
– 用于示例部署的Google 项目的名称(仅当您有多个 Google 项目时才需要)。--txt-owner-id
– 您选择的 ID(示例部署所独有)。笔记: 您需要在 ExternalDNS 部署规范中包含的参数可能会因您选择的 DNS 提供商而异。 有关使用不同 DNS 提供商将 ExternalDNS 部署到集群的教程列表,请参阅ExternalDNS 文档。
在集群中部署 ExternalDNS 并验证部署是否成功运行(为了易读,输出分布在两行)。
$ kubectl apply -f external-dns-gcloud.yaml $ kubectl get pods -o wide NAME READY STATUS ... external-dns-4hrytf7f98f-ffuffjbf7 1/1 正在运行... ... 重新开始年龄... 0 1分钟
接下来,我们使用 Ingress 负载均衡规则配置 VirtualServer 资源,将外部连接路由到我们的 Kubernetes应用中。
在app-virtual-server.yaml中,设置主机
字段(第 6 行):
6 主机:ingress.external-dns。<我的域名>
该值与external-dns-gcloud.yaml第 59 行的domain-filter
值(在上一节第 2 步中设置)之间的映射实现了 DNS 记录的自动更新。
应用app-virtual-server.yaml并验证 VirtualServer 是否正确配置。
$ kubectl apply -f app-secret.yaml && kubectl apply -f app-virtual-server.yaml
$ kubectl 获取 vs
名称 状态 主机 IP
咖啡馆 有效 ingress.external-dns。<我的域名> 34.168.十。是
验证 DNS 类型A
记录已添加到 DNS 区域。 具体来说, DATA
字段中的 IP 地址必须与上一步中kubectl
get
vs
命令输出中的IP
字段匹配(公开 NGINX Ingress Controller 的LoadBalancer
类型服务的外部 IP 地址,或本地部署中的等效地址)。
$ gcloud dns 记录集列表 --zone external-dns- <我的域> -name ingress.external-dns。 <我的域> --type A NAME TYPE TTL DATA ingress.external-dns。 <我的域> 。 A300 34.168.X.Y
为了验证 VirtualServer 主机名是否可以在本地计算机上解析,请获取分配给 DNS 区域的名称服务器(在本例中为 my-ns-domains
)。
$ gcloud dns 记录集列表 --zone external-dns。 <我的域> --name external-dns。 <我的域> . --type NS名称类型 TTL 数据 external-dns。 <我的域> . NS 21600 我的 ns 域 $ dig +short @我的 ns 域 ingress.external-dns。 <我的域>
34.168.坐标
验证您现在可以访问 VirtualServer 主机名,因为它已暴露给全球互联网。
$ curl -i --insecure https://ingress.external-dns。<我的域名>/茶HTTP/1.1 200 OK
服务器:nginx/1.23.0
日期: 日, DD MM YYYY hh : mm : ss TZ内容类型:text/plain 内容长度: 160 连接:保持活动 过期时间: 日, DD MM YYYY hh : mm : ss TZ缓存控制: 无缓存
您可以通过自动创建外部 DNS 记录并将其解析为图中的新集群入口点( Kubernetes 集群 1和Kubernetes 集群 2 )来快速扩展架构并自动发现多个集群。 重复部署 NGINX Ingress Controller 和 ExternalDNS和配置 NGINX Ingress Controller中的说明。
您还可以在 CI/CD 管道中使用Infrastructure-as-Code工具,使用 ExternalDNS 和 NGINX Ingress Controller 生成新集群并将其公开给外部流量。 此外,您可以管理多个 DNS 区域,甚至多个 DNS 提供商,具体取决于启用发现的方式。
平衡生产力与减轻违规行为的安全措施可能很困难。 对 DevOps 团队施加限制通常会导致他们与 NetOps/SecOps 团队之间产生摩擦。 每个组织的理想平衡都不同,而 NGINX 提供了灵活性,可以建立符合您的优先级和要求的平衡。
过去,应用程序所有者依靠 NetOps 团队将他们的应用连接到外部系统。 通过使用 ExternalDNS 与 NGINX 的集成,开发人员和 DevOps 团队能够自行部署可发现的应用,从而有助于加快创新的上市时间。
有关在 Kubernetes 中使用 NGINX 的完整指南,请下载我们的免费电子书《使用 F5 NGINX 管理 Kubernetes 流量》: 实用指南。
您也可以立即开始申请30 天免费试用NGINX Ingress Controller 和 NGINX App Protect WAF 和 DoS,或者联系我们讨论您的用例。
“这篇博文可能引用了不再可用和/或不再支持的产品。 有关 F5 NGINX 产品和解决方案的最新信息,请探索我们的NGINX 产品系列。 NGINX 现在是 F5 的一部分。 所有之前的 NGINX.com 链接都将重定向至 F5.com 上的类似 NGINX 内容。”