Service的概念

Kubernetes Service定義了這樣一種抽象：一個Pod的邏輯分組，一種可以訪問它們的策略–通常稱為微服務，這一組Pod能夠被Service訪問到，通常是通過Label Selector

Service能夠提供負載均衡能力，但是在使用上有以下限制：

• 只提供4層負載能力，而沒有7層功能，但是有時我們可能需要更多的匹配規則來轉發請求，這點來說4層負載均衡時不支持的

Service的類型

Service的四種類型：

• ClusterIP：默認類型，自動分配一個僅Cluster內部可訪問的虛擬IP
• NodePort：在ClusterIP基礎上為Service在每臺機器上綁定一個端口，這樣就可以通過:來訪問該服務
• LoadBalance：在NodePort的基礎上，借助cloud provider創建一個外部負載均衡器，并將請求轉發到:
• ExternalName:把集群外部的服務引入到集群內部來，在集群內部直接使用，沒有任何類型代理被創建，這只有Kubernetes1.7以上版本的kube-dns才支持

VIP和Service代理

在Kubernetes集群中，每個Node節點運行一個kube-proxy進程，kube-proxy負責Service實現一種虛擬IP的形式，而不是ExternalName的形式，在Kubernetesv1.0版本，代理完全在userspace，在Kubernetes v1.1版本，新增了iptables代理，但并不是默認的運行模式。從Kubernetes v1.2版本開始，默認就是iptables代理，在Kubernetes v1.8.0-beta.0中，添加了ipvs代理，在Kubernetes v1.14版本開始默認使用ipvs代理

在Kubernetesv1.0版本Service是4層（TCP/UDP over IP）概念，在Kubernetes v1.1版本新增了Ingress API（beta版），用來表示7層（HTTP）服務

ipvs代理模式

這種模式，kube-proxy會監視Kubernetes Service對象和Endpoints，調用netlink接口以相對應地創建ipvs規則并定期與Kubernetes Service對象和Endpoint對象同步ipvs，以確保ipvs狀態與期望一致，訪問服務時，流量被重定向到其中一個后端Pod，與iptables類似，ipvs與netfilter的hook功能，但使用哈希表作為底層數據結構并在內核空間中工作，這意味著可以更快地重定向流量，并且在同步代理規則時具有更好的性能，此外，ipvs為負載均衡算法提供更多選項，例如：

• rr:輪訓調度
• lc:最小連接數
• dn:目標哈希
• sh:源哈希
• sed:最短期望延遲
• nq:不排隊調度

ClusterIP

ClusterIP主要在每個Node節點使用iptables/ipvs將發向ClusterIP對應端口的數據，轉發到kube-proxy中，然后kube-proxy自己內部實現有負載均衡的方法，并可以查詢到這個service下對應Pod的地址和端口，進而把數據轉發給對應的Pod的地址和端口

為例實現該流程，主要需要以下幾個組件的協同工作：

• APIServer用戶通過kubectl命令向APIServer發送創建service的命令，APIServer接收到請求后將數據存儲到etcd中
• kube-proxy Kubernetes的每個節點都有一個叫做kube-proxy的進程，這個進程負責感知service，pod的變化，并將變化信息寫入本地的iptables/ipvs規則中
• iptables/ipvs使用NAT等技術將VIP的流量轉至endpoint中

創建Deployment信息

apiVersion: apps/v1 kind: Deployment metadata:name: myapp-deploynamespace: default spec:replicas: 3selector:matchLabels:app: myapprelease: stabeltemplate:metadata:labels:app: myapprelease: stabelenv: testspec:containers:- name: myappimage: myapp:v1imagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80

創建Service信息

apiVersion: v1 kind: Service metadata:name: myappnamespace: default spec:type: ClusterIPselector:app: myapp #標簽選擇器release: stabelports:- name: httpport: 80targetPort: 80

查詢命令

ipvsadm -Ln

Headless Service

有時不需要或不想要負載均衡，以及單獨的Service IP，遇到這種情況，可以通過指定ClusterIP的值為None來創建Headless Service，這類Service并不會分配ClusterIP，kube-proxy不會處理它們，并且平臺也不會為它們進行負載均衡和路由

apiVersion: v1 kind: Service metadata:name: myapp-headlessnamespace: default spec:selector:app: myappClusterIP: "None"ports:- port: 80targetPort: 80

NodePort

NodePort的原理在于在node上開了一個端口，將向該端口的流量導入到kube-proxy，然后有kube-proxy進一步給對應的Pod

apiVersion: v1 kind: Service metadata:name: myappnamespace: default spec:type: NodePortselector:app: myapp #標簽選擇器release: stabelports:- name: httpport: 80targetPort: 80

查詢命令

ipvsadm -Ln

LoadBalancer

LoadBalancer和NodePode其實是同一種方式，區別在于loadBalancer比NodePort多了一步，就是可以調用cloud provider去創建LB來向節點導流（收費，laas:負載均衡即服務）

ExternalName

這種類型的Service通過返回CNAME和它的值，可以將服務映射到ExternalName字段的內容，ExternalName Service是Service的特例，它沒有selector，也沒有定義任何的端口和endpoint，相反的，對于運行在集群外部的服務，它通過返回該外部服務的別名這種方式來提供服務

apiVersion: v1 kind: Service metadata:name: my-servicenamespace: default spec:type: ExternalNameexternalName: www.example.com

當查詢主機my-service.default.svc.cluster.local時，集群的DSN服務將返回一個值my.database.example.com的CNAM記錄，訪問這個服務的工作方式和其他的相同，唯一不同的是重定向發生在DNS層，而且不會進行代理或轉發

總結

以上是生活随笔為你收集整理的Kubernetes中Service的种类的全部內容，希望文章能夠幫你解決所遇到的問題。

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