建站
咨詢
售后
建站咨詢
新聞中心
服務(wù)
將運(yùn)行在一組 Pods 上的應(yīng)用程序公開為網(wǎng)絡(luò)服務(wù)的抽象方法。
10年積累的成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站建設(shè)經(jīng)驗(yàn)，可以快速應(yīng)對(duì)客戶對(duì)網(wǎng)站的新想法和需求。提供各種問題對(duì)應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你，你也不認(rèn)識(shí)我。但先網(wǎng)站制作后付款的網(wǎng)站建設(shè)流程，更有呼蘭免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。
使用 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 集合通常是通過選擇算符來確定的。
舉個(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ù)代理使用。
服務(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: 9376Endpoints 對(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)?nbsp;kube-proxy 不支持將虛擬 IP 作為目標(biāo)。
訪問沒有選擇算符的 Service，與有選擇算符的 Service 的原理相同。 請(qǐng)求將被路由到用戶定義的 Endpoint，YAML 中為：?192.0.2.42:9376?（TCP）。
ExternalName Service 是 Service 的特例，它沒有選擇算符，但是使用 DNS 名稱。
超出容量的 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)嗟?nbsp;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)簽語法。 其值可以是 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)算法選擇后端。
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)榱髁坑?nbsp;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。
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)行。
在這些代理模型中，綁定到服務(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ā)的?？稍O(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兼容 變量、 簡(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 的方式。
無頭服務(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 能夠通過 ?spec.clusterIp:spec.ports[*].port? 而對(duì)外可見。 如果設(shè)置了 kube-proxy 的 ?--nodeport-addresses? 參數(shù)或 kube-proxy 配置文件中的等效字段， ?
例如：
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: 30007LoadBalancer 類型
在使用支持外部負(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ù)添加以下注解之一。
- GCP
[...]
metadata:
name: my-service
annotations:
cloud.google.com/load-balancer-type: "Internal"
[...][...]
metadata:
name: my-service
annotations:
service.beta.kubernetes.io/aws-load-balancer-internal: "true"
[...][...]
metadata:
name: my-service
annotations:
service.beta.kubernetes.io/azure-load-balancer-internal: "true"
[...][...]
metadata:
name: my-service
annotations:
service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
[...][...]
metadata:
name: my-service
annotations:
service.beta.kubernetes.io/openstack-internal-load-balancer: "true"
[...][...]
metadata:
name: my-service
annotations:
service.beta.kubernetes.io/cce-load-balancer-internal-vpc: "true"
[...][...]
metadata:
annotations:
service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxx
[...][...]
metadata:
annotations:
service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet"
[...]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)安全組：
| Rule | Protocol | Port(s) | IpRange(s) | IpRange Description |
|---|---|---|---|---|
| Health Check | TCP | NodePort(s) (.spec.healthCheckNodePort for .spec.externalTrafficPolicy = Local) | Subnet CIDR | kubernetes.io/rule/nlb/health= |
| Client Traffic | TCP | NodePort(s) | .spec.loadBalancerSourceRanges (defaults to 0.0.0.0/0) | kubernetes.io/rule/nlb/client= |
| MTU Discovery | ICMP | 3,4 | .spec.loadBalancerSourceRanges (defaults to 0.0.0.0/0) | kubernetes.io/rule/nlb/mtu= |
為了限制哪些客戶端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: trueExternalName 類型
類型為 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.comExternalName 服務(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)樗麄兊?nbsp;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ù)。
分享文章：創(chuàng)新互聯(lián)kubernetes教程：Kubernetes服務(wù)
分享鏈接：http://www.dlmjj.cn/article/djiphoj.html
