公司网站开发计划书,广州全面优化各项防控措施,中天建设集团有限公司总部在哪里,阿里云域名注册备案流程CoreDNS作为现阶段k8s的默认DNS服务以及服务发现的重要一环#xff0c;其内置的kubernetes插件可谓是举足轻重。本文主要讲解介绍CoreDNS内置的核心插件kubernetes的使用方式和适用场景。
CoreDNS的kubernetes插件的具体实现遵循k8s官方提供的标准指南Kubernetes DNS-Based S…CoreDNS作为现阶段k8s的默认DNS服务以及服务发现的重要一环其内置的kubernetes插件可谓是举足轻重。本文主要讲解介绍CoreDNS内置的核心插件kubernetes的使用方式和适用场景。
CoreDNS的kubernetes插件的具体实现遵循k8s官方提供的标准指南Kubernetes DNS-Based Service Discovery Specification这也是它能够替代kube-dns成为kubebernetes中默认的DNS的重要原因。
虽然 Kubernetes 中的服务发现可以通过其他协议和机制提供如consul等服务注册发现中心但DNS是非常常用的一种协议同时考虑到K8S中的东西流量互访主要也是通过域名实现因此K8S官方非常推荐使用DNS插件来实现K8S中的服务发现。
This document is a specification for DNS-based Kubernetes service discovery. While service discovery in Kubernetes may be provided via other protocols and mechanisms, DNS is very commonly used and is a highly recommended add-on. The actual DNS service itself need not be provided by the default Kube-DNS implementation. This document is intended to provide a baseline for commonality between implementations. 在开始介绍kubernetes插件之前我们需要先了解一些K8S中的基础DNS知识。
1 K8S中的DNS服务
众所周知在K8S中IP是随时会发生变化的变化最频繁的就是Pod IPCluster IP也并不是一定不会发生变化EXTERNAL-IP虽然可以手动指定静态IP保持不变但是主要面向的是集群外部的服务因此在K8S集群中最好的服务之间相互访问的方式就是通过域名。
1.1 DNS创建规则
在K8S集群中Kubernetes 为 Service 和 Pod 创建 DNS 记录。
前面我们介绍了K8S中的每个SVC都会有一个对应的域名域名的组成格式为$service_name.$namespace_name.svc.$cluster_name同时也会给这个SVC下的所有Pod都创建一个$pod_name.$service_name.$namespace_name.svc.$cluster_name的这种域名这个域名的解析结果就是Pod IP。
Pod域名有两个比较明显的特征
一是域名的组成比较特殊因为域名中使用了Pod的名称而pod名称在K8S中是会发生变化的例如在服务更新或者滚动重启时同时由于默认情况下Pod的命名是没有太明显的规律大部分名字中会包含一串随机UUID二是域名的解析结果特殊相较于集群内的其他类型域名Pod域名的解析是可以精确到特定的某个Pod因此一些特殊的需要点对点通信的服务可以使用这类Pod域名
1.2 DNS策略配置
DNS 策略可以逐个 Pod 来设定。目前 Kubernetes 支持以下特定 Pod 的 DNS 策略。 这些策略可以在 Pod 规约中的 dnsPolicy 字段设置
Default: Pod 从运行所在的K8S宿主机节点继承域名解析配置ClusterFirst: 不指定任何dnsPolicy配置情况下的默认选项所有查询的域名都会根据生成的集群的K8S域名等信息生成的 /etc/resolv.conf 配置进行解析和转发到集群内部的DNS服务进行解析ClusterFirstWithHostNet主要用于以 hostNetwork 方式运行的 Pod如果这些pod想要使用K8S集群内的DNS服务则可以配置为这个字段None: 此设置允许 Pod 忽略 Kubernetes 环境中的 DNS 设置Pod 会使用其 dnsConfig 字段 所配置的 DNS 设置
说明 下面主要介绍ClusterFirst模式
1.3 DNS解析规则
DNS 查询参照 Pod 中的 /etc/resolv.conf 配置kubelet 会为每个 Pod 生成此文件。因此在每个pod里面都有一个类似下面这样的 /etc/resolv.conf文件通过修改其中的配置可以更改DNS的查询规则 nameserver 10.32.0.10search namespace.svc.cluster.local svc.cluster.local cluster.localoptions ndots:5
这里的配置有几个需要注意的点
nameserver集群中的DNS服务器IP一般来说就是CoreDNS的ClusterIPsearch需要搜索的域默认情况下会从该pod所属的namespace开始逐级补充options ndots触发上面的search的域名点数默认为1上限15在K8S中一般为5例如在Linux中tinychen.com这个域名的ndots是1tinychen.com.这个域名的ndots才是2需要注意所有域名其实都有一个根域.因此tinychen.com的全称应该是tinychen.com.
这是一个比较通用的案例我们再来看一个比较特殊的配置 # 首先进入一个pod查看里面的DNS解析配置[roottiny-calico-master-88-1 tiny-calico]# kubectl exec -it -n ngx-system ngx-ex-deploy-6bf6c99d95-5qh2w /bin/bashkubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.[rootngx-ex-deploy-6bf6c99d95-5qh2w /]# cat /etc/resolv.confnameserver 10.88.0.10search ngx-system.svc.cali-cluster.tclocal svc.cali-cluster.tclocal cali-cluster.tclocal k8s.tcinternaloptions ndots:5[rootngx-ex-deploy-6bf6c99d95-5qh2w /]# exit
这个pod里面的/etc/resolv.conf配置文件有两个和前面不同的地方
cluster.local变成了cali-cluster.tclocal 这里我们可以看到coredns的配置中就是配置的cali-cluster.tclocal也就是说/etc/resolv.conf中的配置其实是和coredns中的配置一样更准确的说是和该K8S集群初始化时配置的集群名一样 # 再查看K8S集群中的coredns的configmap [roottiny-calico-master-88-1 tiny-calico]# kubectl get configmaps -n kube-system coredns -oyamlapiVersion: v1data:Corefile: |.:53 {errorshealth {lameduck 5s}readykubernetes cali-cluster.tclocal in-addr.arpa ip6.arpa {pods insecurefallthrough in-addr.arpa ip6.arpattl 30}prometheus :9153forward . 10.31.100.100 {max_concurrent 1000}cache 30loopreloadloadbalance}kind: ConfigMapmetadata:creationTimestamp: 2022-05-06T05:19:08Zname: corednsnamespace: kube-systemresourceVersion: 3986029uid: 54f5f803-a5ab-4c77-b149-f02229bcad0a
search新增了一个k8s.tcinternal 实际上我们再查看K8S的宿主机节点的DNS配置规则时会发现这个k8s.tcinternal是从宿主机上面继承而来的 # 最后查看宿主机节点上面的DNS解析配置[roottiny-calico-master-88-1 tiny-calico]# cat /etc/resolv.conf# Generated by NetworkManagersearch k8s.tcinternalnameserver 10.31.254.253
1.4 DNS解析流程
温馨提示阅读这部分内容的时候要特别注意域名结尾是否有一个点号 . 当ndots小于options ndots
前面我们说过options ndots的值默认情况下是1在K8S中为5为了效果明显我们这里使用K8S中的5作为示例
这里同样是在一个命名空间demo-ns中有两个SVC分别为demo-svc1和demo-svc2那么他们的/etc/resolv.conf应该是下面这样的 nameserver 10.32.0.10search demo-ns.svc.cluster.local svc.cluster.local cluster.localoptions ndots:5
我们在demo-svc1中直接请求域名demo-svc2此时ndots为1小于配置中的5因此会触发上面的search规则这时第一个解析的域名就是demo-svc2.demo-ns.svc.cluster.local当解析不出来的时候继续下面的demo-svc2.svc.cluster.local、demo-svc2.cluster.local最后才是直接去解析demo-svc2.。
注意上面的规则适用于任何一个域名也就是当我们试图在pod中去访问一个外部域名如tinychen.com的时候也会依次进行上述查询。
当ndots大于等于options ndots
我们在demo-svc1中直接请求域名demo-svc2.demo-ns.svc.cluster.local此时的ndots为4还是会触发上面的search规则。
而请求域名demo-svc2.demo-ns.svc.cluster.local.ndots为5等于配置中的5因此不会触发上面的search规则直接去解析demo-svc2.demo-ns.svc.cluster.local.这个域名并返回结果
如果我们请求更长的域名如POD域名pod-1.demo-svc2.demo-ns.svc.cluster.local.此时的ndots为6大于配置中的5因此也不会触发上面的search规则会直接查询域名并返回解析
小结
通过上面的分析我们不难得出下面几点结论
同命名空间namespace内的服务直接通过$service_name进行互相访问而不需要使用全域名FQDN此时DNS解析速度最快跨命名空间namespace的服务可以通过$service_name.$namespace_name进行互相访问此时DNS解析第一次查询失败第二次才会匹配到正确的域名所有的服务之间通过全域名FQDN$service_name.$namespace_name.svc.$cluster_name.访问的时候DNS解析的速度最快在K8S集群内访问大部分的常见外网域名ndots小于5都会触发search规则因此在访问外部域名的时候可以使用FQDN即在域名的结尾配置一个点号.
2 kubernetes插件
kubernetes插件的主要作用就是用来连接k8s集群的apiserver并对外提供符合规范的域名解析服务该插件在每个配置块中仅能使用一次但在一个coredns实例中可以存在多个配置块也就意味着一个coredns实例实际上是可以连接多个k8s集群并对外提供域名解析的。
接下来我们详细看一下kubernetes插件的各种具体配置下面的这个是官方给出的一个配置文件示例 kubernetes [ZONES...] {endpoint URLtls CERT KEY CACERTkubeconfig KUBECONFIG [CONTEXT]namespaces NAMESPACE...namespace_labels EXPRESSIONlabels EXPRESSIONpods POD-MODEendpoint_pod_namesttl TTLnoendpointsfallthrough [ZONES...]ignore empty_service}
endpoint 用来指定k8s集群的apiserver地址如https://10.31.88.1:6443当然也可以是域名等其他形式如果不配置那么默认情况下会使用对应的service account去连接当前k8s集群内的apiserver如果不是在k8s集群中部署那么就会连接失败。tlsCERT KEY CACERT是远程 k8s 连接的 TLS 证书、密钥和 CA 证书文件名。如果前面的endpoint没有配置那么这个配置项会被忽略。kubeconfigKUBECONFIG [CONTEXT]使用 kubeconfig 文件验证与远程 k8s 集群的连接。 [CONTEXT]是可选配置的如果未设置则将使用 kubeconfig中默认的[CONTEXT]。它支持 TLS、用户名和密码或基于令牌的身份验证。 如果前面的endpoint没有配置那么这个配置项会被忽略。namespacesNAMESPACE [NAMESPACE…] 用来限制对外暴露的命名空间多个命名空间之间使用空格间隔。如果不配置的话则会暴露所有的命名空间。namespace_labelsnamespace_labels EXPRESSION可以限定DNS的查询范围仅有匹配labels的命名空间才能被查询到。labelslabels EXPRESSION可以限定DNS的查询范围仅有匹配lalels的service才能被查询到。
注意这里的 labels匹配的是 service中的 labels而前面的 labels匹配的是 namespace中的 labels。这两个 labels的配置写法可以和使用 kubectl命令中的 -l参数完全一致。 如果要使用多个labels匹配规则注意不要使用空格而是对应的表达式进行匹配 -l, --selector: Selector (label query) to filter on, supports , , and !.(e.g. -l key1value1,key2value2) podspods POD-MODE设置处理基于 IP 的 pod A 记录的模式例如客户端向coredns查询域名1-2-3-4.ns.pod.cluster.local.该参数用于控制响应的结果提供此选项是为了方便在直接连接到 pod 时使用 SSL 证书。POD-MODE 有效值 disabled 默认。不处理 pod 请求总是返回NXDOMAINinsecure总是从请求中返回带有 IP 的 A 记录不检查 k8s即查询域名1-2-3-4.ns.pod.cluster.local.的时候不论是否存在一个IP地址为1.2.3.4的pod都返回这个结果给客户端。如果与通配符 SSL 证书一起被恶意使用此选项很容易被滥用。提供此选项是为了向后兼容 kube-dns。verified: 如果在同一个命名空间中存在匹配 IP 的 Pod则返回 A 记录即查询域名1-2-3-4.ns.pod.cluster.local.的时候只有当该ns中确实存在一个IP地址为1.2.3.4的pod才返回这个结果给客户端否则返回NXDOMAIN。与insecure模式相比此选项需要更多的内存因为它需要监控所有的pods。endpoint_pod_names 使用endpoints所对应的pod名称作为A记录中的端点名称例如 endpoint-name.my-service.namespace.svc.cluster.local. in A 1.2.3.4 在没有配置该参数的情况下endpoints名称选择如下优先使用endpoints的hostname如果endpoints没有配置hostname则使用 IP 地址的虚线形式例如1-2-3-4.my-service.namespace.svc.cluster.local. 如果配置了该参数则endpoints名称选择如下优先使用endpoints的hostname如果endpoints没有配置hostname则使用endpoints对应的pod名称如果pod名称不存在或者长度超过63则使用 IP 地址的虚线形式。ttl 设置标准的DNS域名TTL默认值为 5 秒。允许的最小 TTL 为 0 秒最大值为 3600 秒。将 TTL 设置为 0 将防止记录被缓存如果查询的客户端遵循DNS规范。noendpoints 配置该参数将禁用对K8S集群中的endpoints记录功能因此所有endpoints查询和headless服务查询都将返回 NXDOMAIN。fallthrough [ZONES…] 正常情况下一个客户端对CoreDNS发起了一个DNS查询如果该记录不存在那么就会直接返回一个NXDOMAIN的响应。 但是我们可以通过配置fallthrough参数来将这些NXDOMAIN的域名转发到配置块中的下一个插件。 例如在fallthrough插件后面还使用了诸如file插件之类的配置了DNS解析那么这个请求就会转发到file插件进行查询并响应zones参数可以用来控制哪些域的域名会被fallthrough插件转发留空的情况下是所有的域名都会被转发当然也可以指定部分域名如(for example in-addr.arpa and ip6.arpa)此时就只有in-addr.arpa 和 ip6.arpa的查询出现NXDOMAIN才会被转发到下一个插件进行查询ignore empty_service 如果一个service当中没有任何可用的endpoints即关联的所有pods都不是ready状态那么会返回一个NXDOMAIN。 这个配置项的主要作用就是让这类不正常的服务域名查询的时候能够返回NXDOMAIN响应码从而触发配置的其他插件如上面提到的fallthrough进行组合操作。
3 一些其他问题
3.1 延迟启动
当CoreDNS启用了kubernetes插件之后CoreDNS实例在启动的时候会延迟5s的时间再对外提供服务这5s内CoreDNS会尝试和K8S的apiserver建立连接并同步信息。
如果5s内CoreDNS还是无法和k8s的apiserver完成信息同步工作那么会开始对外提供服务并且继续尝试同步信息但是在成功和apiserver建立连接并同步信息之前所有k8s相关的域名查询都会返回SERVFAIL。
3.2 连接中断
如果在CoreDNS实例正常运行的时候突然和k8s的apiserver断开连接并且一直没有恢复那么此时的CoreDNS实例是依旧正常运行的对应的K8S集群域名也是能够正常解析的但是解析出来的endpoint信息就有可能不是最新的。
如果此时再对CoreDNS实例进行重启操作那么具体的过程就和上面讲述的延迟启动一样最后会导致所有k8s相关的域名查询都会返回SERVFAIL。
3.3 配置检查
kubernetes的健康状态会暴露在ready插件中如果出现配置错误可以通过请求ready插件暴露的接口发现但是如果出现连接异常这种情况ready接口是无法探测出来的。
