目前公司正在做的发布系统正在面临DNS相关的设计问题。
公司的应用都会按域名的方式连接mysql、redis等存储资源，也会按域名调用其他应用。
传统虚拟机的hosts解析方案
当前的处理方式是基于hosts文件完成解析的，其利弊如下：
- 优点：不用维护DNS服务，每个应用的解析具备隔离性，很容易看出应用的依赖（前提是应用不能混布）。
- 坏处：hosts文件需要分发到集群各个节点，应用依赖需要逐个梳理，不如DNS全局管理爽。
K8S内的解析方案
迁移到K8S后有哪些应对方式呢？
- 基于coredns，其利弊如下：
- 好处：方便全局管理，准实时生效
- 坏处：
- 应用之间不具备隔离性（比如2个应用要求同一个host解析到不同IP）
- 修改配置失误容易集群宕机
- dns服务资源占用要求高
- 基于hosts，其利弊如下：
- 好处：
- 应用解析隔离，修改错误影响面小
- 没有DNS服务的资源占用
- 坏处：
- 仍需混合使用Coredns支持K8S的service解析
- hosts是POD级配置，所以修改hosts需要重新发布POD
- 要求应用之间做好资源隔离，比如不要共享mysql或者redis，否则host变更ip需要每个应用都重新发布一遍。
- 好处：
我认为在微服务资源拆分良好的情况下，如果公司业务同时存在VM和K8S资源，那么可以考虑使用hosts来支持VM资源解析，coredns来支持K8S资源解析，这样可以平滑的支撑从VM到K8S的过度过程。
最终所有VM资源全部迁入K8S后，就可以只维护coredns了。
关于hosts配置，参考官方文档即可：https://kubernetes.io/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases/。
其配置示例如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
apiVersion: v1 kind: Pod metadata: name: hostaliases-pod spec: restartPolicy: Never hostAliases: - ip: "127.0.0.1" hostnames: - "foo.local" - "bar.local" - ip: "10.1.2.3" hostnames: - "foo.remote" - "bar.remote" containers: - name: cat-hosts image: busybox command: - cat args: - "/etc/hosts" |
通过hostAliases可以追加hosts项到POD内所有容器的/etc/hosts文件中，非常简单。
最终的方式
集群内走coredns，集群外VM hosts的解析交给coredns的上游，这样应该是个更合理的架构。
如果文章帮助您解决了工作难题，您可以帮我点击屏幕上的任意广告，或者赞助少量费用来支持我的持续创作，谢谢~
