Do you have some documentation lying around describing the benefits of this over having different cluster domains and then just having zones with forwards in each coredns config? For example, how to you deal with collisions if there are identically named services and the cluster domain is the same? My thinking is that you get most of the benefits with using dns, and then where you genuinely want to have apps contact services regardless of where they are, you create a service to point to the dns entry (rather than the remote cluster IP, which this appears to try and be solving). Eg. securebackups.myns.mycluster.local could be a service which points to either securebackups-real.myns.mycluster.local, securebackups-real.myns.hiscluster.local or securebackups-real.myns.hercluster.local, depending on current needs/constraints.
Am I missing something that the automated service-based approach adds over dns?
Do you have some documentation lying around describing the benefits of this over having different cluster domains and then just having zones with forwards in each coredns config? For example, how to you deal with collisions if there are identically named services and the cluster domain is the same? My thinking is that you get most of the benefits with using dns, and then where you genuinely want to have apps contact services regardless of where they are, you create a service to point to the dns entry (rather than the remote cluster IP, which this appears to try and be solving). Eg. securebackups.myns.mycluster.local could be a service which points to either securebackups-real.myns.mycluster.local, securebackups-real.myns.hiscluster.local or securebackups-real.myns.hercluster.local, depending on current needs/constraints.
Am I missing something that the automated service-based approach adds over dns?