Kubernetes1.6中配置私有 DNS 区域以及上级域名服务
很多用户都有自己的域名区域,并且希望能够集成到 Kubernetes DNS 的命名空间去。例如混合云 用户可能希望能在集群内解析他们内部的 “.corp” 。其他用户用户可能有一个受非 Kubernetes 管理的服务发现系统(例如 Consul)。我们在 Kubernetes 1.6 中推出了新功能,可配置私有 DNS 区域(通常称为存根域)以及外部的上级域名服务,本文将会讲解如何使用这一功能。
Kubernetes 目前在 Pod 定义中支持两个 DNS 策略:Default
和ClusterFirst
,dnsPolicy
缺省为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 的命名空间中。
- 格式:一个 JSON 编码的 Map 格式,其 Key 为 DNS 后缀(也就是
-
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 区域以及上级域名服务 
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
k8s1.6伸缩性升级,支持处理5000 Node 和 15 万个 Pod
上个夏天,我们分享了 Kubernetes 的伸缩性更新,经过一番努力,我们自豪的宣布 Kubernetes 1.6 能够处理 5000 个节点的集群和 15 万个 Pod 了;另外即使在这种负载规模下,端到端的 Pod 启动速度依然优于 2000 节点规模的 1.3 版本 的 Kubernetes 集群,API 调用的延迟依然满足 1 秒的 SLO。 本文中我们会讨论到 性能测试的指标和结果 提高性能的改进 未来在伸缩性方面的发展计划 XX 节点的集群意味着什么? 现在 Kubernetes 1.6 已经发布,那么当我们说到支持多少个节点的集群的时候,我们到底在说什么?前文说过,我们有两个性能相关的服务水平目标(SLO): API 响应性:99% 的 API 调用应该在一秒之内返回。 Pod 启动时间:99% 的 Pod 及其容器(已拉取镜像)在五秒之内完成启动。 跟以前一样,集群规模是可以超过 5000 节点的,但是会引起性能下降,可能无法满足 SLO 要求。 我们知道 SLO 的限制。还有很多我们没有覆盖到的系统因素。例如,新 Pod 启动之后,需要多久才能通过服务 IP 进行访...
- 下一篇
Kubernetes网络接口(CNI) midonet网络插件设计与实现
先来讲讲什么是CNI? CNI(容器网络接口)是一种操作容器网络规范,包含方法规范,参数规 范等。 CNI只关心容器的网络连接,在容器创建时分配网络资源,并在删除容器时删除分配的资源。因为这个焦点,CNI有广泛的支持,规格易于实现。CNI接口只需要实现两个方法,一个创建容器时调用,一个删除容器时调用。 kubernetes如何支持和运行遵循CNI规范的插件 kubernetes首先以插件的形式完成(pod)容器的网络资源设置。内置的插件包括:cni,kubenet,hostport等。这里简单说说kubenet。这是一个简单的网络插件,每台机器上创建一个br0网桥,根据PodCIDR为每个pod设置ip连接到br0网桥上。次方式可结合一些网络路由工具完成一个小规模的集群网络pod互联。我们主要讲CNI插件。kubernetes以cni插件来支持cni规范,调用其他厂商和个人开发的遵循cni规范的各种网络插件,例如Calico,Flannel等。k8s默认情况下cni模式不支持端口映射等。k8s将容器网络设置none,完全交给插件去管理容器网络资源。 上文多次提到的网络资源是什么? 容器...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- 设置Eclipse缩进为4个空格,增强代码规范
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- CentOS6,CentOS7官方镜像安装Oracle11G
- Docker安装Oracle12C,快速搭建Oracle学习环境
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- SpringBoot2全家桶,快速入门学习开发网站教程
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装