1. 程式人生 > >【K8S】Service服務詳解,看這一篇就夠了!!

【K8S】Service服務詳解,看這一篇就夠了!!

k8s用名稱空間namespace把資源進行隔離,預設情況下,相同的名稱空間裡的服務可以相互通訊,反之進行隔離。

1.1 Service

Kubernetes中一個應用服務會有一個或多個例項(Pod,Pod可以通過rs進行多複本的建立),每個例項(Pod)的IP地址由網路外掛動態隨機分配(Pod重啟後IP地址會改變)。為遮蔽這些後端例項的動態變化和對多例項的負載均衡,引入了Service這個資源物件,如下所示:

apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
  labels:
    app: nginx
spec:
  type: ClusterIP
  ports:
    - port: 80
       targetPort: 80
  selector:  #service通過selector和pod建立關聯
    app: nginx

根據建立Service的type型別不同,可分成4種模式:

  • ClusterIP: 預設方式。根據是否生成ClusterIP又可分為普通Service和Headless Service兩類:
    • 普通Service:通過為Kubernetes的Service分配一個叢集內部可訪問的固定虛擬IP(Cluster IP),實現叢集內的訪問。為最常見的方式。
    • Headless Service:該服務不會分配Cluster IP,也不通過kube-proxy做反向代理和負載均衡。而是通過DNS提供穩定的絡ID來訪問,DNS會將headless service的後端直接解析為podIP列表。主要供StatefulSet使用。
  • NodePort:除了使用Cluster IP之外,還通過將service的port對映到叢集內每個節點的相同一個埠,實現通過nodeIP:nodePort從叢集外訪問服務。
  • LoadBalancer:和nodePort類似,不過除了使用一個Cluster IP和nodePort之外,還會向所使用的公有云申請一個負載均衡器(負載均衡器後端對映到各節點的nodePort),實現從叢集外通過LB訪問服務。
  • ExternalName:是 Service 的特例。此模式主要面向執行在叢集外部的服務,通過它可以將外部服務對映進k8s叢集,且具備k8s內服務的一些特徵(如具備namespace等屬性),來為叢集內部提供服務。此模式要求kube-dns的版本為1.7或以上。這種模式和前三種模式(除headless service)最大的不同是重定向依賴的是dns層次,而不是通過kube-proxy。
    比如,在service定義中指定externalName的值"my.database.example.com":

此時k8s叢集內的DNS服務會給叢集內的服務名 ..svc.cluster.local 建立一個CNAME記錄,其值為指定的"my.database.example.com"。
當查詢k8s叢集內的服務my-service.prod.svc.cluster.local時,叢集的 DNS 服務將返回對映的CNAME記錄"foo.bar.example.com"。

備註: 前3種模式,定義服務的時候通過selector指定服務對應的pods,根據pods的地址創建出endpoints作為服務後端;Endpoints Controller會watch Service以及pod的變化,維護對應的Endpoint資訊。kube-proxy根據Service和Endpoint來維護本地的路由規則。當Endpoint發生變化,即Service以及關聯的pod發生變化,kube-proxy都會在每個節點上更新iptables,實現一層負載均衡。 而ExternalName模式則不指定selector,相應的也就沒有port和endpoints。 ExternalName和ClusterIP中的Headles Service同屬於Headless Service的兩種情況。Headless Service主要是指不分配Service IP,且不通過kube-proxy做反向代理和負載均衡的服務。

1.2 Port

Service中主要涉及三種Port: * port 這裡的port表示service暴露在clusterIP上的埠,clusterIP:Port 是提供給叢集內部訪問kubernetes服務的入口。

  • targetPort

containerPort,targetPort是pod上的埠,從port和nodePort上到來的資料最終經過kube-proxy流入到後端pod的targetPort上進入容器。

  • nodePort

nodeIP:nodePort 是提供給從叢集外部訪問kubernetes服務的入口。

總的來說,port和nodePort都是service的埠,前者暴露給從叢集內訪問服務,後者暴露給從叢集外訪問服務。從這兩個埠到來的資料都需要經過反向代理kube-proxy流入後端具體pod的targetPort,從而進入到pod上的容器內。

1.3 IP

使用Service服務還會涉及到幾種IP:

  • ClusterIP

Pod IP 地址是實際存在於某個網絡卡(可以是虛擬裝置)上的,但clusterIP就不一樣了,沒有網路裝置承載這個地址。它是一個虛擬地址,由kube-proxy使用iptables規則重新定向到其本地埠,再均衡到後端Pod。當kube-proxy發現一個新的service後,它會在本地節點開啟一個任意埠,建立相應的iptables規則,重定向服務的clusterIP和port到這個新建的埠,開始接受到達這個服務的連線。

  • Pod IP

Pod的IP,每個Pod啟動時,會自動建立一個映象為gcr.io/google_containers/pause的容器,Pod內部其他容器的網路模式使用container模式,並指定為pause容器的ID,即:network_mode: "container:pause容器ID",使得Pod內所有容器共享pause容器的網路,與外部的通訊經由此容器代理,pause容器的IP也可以稱為Pod IP。

  • 節點IP

Node-IP,service物件在Cluster IP range池中分配到的IP只能在內部訪問,如果服務作為一個應用程式內部的層次,還是很合適的。如果這個service作為前端服務,準備為叢集外的客戶提供業務,我們就需要給這個服務提供公共IP了。指定service的spec.type=NodePort,這個型別的service,系統會給它在叢集的各個代理節點上分配一個節點級別的埠,能訪問到代理節點的客戶端都能訪問這個埠,從而訪問到服務。

&n