Kubernetes Service

目錄

• 基本概念
• 服務發現與負載均衡
• 配置Service
  • 建立一個ClusterIP類型的Service
  • 建立一個指定ClusterIP的Service
  • 建立一個headless service
  • 建立一個nodeport的service
• 配置service使用session affinity

基本概念

當應用由單體架構轉向微服務架構時，應用被拆成不少小的互相協做的微服務，每一個服務會以多個副本運行，副本數量會隨着系統所需的處理能力進行變化，這就是微服務的伸縮性。 微服務的負載均衡器對實現伸縮性起了十分重要的做用。

Service是Kubernetes最重要的資源對象。Kubernetes中的Service對象能夠對應微服務架構中的微服務。Service定義了服務的訪問入口，服務的調用者Pod經過這個地址訪問Service後端的Pod副本實例。 Service經過Label Selector同後端的Pod副本創建關係，Replication Controller保證後端Pod副本的數量，也就是保證服務的伸縮性。

服務發現與負載均衡

咱們知道，kubernetes的node節點運行的時候，須要啓動兩個進程，分別是kubelet和kube-proxy。其中kubeproxy實際上就是一個智能的負載均衡器。發送到service的請求由kube-proxy轉發到後端在的某個pod實例上，同時支持不一樣的負載均衡策略和會話保持機制。kubernetes爲每一個service分配一個全局惟一的虛擬IP，叫作ClusterIP，這樣在整個集羣中，服務的調用者都經過ClusterIP和服務進行通訊。

Service建立完畢後，在Service的整個生命週期內Service的名稱和ClusterIP保持不變，所以經過引入域名服務將Service的名稱和ClusterIP創建DNS域名映射，服務的調用者能夠經過使用服務的名稱來訪問服務。服務發佈機制完美支持。

當前kubernetes支持兩種負載均衡策略：

• RoundRobin：默認策略，請求被輪循轉發到後端的pod實例副本上。
• SessionAffinilty：基於客戶端的IP進行會話保持的模式，實現粘性session，客戶端請求第一次被轉發到某個pod之後，後邊全部的請求都固定轉發到這個Pod上。SessionAffinilty經過服務的定義service.spec.session.Affinity設備

配置Service

kubrenetes支持三種類型的service，能夠經過ServicesTypes指定：

• ClusterIP：僅僅使用一個集羣內部的地址，這也是默認值，使用該類型，意味着，service只能在集羣內部被訪問
• NodePort：在集羣內部的每一個節點上，都開放這個服務。能夠在任意的 :NodePort地址上訪問到這個服務
• LoadBalancer：這是當kubernetes部署到公有云上時纔會使用到的選項，是向雲提供商申請一個負載均衡器，將流量轉發到已經以NodePort形式開放的service上。

下面示例建立一個nginx的deployment，包含三個pod，後面全部建立的service都會與之關聯：

建立一個nginx的Deployment：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
  spec:
    containers:
      - name: nginx
        image: nginx
        ports:
          - containerPort:80

能夠經過以下指令查看建立的pod：

kubectl get pod -l app=nginx -o wide

建立一個ClusterIP類型的Service

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  ports:
    - port: 80 
      targetPort: 80
  selector:
    app: nginx

須要說明下三個端口的意義，其中port表示service監聽的端口，targetPort表示後端Pod監聽的端口，nodePort表示若是要將service暴露出來，外部訪問的端口。不指定ClusterIP，則默認使用ClusterIP方式建立Service，並自動生成一個ClusterIP。能夠經過查看service來看到ClusterIP。

查看service：

kubectl get svc nginx

建立一個指定ClusterIP的Service

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  clusterIP: 10.254.0.100
  ports:
    - port: 80 
      targetPort: 80
  selector:
    app: nginx

默認狀況下，ClusterIP的值是由k8s自動建立的，咱們能夠經過ClusterIP指定，在建立k8s中的dns的時候會用到。

建立一個headless service

建立一個headless service，即指定ClusterIP爲None，這個時候，建立的Service沒有IP地址。

咱們知道，在默認狀況下建立的service，k8s會自動爲其生成一個ip地址，並在dns中生成一條域名記錄指向該ip，當外部有請求到達時，由kubeproxy組件接受請求並轉發到後端的pods。而當ClusterIP爲None時，k8s並不會爲service生成一個IP，可是仍然會往dns裏生成一條域名記錄，而這個域名的值會直接指向service所關聯的pods的IP地址，有多個pods，就會生成多條A記錄。這樣的好處是，當有請求到達時，會直接請求到指定的pods，而無需再經過kubeproxy轉發，從而提升了響應效率。缺點是負載均衡依賴於dns輪循，沒有更靈活的均衡方案。

示例：

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  clusterIP: None
  ports:
    - port: 80 
      targetPort: 80
  selector:
    app: nginx

建立一個nodeport的service

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  type: NodePort
  ports:
    - port: 80 
      targetPort: 80
      nodePort: 80
  selector:
    app: nginx

配置service使用session affinity

apiVersion: v1
kind: Service
metadata:
  name: nginx-app
  labels:
    app: nginx-app
    tier: nginx-app
spec:
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: nginx-app
    tier: nginx-app
  type: LoadBalancer
  sessionAffinity: ClientIP
  loadBalancerIP: 123.123.123.123