文章目录
场景
使用argo时遇到的问题，argoWorkFlow和argo-Events是两个不同的组件，他们允许在不同的命名空间中。此时argo-events需要访问到argoWrokFlow的minio组件，以下以A代替argo-evnets命名空间B代替命名空间argo
一、Kube-DNS
集群中定义的每个 Service （包括 DNS 服务器自身）都被赋予一个 DNS 名称。 默认情况下，客户端 Pod 的 DNS 搜索列表会包含 Pod 自身的名字空间和集群 的默认域。
Service
A/AAAA 记录
“普通” 服务（除了无头服务）会以 my-svc.my-namespace.svc.cluster-domain.example 这种名字的形式被分配一个 DNS A 或 AAAA 记录，取决于服务的 IP 协议族。 该名称会解析成对应服务的集群 IP。
“无头（Headless）” 服务（没有集群 IP）也会以 my-svc.my-namespace.svc.cluster-domain.example 这种名字的形式被指派一个 DNS A 或 AAAA 记录， 具体取决于服务的 IP 协议族。 与普通服务不同，这一记录会被解析成对应服务所选择的 Pod 集合的 IP。 客户端要能够使用这组 IP，或者使用标准的轮转策略从这组 IP 中进行选择。[https://www.cnblogs.com/allcloud/p/7614123.html]
- kubeDNS：提供了原来 kube2sky + etcd + skyDNS 的功能，可以单独对外提供 DNS 查询服务
- dnsmasq： 一个轻量级的 DNS 服务软件，可以提供 DNS 缓存功能。kubeDNS 模式下，dnsmasq 在内存中预留一块大小（默认是 1G）的地方，保存当前最常用的 DNS 查询记录，如果缓存中没有要查找的记录，它会到 kubeDNS 中查询，并把结果缓存起来
- 每种模式都可以运行额外的 exec-healthz 容器对外提供 health check 功能，证明当前 DNS 服务是正常的。
exec-healthz：运行某个命令，根据结果来对外提供 /healthz 结果
2.externalName Service
使用ExternalName将外部服务映射到内部服务。通过返回CNAME和它的值，可以将服务映射到externalName字段的内容上。
代码如下（示例）：
kind: Service
apiVersion: v1
metadata:
name: minio
namespace: argo-events
spec:
type: ExternalName
externalName: minio.argo.svc.cluster.local
ports:
- port: 9000
当创建该service的时候会对应mino.argo-events.svc.cluster.local记录留到kube-dns中,当查找集群的minio.argo-events.svc.cluster.local，集群的dns返回的是minio.argo.svc.cluster.local。也就是当A命名空间的pod访问minio时访问的是B命名空间的minio。
总结
命名空间的作用：是建立一些互相分隔的作用域，把一些全局实体分隔开来。要在不同命名空间相互访问，并且以不定死ip的方式访问。即不根据cluster ip/pod ip的访问pod,可以通过K8S自带的域名解析对其pod 暴露的endpoint 进行访问。