Kubernetes1.6中配置私有 DNS 区域以及上级域名服务

本文涉及的产品
全局流量管理 GTM,标准版 1个月
云解析 DNS,旗舰版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介: 很多用户都有自己的域名区域,并且希望能够集成到 Kubernetes DNS 的命名空间去。例如混合云用户可能希望能在集群内解析他们内部的 “.corp” 。其他用户用户可能有一个受非 Kubernetes 管理的服务发现系统(例如 Consul)。

很多用户都有自己的域名区域,并且希望能够集成到 Kubernetes DNS 的命名空间去。例如混合云 用户可能希望能在集群内解析他们内部的 “.corp” 。其他用户用户可能有一个受非 Kubernetes 管理的服务发现系统(例如 Consul)。我们在 Kubernetes 1.6 中推出了新功能,可配置私有 DNS 区域(通常称为存根域)以及外部的上级域名服务,本文将会讲解如何使用这一功能。

Kubernetes 目前在 Pod 定义中支持两个 DNS 策略:DefaultClusterFirstdnsPolicy缺省为ClusterFirst

  • 如果dnsPolicy设置为Default,那么域名解析配置会从 Pod 所在节点继承而来。注意,本文所述功能在dnsPolicy设置为Default时无效。
  • 如果dnsPolicy设置为ClusterFirst,DNS 查询会被发送到 kube-dns 服务。kube-dns 服务负责相应以集群域名为后缀(例如.cluster.local)的查询。其他的域名查询(例如 www.kubernetes.io )会被转发给来自节点定义的上级域名服务器。

在这一功能推出之前,通常需要利用替换上级 DNS 为自定义解析的方式来完成存根域查询。然而这就使得这个自定义域名解析器成为 DNS 解析过程中的一个高风险因素。本功能让用户能够无需对整个 DNS 路径进行改造就完成自定义解析过程。

自定义 DNS 流程

从 Kubernetes 1.6 开始,集群管理员能够利用 ConfigMap 指定自定义的存根域以及上级 NameServer。下文的配置包含一个存根域和两个上级域名服务器。对域名后缀为.aceme.local的查询会被发送到地址为 1.2.3.4 的 DNS 服务。另外会把 Google 公共 DNS 作为上级服务器。注意本节末尾对 ConfigMap 中的数据格式进行的解释。

apiVersion: v1
kind: ConfigMap
metadata:
 name: kube-dns
 namespace: kube-system
data:
 stubDomains: | {"acme.local": ["1.2.3.4"]}
 upstreamNameservers: | ["8.8.8.8", "8.8.4.4"]

下图显示了配置中所指示的 DNS 查询过程。当dnsPolicy设置为ClusterFirst时,DNS 查询首先被发送到 kube-dns 的 DNS 缓存层。从这里开始检查域名后缀,然后发送到指定的 DNS。在本例中,集群后缀的域名(.cluster.local),被发送到 kube-dns,最后不符合上面后缀的其他查询被转发到上级 DNS 去进行解析。

下文表格用来说明域名解析的过程:

域名 解析服务
kubernetes.default.svc.cluster.local kube-dns
foo.acme.local 自定义 DNS(1.2.3.4)
widget.com 上级 DNS(8.8.8.8 和 8.8.4.4)中的一个

ConfigMap 配置说明

  • stubDomains (可选)
    • 格式:一个 JSON 编码的 Map 格式,其 Key 为 DNS 后缀(也就是acme.local),值是一个 JSON 数组,代表一组 DNS IP。
    • 注意:目标域名服务器也可以是 Kuernetes 服务。例如可以用 dnsmasq 把自定义 DNS 导出到 ClusterDNS 的命名空间中。
  • upstreamNameservers
    • 格式:一个 DNS IP 组成的 JSON 数组。
    • 注意:如果指定了这个值,那么从节点的 /etc/resolv.conf 继承过来的值就会被覆盖。
    • 限制:最多可以指定三个。

例 1:添加一个 Consul DNS 存根域

这个例子中,用户希望把 Consul DNS 服务集成到 kube-dns。Consul 服务位于10.150.0.1,所有的 consul 命名后缀都是.consul.local。Kubernetes 管理员简单的创建一个ConfigMap对象就可以完成。注意:本例中管理员不想覆盖节点的上级 DNS 定义,所以不需要指定upstreamNameservers

apiVersion: v1
kind: ConfigMap
metadata:
 name: kube-dns
 namespace: kube-system
data:
 stubDomains: | {"consul.local": "10.150.0.1"}

例 2:替换上级 Nameserver

这个例子中,集群管理员希望所有的集群外 DNS 查询由172.16.0.1的服务来完成,同样的用一个 ConfigMap 完成:

apiVersion: v1
kind: ConfigMap
metadata:
 name: kube-dns
 namespace: kube-system
data:
 upstreamNameservers: | ["172.16.0.1"]
本文转自中文社区- Kubernetes1.6中配置私有 DNS 区域以及上级域名服务
相关文章
|
3天前
|
域名解析 监控 安全
slb配置检查域名说明注意事项
slb配置检查域名说明注意事项
14 5
|
4天前
|
域名解析 网络协议 安全
反向DNS解析是从IP地址到域名的映射,主要作用于验证和识别,提高通信来源的可信度和可追溯性
在网络世界中,反向DNS解析是从IP地址到域名的映射,主要作用于验证和识别,提高通信来源的可信度和可追溯性。它在邮件服务器验证、网络安全等领域至关重要,帮助识别恶意行为,增强网络安全性。尽管存在配置错误等挑战,但正确管理下,反向DNS解析能显著提升网络环境的安全性和可靠性。
21 3
|
12天前
|
网络协议 网络安全 网络虚拟化
本文介绍了十个重要的网络技术术语,包括IP地址、子网掩码、域名系统(DNS)、防火墙、虚拟专用网络(VPN)、路由器、交换机、超文本传输协议(HTTP)、传输控制协议/网际协议(TCP/IP)和云计算
本文介绍了十个重要的网络技术术语,包括IP地址、子网掩码、域名系统(DNS)、防火墙、虚拟专用网络(VPN)、路由器、交换机、超文本传输协议(HTTP)、传输控制协议/网际协议(TCP/IP)和云计算。通过这些术语的详细解释,帮助读者更好地理解和应用网络技术,应对数字化时代的挑战和机遇。
48 3
|
14天前
|
运维 监控 安全
在实际应用中,如何选择基于不同域名还是不同 IP 进行代理多服务的配置?
综上所述,在实际应用中选择基于不同域名还是不同 IP 进行代理多服务的配置,需要根据具体的业务需求、可扩展性、性能、安全性以及维护和管理成本等多方面因素进行综合考虑,权衡利弊,选择最适合自己系统架构和运营需求的配置方式。
|
25天前
|
域名解析 缓存 网络协议
浏览器中输入URL返回页面过程(超级详细)、DNS域名解析服务,TCP三次握手、四次挥手
浏览器中输入URL返回页面过程(超级详细)、DNS域名解析服务,TCP三次握手、四次挥手
|
29天前
|
域名解析 存储 缓存
DNS是什么?内网电脑需要配置吗?
【10月更文挑战第22天】DNS是什么?内网电脑需要配置吗?
114 1
|
16天前
|
Kubernetes 监控 Java
如何在Kubernetes中配置镜像和容器的定期垃圾回收
如何在Kubernetes中配置镜像和容器的定期垃圾回收
|
2月前
|
JSON JavaScript 前端开发
深入解析ESLint配置:从入门到精通的全方位指南,精细调优你的代码质量保障工具
深入解析ESLint配置:从入门到精通的全方位指南,精细调优你的代码质量保障工具
87 0
|
2月前
|
域名解析 弹性计算
内网域?名解析记录是否会覆盖公网域名解析记录?
内网域?名解析记录是否会覆盖公网域名解析记录?
|
12天前
|
监控 Java 应用服务中间件
高级java面试---spring.factories文件的解析源码API机制
【11月更文挑战第20天】Spring Boot是一个用于快速构建基于Spring框架的应用程序的开源框架。它通过自动配置、起步依赖和内嵌服务器等特性,极大地简化了Spring应用的开发和部署过程。本文将深入探讨Spring Boot的背景历史、业务场景、功能点以及底层原理,并通过Java代码手写模拟Spring Boot的启动过程,特别是spring.factories文件的解析源码API机制。
41 2

相关产品

  • 云解析DNS
  • 推荐镜像

    更多
    下一篇
    无影云桌面