服務(wù)

將運(yùn)行在一組 Pods 上的應(yīng)用程序公開為網(wǎng)絡(luò)服務(wù)的抽象方法拯腮。

使用 Kubernetes，你無需修改應(yīng)用程序即可使用不熟悉的服務(wù)發(fā)現(xiàn)機(jī)制。 Kubernetes 為 Pods 提供自己的 IP 地址仁卷，并為一組 Pod 提供相同的 DNS 名， 并且可以在它們之間進(jìn)行負(fù)載均衡馆里。

動(dòng)機(jī)

創(chuàng)建和銷毀 Kubernetes Pod 以匹配集群狀態(tài)蟹演。 Pod 是非永久性資源。 如果你使用 Deployment 來運(yùn)行你的應(yīng)用程序活喊，則它可以動(dòng)態(tài)創(chuàng)建和銷毀 Pod。

每個(gè) Pod 都有自己的 IP 地址量愧，但是在 Deployment 中钾菊，在同一時(shí)刻運(yùn)行的 Pod 集合可能與稍后運(yùn)行該應(yīng)用程序的 Pod 集合不同。

這導(dǎo)致了一個(gè)問題： 如果一組 Pod（稱為“后端”）為集群內(nèi)的其他 Pod（稱為“前端”）提供功能偎肃， 那么前端如何找出并跟蹤要連接的 IP 地址煞烫，以便前端可以使用提供工作負(fù)載的后端部分？

進(jìn)入 Services累颂。

Service 資源

Kubernetes Service 定義了這樣一種抽象：邏輯上的一組 Pod滞详，一種可以訪問它們的策略 —— 通常稱為微服務(wù)。 Service 所針對(duì)的 Pods 集合通常是通過選擇算符來確定的紊馏。 要了解定義服務(wù)端點(diǎn)的其他方法料饥，請(qǐng)參閱不帶選擇算符的服務(wù)。

舉個(gè)例子朱监，考慮一個(gè)圖片處理后端岸啡，它運(yùn)行了 3 個(gè)副本。這些副本是可互換的 —— 前端不需要關(guān)心它們調(diào)用了哪個(gè)后端副本赫编。 然而組成這一組后端程序的 Pod 實(shí)際上可能會(huì)發(fā)生變化巡蘸， 前端客戶端不應(yīng)該也沒必要知道，而且也不需要跟蹤這一組后端的狀態(tài)擂送。

Service 定義的抽象能夠解耦這種關(guān)聯(lián)悦荒。

云原生服務(wù)發(fā)現(xiàn)

如果你想要在應(yīng)用程序中使用 Kubernetes API 進(jìn)行服務(wù)發(fā)現(xiàn)，則可以查詢 API 服務(wù)器 的 Endpoints 資源嘹吨，只要服務(wù)中的 Pod 集合發(fā)生更改搬味，Endpoints 就會(huì)被更新。

對(duì)于非本機(jī)應(yīng)用程序，Kubernetes 提供了在應(yīng)用程序和后端 Pod 之間放置網(wǎng)絡(luò)端口或負(fù)載均衡器的方法身腻。

定義 Service

Service 在 Kubernetes 中是一個(gè) REST 對(duì)象产还，和 Pod 類似。 像所有的 REST 對(duì)象一樣嘀趟，Service 定義可以基于 POST 方式脐区，請(qǐng)求 API server 創(chuàng)建新的實(shí)例。 Service 對(duì)象的名稱必須是合法的 RFC 1035 標(biāo)簽名稱.她按。

例如牛隅，假定有一組 Pod，它們對(duì)外暴露了 9376 端口酌泰，同時(shí)還被打上 app=MyApp 標(biāo)簽：

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

上述配置創(chuàng)建一個(gè)名稱為 "my-service" 的 Service 對(duì)象媒佣，它會(huì)將請(qǐng)求代理到使用 TCP 端口 9376，并且具有標(biāo)簽 "app=MyApp" 的 Pod 上陵刹。

Kubernetes 為該服務(wù)分配一個(gè) IP 地址（有時(shí)稱為 "集群IP"）默伍，該 IP 地址由服務(wù)代理使用。 (請(qǐng)參見下面的 VIP 和 Service 代理).

服務(wù)選擇算符的控制器不斷掃描與其選擇器匹配的 Pod衰琐，然后將所有更新發(fā)布到也稱為 “my-service” 的 Endpoint 對(duì)象也糊。

說明： 需要注意的是，Service 能夠?qū)⒁粋€(gè)接收 port 映射到任意的 targetPort羡宙。 默認(rèn)情況下狸剃，targetPort 將被設(shè)置為與 port 字段相同的值。

Pod 中的端口定義是有名字的狗热，你可以在服務(wù)的 targetPort 屬性中引用這些名稱钞馁。 即使服務(wù)中使用單個(gè)配置的名稱混合使用 Pod，并且通過不同的端口號(hào)提供相同的網(wǎng)絡(luò)協(xié)議匿刮，此功能也可以使用僧凰。 這為部署和發(fā)展服務(wù)提供了很大的靈活性。 例如熟丸，你可以更改 Pods 在新版本的后端軟件中公開的端口號(hào)训措，而不會(huì)破壞客戶端。

服務(wù)的默認(rèn)協(xié)議是 TCP虑啤；你還可以使用任何其他受支持的協(xié)議。

由于許多服務(wù)需要公開多個(gè)端口架馋，因此 Kubernetes 在服務(wù)對(duì)象上支持多個(gè)端口定義狞山。 每個(gè)端口定義可以具有相同的 protocol，也可以具有不同的協(xié)議叉寂。

沒有選擇算符的 Service

服務(wù)最常見的是抽象化對(duì) Kubernetes Pod 的訪問萍启，但是它們也可以抽象化其他種類的后端。 實(shí)例:

• 希望在生產(chǎn)環(huán)境中使用外部的數(shù)據(jù)庫(kù)集群，但測(cè)試環(huán)境使用自己的數(shù)據(jù)庫(kù)勘纯。
• 希望服務(wù)指向另一個(gè) 名字空間（Namespace） 中或其它集群中的服務(wù)局服。
• 你正在將工作負(fù)載遷移到 Kubernetes。 在評(píng)估該方法時(shí)驳遵，你僅在 Kubernetes 中運(yùn)行一部分后端淫奔。

在任何這些場(chǎng)景中，都能夠定義沒有選擇算符的 Service堤结。 實(shí)例:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

由于此服務(wù)沒有選擇算符唆迁，因此不會(huì)自動(dòng)創(chuàng)建相應(yīng)的 Endpoint 對(duì)象。 你可以通過手動(dòng)添加 Endpoint 對(duì)象竞穷，將服務(wù)手動(dòng)映射到運(yùn)行該服務(wù)的網(wǎng)絡(luò)地址和端口：

apiVersion: v1
kind: Endpoints
metadata:
  name: my-service
subsets:
  - addresses:
      - ip: 192.0.2.42
    ports:
      - port: 9376

Endpoints 對(duì)象的名稱必須是合法的 DNS 子域名唐责。

說明：

端點(diǎn) IPs 必須不可以 是：本地回路（IPv4 的 127.0.0.0/8, IPv6 的 ::1/128）或 本地鏈接（IPv4 的 169.254.0.0/16 和 224.0.0.0/24，IPv6 的 fe80::/64)瘾带。

端點(diǎn) IP 地址不能是其他 Kubernetes 服務(wù)的集群 IP鼠哥，因?yàn)?kube-proxy 不支持將虛擬 IP 作為目標(biāo)。

訪問沒有選擇算符的 Service看政，與有選擇算符的 Service 的原理相同朴恳。 請(qǐng)求將被路由到用戶定義的 Endpoint，YAML 中為：192.0.2.42:9376（TCP）帽衙。

ExternalName Service 是 Service 的特例菜皂，它沒有選擇算符，但是使用 DNS 名稱厉萝。 有關(guān)更多信息恍飘，請(qǐng)參閱本文檔后面的ExternalName。

超出容量的 Endpoints

如果某個(gè) Endpoints 資源中包含的端點(diǎn)個(gè)數(shù)超過 1000谴垫，則 Kubernetes v1.22 版本 （及更新版本）的集群會(huì)將為該 Endpoints 添加注解 endpoints.kubernetes.io/over-capacity: truncated章母。 這一注解表明所影響到的 Endpoints 對(duì)象已經(jīng)超出容量，此外 Endpoints 控制器還會(huì)將 Endpoints 對(duì)象數(shù)量截?cái)嗟?1000翩剪。

EndpointSlices

FEATURE STATE: Kubernetes v1.21 [stable]

EndpointSlices 是一種 API 資源乳怎，可以為 Endpoints 提供更可擴(kuò)展的替代方案。 盡管從概念上講與 Endpoints 非常相似前弯，但 EndpointSlices 允許跨多個(gè)資源分布網(wǎng)絡(luò)端點(diǎn)蚪缀。 默認(rèn)情況下，一旦到達(dá) 100 個(gè) Endpoint恕出，該 EndpointSlice 將被視為“已滿”询枚， 屆時(shí)將創(chuàng)建其他 EndpointSlices 來存儲(chǔ)任何其他 Endpoints。

EndpointSlices 提供了附加的屬性和功能浙巫，這些屬性和功能在 EndpointSlices 中有詳細(xì)描述金蜀。

應(yīng)用協(xié)議

FEATURE STATE: Kubernetes v1.20 [stable]

appProtocol 字段提供了一種為每個(gè) Service 端口指定應(yīng)用協(xié)議的方式刷后。 此字段的取值會(huì)被映射到對(duì)應(yīng)的 Endpoints 和 EndpointSlices 對(duì)象。

該字段遵循標(biāo)準(zhǔn)的 Kubernetes 標(biāo)簽語(yǔ)法渊抄。 其值可以是 IANA 標(biāo)準(zhǔn)服務(wù)名稱 或以域名為前綴的名稱尝胆，如 mycompany.com/my-custom-protocol。

虛擬 IP 和 Service 代理

在 Kubernetes 集群中护桦，每個(gè) Node 運(yùn)行一個(gè) kube-proxy 進(jìn)程含衔。 kube-proxy 負(fù)責(zé)為 Service 實(shí)現(xiàn)了一種 VIP（虛擬 IP）的形式，而不是 ExternalName 的形式嘶炭。

為什么不使用 DNS 輪詢抱慌？

時(shí)不時(shí)會(huì)有人問到為什么 Kubernetes 依賴代理將入站流量轉(zhuǎn)發(fā)到后端。那其他方法呢眨猎？ 例如抑进，是否可以配置具有多個(gè) A 值（或 IPv6 為 AAAA）的 DNS 記錄，并依靠輪詢名稱解析睡陪？

使用服務(wù)代理有以下幾個(gè)原因：

• DNS 實(shí)現(xiàn)的歷史由來已久寺渗，它不遵守記錄 TTL，并且在名稱查找結(jié)果到期后對(duì)其進(jìn)行緩存兰迫。
• 有些應(yīng)用程序僅執(zhí)行一次 DNS 查找信殊，并無限期地緩存結(jié)果。
• 即使應(yīng)用和庫(kù)進(jìn)行了適當(dāng)?shù)闹匦陆馕鲋珼NS 記錄上的 TTL 值低或?yàn)榱阋部赡軙?huì)給 DNS 帶來高負(fù)載涡拘，從而使管理變得困難。

userspace 代理模式

這種模式据德，kube-proxy 會(huì)監(jiān)視 Kubernetes 控制平面對(duì) Service 對(duì)象和 Endpoints 對(duì)象的添加和移除操作鳄乏。 對(duì)每個(gè) Service，它會(huì)在本地 Node 上打開一個(gè)端口（隨機(jī)選擇）棘利。 任何連接到“代理端口”的請(qǐng)求橱野，都會(huì)被代理到 Service 的后端 Pods 中的某個(gè)上面（如 Endpoints 所報(bào)告的一樣）。 使用哪個(gè)后端 Pod善玫，是 kube-proxy 基于 SessionAffinity 來確定的水援。

最后，它配置 iptables 規(guī)則茅郎，捕獲到達(dá)該 Service 的 clusterIP（是虛擬 IP） 和 Port 的請(qǐng)求蜗元，并重定向到代理端口，代理端口再代理請(qǐng)求到后端Pod系冗。

默認(rèn)情況下奕扣，用戶空間模式下的 kube-proxy 通過輪轉(zhuǎn)算法選擇后端。

[圖片上傳失敗...(image-d718e8-1646297278583)]

iptables 代理模式

這種模式毕谴，kube-proxy 會(huì)監(jiān)視 Kubernetes 控制節(jié)點(diǎn)對(duì) Service 對(duì)象和 Endpoints 對(duì)象的添加和移除成畦。 對(duì)每個(gè) Service，它會(huì)配置 iptables 規(guī)則涝开，從而捕獲到達(dá)該 Service 的 clusterIP 和端口的請(qǐng)求循帐，進(jìn)而將請(qǐng)求重定向到 Service 的一組后端中的某個(gè) Pod 上面。 對(duì)于每個(gè) Endpoints 對(duì)象舀武，它也會(huì)配置 iptables 規(guī)則拄养，這個(gè)規(guī)則會(huì)選擇一個(gè)后端組合。

默認(rèn)的策略是银舱，kube-proxy 在 iptables 模式下隨機(jī)選擇一個(gè)后端瘪匿。

使用 iptables 處理流量具有較低的系統(tǒng)開銷，因?yàn)榱髁坑?Linux netfilter 處理寻馏， 而無需在用戶空間和內(nèi)核空間之間切換棋弥。 這種方法也可能更可靠。

如果 kube-proxy 在 iptables 模式下運(yùn)行诚欠，并且所選的第一個(gè) Pod 沒有響應(yīng)顽染， 則連接失敗。 這與用戶空間模式不同：在這種情況下轰绵，kube-proxy 將檢測(cè)到與第一個(gè) Pod 的連接已失敗粉寞， 并會(huì)自動(dòng)使用其他后端 Pod 重試。

你可以使用 Pod 就緒探測(cè)器 驗(yàn)證后端 Pod 可以正常工作左腔，以便 iptables 模式下的 kube-proxy 僅看到測(cè)試正常的后端唧垦。 這樣做意味著你避免將流量通過 kube-proxy 發(fā)送到已知已失敗的 Pod。

[圖片上傳失敗...(image-19645b-1646297278583)]

IPVS 代理模式

FEATURE STATE: Kubernetes v1.11 [stable]

在 ipvs 模式下液样，kube-proxy 監(jiān)視 Kubernetes 服務(wù)和端點(diǎn)振亮，調(diào)用 netlink 接口相應(yīng)地創(chuàng)建 IPVS 規(guī)則， 并定期將 IPVS 規(guī)則與 Kubernetes 服務(wù)和端點(diǎn)同步蓄愁。 該控制循環(huán)可確保IPVS 狀態(tài)與所需狀態(tài)匹配双炕。訪問服務(wù)時(shí)，IPVS 將流量定向到后端Pod之一撮抓。

IPVS代理模式基于類似于 iptables 模式的 netfilter 掛鉤函數(shù)妇斤， 但是使用哈希表作為基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)，并且在內(nèi)核空間中工作丹拯。 這意味著站超，與 iptables 模式下的 kube-proxy 相比，IPVS 模式下的 kube-proxy 重定向通信的延遲要短乖酬，并且在同步代理規(guī)則時(shí)具有更好的性能死相。 與其他代理模式相比，IPVS 模式還支持更高的網(wǎng)絡(luò)流量吞吐量咬像。

IPVS 提供了更多選項(xiàng)來平衡后端 Pod 的流量算撮。 這些是：

• rr：輪替（Round-Robin）
• lc：最少鏈接（Least Connection）生宛，即打開鏈接數(shù)量最少者優(yōu)先
• dh：目標(biāo)地址哈希（Destination Hashing）
• sh：源地址哈希（Source Hashing）
• sed：最短預(yù)期延遲（Shortest Expected Delay）
• nq：從不排隊(duì)（Never Queue）

說明：

要在 IPVS 模式下運(yùn)行 kube-proxy，必須在啟動(dòng) kube-proxy 之前使 IPVS 在節(jié)點(diǎn)上可用肮柜。

當(dāng) kube-proxy 以 IPVS 代理模式啟動(dòng)時(shí)陷舅，它將驗(yàn)證 IPVS 內(nèi)核模塊是否可用。 如果未檢測(cè)到 IPVS 內(nèi)核模塊审洞，則 kube-proxy 將退回到以 iptables 代理模式運(yùn)行莱睁。

[圖片上傳失敗...(image-dafc42-1646297278583)]

在這些代理模型中，綁定到服務(wù) IP 的流量： 在客戶端不了解 Kubernetes 或服務(wù)或 Pod 的任何信息的情況下芒澜，將 Port 代理到適當(dāng)?shù)暮蠖恕?/p>

如果要確保每次都將來自特定客戶端的連接傳遞到同一 Pod仰剿， 則可以通過將 service.spec.sessionAffinity 設(shè)置為 "ClientIP" （默認(rèn)值是 "None"），來基于客戶端的 IP 地址選擇會(huì)話關(guān)聯(lián)痴晦。 你還可以通過適當(dāng)設(shè)置 service.spec.sessionAffinityConfig.clientIP.timeoutSeconds 來設(shè)置最大會(huì)話停留時(shí)間南吮。 （默認(rèn)值為 10800 秒，即 3 小時(shí)）誊酌。

多端口 Service

對(duì)于某些服務(wù)旨袒，你需要公開多個(gè)端口。 Kubernetes 允許你在 Service 對(duì)象上配置多個(gè)端口定義术辐。 為服務(wù)使用多個(gè)端口時(shí)砚尽，必須提供所有端口名稱，以使它們無歧義辉词。 例如：

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 9376
    - name: https
      protocol: TCP
      port: 443
      targetPort: 9377

說明：

與一般的Kubernetes名稱一樣必孤，端口名稱只能包含小寫字母數(shù)字字符 和 -。 端口名稱還必須以字母數(shù)字字符開頭和結(jié)尾瑞躺。

例如敷搪，名稱 123-abc 和 web 有效一也，但是 123_abc 和 -web 無效裁僧。

選擇自己的 IP 地址

在 Service 創(chuàng)建的請(qǐng)求中税弃，可以通過設(shè)置 spec.clusterIP 字段來指定自己的集群 IP 地址献烦。 比如，希望替換一個(gè)已經(jīng)已存在的 DNS 條目派继，或者遺留系統(tǒng)已經(jīng)配置了一個(gè)固定的 IP 且很難重新配置恰力。

用戶選擇的 IP 地址必須合法可岂，并且這個(gè) IP 地址在 service-cluster-ip-range CIDR 范圍內(nèi)岸售， 這對(duì) API 服務(wù)器來說是通過一個(gè)標(biāo)識(shí)來指定的践樱。 如果 IP 地址不合法，API 服務(wù)器會(huì)返回 HTTP 狀態(tài)碼 422凸丸，表示值不合法拷邢。

流量策略

外部流量策略

你可以通過設(shè)置 spec.externalTrafficPolicy 字段來控制來自于外部的流量是如何路由的。 可選值有 Cluster 和 Local屎慢。字段設(shè)為 Cluster 會(huì)將外部流量路由到所有就緒的端點(diǎn)瞭稼， 設(shè)為 Local 會(huì)只路由到當(dāng)前節(jié)點(diǎn)上就緒的端點(diǎn)忽洛。 如果流量策略設(shè)置為 Local，而且當(dāng)前節(jié)點(diǎn)上沒有就緒的端點(diǎn)环肘，kube-proxy 不會(huì)轉(zhuǎn)發(fā)請(qǐng)求相關(guān)服務(wù)的任何流量脐瑰。

說明：

FEATURE STATE: Kubernetes v1.22 [alpha]

如果你啟用了 kube-proxy 的 ProxyTerminatingEndpoints 特性門控， kube-proxy 會(huì)檢查節(jié)點(diǎn)是否有本地的端點(diǎn)廷臼，以及是否所有的本地端點(diǎn)都被標(biāo)記為終止中。

如果本地有端點(diǎn)绝页，而且所有端點(diǎn)處于終止中的狀態(tài)荠商，那么 kube-proxy 會(huì)忽略任何設(shè)為 Local 的外部流量策略。 在所有本地端點(diǎn)處于終止中的狀態(tài)的同時(shí)续誉，kube-proxy 將請(qǐng)求指定服務(wù)的流量轉(zhuǎn)發(fā)到位于其它節(jié)點(diǎn)的 狀態(tài)健康的端點(diǎn)莱没，如同外部流量策略設(shè)為 Cluster。

針對(duì)處于正被終止?fàn)顟B(tài)的端點(diǎn)這一轉(zhuǎn)發(fā)行為使得外部負(fù)載均衡器可以優(yōu)雅地排出由 NodePort 服務(wù)支持的連接酷鸦，就算是健康檢查節(jié)點(diǎn)端口開始失敗也是如此饰躲。 否則，當(dāng)節(jié)點(diǎn)還在負(fù)載均衡器的節(jié)點(diǎn)池內(nèi)臼隔，在 Pod 終止過程中的流量會(huì)被丟掉嘹裂，這些流量可能會(huì)丟失。

內(nèi)部流量策略

FEATURE STATE: Kubernetes v1.22 [beta]

你可以設(shè)置 spec.internalTrafficPolicy 字段來控制內(nèi)部來源的流量是如何轉(zhuǎn)發(fā)的摔握〖睦牵可設(shè)置的值有 Cluster 和 Local。 將字段設(shè)置為 Cluster 會(huì)將內(nèi)部流量路由到所有就緒端點(diǎn)氨淌，設(shè)置為 Local 只會(huì)路由到當(dāng)前節(jié)點(diǎn)上就緒的端點(diǎn)泊愧。 如果流量策略是 Local，而且當(dāng)前節(jié)點(diǎn)上沒有就緒的端點(diǎn)盛正，那么 kube-proxy 會(huì)丟棄流量删咱。

服務(wù)發(fā)現(xiàn)

Kubernetes 支持兩種基本的服務(wù)發(fā)現(xiàn)模式 —— 環(huán)境變量和 DNS。

環(huán)境變量

當(dāng) Pod 運(yùn)行在 Node 上豪筝，kubelet 會(huì)為每個(gè)活躍的 Service 添加一組環(huán)境變量痰滋。 它同時(shí)支持 Docker links兼容 變量 （查看 makeLinkVariables）、 簡(jiǎn)單的 {SVCNAME}_SERVICE_HOST 和 {SVCNAME}_SERVICE_PORT 變量续崖。 這里 Service 的名稱需大寫即寡，橫線被轉(zhuǎn)換成下劃線。

舉個(gè)例子袜刷，一個(gè)名稱為 redis-master 的 Service 暴露了 TCP 端口 6379聪富， 同時(shí)給它分配了 Cluster IP 地址 10.0.0.11，這個(gè) Service 生成了如下環(huán)境變量：

REDIS_MASTER_SERVICE_HOST=10.0.0.11
REDIS_MASTER_SERVICE_PORT=6379
REDIS_MASTER_PORT=tcp://10.0.0.11:6379
REDIS_MASTER_PORT_6379_TCP=tcp://10.0.0.11:6379
REDIS_MASTER_PORT_6379_TCP_PROTO=tcp
REDIS_MASTER_PORT_6379_TCP_PORT=6379
REDIS_MASTER_PORT_6379_TCP_ADDR=10.0.0.11

說明：

當(dāng)你具有需要訪問服務(wù)的 Pod 時(shí)著蟹，并且你正在使用環(huán)境變量方法將端口和集群 IP 發(fā)布到客戶端 Pod 時(shí)墩蔓，必須在客戶端 Pod 出現(xiàn) 之前 創(chuàng)建服務(wù)梢莽。 否則，這些客戶端 Pod 將不會(huì)設(shè)定其環(huán)境變量奸披。

如果僅使用 DNS 查找服務(wù)的集群 IP昏名，則無需擔(dān)心此設(shè)定問題。

DNS

你可以（幾乎總是應(yīng)該）使用附加組件 為 Kubernetes 集群設(shè)置 DNS 服務(wù)阵面。

支持集群的 DNS 服務(wù)器（例如 CoreDNS）監(jiān)視 Kubernetes API 中的新服務(wù)轻局，并為每個(gè)服務(wù)創(chuàng)建一組 DNS 記錄。 如果在整個(gè)集群中都啟用了 DNS样刷，則所有 Pod 都應(yīng)該能夠通過其 DNS 名稱自動(dòng)解析服務(wù)仑扑。

例如，如果你在 Kubernetes 命名空間 my-ns 中有一個(gè)名為 my-service 的服務(wù)置鼻， 則控制平面和 DNS 服務(wù)共同為 my-service.my-ns 創(chuàng)建 DNS 記錄镇饮。 my-ns 命名空間中的 Pod 應(yīng)該能夠通過按名檢索 my-service 來找到服務(wù) （my-service.my-ns 也可以工作）。

其他命名空間中的 Pod 必須將名稱限定為 my-service.my-ns箕母。 這些名稱將解析為為服務(wù)分配的集群 IP储藐。

Kubernetes 還支持命名端口的 DNS SRV（服務(wù)）記錄。 如果 my-service.my-ns 服務(wù)具有名為 http　的端口嘶是，且協(xié)議設(shè)置為 TCP钙勃， 則可以對(duì) _http._tcp.my-service.my-ns 執(zhí)行 DNS SRV 查詢查詢以發(fā)現(xiàn)該端口號(hào), "http" 以及 IP 地址。

Kubernetes DNS 服務(wù)器是唯一的一種能夠訪問 ExternalName 類型的 Service 的方式聂喇。 更多關(guān)于 ExternalName 信息可以查看 DNS Pod 和 Service肺缕。

無頭服務(wù)（Headless Services）

有時(shí)不需要或不想要負(fù)載均衡，以及單獨(dú)的 Service IP授帕。 遇到這種情況同木，可以通過指定 Cluster IP（spec.clusterIP）的值為 "None" 來創(chuàng)建 Headless Service。

你可以使用無頭 Service 與其他服務(wù)發(fā)現(xiàn)機(jī)制進(jìn)行接口跛十，而不必與 Kubernetes 的實(shí)現(xiàn)捆綁在一起彤路。

對(duì)這無頭 Service 并不會(huì)分配 Cluster IP，kube-proxy 不會(huì)處理它們芥映， 而且平臺(tái)也不會(huì)為它們進(jìn)行負(fù)載均衡和路由洲尊。 DNS 如何實(shí)現(xiàn)自動(dòng)配置，依賴于 Service 是否定義了選擇算符奈偏。

帶選擇算符的服務(wù)

對(duì)定義了選擇算符的無頭服務(wù)坞嘀，Endpoint 控制器在 API 中創(chuàng)建了 Endpoints 記錄， 并且修改 DNS 配置返回 A 記錄（IP 地址）惊来，通過這個(gè)地址直接到達(dá) Service 的后端 Pod 上丽涩。

無選擇算符的服務(wù)

對(duì)沒有定義選擇算符的無頭服務(wù)，Endpoint 控制器不會(huì)創(chuàng)建 Endpoints 記錄。 然而 DNS 系統(tǒng)會(huì)查找和配置矢渊，無論是：

• 對(duì)于 ExternalName 類型的服務(wù)继准，查找其 CNAME 記錄
• 對(duì)所有其他類型的服務(wù)，查找與 Service 名稱相同的任何 Endpoints 的記錄

發(fā)布服務(wù)（服務(wù)類型)

對(duì)一些應(yīng)用的某些部分（如前端）矮男，可能希望將其暴露給 Kubernetes 集群外部 的 IP 地址移必。

Kubernetes ServiceTypes 允許指定你所需要的 Service 類型，默認(rèn)是 ClusterIP毡鉴。

Type 的取值以及行為如下：

• ClusterIP：通過集群的內(nèi)部 IP 暴露服務(wù)崔泵，選擇該值時(shí)服務(wù)只能夠在集群內(nèi)部訪問。 這也是默認(rèn)的 ServiceType猪瞬。

• NodePort：通過每個(gè)節(jié)點(diǎn)上的 IP 和靜態(tài)端口（NodePort）暴露服務(wù)憎瘸。 NodePort 服務(wù)會(huì)路由到自動(dòng)創(chuàng)建的 ClusterIP 服務(wù)。 通過請(qǐng)求 <節(jié)點(diǎn) IP>:<節(jié)點(diǎn)端口>撑螺，你可以從集群的外部訪問一個(gè) NodePort 服務(wù)。

• LoadBalancer：使用云提供商的負(fù)載均衡器向外部暴露服務(wù)崎弃。 外部負(fù)載均衡器可以將流量路由到自動(dòng)創(chuàng)建的 NodePort 服務(wù)和 ClusterIP 服務(wù)上甘晤。

• ExternalName：通過返回 CNAME 和對(duì)應(yīng)值，可以將服務(wù)映射到 externalName 字段的內(nèi)容（例如饲做，foo.bar.example.com）线婚。 無需創(chuàng)建任何類型代理。

  說明： 你需要使用 kube-dns 1.7 及以上版本或者 CoreDNS 0.0.8 及以上版本才能使用 ExternalName 類型盆均。

你也可以使用 Ingress 來暴露自己的服務(wù)塞弊。 Ingress 不是一種服務(wù)類型，但它充當(dāng)集群的入口點(diǎn)泪姨。 它可以將路由規(guī)則整合到一個(gè)資源中游沿，因?yàn)樗梢栽谕籌P地址下公開多個(gè)服務(wù)。

NodePort 類型

如果你將 type 字段設(shè)置為 NodePort肮砾，則 Kubernetes 控制平面將在 --service-node-port-range 標(biāo)志指定的范圍內(nèi)分配端口（默認(rèn)值：30000-32767）诀黍。 每個(gè)節(jié)點(diǎn)將那個(gè)端口（每個(gè)節(jié)點(diǎn)上的相同端口號(hào)）代理到你的服務(wù)中。 你的服務(wù)在其 .spec.ports[*].nodePort 字段中要求分配的端口仗处。

如果你想指定特定的 IP 代理端口眯勾，則可以設(shè)置 kube-proxy 中的 --nodeport-addresses 參數(shù) 或者將kube-proxy 配置文件 中的等效 nodePortAddresses 字段設(shè)置為特定的 IP 塊。 該標(biāo)志采用逗號(hào)分隔的 IP 塊列表（例如婆誓，10.0.0.0/8吃环、192.0.2.0/25）來指定 kube-proxy 應(yīng)該認(rèn)為是此節(jié)點(diǎn)本地的 IP 地址范圍。

例如洋幻，如果你使用 --nodeport-addresses=127.0.0.0/8 標(biāo)志啟動(dòng) kube-proxy郁轻， 則 kube-proxy 僅選擇 NodePort Services 的本地回路接口。 --nodeport-addresses 的默認(rèn)值是一個(gè)空列表文留。 這意味著 kube-proxy 應(yīng)該考慮 NodePort 的所有可用網(wǎng)絡(luò)接口范咨。 （這也與早期的 Kubernetes 版本兼容）故觅。

如果需要特定的端口號(hào)，你可以在 nodePort 字段中指定一個(gè)值渠啊。 控制平面將為你分配該端口或報(bào)告 API 事務(wù)失敗输吏。 這意味著你需要自己注意可能發(fā)生的端口沖突。 你還必須使用有效的端口號(hào)替蛉，該端口號(hào)在配置用于 NodePort 的范圍內(nèi)贯溅。

使用 NodePort 可以讓你自由設(shè)置自己的負(fù)載均衡解決方案， 配置 Kubernetes 不完全支持的環(huán)境躲查， 甚至直接暴露一個(gè)或多個(gè)節(jié)點(diǎn)的 IP它浅。

需要注意的是，Service 能夠通過 <NodeIP>:spec.ports[*].nodePort 和 spec.clusterIp:spec.ports[*].port 而對(duì)外可見镣煮。 如果設(shè)置了 kube-proxy 的 --nodeport-addresses 參數(shù)或 kube-proxy 配置文件中的等效字段姐霍， <NodeIP> 將被過濾 NodeIP。

例如：

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: NodePort
  selector:
    app: MyApp
  ports:
      # 默認(rèn)情況下典唇，為了方便起見镊折，`targetPort` 被設(shè)置為與 `port` 字段相同的值。
    - port: 80
      targetPort: 80
      # 可選字段
      # 默認(rèn)情況下介衔，為了方便起見恨胚，Kubernetes 控制平面會(huì)從某個(gè)范圍內(nèi)分配一個(gè)端口號(hào)（默認(rèn)：30000-32767）
      nodePort: 30007

LoadBalancer 類型

在使用支持外部負(fù)載均衡器的云提供商的服務(wù)時(shí)，設(shè)置 type 的值為 "LoadBalancer"炎咖， 將為 Service 提供負(fù)載均衡器赃泡。 負(fù)載均衡器是異步創(chuàng)建的，關(guān)于被提供的負(fù)載均衡器的信息將會(huì)通過 Service 的 status.loadBalancer 字段發(fā)布出去乘盼。

實(shí)例：

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
  clusterIP: 10.0.171.239
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
      - ip: 192.0.2.127

來自外部負(fù)載均衡器的流量將直接重定向到后端 Pod 上升熊，不過實(shí)際它們是如何工作的，這要依賴于云提供商绸栅。

某些云提供商允許設(shè)置 loadBalancerIP僚碎。 在這些情況下，將根據(jù)用戶設(shè)置的 loadBalancerIP 來創(chuàng)建負(fù)載均衡器阴幌。 如果沒有設(shè)置 loadBalancerIP 字段勺阐，將會(huì)給負(fù)載均衡器指派一個(gè)臨時(shí) IP。 如果設(shè)置了 loadBalancerIP矛双，但云提供商并不支持這種特性渊抽，那么設(shè)置的 loadBalancerIP 值將會(huì)被忽略掉。

說明：

在 Azure 上议忽，如果要使用用戶指定的公共類型 loadBalancerIP懒闷，則 首先需要?jiǎng)?chuàng)建靜態(tài)類型的公共 IP 地址資源。 此公共 IP 地址資源應(yīng)與集群中其他自動(dòng)創(chuàng)建的資源位于同一資源組中。 例如愤估，MC_myResourceGroup_myAKSCluster_eastus帮辟。

將分配的 IP 地址設(shè)置為 loadBalancerIP。確保你已更新云提供程序配置文件中的 securityGroupName玩焰。 有關(guān)對(duì) CreatingLoadBalancerFailed 權(quán)限問題進(jìn)行故障排除的信息由驹， 請(qǐng)參閱 與 Azure Kubernetes 服務(wù)（AKS）負(fù)載平衡器一起使用靜態(tài) IP 地址 或在 AKS 集群上使用高級(jí)聯(lián)網(wǎng)時(shí)出現(xiàn) CreatingLoadBalancerFailed。

混合協(xié)議類型的負(fù)載均衡器

FEATURE STATE: Kubernetes v1.20 [alpha]

默認(rèn)情況下昔园，對(duì)于 LoadBalancer 類型的服務(wù)蔓榄，當(dāng)定義了多個(gè)端口時(shí)，所有 端口必須具有相同的協(xié)議默刚，并且該協(xié)議必須是受云提供商支持的協(xié)議甥郑。

如果為 kube-apiserver 啟用了 MixedProtocolLBService 特性門控， 則當(dāng)定義了多個(gè)端口時(shí)荤西，允許使用不同的協(xié)議澜搅。

說明： 可用于 LoadBalancer 類型服務(wù)的協(xié)議集仍然由云提供商決定。

禁用負(fù)載均衡器節(jié)點(diǎn)端口分配

FEATURE STATE: Kubernetes v1.20 [alpha]

從 v1.20 版本開始邪锌， 你可以通過設(shè)置 spec.allocateLoadBalancerNodePorts 為 false 對(duì)類型為 LoadBalancer 的服務(wù)禁用節(jié)點(diǎn)端口分配勉躺。 這僅適用于直接將流量路由到 Pod 而不是使用節(jié)點(diǎn)端口的負(fù)載均衡器實(shí)現(xiàn)。 默認(rèn)情況下秃流，spec.allocateLoadBalancerNodePorts 為 true赂蕴， LoadBalancer 類型的服務(wù)繼續(xù)分配節(jié)點(diǎn)端口柳弄。 如果現(xiàn)有服務(wù)已被分配節(jié)點(diǎn)端口舶胀，將參數(shù) spec.allocateLoadBalancerNodePorts 設(shè)置為 false 時(shí)，這些服務(wù)上已分配置的節(jié)點(diǎn)端口不會(huì)被自動(dòng)釋放碧注。 你必須顯式地在每個(gè)服務(wù)端口中刪除 nodePorts 項(xiàng)以釋放對(duì)應(yīng)端口嚣伐。 你必須啟用 ServiceLBNodePortControl 特性門控才能使用該字段。

設(shè)置負(fù)載均衡器實(shí)現(xiàn)的類別

FEATURE STATE: Kubernetes v1.22 [beta]

spec.loadBalancerClass 允許你不使用云提供商的默認(rèn)負(fù)載均衡器實(shí)現(xiàn)萍丐，轉(zhuǎn)而使用指定的負(fù)載均衡器實(shí)現(xiàn)轩端。 這個(gè)特性從 v1.21 版本開始可以使用，你在 v1.21 版本中使用這個(gè)字段必須啟用 ServiceLoadBalancerClass 特性門控逝变，這個(gè)特性門控從 v1.22 版本及以后默認(rèn)打開基茵。 默認(rèn)情況下，.spec.loadBalancerClass 的取值是 nil壳影，如果集群使用 --cloud-provider 配置了云提供商拱层， LoadBalancer 類型服務(wù)會(huì)使用云提供商的默認(rèn)負(fù)載均衡器實(shí)現(xiàn)。 如果設(shè)置了 .spec.loadBalancerClass宴咧，則假定存在某個(gè)與所指定的類相匹配的 負(fù)載均衡器實(shí)現(xiàn)在監(jiān)視服務(wù)變化根灯。 所有默認(rèn)的負(fù)載均衡器實(shí)現(xiàn)（例如，由云提供商所提供的）都會(huì)忽略設(shè)置了此字段 的服務(wù)。.spec.loadBalancerClass 只能設(shè)置到類型為 LoadBalancer 的 Service 之上烙肺，而且一旦設(shè)置之后不可變更纳猪。

.spec.loadBalancerClass 的值必須是一個(gè)標(biāo)簽風(fēng)格的標(biāo)識(shí)符， 可以有選擇地帶有類似 "internal-vip" 或 "example.com/internal-vip" 這類 前綴桃笙。沒有前綴的名字是保留給最終用戶的氏堤。

內(nèi)部負(fù)載均衡器

在混合環(huán)境中，有時(shí)有必要在同一(虛擬)網(wǎng)絡(luò)地址塊內(nèi)路由來自服務(wù)的流量怎栽。

在水平分割 DNS 環(huán)境中丽猬，你需要兩個(gè)服務(wù)才能將內(nèi)部和外部流量都路由到你的端點(diǎn)（Endpoints）。

如要設(shè)置內(nèi)部負(fù)載均衡器熏瞄，請(qǐng)根據(jù)你所使用的云運(yùn)營(yíng)商脚祟，為服務(wù)添加以下注解之一。

• Default
• GCP
• AWS
• Azure
• IBM Cloud
• OpenStack
• Baidu Cloud
• Tencent Cloud
• Alibaba Cloud

選擇一個(gè)標(biāo)簽

AWS TLS 支持

為了對(duì)在 AWS 上運(yùn)行的集群提供 TLS/SSL 部分支持强饮，你可以向 LoadBalancer 服務(wù)添加三個(gè)注解：

metadata:
  name: my-service
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012

第一個(gè)指定要使用的證書的 ARN由桌。 它可以是已上載到 IAM 的第三方頒發(fā)者的證書， 也可以是在 AWS Certificate Manager 中創(chuàng)建的證書邮丰。

metadata:
  name: my-service
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: (https|http|ssl|tcp)

第二個(gè)注解指定 Pod 使用哪種協(xié)議行您。 對(duì)于 HTTPS 和 SSL，ELB 希望 Pod 使用證書 通過加密連接對(duì)自己進(jìn)行身份驗(yàn)證剪廉。

HTTP 和 HTTPS 選擇第7層代理：ELB 終止與用戶的連接娃循，解析標(biāo)頭，并在轉(zhuǎn)發(fā)請(qǐng)求時(shí)向 X-Forwarded-For 標(biāo)頭注入用戶的 IP 地址（Pod 僅在連接的另一端看到 ELB 的 IP 地址）斗蒋。

TCP 和 SSL 選擇第4層代理：ELB 轉(zhuǎn)發(fā)流量而不修改報(bào)頭捌斧。

在某些端口處于安全狀態(tài)而其他端口未加密的混合使用環(huán)境中，可以使用以下注解：

    metadata:
      name: my-service
      annotations:
        service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
        service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443,8443"

在上例中泉沾，如果服務(wù)包含 80捞蚂、443 和 8443 三個(gè)端口， 那么 443 和 8443 將使用 SSL 證書跷究， 而 80 端口將轉(zhuǎn)發(fā) HTTP 數(shù)據(jù)包姓迅。

從 Kubernetes v1.9 起可以使用 預(yù)定義的 AWS SSL 策略 為你的服務(wù)使用 HTTPS 或 SSL 偵聽器。 要查看可以使用哪些策略俊马，可以使用 aws 命令行工具：

aws elb describe-load-balancer-policies --query 'PolicyDescriptions[].PolicyName'

然后丁存，你可以使用 "service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy" 注解; 例如：

    metadata:
      name: my-service
      annotations:
        service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy: "ELBSecurityPolicy-TLS-1-2-2017-01"

AWS 上的 PROXY 協(xié)議支持

為了支持在 AWS 上運(yùn)行的集群，啟用 PROXY 協(xié)議柴我。 你可以使用以下服務(wù)注解：

    metadata:
      name: my-service
      annotations:
        service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: "*"

從 1.3.0 版開始解寝，此注解的使用適用于 ELB 代理的所有端口，并且不能進(jìn)行其他配置屯换。

AWS 上的 ELB 訪問日志

有幾個(gè)注解可用于管理 AWS 上 ELB 服務(wù)的訪問日志编丘。

注解 service.beta.kubernetes.io/aws-load-balancer-access-log-enabled 控制是否啟用訪問日志与学。

注解 service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval 控制發(fā)布訪問日志的時(shí)間間隔（以分鐘為單位）。你可以指定 5 分鐘或 60 分鐘的間隔嘉抓。

注解 service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name 控制存儲(chǔ)負(fù)載均衡器訪問日志的 Amazon S3 存儲(chǔ)桶的名稱索守。

注解 service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix 指定為 Amazon S3 存儲(chǔ)桶創(chuàng)建的邏輯層次結(jié)構(gòu)。

    metadata:
      name: my-service
      annotations:
        service.beta.kubernetes.io/aws-load-balancer-access-log-enabled: "true"
        # 指定是否為負(fù)載均衡器啟用訪問日志
        service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval: "60"
        # 發(fā)布訪問日志的時(shí)間間隔抑片。你可以將其設(shè)置為 5 分鐘或 60 分鐘卵佛。
        service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name: "my-bucket"
        # 用來存放訪問日志的 Amazon S3 Bucket 名稱
        service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix: "my-bucket-prefix/prod"
        # 你為 Amazon S3 Bucket 所創(chuàng)建的邏輯層次結(jié)構(gòu)，例如 `my-bucket-prefix/prod`

AWS 上的連接排空

可以將注解 service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled 設(shè)置為 "true" 來管理 ELB 的連接排空敞斋。 注解 service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout 也可以用于設(shè)置最大時(shí)間（以秒為單位）截汪，以保持現(xiàn)有連接在注銷實(shí)例之前保持打開狀態(tài)。

    metadata:
      name: my-service
      annotations:
        service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled: "true"
        service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout: "60"

其他 ELB 注解

還有其他一些注解植捎，用于管理經(jīng)典彈性負(fù)載均衡器衙解，如下所述。

    metadata:
      name: my-service
      annotations:
        # 按秒計(jì)的時(shí)間焰枢，表示負(fù)載均衡器關(guān)閉連接之前連接可以保持空閑
        # （連接上無數(shù)據(jù)傳輸）的時(shí)間長(zhǎng)度
        service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: "60"

        # 指定該負(fù)載均衡器上是否啟用跨區(qū)的負(fù)載均衡能力
        service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"

        # 逗號(hào)分隔列表值蚓峦，每一項(xiàng)都是一個(gè)鍵-值耦對(duì)，會(huì)作為額外的標(biāo)簽記錄于 ELB 中
        service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags: "environment=prod,owner=devops"

        # 將某后端視為健康济锄、可接收請(qǐng)求之前需要達(dá)到的連續(xù)成功健康檢查次數(shù)暑椰。
        # 默認(rèn)為 2，必須介于 2 和 10 之間
        service.beta.kubernetes.io/aws-load-balancer-healthcheck-healthy-threshold: ""

        # 將某后端視為不健康荐绝、不可接收請(qǐng)求之前需要達(dá)到的連續(xù)不成功健康檢查次數(shù)一汽。
        # 默認(rèn)為 6，必須介于 2 和 10 之間
        service.beta.kubernetes.io/aws-load-balancer-healthcheck-unhealthy-threshold: "3"

        # 對(duì)每個(gè)實(shí)例進(jìn)行健康檢查時(shí)低滩，連續(xù)兩次檢查之間的大致間隔秒數(shù)
        # 默認(rèn)為 10召夹，必須介于 5 和 300 之間
        service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval: "20"

        # 時(shí)長(zhǎng)秒數(shù)，在此期間沒有響應(yīng)意味著健康檢查失敗
        # 此值必須小于 service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval
        # 默認(rèn)值為 5委造，必須介于 2 和 60 之間
        service.beta.kubernetes.io/aws-load-balancer-healthcheck-timeout: "5"

        # 由已有的安全組所構(gòu)成的列表戳鹅，可以配置到所創(chuàng)建的 ELB 之上均驶。
        # 與注解 service.beta.kubernetes.io/aws-load-balancer-extra-security-groups 不同昏兆，
        # 這一設(shè)置會(huì)替代掉之前指定給該 ELB 的所有其他安全組，也會(huì)覆蓋掉為此
        # ELB 所唯一創(chuàng)建的安全組妇穴。 
        # 此列表中的第一個(gè)安全組 ID 被用來作為決策源，以允許入站流量流入目標(biāo)工作節(jié)點(diǎn)
        # (包括服務(wù)流量和健康檢查）。
        # 如果多個(gè) ELB 配置了相同的安全組 ID临谱，為工作節(jié)點(diǎn)安全組添加的允許規(guī)則行只有一個(gè)碗誉，
        # 這意味著如果你刪除了這些 ELB 中的任何一個(gè)，都會(huì)導(dǎo)致該規(guī)則記錄被刪除瞒滴，
        # 以至于所有共享該安全組 ID 的其他 ELB 都無法訪問該節(jié)點(diǎn)曲梗。
        # 此注解如果使用不當(dāng)赞警，會(huì)導(dǎo)致跨服務(wù)的不可用狀況。
        service.beta.kubernetes.io/aws-load-balancer-security-groups: "sg-53fae93f"

        # 額外的安全組列表虏两，將被添加到所創(chuàng)建的 ELB 之上愧旦。
        # 添加時(shí)，會(huì)保留為 ELB 所專門創(chuàng)建的安全組定罢。
        # 這樣會(huì)確保每個(gè) ELB 都有一個(gè)唯一的安全組 ID 和與之對(duì)應(yīng)的允許規(guī)則記錄笤虫，
        # 允許請(qǐng)求（服務(wù)流量和健康檢查）發(fā)送到目標(biāo)工作節(jié)點(diǎn)。
        # 這里頂一個(gè)安全組可以被多個(gè)服務(wù)共享祖凫。
        service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-53fae93f,sg-42efd82e"

        # 用逗號(hào)分隔的一個(gè)鍵-值偶對(duì)列表琼蚯，用來為負(fù)載均衡器選擇目標(biāo)節(jié)點(diǎn)
        service.beta.kubernetes.io/aws-load-balancer-target-node-labels: "ingress-gw,gw-name=public-api"

AWS 上網(wǎng)絡(luò)負(fù)載均衡器支持

FEATURE STATE: Kubernetes v1.15 [beta]

要在 AWS 上使用網(wǎng)絡(luò)負(fù)載均衡器，可以使用注解 service.beta.kubernetes.io/aws-load-balancer-type惠况，將其取值設(shè)為 nlb遭庶。

    metadata:
      name: my-service
      annotations:
        service.beta.kubernetes.io/aws-load-balancer-type: "nlb"

說明： NLB 僅適用于某些實(shí)例類。有關(guān)受支持的實(shí)例類型的列表稠屠， 請(qǐng)參見 AWS文檔 中關(guān)于所支持的實(shí)例類型的 Elastic Load Balancing 說明罚拟。

與經(jīng)典彈性負(fù)載平衡器不同，網(wǎng)絡(luò)負(fù)載平衡器（NLB）將客戶端的 IP 地址轉(zhuǎn)發(fā)到該節(jié)點(diǎn)完箩。 如果服務(wù)的 .spec.externalTrafficPolicy 設(shè)置為 Cluster 赐俗，則客戶端的IP地址不會(huì)傳達(dá)到最終的 Pod。

通過將 .spec.externalTrafficPolicy 設(shè)置為 Local弊知，客戶端IP地址將傳播到最終的 Pod阻逮， 但這可能導(dǎo)致流量分配不均。 沒有針對(duì)特定 LoadBalancer 服務(wù)的任何 Pod 的節(jié)點(diǎn)將無法通過自動(dòng)分配的 .spec.healthCheckNodePort 進(jìn)行 NLB 目標(biāo)組的運(yùn)行狀況檢查秩彤，并且不會(huì)收到任何流量叔扼。

為了獲得均衡流量，請(qǐng)使用 DaemonSet 或指定 Pod 反親和性 使其不在同一節(jié)點(diǎn)上漫雷。

你還可以將 NLB 服務(wù)與內(nèi)部負(fù)載平衡器 注解一起使用瓜富。

為了使客戶端流量能夠到達(dá) NLB 后面的實(shí)例，使用以下 IP 規(guī)則修改了節(jié)點(diǎn)安全組：

為了限制哪些客戶端IP可以訪問網(wǎng)絡(luò)負(fù)載平衡器降盹，請(qǐng)指定 loadBalancerSourceRanges与柑。

spec:
  loadBalancerSourceRanges:
    - "143.231.0.0/16"

說明： 如果未設(shè)置 .spec.loadBalancerSourceRanges ，則 Kubernetes 允許從 0.0.0.0/0 到節(jié)點(diǎn)安全組的流量蓄坏。 如果節(jié)點(diǎn)具有公共 IP 地址价捧，請(qǐng)注意，非 NLB 流量也可以到達(dá)那些修改后的安全組中的所有實(shí)例涡戳。

有關(guān)彈性 IP 注解和更多其他常見用例结蟋， 請(qǐng)參閱AWS負(fù)載均衡控制器文檔。

騰訊 Kubernetes 引擎（TKE）上的 CLB 注解

以下是在 TKE 上管理云負(fù)載均衡器的注解渔彰。

    metadata:
      name: my-service
      annotations:
        # 綁定負(fù)載均衡器到指定的節(jié)點(diǎn)嵌屎。
        service.kubernetes.io/qcloud-loadbalancer-backends-label: key in (value1, value2)

        # 為已有負(fù)載均衡器添加 ID推正。
        service.kubernetes.io/tke-existed-lbid：lb-6swtxxxx

        # 負(fù)載均衡器（LB）的自定義參數(shù)尚不支持修改 LB 類型。
        service.kubernetes.io/service.extensiveParameters: ""

        # 自定義負(fù)載均衡監(jiān)聽器宝惰。
        service.kubernetes.io/service.listenerParameters: ""

        # 指定負(fù)載均衡類型舔稀。
        # 可用參數(shù): classic (Classic Cloud Load Balancer) 或 application (Application Cloud Load Balancer)
        service.kubernetes.io/loadbalance-type: xxxxx

        # 指定公用網(wǎng)絡(luò)帶寬計(jì)費(fèi)方法。
        # 可用參數(shù): TRAFFIC_POSTPAID_BY_HOUR(bill-by-traffic) 和 BANDWIDTH_POSTPAID_BY_HOUR (bill-by-bandwidth).
        service.kubernetes.io/qcloud-loadbalancer-internet-charge-type: xxxxxx

        # 指定帶寬參數(shù) (取值范圍： [1,2000] Mbps).
        service.kubernetes.io/qcloud-loadbalancer-internet-max-bandwidth-out: "10"

        # 當(dāng)設(shè)置該注解時(shí)掌测，負(fù)載平衡器將只注冊(cè)正在運(yùn)行 Pod 的節(jié)點(diǎn)内贮，
        # 否則所有節(jié)點(diǎn)將會(huì)被注冊(cè)。
        service.kubernetes.io/local-svc-only-bind-node-with-pod: true

ExternalName 類型

類型為 ExternalName 的服務(wù)將服務(wù)映射到 DNS 名稱汞斧，而不是典型的選擇器夜郁，例如 my-service 或者 cassandra。 你可以使用 spec.externalName 參數(shù)指定這些服務(wù)粘勒。

例如竞端，以下 Service 定義將 prod 名稱空間中的 my-service 服務(wù)映射到 my.database.example.com：

apiVersion: v1
kind: Service
metadata:
  name: my-service
  namespace: prod
spec:
  type: ExternalName
  externalName: my.database.example.com

說明： ExternalName 服務(wù)接受 IPv4 地址字符串，但作為包含數(shù)字的 DNS 名稱庙睡，而不是 IP 地址事富。 類似于 IPv4 地址的外部名稱不能由 CoreDNS 或 ingress-nginx 解析，因?yàn)橥獠棵Q旨在指定規(guī)范的 DNS 名稱乘陪。 要對(duì) IP 地址進(jìn)行硬編碼统台，請(qǐng)考慮使用 headless Services。

當(dāng)查找主機(jī) my-service.prod.svc.cluster.local 時(shí)啡邑，集群 DNS 服務(wù)返回 CNAME 記錄贱勃， 其值為 my.database.example.com。 訪問 my-service 的方式與其他服務(wù)的方式相同谤逼，但主要區(qū)別在于重定向發(fā)生在 DNS 級(jí)別贵扰，而不是通過代理或轉(zhuǎn)發(fā)。 如果以后你決定將數(shù)據(jù)庫(kù)移到集群中流部，則可以啟動(dòng)其 Pod戚绕，添加適當(dāng)?shù)倪x擇器或端點(diǎn)以及更改服務(wù)的 type。

警告：

對(duì)于一些常見的協(xié)議枝冀，包括 HTTP 和 HTTPS舞丛， 你使用 ExternalName 可能會(huì)遇到問題。 如果你使用 ExternalName宾茂，那么集群內(nèi)客戶端使用的主機(jī)名 與 ExternalName 引用的名稱不同瓷马。

對(duì)于使用主機(jī)名的協(xié)議拴还，此差異可能會(huì)導(dǎo)致錯(cuò)誤或意外響應(yīng)跨晴。 HTTP 請(qǐng)求將具有源服務(wù)器無法識(shí)別的 Host: 標(biāo)頭；TLS 服 務(wù)器將無法提供與客戶端連接的主機(jī)名匹配的證書片林。

說明： 本部分感謝 Alen Komljen的 Kubernetes Tips - Part1 博客文章端盆。

外部 IP

如果外部的 IP 路由到集群中一個(gè)或多個(gè) Node 上怀骤，Kubernetes Service 會(huì)被暴露給這些 externalIPs。 通過外部 IP（作為目的 IP 地址）進(jìn)入到集群焕妙，打到 Service 的端口上的流量蒋伦， 將會(huì)被路由到 Service 的 Endpoint 上。 externalIPs 不會(huì)被 Kubernetes 管理焚鹊，它屬于集群管理員的職責(zé)范疇痕届。

根據(jù) Service 的規(guī)定，externalIPs 可以同任意的 ServiceType 來一起指定末患。 在上面的例子中研叫，my-service 可以在 "80.11.12.10:80"(externalIP:port) 上被客戶端訪問。

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 9376
  externalIPs:
    - 80.11.12.10

不足之處

為 VIP 使用用戶空間代理璧针，將只適合小型到中型規(guī)模的集群嚷炉，不能夠擴(kuò)展到上千 Service 的大型集群。 查看最初設(shè)計(jì)方案 獲取更多細(xì)節(jié)探橱。

使用用戶空間代理申屹，隱藏了訪問 Service 的數(shù)據(jù)包的源 IP 地址。 這使得一些類型的防火墻無法起作用隧膏。 iptables 代理不會(huì)隱藏 Kubernetes 集群內(nèi)部的 IP 地址哗讥，但卻要求客戶端請(qǐng)求 必須通過一個(gè)負(fù)載均衡器或 Node 端口。

Type 字段支持嵌套功能 —— 每一層需要添加到上一層里面胞枕。 不會(huì)嚴(yán)格要求所有云提供商（例如忌栅，GCE 就沒必要為了使一個(gè) LoadBalancer 能工作而分配一個(gè) NodePort，但是 AWS 需要 ）曲稼，但當(dāng)前 API 是強(qiáng)制要求的索绪。

虛擬IP實(shí)施

對(duì)很多想使用 Service 的人來說，前面的信息應(yīng)該足夠了贫悄。 然而瑞驱，有很多內(nèi)部原理性的內(nèi)容，還是值去理解的窄坦。

避免沖突

Kubernetes 最主要的哲學(xué)之一唤反，是用戶不應(yīng)該暴露那些能夠?qū)е滤麄儾僮魇　⒌植皇撬麄兊倪^錯(cuò)的場(chǎng)景鸭津。 對(duì)于 Service 資源的設(shè)計(jì)彤侍，這意味著如果用戶的選擇有可能與他人沖突，那就不要讓用戶自行選擇端口號(hào)逆趋。 這是一個(gè)隔離性的失敗盏阶。

為了使用戶能夠?yàn)樗麄兊?Service 選擇一個(gè)端口號(hào)，我們必須確保不能有2個(gè) Service 發(fā)生沖突闻书。 Kubernetes 通過為每個(gè) Service 分配它們自己的 IP 地址來實(shí)現(xiàn)名斟。

為了保證每個(gè) Service 被分配到一個(gè)唯一的 IP脑慧，需要一個(gè)內(nèi)部的分配器能夠原子地更新 etcd 中的一個(gè)全局分配映射表， 這個(gè)更新操作要先于創(chuàng)建每一個(gè) Service砰盐。 為了使 Service 能夠獲取到 IP闷袒，這個(gè)映射表對(duì)象必須在注冊(cè)中心存在， 否則創(chuàng)建 Service 將會(huì)失敗岩梳，指示一個(gè) IP 不能被分配囊骤。

在控制平面中，一個(gè)后臺(tái) Controller 的職責(zé)是創(chuàng)建映射表 （需要支持從使用了內(nèi)存鎖的 Kubernetes 的舊版本遷移過來）冀值。 同時(shí) Kubernetes 會(huì)通過控制器檢查不合理的分配（如管理員干預(yù)導(dǎo)致的） 以及清理已被分配但不再被任何 Service 使用的 IP 地址淘捡。

Service IP 地址

不像 Pod 的 IP 地址，它實(shí)際路由到一個(gè)固定的目的地池摧，Service 的 IP 實(shí)際上 不能通過單個(gè)主機(jī)來進(jìn)行應(yīng)答焦除。 相反，我們使用 iptables（Linux 中的數(shù)據(jù)包處理邏輯）來定義一個(gè) 虛擬 IP 地址（VIP）作彤，它可以根據(jù)需要透明地進(jìn)行重定向膘魄。 當(dāng)客戶端連接到 VIP 時(shí)，它們的流量會(huì)自動(dòng)地傳輸?shù)揭粋€(gè)合適的 Endpoint竭讳。 環(huán)境變量和 DNS创葡，實(shí)際上會(huì)根據(jù) Service 的 VIP 和端口來進(jìn)行填充。

kube-proxy支持三種代理模式: 用戶空間绢慢，iptables和IPVS灿渴；它們各自的操作略有不同。

Userspace

作為一個(gè)例子胰舆，考慮前面提到的圖片處理應(yīng)用程序骚露。 當(dāng)創(chuàng)建后端 Service 時(shí)，Kubernetes master 會(huì)給它指派一個(gè)虛擬 IP 地址缚窿，比如 10.0.0.1棘幸。 假設(shè) Service 的端口是 1234，該 Service 會(huì)被集群中所有的 kube-proxy 實(shí)例觀察到倦零。 當(dāng)代理看到一個(gè)新的 Service误续， 它會(huì)打開一個(gè)新的端口，建立一個(gè)從該 VIP 重定向到 新端口的 iptables扫茅，并開始接收請(qǐng)求連接蹋嵌。

當(dāng)一個(gè)客戶端連接到一個(gè) VIP，iptables 規(guī)則開始起作用葫隙，它會(huì)重定向該數(shù)據(jù)包到 "服務(wù)代理" 的端口栽烂。 "服務(wù)代理" 選擇一個(gè)后端，并將客戶端的流量代理到后端上。

這意味著 Service 的所有者能夠選擇任何他們想使用的端口愕鼓，而不存在沖突的風(fēng)險(xiǎn)钙态。 客戶端可以連接到一個(gè) IP 和端口慧起，而不需要知道實(shí)際訪問了哪些 Pod菇晃。

iptables

再次考慮前面提到的圖片處理應(yīng)用程序。 當(dāng)創(chuàng)建后端 Service 時(shí)蚓挤，Kubernetes 控制面板會(huì)給它指派一個(gè)虛擬 IP 地址磺送，比如 10.0.0.1。 假設(shè) Service 的端口是 1234灿意，該 Service 會(huì)被集群中所有的 kube-proxy 實(shí)例觀察到估灿。 當(dāng)代理看到一個(gè)新的 Service， 它會(huì)配置一系列的 iptables 規(guī)則缤剧，從 VIP 重定向到每個(gè) Service 規(guī)則馅袁。 該特定于服務(wù)的規(guī)則連接到特定于 Endpoint 的規(guī)則，而后者會(huì)重定向（目標(biāo)地址轉(zhuǎn)譯）到后端荒辕。

當(dāng)客戶端連接到一個(gè) VIP汗销，iptables 規(guī)則開始起作用。一個(gè)后端會(huì)被選擇（或者根據(jù)會(huì)話親和性抵窒，或者隨機(jī)）弛针， 數(shù)據(jù)包被重定向到這個(gè)后端。 不像用戶空間代理李皇，數(shù)據(jù)包從來不拷貝到用戶空間削茁，kube-proxy 不是必須為該 VIP 工作而運(yùn)行， 并且客戶端 IP 是不可更改的掉房。

當(dāng)流量打到 Node 的端口上茧跋，或通過負(fù)載均衡器，會(huì)執(zhí)行相同的基本流程卓囚， 但是在那些案例中客戶端 IP 是可以更改的厌衔。

IPVS

在大規(guī)模集群（例如 10000 個(gè)服務(wù)）中，iptables 操作會(huì)顯著降低速度捍岳。 IPVS 專為負(fù)載平衡而設(shè)計(jì)富寿，并基于內(nèi)核內(nèi)哈希表。 因此锣夹，你可以通過基于 IPVS 的 kube-proxy 在大量服務(wù)中實(shí)現(xiàn)性能一致性页徐。 同時(shí)，基于 IPVS 的 kube-proxy 具有更復(fù)雜的負(fù)載均衡算法（最小連接银萍、局部性变勇、 加權(quán)、持久性）。

API 對(duì)象

Service 是 Kubernetes REST API 中的頂級(jí)資源搀绣。你可以在以下位置找到有關(guān) API 對(duì)象的更多詳細(xì)信息： Service 對(duì)象 API.

受支持的協(xié)議

TCP

你可以將 TCP 用于任何類型的服務(wù)飞袋，這是默認(rèn)的網(wǎng)絡(luò)協(xié)議。

UDP

你可以將 UDP 用于大多數(shù)服務(wù)链患。 對(duì)于 type=LoadBalancer 服務(wù)巧鸭，對(duì) UDP 的支持取決于提供此功能的云提供商。

SCTP

FEATURE STATE: Kubernetes v1.20 [stable]

一旦你使用了支持 SCTP 流量的網(wǎng)絡(luò)插件麻捻，你就可以使用 SCTP 于更多的服務(wù)纲仍。 對(duì)于 type = LoadBalancer 的服務(wù)，SCTP 的支持取決于提供此設(shè)施的云供應(yīng)商（大多數(shù)不支持）贸毕。

警告

支持多宿主 SCTP 關(guān)聯(lián)

警告：

支持多宿主SCTP關(guān)聯(lián)要求 CNI 插件能夠支持為一個(gè) Pod 分配多個(gè)接口和IP地址郑叠。

用于多宿主 SCTP 關(guān)聯(lián)的 NAT 在相應(yīng)的內(nèi)核模塊中需要特殊的邏輯。

Windows

說明： 基于 Windows 的節(jié)點(diǎn)不支持 SCTP明棍。

用戶空間 kube-proxy

警告： 當(dāng) kube-proxy 處于用戶空間模式時(shí)乡革，它不支持 SCTP 關(guān)聯(lián)的管理。

HTTP

如果你的云提供商支持它摊腋，則可以在 LoadBalancer 模式下使用服務(wù)來設(shè)置外部 HTTP/HTTPS 反向代理沸版，并將其轉(zhuǎn)發(fā)到該服務(wù)的 Endpoints。

說明： 你還可以使用 Ingress 代替 Service 來公開 HTTP/HTTPS 服務(wù)歌豺。

PROXY 協(xié)議

如果你的云提供商支持它推穷， 則可以在 LoadBalancer 模式下使用 Service 在 Kubernetes 本身之外配置負(fù)載均衡器， 該負(fù)載均衡器將轉(zhuǎn)發(fā)前綴為 PROXY 協(xié)議 的連接类咧。

負(fù)載平衡器將發(fā)送一系列初始字節(jié)馒铃，描述傳入的連接，類似于此示例

PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n

上述是來自客戶端的數(shù)據(jù)痕惋。