カスタムDNS;
1.はじめに; 2. DNS名を取得する方法; ; DNSモードの3のサポート 4.カスタムDNS;
1.はじめに
Kubernetesクラスタおよびポッド上のDNS DNSサービスをスケジュール、およびDNS IPを使用して個々の容器に配置kubeletサービスを通知するためには、DNS名を解決します。
DNS名を取得する方法2。
（DNSサーバ自体を含む）クラスタ内で定義されている各サービスは、DNS名が割り当てられます。デフォルトでは、DNSクライアントポッドの検索リストは、ポッド自身の名前空間のクラスタとデフォルトのドメインが含まれています。これはよく、以下の例で説明することができます。
名前空間Kubernetesクラスタと仮定すると bar 、サービスの定義を foo。名前空間はで実行 bar するだけDNSクエリによって、内ポッド foo サービスを検索します。で実行する名前空間 quux ポッドは、DNSを照会することができる foo.bar サービスを見つけること。
次のセクションで詳細には、レコードタイプのレイアウトは、サポートとサポート。コードレイアウトのどの部分、またはクエリコマンドの名前は、実装の詳細は予告なく変更されることが考えられています。最新の仕様についてはKubernetes DNSベースのサービスの発見を参照してください。
DNSモードの3のサポート
詳細な説明サポートレコード型と下の段落のレイアウト。他のレイアウト、またはクエリ名ならば、また、彼らが使用することはできません以後の変更を避けるために、下の彼らの実装の詳細を調べる必要とし、使用することを起こります。
サービス
記録
（ヘッドレスサービスを除く）「ノーマル」 -サービスはなり my-svc.my-namespace.svc.cluster-domain.example DNSの形にこの名前のレコードを割り当てられます。これは、クラスタIPサービスに解決されます。
「ヘッドレス」サービス（なしクラスタIP）がすることもある my-svc.my-namespace.svc.cluster-domain.example DNSこの名前のレコード形式を割り当てること。通常のサービスとは異なり、それは、IPを選択したサービスポッドのグループに解決されます。私たちは、クライアントがIPのこのセットを使用するか、または標準ラウンドロビン戦略の使用上のIPのセットから選択できるようにしたいです。
SRVレコード
名前付きポートがSRVレコードを作成する必要があり、これらのポートは、サービスやヘッドレスサービスの正常な部分です。それぞれの名前付きポートについて、SRVレコードが持つ _my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example このフォームを。ポート番号とCNAMEに解決される通常のサービス、： my-svc.my-namespace.svc.cluster-domain.example。その結果、複数のに解析され、ヘッドレス・サービスについては、各ポッドサービス含むそれぞれに対応するバックエンド auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example このフォームポッドポート番号とCNAMEを。
ポッド
ポッドのホスト名とフィールドのサブドメイン
現在、ポッドは、その名のポッドのホストで、作成され metadata.name た値。
バージョン1.2以降では、ユーザはにより、ポッド注釈を設定することができ pod.beta.kubernetes.io/hostname ポッドのホスト名を設定します。あなたはポッドのためのアノテーションを設定した場合、ポッドは、ホスト名として名を使用するために優先させて頂きます。例えば、ポッド、注釈を持つ与えられ pod.beta.kubernetes.io/hostname: my-pod-name、ポッドのホスト名は、「私のポッド名」に設定されています。
在 v1.3 版本中，PodSpec 具有 hostname 字段，可以用来指定 Pod 的主机名。这个字段的值优先于 annotation pod.beta.kubernetes.io/hostname。 在 v1.2 版本中引入了 beta 特性，用户可以为 Pod 指定 annotation，其中 pod.beta.kubernetes.io/subdomain 指定了 Pod 的子域名。 最终的域名将是 “...svc.”。 举个例子，Pod 的主机名 annotation 设置为 “foo”，子域名 annotation 设置为 “bar”，在 Namespace “my-namespace” 中对应的 FQDN 为 “foo.bar.my-namespace.svc.cluster.local”。
在 v1.3 版本中，PodSpec 具有 subdomain 字段，可以用来指定 Pod 的子域名。 这个字段的值优先于 annotation pod.beta.kubernetes.io/subdomain 的值。
4.Pod 的 DNS 设定
Pod 的 DNS 配置可让用户对 Pod 的 DNS 设置进行更多控制。
dnsConfig 字段是可选的，它可以与任何 dnsPolicy 设置一起使用。 但是，当 Pod 的 dnsPolicy 设置为 “None” 时，必须指定 dnsConfig 字段。
用户可以在 dnsConfig 字段中指定以下属性：
nameservers: 将用作于 Pod 的 DNS 服务器的 IP 地址列表。最多可以指定3个 IP 地址。 当 Pod 的dnsPolicy设置为 “None” 时，列表必须至少包含一个IP地址，否则此属性是可选的。列出的服务器将合并到从指定的 DNS 策略生成的基本名称服务器，并删除重复的地址。searches: 用于在 Pod 中查找主机名的 DNS 搜索域的列表。此属性是可选的。指定后，提供的列表将合并到根据所选 DNS 策略生成的基本搜索域名中。 重复的域名将被删除。 Kubernetes最多允许6个搜索域。options: 对象的可选列表，其中每个对象可能具有name属性（必需）和value属性（可选）。 此属性中的内容将合并到从指定的 DNS 策略生成的选项。 重复的条目将被删除。
以下是具有自定义DNS设置的Pod示例
(1).dns yaml 配置详细;
(2).运行dns ymal
(3).测试解析dns;
(4).创建上面的Pod后，容器 test 会在其 /etc/resolv.conf 文件中获取以下内容:
二.通过 kube-dns 配置私有dns;
1.准备开始 2.配置存根域和上游 DNS 服务器 3.理解 Kubernetes 中名字解析 4.ConfigMap 选项
在 Kubernetes 中配置私有 DNS 和上游域名服务器
准备开始
你必须拥有一个 Kubernetes 的集群，同时你的 Kubernetes 集群必须带有 kubectl 命令行工具。 如果你还没有集群，你可以通过 Minikube 构建一 个你自己的集群，或者你可以使用下面任意一个 Kubernetes 工具构建：
Katacoda
Play with Kubernetes
要获知版本信息，请输入 kubectl version.
Kubernetes 1.6 及其以上版本。
集群必须配置使用
kube-dns插件。
配置存根域和上游 DNS 服务器
通过为 kube-dns （kube-system:kube-dns）提供 ConfigMap，集群管理员能够指定自定义存根域和上游域名服务器。
例如，下面的 ConfigMap 建立了一个 DNS 配置，它具有一个单独的存根域和两个上游域名服务器：
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"]
按如上说明，具有 “.acme.local” 后缀的 DNS 请求被转发到 DNS 1.2.3.4。Google 公共 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 选项 获取更多关于配置选项格式的详细信息。
理解 Kubernetes 中名字解析
可以为每个 Pod 设置 DNS 策略。 当前 Kubernetes 支持两种 Pod 特定的 DNS 策略：“Default” 和 “ClusterFirst”。 可以通过 dnsPolicy 标志来指定这些策略。 注意：“Default” 不是默认的 DNS 策略。如果没有显式地指定 dnsPolicy，将会使用 “ClusterFirst”。
“Default” DNS 策略
如果 dnsPolicy 被设置为 “Default”，则名字解析配置会继承自 Pod 运行所在的节点。 自定义上游域名服务器和存根域不能够与这个策略一起使用。
“ClusterFirst” DNS 策略
如果 dnsPolicy 被设置为 “ClusterFirst”，处理名字解析有所不同，*依赖于是否配置了存根域和上游 DNS 服务器*。
未进行自定义配置：没有匹配上配置的集群域名后缀的任何请求，例如 “www.kubernetes.io”，将会被转发到继承自节点的上游域名服务器。
进行自定义配置：如果配置了存根域和上游 DNS 服务器（类似于 前面示例 配置的内容），DNS 查询将基于下面的流程对请求进行路由：
查询首先被发送到 kube-dns 中的 DNS 缓存层。
从缓存层，检查请求的后缀，并根据下面的情况转发到对应的 DNS 上：
*具有集群后缀的名字*（例如 “.cluster.local”）：请求被发送到 kube-dns。
*具有存根域后缀的名字*（例如 “.acme.local”）：请求被发送到配置的自定义 DNS 解析器（例如：监听在 1.2.3.4）。
*未能匹配上后缀的名字*（例如 “widget.com”）：请求被转发到上游 DNS（例如：Google 公共 DNS 服务器，8.8.8.8 和 8.8.4.4）。
ConfigMap 选项
kube-dns kube-system:kube-dns 对应的 ConfigMap 选项如下所示：
| 字段 | 格式 | 描述 |
|---|---|---|
stubDomains（可选） |
使用 DNS 后缀作为键（例如 “acme.local”）的 JSON map，以及由 DNS IP 的 JSON 数组组成的值。 | 目标域名服务器可能是一个 Kubernetes Service。例如，可以运行自己的 dnsmasq 副本，将 DNS 名字暴露到 ClusterDNS namespace 中。 |
upstreamNameservers（可选） |
DNS IP 的 JSON 数组。 | 注意：如果指定，则指定的值会替换掉被默认从节点的 /etc/resolv.conf 中获取到的域名服务器。限制：最多可以指定三个上游域名服务器。 |
附加示例
示例：存根域
在这个例子中，用户有一个 Consul DNS 服务发现系统，他们希望能够与 kube-dns 集成起来。 Consul 域名服务器地址为 10.150.0.1，所有的 Consul 名字具有后缀 “.consul.local”。 要配置 Kubernetes，集群管理员只需要简单地创建一个 ConfigMap 对象，如下所示：
apiVersion: v1
kind: ConfigMap
metadata:
name: kube-dns
namespace: kube-system
data: stubDomains: |
{"consul.local": ["10.150.0.1"]}
注意，集群管理员不希望覆盖节点的上游域名服务器，所以他们不会指定可选的 upstreamNameservers 字段。
示例：上游域名服务器
在这个示例中，集群管理员不希望显式地强制所有非集群 DNS 查询进入到他们自己的域名服务器 172.16.0.1。 而且这很容易实现：他们只需要创建一个 ConfigMap，upstreamNameservers 字段指定期望的域名服务器即可：
apiVersion: v1 kind: ConfigMap metadata: name: kube-dns namespace: kube-system data: upstreamNameservers: | ["172.16.0.1"]