k8s之Service

爲何須要Service

咱們知道k8s的pod在死掉之後，重啓的時候ip是會變化的。這就引發了一個問題，若是一些Pods提供一些功能供其餘的Pod使用，那麼在k8s中如何實現讓這些pod可以持續的請求到依賴的這些Pod呢。另外，在這一組對外提供服務的pods之間如何保持負載均衡呢，而Service就是解決這個問題的。

k8s的Service是一個定義了一組Pod的策略的抽象，咱們有時候也叫作宏觀服務，這些被服務標記的Pod通常都是經過label selector選擇的。

如何定義一個Service

咱們能夠經過以下yaml格式定義一個Service

apiVersion: v1
kind: Service
metadata:
  name: hostnames
spec:
  selector:
    app: hostnames
  ports:
  - name: default
    protocol: TCP
    port: 80
    targetPort: 9376

咱們是用selector字段來聲明瞭這個Service代理的是app爲hostnames的pod。而且這個Service的80端口代理的是Pod的9376端口。

三種主要的Service

每個Service都會有一個字段定義了該服務如何被調用，這個字段的值能夠分紅三種

• ClusterIP: 僅僅使用一個集羣內部的IP地址 - 這是默認值。選擇這個值意味着你只想這個服務在集羣內部才能夠被訪問到。

• NodePort: 在集羣內部IP的基礎上，在集羣的每個節點的端口上開放這個服務。你能夠在任意 :NodePort地址上訪問到這個服務。例如，咱們能夠設計一個以下的Service的yaml文件：

  apiVersion: v1
  kind: Service
  metadata:
    name: my-nginx
    labels:
      run: my-nginx
  spec:
    type: NodePort
    ports:
    - nodePort: 8080
      targetPort: 80
      protocol: TCP
      name: http
    - nodePort: 443
      protocol: TCP
      name: https
    selector:
      run: my-nginx

  在這個Service中咱們制定了type=NodePort，而後咱們聲明瞭使用8080端口代理Pod的80端口，使用Service的443端口代理Pod的443端口。固然若是咱們不顯示的制動nodePort，系統就會在30000-32767之間隨機爲咱們分配一個端口。這樣之後，咱們就能夠經過< 任何一臺宿主機的 IP 地址 >:8080 訪問這個Service了。

• LoadBalancer: 在使用一個集羣內部IP地址和在NodePort上開放一個服務以外，向雲提供商申請一個負載均衡器，會讓流量轉發到這個在每一個節點上以 :NodePort的形式開放的服務上。