在 Kubernetes 集群中，服务间访问主要通过 **DNS 域名解析** 和 **Service 的负载均衡机制** 实现，以下是具体实现方式和原理：
---
### **1. 服务间访问的核心机制**
• **DNS 解析**：
Kubernetes 默认使用 **CoreDNS** 作为集群内的 DNS 服务，为每个 Service 创建域名记录，格式为 `<service-name>.<namespace>.svc.cluster.local`。例如，名为 `my-service` 的服务在 `default` 命名空间下的域名是 `my-service.default.svc.cluster.local`。应用通过此域名访问服务时，DNS 会将其解析为 Service 的 ClusterIP 地址。
• **Service 的负载均衡**：
ClusterIP 类型的 Service 会通过 kube-proxy 维护 iptables/IPVS 规则，将流量均匀转发到后端 Pod。即使 Pod IP 变化，Service 的虚拟 IP（ClusterIP）保持不变，确保访问稳定性。
---
### **2. 具体实现细节**
#### **(1) DNS 解析流程**
1. **Pod 的 DNS 配置**：
每个 Pod 的 `/etc/resolv.conf` 文件默认指向 CoreDNS 的 ClusterIP（如 `10.96.0.10`），并配置搜索域（如 `default.svc.cluster.local`），简化域名输入。
```plaintext
nameserver 10.96.0.10
search default.svc.cluster.local
options ndots:5
```
2. **域名解析过程**：
• 应用通过服务名（如 `my-service`）发起请求，CoreDNS 将其解析为 ClusterIP。
• 若跨命名空间访问，需使用完整域名（如 `my-service.other-ns.svc.cluster.local`）。
#### **(2) 流量转发**
• **kube-proxy 的角色**：
kube-proxy 根据 Service 配置生成 iptables 或 IPVS 规则，将 ClusterIP 的流量负载均衡到后端 Pod IP。例如，访问 `my-service` 的请求会被转发到关联 Pod 的 IP 和端口。
#### **(3) 其他访问方式**
• **环境变量（辅助方式）**：
Pod 启动时会注入环境变量（如 `MY_SERVICE_SERVICE_HOST` 和 `MY_SERVICE_SERVICE_PORT`），但仅适用于同一命名空间下的服务，且依赖启动顺序，因此 **DNS 是推荐方式**。
---
### **3. 关键配置策略**
• **DNS Policy**：
• **ClusterFirst**（默认）：优先使用集群 DNS（CoreDNS），适用于服务间通信。
• **Default**：继承宿主机的 DNS 配置，适用于需要访问外部服务的场景。
• **None**：自定义 DNS 配置，需通过 `dnsConfig` 手动指定。
• **Headless Service**：
当需要直接访问 Pod IP（如 StatefulSet 场景），可创建 Headless Service（无 ClusterIP），此时 DNS 返回所有 Pod IP，客户端自行选择。
---
### **4. 总结**
• **主要依赖**：服务间访问 **主要依赖 DNS 解析**（CoreDNS）和 Service 的负载均衡机制。
• **优势**：通过 DNS 抽象了后端 Pod 的动态 IP，提供稳定的服务发现和负载均衡。
• **适用场景**：
• 微服务内部通信（如 API 调用、数据库访问）。
• 跨命名空间服务交互。
如果需要更深入的技术细节（如 Ingress 七层路由或跨集群访问），可进一步探讨。
