共计 3401 个字符，预计需要花费 9 分钟才能阅读完成。
容器作为近些年最炽热的后端技术，放慢了很多企业的数字化转型过程。目前的企业，不是在应用云原生技术，就是在转向云原生技术的过程中。在容器化过程中，如何放弃业务的安稳迁徙，如何将现有的一些服务设施一并进行容器化迁徙，也是泛滥企业较为关注的点。
以 DNS 为例，如何构建一个云原生的企业 DNS 零碎？
CoreDNS 简介
CoreDNS 是一个 Go 语言编写的灵便可扩大的 DNS 服务器，在 Kubernetes 中，作为一个服务发现的配置核心，在 Kubernetes 中创立的 Service 和 Pod 都会在其中主动生成相应的 DNS 记录。Kubernetes 服务发现的个性，使 CoreDNS 很适宜作为企业云原生环境的 DNS 服务器，保障企业容器化和非容器化业务服务的稳固运行。
构建企业 DNS 服务器时，个别会有以下需要：
- 用户外网域名拜访服务；
- 混合云业务迁徙、数据共享、容灾；
- 开发代码 IP 写死导致架构可用性、弹性无奈实现；
- 对立 DNS 治理需要，含上下级平台对接；
- DNS 劫持等网络安全危险；
- 存量代码固定域名拜访；
- 集群外域名拜访；
相比于 Bind 开源计划或 Windows Server DNS 商业 DNS 服务器，CoreDNS 有以下劣势：
- 无商业许可要求，升高投资老本；
- 轻量化，通过插件实现性能增加；
- 反对 DNS，DNS over TLS，DNS over HTTP/2，DNS over gRPC 协定；
- 提供 kubernetes 服务发现；
- 反对对接 Route53/Google Cloud DNS/AzureDNS；
- 反对集成 Prometheus，OpenTracing，OPA，带来更全面的运维体验；
- 反对整合容器治理平台，提供对立 DNS 零碎运维。
构建企业云原生 DNS 前，对 CoreDNS 做一个更深刻的理解。
CoreDNS 运行原理与插件介绍
CoreDNS 基于 Caddy 框架实现模块化设计，每个插件承载相应的具体性能，对于 DNS 零碎而言，CoreDNS 应用 File，ETCD 插件等加载 DNS 记录，应用 Kubernetes 插件实现集群服务发现，内部 DNS 申请达到 CoreDNS 后，依据插件调用链顺次解决 DNS 申请。
CoreDNS 社区官网提供了 50 多种插件，开发者亦可依据需要开发个性化的内部插件。CoreDNS 罕用插件如下图，依据应用场景，可分为运维、DNS 解决、后端数据存储等三个类别。
CoreDNS 定义 Corefile 配置文件，服务器在加载 Corefile 后处理 DNS 申请，对于以下插件，只需在 Corefile 中援用即可，之后 CoreDNS 会应用插件链进行调用，插件链可参考以下链接：https://github.com/coredns/co…
设计一个基于 CoreDNS 的分层 DNS 架构
在相熟 CoreDNS 个性后，可设计企业的 DNS 架构：
DNS 架构以外网 DNS、内网 DNS、分区 DNS 组成：
外网 DNS：
- 应用 DNSSEC、DOT、DOH 等保障 DNS 平安；
- 缓存 DNS 记录；
- 构建 DNS 实例主动伸缩，应答高 QPS 需要；
内网 DNS：
- Kubernetes 服务发现；
- 构建上游 DNS 区域；
分区 DNS：
- 建设开发、测试、UAT、生产等区域 DNS；
- NodeLocalDNS 进步性能；
- 设置转发器解决递归 DNS 申请；
KubeSphere 部署 CoreDNS
因为 CoreDNS 是一个 CNCF 毕业的云原生我的项目，是目前反对云原生最好的一个 DNS 服务器，用户可间接在 KubeSphere 利用商店一键装置。KubeSphere 提供了基于 Helm 模板的利用商店，反对云原生利用的生命周期治理，提供开发人员利用上传、测试，版本提交，利用管理人员进行审核、公布等流程治理。用户在利用商店抉择 CoreDNS 利用后，可按需部署于不同集群的不同我的项目中，并自定义利用模板配置：
服务发现与 DNS 配置
部署 CoreDNS 后，对于运维人员来说，CoreDNS 的配置大体分为两类：一类为 Kubernetes 配置，一类为 DNS 配置。CoreDNS 提供了 Kubernetes 插件，反对在 kubernetes 集群中读取区域数据，并依据 Pod 和 Service 的域名记录相应的 A 记录和 PTR 记录。
这是一个 Kubernetes 集群中的 CoreDNS corefile 默认配置，CoreDNS 会在 53 端口读取 cluster.local 后缀的 Kubernetes 集群 A 记录和 PTR 记录。并将 CoreDNS 收集到的监控指标通过 9153 端口输入到集群内的 Prometheus。而 Kubernetes 不同类型 Service 的 DNS 记录格局，CoreDNS 也有相应规范进行记录。
设置完 Kubernetes 后，能够设置其余业务需要的 DNS 配置，如：
- 设置不同的存根域；
- 设置存根域动态 DNS 条目；
- 面对存量代码，设置域名重写；
- 面对集群外服务，设置 DNS 转发；
- 设置日志和监控集成；
- 设置缓存、衰弱、就绪查看及链路追踪；
依据以上配置，就构建了一个根底的企业云原生 DNS 零碎：
DNS 服务裸露
对于集群外的服务而言，存量业务可能还是一些虚拟化和裸机的利用，若和集群网络无奈互联，如何在业务迁徙时拜访新的 DNS 服务？
KubeSphere 提供了一个开源我的项目——OpenELB 来解决云原生环境下的服务裸露问题，这是一个 CNCF 的沙箱我的项目。OpenELB 通过物理环境的交换机应用 BGP 协定将 LoadBalancer 类型服务的 ExternalIP 宣告进来，在 IP 可达的环境下集群内部业务即可通过 EIP 拜访 Kubernetes 服务资源。
对于集群外须要设置 DNS 服务器的服务资源，可通过 OpenELB 应用 EIP 裸露 CoreDNS，即可拜访 DNS 服务。
在 KubeSphere 3.3 版本，用户可在开启集群网关 / 我的项目网关时，在网关拜访 LoadBalancer 模式下，抉择“OpenELB”负载平衡提供商，之后创立的 LoadBalancer 服务都会从 OpenELB 建设的 EIP Pool 中调配 EIP，供集群内部拜访。
DNS 监控运维
为保障 CoreDNS 稳固运行，运维人员还需在基础设施侧欠缺 DNS 零碎的日志、监控、告警、告诉性能，KubeSphere 提供了简略易用的监控面板、日志治理与落盘，多维度的告警策略和音讯，以及对接多个企业应用（邮件，钉钉，企业微信）的告诉零碎，时刻关注业务运行状态。
此处以一个系统管理员视角，展现了在 KubeSphere 日志零碎搜查 NXDOMAIN 类型 DNS 回复的后果。
通过 KubeSphere 自定义监控面板，设置一个基于 CoreDNS 指标的监控面板，KubeSphere 内置了泛滥监控面板，用户可间接应用模板构建亦可应用 PromQL 创立面板：
通过 KubeSphere 告警和告诉组件，用户可基于预置规定模板（CPU、内存、磁盘、网络、异样率）或应用 PromQL 语句自定义告警规定，此处定义当 CoreDNS CPU 用量大于等于 0.1Core 零碎触发告警：
KubeSphere 针对租户设计了告诉模板，蕴含多种告诉系统集成，此处应用邮件将“重要告警”，“危险告警”条件的告警音讯发送给邮件接管人。
当告警触发后，即可在告警音讯和告诉历史处查看到相应的条目，此时用户也会收到一封告警邮件了：
在高并发 DNS 申请场景中，还需对 CoreDNS 进行主动伸缩设计，通常思考到服务高可用性和性能考量，可参考以下计算规格和调度策略设计：
- 正本打散，跨可用区 / 节点。
- 防止所在节点 CPU、内存过高。
- 通常设计正本数为 2。QPS 与 CPU 耗费正相干，单 CPU——1w+QPS
- Kubernetes 集群下，CoreDNS 正本数与集群节点配置 1:8。
- 业务峰值 CPU 占用 >1Core，程度扩容。
通过 KubeSphere 主动伸缩机制，可设置基于 CPU 用量的主动伸缩策略，保障 CoreDNS 在刹时高并发场景稳固运行。
总结
以上就是建设一个云原生的 DNS 零碎的全部内容了，能够看出，在云原生时代，新的技术层出不穷，IT 零碎的部门和人员也越发趋于协同作战，以往构建一个 DNS 零碎可能只须要装置一套稳固能进行 DNS 解析的零碎，并实现主备切换即可。在利用驱动基础架构转型的云原生时代，根底服务利用还更须要思考异构零碎的连贯，灵便简便的装置降级治理，更弱小的可靠性和自愈能力，日志监控告诉零碎的欠缺，还有更适宜理论业务需要的弹性设计，来减速利用现代化，推动业务利用继续转型。
本文由博客一文多发平台 OpenWrite 公布！
