辰东完美世界有声小说,欢乐颂小说结局

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

創(chuàng)新互聯(lián)kubernetes教程：Kubernetes服務(wù)

服務(wù)

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

10年積累的成都網(wǎng)站設(shè)計、成都網(wǎng)站建設(shè)經(jīng)驗，可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識你，你也不認(rèn)識我。但先網(wǎng)站制作后付款的網(wǎng)站建設(shè)流程，更有呼蘭免費網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

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

動機(jī)

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

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

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

進(jìn)入 Services。

Service 資源

Kubernetes Service 定義了這樣一種抽象：邏輯上的一組 Pod，一種可以訪問它們的策略 —— 通常稱為微服務(wù)。 Service 所針對的 Pods 集合通常是通過選擇算符來確定的。

舉個例子，考慮一個圖片處理后端，它運行了 3 個副本。這些副本是可互換的 —— 前端不需要關(guān)心它們調(diào)用了哪個后端副本。然而組成這一組后端程序的 Pod 實際上可能會發(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 就會被更新。

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

定義 Service

Service 在 Kubernetes 中是一個 REST 對象，和 Pod 類似。像所有的 REST 對象一樣，Service 定義可以基于 POST 方式，請求 API server 創(chuàng)建新的實例。 Service 對象的名稱必須是合法的 RFC 1035 標(biāo)簽名稱.。

例如，假定有一組 Pod，它們對外暴露了 9376 端口，同時還被打上 ?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)建一個名稱為 "my-service" 的 Service 對象，它會將請求代理到使用 TCP 端口 9376，并且具有標(biāo)簽 ?"app=MyApp"? 的 Pod 上。

Kubernetes 為該服務(wù)分配一個 IP 地址（有時稱為 "集群IP"），該 IP 地址由服務(wù)代理使用。

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

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

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

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

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

沒有選擇算符的 Service

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

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

在任何這些場景中，都能夠定義沒有選擇算符的 Service。實例:

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

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

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

Endpoints 對象的名稱必須是合法的 DNS 子域名。

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

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

訪問沒有選擇算符的 Service，與有選擇算符的 Service 的原理相同。請求將被路由到用戶定義的 Endpoint，YAML 中為：?192.0.2.42:9376?（TCP）。

ExternalName Service 是 Service 的特例，它沒有選擇算符，但是使用 DNS 名稱。

超出容量的 Endpoints

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

EndpointSlices

FEATURE STATE: Kubernetes v1.21 [stable]

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

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

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

FEATURE STATE: Kubernetes v1.20 [stable]

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

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

虛擬 IP 和 Service 代理

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

為什么不使用 DNS 輪詢？

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

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

DNS 實現(xiàn)的歷史由來已久，它不遵守記錄 TTL，并且在名稱查找結(jié)果到期后對其進(jìn)行緩存。
有些應(yīng)用程序僅執(zhí)行一次 DNS 查找，并無限期地緩存結(jié)果。
即使應(yīng)用和庫進(jìn)行了適當(dāng)?shù)闹匦陆馕?，DNS 記錄上的 TTL 值低或為零也可能會給 DNS 帶來高負(fù)載，從而使管理變得困難。

userspace 代理模式

這種模式，kube-proxy 會監(jiān)視 Kubernetes 控制平面對 Service 對象和 Endpoints 對象的添加和移除操作。對每個 Service，它會在本地 Node 上打開一個端口（隨機(jī)選擇）。任何連接到“代理端口”的請求，都會被代理到 Service 的后端 ?Pods ?中的某個上面（如 ?Endpoints ?所報告的一樣）。使用哪個后端 Pod，是 kube-proxy 基于 ?SessionAffinity ?來確定的。

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

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

iptables 代理模式

這種模式，?kube-proxy? 會監(jiān)視 Kubernetes 控制節(jié)點對 Service 對象和 Endpoints 對象的添加和移除。對每個 Service，它會配置 iptables 規(guī)則，從而捕獲到達(dá)該 Service 的 ?clusterIP ?和端口的請求，進(jìn)而將請求重定向到 Service 的一組后端中的某個 Pod 上面。對于每個 Endpoints 對象，它也會配置 iptables 規(guī)則，這個規(guī)則會選擇一個后端組合。

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

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

如果 kube-proxy 在 iptables 模式下運行，并且所選的第一個 Pod 沒有響應(yīng)，則連接失敗。這與用戶空間模式不同：在這種情況下，kube-proxy 將檢測到與第一個 Pod 的連接已失敗，并會自動使用其他后端 Pod 重試。

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

IPVS 代理模式

FEATURE STATE: Kubernetes v1.11 [stable]

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

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

IPVS 提供了更多選項來平衡后端 Pod 的流量。這些是：

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

要在 IPVS 模式下運行 kube-proxy，必須在啟動 kube-proxy 之前使 IPVS 在節(jié)點上可用。

當(dāng) kube-proxy 以 IPVS 代理模式啟動時，它將驗證 IPVS 內(nèi)核模塊是否可用。如果未檢測到 IPVS 內(nèi)核模塊，則 kube-proxy 將退回到以 iptables 代理模式運行。

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

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

多端口 Service

對于某些服務(wù)，你需要公開多個端口。 Kubernetes 允許你在 Service 對象上配置多個端口定義。為服務(wù)使用多個端口時，必須提供所有端口名稱，以使它們無歧義。例如：

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)建的請求中，可以通過設(shè)置 ?spec.clusterIP? 字段來指定自己的集群 IP 地址。比如，希望替換一個已經(jīng)已存在的 DNS 條目，或者遺留系統(tǒng)已經(jīng)配置了一個固定的 IP 且很難重新配置。

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

流量策略

外部流量策略

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

FEATURE STATE: Kubernetes v1.22 [alpha]

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

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

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

內(nèi)部流量策略

FEATURE STATE: Kubernetes v1.22 [beta]

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

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

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

環(huán)境變量

當(dāng) Pod 運行在 ?Node ?上，kubelet 會為每個活躍的 Service 添加一組環(huán)境變量。它同時支持 Docker links兼容變量、簡單的 ?{SVCNAME}_SERVICE_HOST? 和 ?{SVCNAME}_SERVICE_PORT? 變量。這里 Service 的名稱需大寫，橫線被轉(zhuǎn)換成下劃線。

舉個例子，一個名稱為 ?redis-master? 的 Service 暴露了 TCP 端口 6379，同時給它分配了 Cluster IP 地址 10.0.0.11，這個 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 時，并且你正在使用環(huán)境變量方法將端口和集群 IP 發(fā)布到客戶端 Pod 時，必須在客戶端 Pod 出現(xiàn) 之前創(chuàng)建服務(wù)。否則，這些客戶端 Pod 將不會設(shè)定其環(huán)境變量。

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

DNS

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

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

例如，如果你在 Kubernetes 命名空間 ?my-ns? 中有一個名為 ?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，則可以對 ?_http._tcp.my-service.my-ns? 執(zhí)行 DNS SRV 查詢查詢以發(fā)現(xiàn)該端口號, ?"http"? 以及 IP 地址。

Kubernetes DNS 服務(wù)器是唯一的一種能夠訪問 ?ExternalName ?類型的 Service 的方式。

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

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

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

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

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

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

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

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

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

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

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

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

?Type ?的取值以及行為如下：

?ClusterIP?：通過集群的內(nèi)部 IP 暴露服務(wù)，選擇該值時服務(wù)只能夠在集群內(nèi)部訪問。這也是默認(rèn)的 ?ServiceType?。
?NodePort?：通過每個節(jié)點上的 IP 和靜態(tài)端口（?NodePort?）暴露服務(wù)。 ?NodePort ?服務(wù)會路由到自動創(chuàng)建的 ?ClusterIP ?服務(wù)。通過請求 ?<節(jié)點 IP>:<節(jié)點端口>?，你可以從集群的外部訪問一個 ?NodePort ?服務(wù)。
?LoadBalancer?：使用云提供商的負(fù)載均衡器向外部暴露服務(wù)。外部負(fù)載均衡器可以將流量路由到自動創(chuàng)建的 ?NodePort ?服務(wù)和 ?ClusterIP ?服務(wù)上。
?ExternalName?：通過返回 ?CNAME ?和對應(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)集群的入口點。它可以將路由規(guī)則整合到一個資源中，因為它可以在同一IP地址下公開多個服務(wù)。

NodePort 類型

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

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

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

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

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

需要注意的是，Service 能夠通過 ?:spec.ports[*].nodePort? 和 ?spec.clusterIp:spec.ports[*].port? 而對外可見。如果設(shè)置了 kube-proxy 的 ?--nodeport-addresses? 參數(shù)或 kube-proxy 配置文件中的等效字段， ? ? 將被過濾 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 控制平面會從某個范圍內(nèi)分配一個端口號（默認(rèn)：30000-32767）
      nodePort: 30007

LoadBalancer 類型

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

實例：

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è)置 ?loadBalancerIP?。在這些情況下，將根據(jù)用戶設(shè)置的 ?loadBalancerIP ?來創(chuàng)建負(fù)載均衡器。如果沒有設(shè)置 ?loadBalancerIP ?字段，將會給負(fù)載均衡器指派一個臨時 IP。如果設(shè)置了 ?loadBalancerIP?，但云提供商并不支持這種特性，那么設(shè)置的 ?loadBalancerIP ?值將會被忽略掉。

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

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

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

FEATURE STATE: Kubernetes v1.20 [alpha]

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

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

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

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

FEATURE STATE: Kubernetes v1.20 [alpha]

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

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

FEATURE STATE: Kubernetes v1.22 [beta]

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

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

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

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

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

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

[...]
metadata:
    name: my-service
    annotations:
        cloud.google.com/load-balancer-type: "Internal"
[...]

AWS

[...]
metadata:
    name: my-service
    annotations:
        service.beta.kubernetes.io/aws-load-balancer-internal: "true"
[...]

Azure

[...]
metadata:
    name: my-service
    annotations:
        service.beta.kubernetes.io/azure-load-balancer-internal: "true"
[...]

IBM Cloud

[...]
metadata:
    name: my-service
    annotations:
        service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
[...]

OpenStack

[...]
metadata:
    name: my-service
    annotations:
        service.beta.kubernetes.io/openstack-internal-load-balancer: "true"
[...]

Baidu Cloud

[...]
metadata:
    name: my-service
    annotations:
        service.beta.kubernetes.io/cce-load-balancer-internal-vpc: "true"
[...]

Tencent Cloud

[...]
metadata:
  annotations:
    service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxx
[...]

Alibaba Cloud

[...]
metadata:
  annotations:
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet"
[...]

AWS TLS 支持

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

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

第一個指定要使用的證書的 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)

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

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

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

在某些端口處于安全狀態(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 ?三個端口，那么 ?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 上運行的集群，啟用 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 訪問日志

有幾個注解可用于管理 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ā)布訪問日志的時間間隔（以分鐘為單位）。你可以指定 5 分鐘或 60 分鐘的間隔。

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

注解 ?service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix? 指定為 Amazon S3 存儲桶創(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è)置為 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è)置最大時間（以秒為單位），以保持現(xiàn)有連接在注銷實例之前保持打開狀態(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:
    # 按秒計的時間，表示負(fù)載均衡器關(guān)閉連接之前連接可以保持空閑
    # （連接上無數(shù)據(jù)傳輸）的時間長度
    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"

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

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

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

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

    # 時長秒數(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è)置會替代掉之前指定給該 ELB 的所有其他安全組，也會覆蓋掉為此
    # ELB 所唯一創(chuàng)建的安全組。 
    # 此列表中的第一個安全組 ID 被用來作為決策源，以允許入站流量流入目標(biāo)工作節(jié)點
    # (包括服務(wù)流量和健康檢查）。
    # 如果多個 ELB 配置了相同的安全組 ID，為工作節(jié)點安全組添加的允許規(guī)則行只有一個，
    # 這意味著如果你刪除了這些 ELB 中的任何一個，都會導(dǎo)致該規(guī)則記錄被刪除，
    # 以至于所有共享該安全組 ID 的其他 ELB 都無法訪問該節(jié)點。
    # 此注解如果使用不當(dāng)，會導(dǎo)致跨服務(wù)的不可用狀況。
    service.beta.kubernetes.io/aws-load-balancer-security-groups: "sg-53fae93f"

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

    # 用逗號分隔的一個鍵-值偶對列表，用來為負(fù)載均衡器選擇目標(biāo)節(jié)點
    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 僅適用于某些實例類。有關(guān)受支持的實例類型的列表，請參見 AWS文檔中關(guān)于所支持的實例類型的 Elastic Load Balancing 說明。

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

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

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

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

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

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ù)載平衡器，請指定 ?loadBalancerSourceRanges?。

spec:
  loadBalancerSourceRanges:
    - "143.231.0.0/16"

如果未設(shè)置 ?.spec.loadBalancerSourceRanges? ，則 Kubernetes 允許從 ?0.0.0.0/0? 到節(jié)點安全組的流量。如果節(jié)點具有公共 IP 地址，請注意，非 NLB 流量也可以到達(dá)那些修改后的安全組中的所有實例。

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

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

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

metadata:
  name: my-service
  annotations:
    # 綁定負(fù)載均衡器到指定的節(jié)點。
    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ò)帶寬計費方法。
    # 可用參數(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è)置該注解時，負(fù)載平衡器將只注冊正在運行 Pod 的節(jié)點，
    # 否則所有節(jié)點將會被注冊。
    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 解析，因為外部名稱旨在指定規(guī)范的 DNS 名稱。要對 IP 地址進(jìn)行硬編碼，請考慮使用 headless Services。

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

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

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

本部分感謝 Alen Komljen的 Kubernetes Tips - Part1 博客文章。

外部 IP

如果外部的 IP 路由到集群中一個或多個 Node 上，Kubernetes Service 會被暴露給這些 externalIPs。通過外部 IP（作為目的 IP 地址）進(jìn)入到集群，打到 Service 的端口上的流量，將會被路由到 Service 的 Endpoint 上。 ?externalIPs ?不會被 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è)計方案獲取更多細(xì)節(jié)。

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

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

虛擬IP實施

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

避免沖突

Kubernetes 最主要的哲學(xué)之一，是用戶不應(yīng)該暴露那些能夠?qū)е滤麄儾僮魇?、但又不是他們的過錯的場景。對于 Service 資源的設(shè)計，這意味著如果用戶的選擇有可能與他人沖突，那就不要讓用戶自行選擇端口號。這是一個隔離性的失敗。

為了使用戶能夠為他們的 Service 選擇一個端口號，我們必須確保不能有2個 Service 發(fā)生沖突。 Kubernetes 通過為每個 Service 分配它們自己的 IP 地址來實現(xiàn)。

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

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

Service IP 地址

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

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

Userspace

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

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

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

iptables

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

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

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

IPVS

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

API 對象

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

受支持的協(xié)議

TCP

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

UDP

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

SCTP

FEATURE STATE: Kubernetes v1.20 [stable]

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

警告

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

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

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

Windows

基于 Windows 的節(jié)點不支持 SCTP。

用戶空間 kube-proxy

當(dāng) kube-proxy 處于用戶空間模式時，它不支持 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ù)。

新聞標(biāo)題：創(chuàng)新互聯(lián)kubernetes教程：Kubernetes服務(wù)
瀏覽路徑：http://fisionsoft.com.cn/article/djiphoj.html

新聞中心

服務(wù)

動機(jī)

Service 資源

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

定義 Service

沒有選擇算符的 Service

超出容量的 Endpoints

EndpointSlices

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

虛擬 IP 和 Service 代理

為什么不使用 DNS 輪詢？

userspace 代理模式

iptables 代理模式

IPVS 代理模式

多端口 Service

選擇自己的 IP 地址

流量策略

外部流量策略

內(nèi)部流量策略

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

環(huán)境變量

DNS

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

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

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

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

NodePort 類型

LoadBalancer 類型

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

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

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

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

AWS TLS 支持

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

AWS 上的 ELB 訪問日志

AWS 上的連接排空

其他 ELB 注解

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

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

ExternalName 類型

外部 IP

不足之處

虛擬IP實施

避免沖突

Service IP 地址

Userspace

iptables

IPVS

API 對象

受支持的協(xié)議

TCP

UDP

SCTP

警告

Windows

用戶空間 kube-proxy

HTTP

PROXY 協(xié)議

其他資訊

為什么不使用 DNS 輪詢？