Service 官網文檔-service

什么是service

Service 定義了這樣一種抽象：邏輯上的一組 Pod，一種可以訪問它們的策略 。pod重新部署之后ip就會變，所以一般通過service來訪問pod。將service和pod通過某種方式綁定，就可以通過service訪問pod了。同時也可以簡單看作service做了一個負載均衡。就像springcloud中Eureka服務發現，通過名字就可以與真實的服務綁定。k8s中其實endpoints主要定義了真實服務（pod)的訪問地址，service給出自己的name，其他資源對象就可以通過service的name來訪問真實的服務（pod）。

spec (ServiceSpec)

spec 定義 Service 的行為。https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

selector (map[string]string)

將 Service 流量路由到具有與此 selector 匹配的標簽鍵值對的 Pod。

ports ([]ServicePort)

ports.port (int32)，必需

Service 將公開的端口。

ports.targetPort (IntOrString)

在 Service 所針對的 Pod 上要訪問的端口號或名稱。 編號必須在 1 到 65535 的范圍內。

ports.protocol (string)

此端口的 IP 協議。支持 “TCP”、“UDP” 和 “SCTP”。默認為 TCP。

ports.name (string)

• Service 中此端口的名稱。
• 這必須是 DNS_LABEL。
• ServiceSpec 中的所有端口的名稱都必須唯一。
• 在考慮 Service 的端點時，這一字段值必須與 EndpointPort 中的 name 字段相同。 如果此服務上僅定義一個 ServicePort，則為此字段為可選。

ports.nodePort (int32)

當類型為 NodePort 或 LoadBalancer 時，Service 公開在節點上的端口， 通常由系統分配。
如果指定了一個在范圍內且未使用的值，則將使用該值，否則操作將失敗。
如果在創建的 Service 需要該端口時未指定該字段，則會分配端口。
如果在創建不需要該端口的 Service時指定了該字段，則會創建失敗。
當更新 Service 時，如果不再需要此字段（例如，將類型從 NodePort 更改為 ClusterIP），這個字段將被擦除。 更多信息

type (string)

• type 確定 Service 的公開方式。
• 默認為 ClusterIP。
• 有效選項為 ExternalName、ClusterIP、NodePort 和 LoadBalancer。
• “ClusterIP” 為端點分配一個集群內部 IP 地址用于負載均衡。 Endpoints 由 selector 確定，如果未設置 selector，則需要通過手動構造 Endpoints 或 EndpointSlice 的對象來確定。 如果 clusterIP 為 “None”，則不分配虛擬 IP，并且 Endpoints 作為一組端點而不是虛擬 IP 發布。
• “NodePort” 建立在 ClusterIP 之上，并在每個節點上分配一個端口，該端口路由到與 clusterIP 相同的 Endpoints。
• “LoadBalancer” 基于 NodePort 構建并創建一個外部負載均衡器（如果當前云支持），該負載均衡器路由到與 clusterIP 相同的 Endpoints。
• “externalName” 將此 Service 別名為指定的 externalName。其他幾個字段不適用于 ExternalName Service。
• 更多信息

clusterIP (string)

• clusterIP 是服務的 IP 地址，通常是隨機分配的。 如果地址是手動指定的，在范圍內（根據系統配置），且沒有被使用，它將被分配給服務，否則創建服務將失敗。
• clusterIP 一般不會被更改，除非 type 被更改為 ExternalName （ExternalName 需要 clusterIP 為空）或 type 已經是 ExternalName 時，可以更改 clusterIP（在這種情況下，可以選擇指定此字段）。 可選值 “None”、空字符串 (“”) 或有效的 IP 地址。 clusterIP 為 “None” 時會生成“無頭服務”（無虛擬 IP），這在首選直接 Endpoint 連接且不需要代理時很有用。 僅適用于 ClusterIP、NodePort、和 LoadBalancer 類型的服務。 如果在創建 ExternalName 類型的 Service 時指定了 clusterIP，則創建將失敗。 更新 Service type 為 ExternalName 時，clusterIP 會被移除。 更多信息： https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies

externalIPs ([]string)

externalIPs 是一個 IP 列表，集群中的節點會為此 Service 接收針對這些 IP 地址的流量。
這些 IP 不被 Kubernetes 管理。用戶需要確保流量可以到達具有此 IP 的節點。
一個常見的例子是不屬于 Kubernetes 系統的外部負載均衡器。

sessionAffinity (string)

支持 “ClientIP” 和 “None”。用于維護會話親和性。 啟用基于客戶端 IP 的會話親和性。必須是 ClientIP 或 None。默認為 None。 更多信息： https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies

loadBalancerIP (string)

僅適用于服務類型: LoadBalancer。此功能取決于底層云提供商是否支持負載均衡器。 如果云提供商不支持該功能，該字段將被忽略。 已棄用: 該字段信息不足，且其含義因實現而異，而且不支持雙棧。 從 Kubernetes v1.24 開始，鼓勵用戶在可用時使用特定于實現的注釋。在未來的 API 版本中可能會刪除此字段。

service如何選擇pod

Service 所針對的 Pod 集合通常是通過選擇算符來確定的

不帶選擇算符的服務

定義 Service

例如，假定有一組 Pod，它們對外暴露了 9376 端口，同時還被打上 app=MyApp 標簽：

apiVersion: v1 kind: Service metadata:name: my-service spec:selector: #將 Service 流量路由到具有與此 selector 匹配的標簽鍵值對的 Pod。app.kubernetes.io/name: MyApp #代理的是label為該key:value的podports:- protocol: TCP #pod的端口使用tcp協議port: 80 #通過該端口訪問該servicetargetPort: 9376 #被代理的端口，也就是pod上開放的端口

創建一個名稱為 “my-service” 的 Service 對象

它會將請求代理到使用 TCP 端口 9376，并且具有標簽 app.kubernetes.io/name=MyApp 的 Pod 上。

Pod 中的端口定義是有名字的，你可以在 Service 的 targetPort 屬性中引用這些名稱。
在新版本中更改 Pod 中后端軟件公開的端口號，而不會破壞客戶端。

apiVersion: v1 kind: Pod metadata:name: nginxlabels:app.kubernetes.io/name: proxy spec:containers:- name: nginximage: nginx:stableports:- containerPort: 80name: http-web-svc--- apiVersion: v1 kind: Service metadata:name: nginx-service spec:selector:app.kubernetes.io/name: proxyports:- name: name-of-service-portprotocol: TCPport: 80targetPort: http-web-svc

不帶選擇算符的服務

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

由于此服務沒有選擇算符，因此不會自動創建相應的 Endpoints 對象。 你可以通過手動添加 Endpoints 對象，將服務手動映射到運行該服務的網絡地址和端口：( 請求將被路由到用戶定義的 Endpoint)

apiVersion: v1 kind: Endpoints metadata:# 這里的 name 要與 Service 的名字相同name: my-service subsets:- addresses:- ip: 192.0.2.42ports:- port: 9376

端點 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 服務的集群 IP，因為 kube-proxy 不支持將虛擬 IP 作為目標。

status（ServiceStatus）

最近觀察到的 Service 狀態。由系統填充。只讀。 更多信息

Endpoints 官文-Endpoints

什么是endpoints

• pod和service之間的關聯關系，是通過endpoint實現的。 Endpoints表示了一個Service對應的所有Pod副本的訪問地址的集合，也就是官網說的

Endpoints 是實現實際服務的端點的集合

而Endpoints Controller負責生成和維護所有Endpoints對象的控制器。它負責監聽Service和對應的Pod副本的變化。

• 對于pod，endpoint是集群自動創建的，用于將service和pod關聯起來；而對于外部服務（部署在集群外邊的數據庫之類的），我們可以人工的創建endpoint和service。使其能夠更規范的和pod進行通信。
• Endpoint存儲在etcd中,它是根據service配置文件中的selector描述產生的。
• 一個service由一組Pod組成，這些Pod通過Endpoints暴露出來，

subsets ([]EndpointSubset)

subsets.addresses ([]EndpointAddress) EndpointAddress 是描述單個 IP 地址的元組。

提供標記為就緒的相關端口的 IP 地址。 這些端點應該被認為是負載均衡器和客戶端可以安全使用的。

subsets.addresses.ip (string), 必需

• 端點的 IP。
• 不可以是本地回路（127.0.0.0/8）、鏈路本地（169.254.0.0/16）或鏈路本地多播（224.0.0.0/24）地址。 IPv6 也被接受，但并非在所有平臺上都完全支持。 此外，諸如 kube-proxy 等某些 Kubernetes 組件還沒有準備好支持 IPv6。

subsets.addresses.hostname (string)

端點主機名稱。

subsets.addresses.nodeName (string)

可選：承載此端點的節點。此字段可用于確定一個節點的本地端點。

subsets.addresses.targetRef (ObjectReference)

對提供端點的對象的引用。

subsets.notReadyAddresses ([]EndpointAddress)

提供相關端口但由于尚未完成啟動、最近未通過就緒態檢查或最近未通過活躍性檢查而被標記為當前未就緒的 IP 地址。

subsets.notReadyAddresses.ip (string), 必需

端點的 IP。不可以是本地環路（127.0.0.0/8）、鏈路本地（169.254.0.0/16）或鏈路本地多播（224.0.0.0/24）地址。 IPv6 也被接受，但并非在所有平臺上都完全支持。 此外，諸如 kube-proxy 等某些 Kubernetes 組件還沒有準備好支持 IPv6。

subsets.notReadyAddresses.hostname (string)

端點主機名稱。

subsets.notReadyAddresses.nodeName (string)

可選：承載此端點的節點。此字段可用于確定節點的本地端點。

subsets.notReadyAddresses.targetRef (ObjectReference)

對提供端點的對象的引用。

subsets.ports ([]EndpointPort)

相關 IP 地址上可用的端口號。

subsets.ports.port (int32), 必需

端點的端口號。

subsets.ports.protocol (string)

此端口的 IP 協議。必須是 UDP、TCP 或 SCTP。默認值為 TCP。

subsets.ports.name (string)

端口的名稱。此字段必須與相應 ServicePort 中的 name 字段匹配。必須是 DNS_LABEL。 僅當定義了一個端口時才可選。

subsets.ports.appProtocol (string)

端口的應用程序協議。此字段遵循標準的 Kubernetes 標簽語法。 未加前綴的名稱保留給 IANA 標準服務名稱（遵循 RFC-6335 和 https://www.iana.org/assignments/service-names)。 非標準協議應使用帶前綴名稱，如 mycompany.com/my-custom-protocol。

Ingress 官網文檔-ingress

什么是ingress？

Ingress 是對集群中服務的外部訪問進行管理（將集群的服務暴露給集群外訪問，就像nginx）的 API 對象，典型的訪問方式是 HTTP。

用于配置 Ingress 的主機規則列表。如果未指定或沒有規則匹配，則所有流量都將發送到默認后端。

Ingress 不會公開任意端口或協議。 將 HTTP 和 HTTPS 以外的服務公開到 Internet 時，通常使用 Service.Type=NodePort 或 Service.Type=LoadBalancer 類型的 Service。

IngressSpec(代表ingress中自己的spec字段的內容)

defaultBackend (IngressBackend)

ingressClassName (string)

• 沒有指定類的新 Ingress 資源將被分配到此默認類。也就是ingress和ingressClass有綁定關系，同時也是和ingress控制器也有綁定關系
• 當存在多個默認 Ingress Class 時，新的 Ingress 如果沒有指定 ingressClassName 則不會被允許創建。解決這個問題只需確保集群中最多只能有一個 IngressClass 被標記為默認。

rules ([]IngressRule)（文檔中在字段后面加上類型的，應該是代碼中的樣子）

rules.host (string)

不允許 IP。當前 IngressRuleValue 只能應用于父 Ingress Spec 中的 IP。

由于不允許使用端口，因此不理會 “:” 分隔符。 當前 Ingress 的端口隱式為：

:80 用于 http
:443 用于 https
這兩種情況在未來都可能發生變化

rules.http (HTTPIngressRuleValue)

HTTPIngressRuleValue 是指向后端的 http 選擇算符列表。例如 http:///? -> 后端， 其中 url 的部分對應于 RFC 3986，此資源將用于匹配最后一個 “/” 之后和第一個 “?” 之前的所有內容或 “#”。

rules.http.paths ([]HTTPIngressPath)，必需

將請求映射到后端的路徑集合。
將路徑與后端關聯。與路徑匹配的傳入 URL 將轉發到后端。

rules.http.paths.backend (IngressBackend)，必需

backend 定義將流量轉發到的引用服務端點。
IngressBackend
描述給定服務和端口的所有端點。

service (IngressServiceBackend)

IngressServiceBackend 需要端口名或端口號。
IngressServiceBackend 引用一個 Kubernetes Service 作為后端。
service 引用一個 Service 作為后端。此字段是一個與 resource 互斥的設置。

service.name (string)，必需

name 是引用的服務。服務必須與 Ingress 對象位于同一命名空間中。

service.port (ServiceBackendPort)

ServiceBackendPort 是被引用的服務的端口。

service.port.name (string)

name 是服務上的端口名稱。此字段是一個與 number 互斥的設置。

service.port.number (int32)

number 是服務上的數字形式端口號（例如 80）。此字段是一個與 name 互斥的設置。

rules.http.paths.pathType (string)，必需

決定如何解釋 path 匹配

• Exact：與 URL 路徑完全匹配。

• Prefix：根據按 “/” 拆分的 URL 路徑前綴進行匹配。
  匹配是按路徑元素逐個元素完成。路徑元素引用的是路徑中由“/”分隔符拆分的標簽列表。 如果每個 p 都是請求路徑 p 的元素前綴，則請求與路徑 p 匹配。 請注意，如果路徑的最后一個元素是請求路徑中的最后一個元素的子字符串，則匹配不成功 （例如 /foo/bar 匹配 /foo/bar/baz，但不匹配 /foo/barbaz）。

• ImplementationSpecific：路徑匹配的解釋取決于 IngressClass。 實現可以將其視為單獨的路徑類型，也可以將其視為前綴或確切的路徑類型。 實現需要支持所有路徑類型。

rules.http.paths.path (string)

path 要與傳入請求的路徑進行匹配。 目前，它可以包含 RFC 3986 定義的 URL 的常規 “路徑” 部分所不允許的字符。 路徑必須以 “/” 開頭，并且在 pathType 值為 “Exact” 或 “Prefix” 時必須存在。

status (IngressStatus)

status 是 Ingress 的當前狀態。 更多信息

IngressClass 官文-ingressClass

什么是ingressClass

IngressClass 代表 Ingress 的類，被 Ingress 的規約引用。

spec (IngressClassSpec)

spec 是 IngressClass 的期望狀態。更多信息

controller (string)

• controller 是指應該處理此類的控制器名稱。
  這允許由同一控制器控制不同“口味”。例如，對于同一個實現的控制器你可能有不同的參數。 此字段應該指定為長度不超過 250 個字符的域前綴路徑，例如 “acme.io/ingress-controller”。 該字段是不可變的。

parameters (IngressClassParametersReference)

parameters 是指向控制器中包含額外配置的自定義資源的鏈接。 如果控制器不需要額外的屬性，這是可選的。
IngressClassParametersReference 標識一個 API 對象。這可以用來指定一個集群或者命名空間范圍的資源

parameters.kind (string)，必需

kind 是被引用資源的類型。

parameters.name (string)，必需

name 是被引用資源的名稱。

parameters.apiGroup (string)

apiGroup 是被引用資源的組。 如果未指定 apiGroup，則被指定的 kind 必須在核心 API 組中。 對于任何其他第三方類型，apiGroup 是必需的。

parameters.namespace (string)

namespace 是被引用資源的命名空間。 當范圍被設置為 “namespace” 時，此字段是必需的； 當范圍被設置為 “Cluster” 時，此字段必須不設置。

parameters.scope (string)

scope 表示是否引用集群或者命名空間范圍的資源。 這可以設置為“集群”（默認）或者“命名空間”。

Ingress 控制器 官文-Ingress 控制器

• 為了讓 Ingress 資源工作，集群必須有一個正在運行的 Ingress 控制器。

• 必須擁有一個 Ingress 控制器 才能滿足 Ingress 的要求。 僅創建 Ingress 資源本身沒有任何效果。就像只有nginx配置文件沒有nginx服務是不行的。

• 與作為 kube-controller-manager 可執行文件的一部分運行的其他類型的控制器不同， Ingress 控制器不是隨集群自動啟動的。 基于此頁面，你可選擇最適合你的集群的 ingress 控制器實現。

• Kubernetes 作為一個項目，目前支持和維護 AWS、 GCE 和 Nginx Ingress 控制器。

參考資料

k8s的service和endpoint
ingress,ingressController,ingressClass
service詳解

總結

以上是生活随笔為你收集整理的k8s--serviec，endpoint,ingress和pod的全部內容，希望文章能夠幫你解決所遇到的問題。

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