K8S – 给POD配置host

目前公司正在做的发布系统正在面临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/

其配置示例如下:

通过hostAliases可以追加hosts项到POD内所有容器的/etc/hosts文件中,非常简单。

最终的方式

集群内走coredns,集群外VM hosts的解析交给coredns的上游,这样应该是个更合理的架构。

如果文章帮助到你,那么帮我点一下广告 or 打赏1元钱,服务器费用需要大家的支持。

发表评论

电子邮件地址不会被公开。