Service

Service 通過標簽選擇 pod，將各 pod 的 ip 保存到它的 endpoints 屬性中。Service 的收到的請求會被均攤到這一組 endpoints 上。

DNS

在 k8s 中做服務發現，最常用的方式是通過 DNS 解析。

在我們的 k8s 集群配置了 dns 服務（最常用的是 coredns）的前提下，我們就可以直接通過全限定域名（FQDN）來訪問別的服務。

全限定域名的格式如下：

# 格式
<service-name>.<namespace>.svc.cluster.local  # 域名 .svc.cluster.local 是可自定義的

# 舉例：訪問 default 名字空間下的 nginx 服務
nginx.default.svc.cluster.local

如果兩個服務在同一個名字空間內，可以省略掉后面的 .<namespace>.svc.cluster.local，直接以服務名稱為 DNS 訪問別的服務

P.S. DNS 服務發現的實現方式：修改每個容器的 /etc/resolv.conf，使容器訪問 k8s 自己的 dns 服務器。而該 dns 服務器知道系統中的所有服務，所以它能給出正確的響應。

SRV 記錄

Service 除了會使用最常見的 A 記錄做 Pod 的負載均衡外，還提供一種 SRV 記錄，這種類型的服務被稱為 Headless Service.

將 Service 的 spec.ClusterIP 設為 None，得到的就是一個 Headless Service。

普通的 Service 擁有自己的 ClusterIP 地址，service name 會被 DNS 解析到這個虛擬的 ClusterIP（A 記錄或 CNAME 記錄），然后被 kubectl proxy 轉發到具體的 Pod。

而 Headless Service 沒有自己的 ClusterIP（這個值被指定成了 None），service name 只提供 SRV 記錄的 DNS 解析，返回一個 Pods 的 ip/dns 列表。

有狀態集可能會比較需要 SRV 記錄。

最佳實踐

總是使用 Deployment，避免直接使用 ReplicaSet/Pod
為 Pod 的 Port 命名（比如命名成 http/https），然后在 Service 的 targetPort 中通過端口名稱（http/https）來指定目標端口（容器端口）。

更直觀，也更靈活

應用通過 dns 查找/發現其他服務

同一名字空間下的應用，可以直接以服務名稱為域名發現別的服務，如通過 http://nginx 訪問 nginx

Service 配置會話親和性為 ClientIP 可能會更好（會話將被同一個 pod 處理，不會發生轉移）
配置 externalTrafficPolicy: Local 可以防止不必要的網絡跳數，但是可能會導致 pod 之間的流量分配不均。

總結

以上是生活随笔為你收集整理的Kubernetes 学习笔记（四）：详解 k8s 的各项资源的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。