Kubernetes Services 詳解

Kubernetes Services 詳解

原文鏈接：https://medium.com/swlh/kubernetes-services-simply-visually-explained-2d84e58d70e5

Kubernetes 有四種 service 類型，而 ClusterIP 是最基礎的：

如上圖所示，你可以想象一下，如果你要創建一個 NodePort 類型的 service，Kubernetes 也會創建一個 ClusterIP。如果你要創建一個 LoadBalancer 類型的 service，Kubernetes 會創建一個 NodePort 以及 ClusterIP。如果你以這樣的方式思考，對 Kubernetes service 的理解將變得容易。

接下來我們將會對此進行一一解釋。

Services和Pods

Services 通過使用 labels 直接指向 pods，而不是指向 deployments 或者 replicasets。這種設計的靈活性極高，因爲創建 pods 的方式有很多，而 Service 不需要關心 pods 通過哪種方式創建。

我們先闡述一個簡單的示例，然後逐步介紹不同的 service 類型，來了解它們是如何在彼此之上構建的。

不使用 Services

首先，讓我們看下不使用 services 的情況。

如上圖，我們有2個 node 和 1 個 pod。兩個 node 分別使用外部 IP 地址（4.4.4.1和4.4.4.2）以及內部 IP 地址（1.1.1.1和1.1.1.2），而名爲 pod-python 的 pod 只有一個內部 IP 地址。

如上圖，現在我們添加第二個名爲 pod-nginx 的 pod，它被調度到了 node-1 上。雖然兩個 pod 在不同的 node 上，但這不影響它們互相訪問。在 Kubernetes 集羣中，所有的 pod 都可以通過內部 IP 地址訪問其他的 pod，不管它們運行在哪個 node 上。

這就意味着 pod-nginx 能通過內部 IP 地址 1.1.1.3 ping通或者連接 pod-python。

如上圖，現在我們考慮將 pod-python 殺死並重建一個新 pod。（本文不負責介紹如何管理和控制 pod。）操作完成之後，pod-nginx 就無法繼續訪問 IP 地址 1.1.1.3，這樣系統就中斷崩潰了。爲了避免這種問題，我們來創建第一類 service！

ClusterIP 類型

與上述場景一樣，但這次我們配置了一個 ClusterIP 類型的 service。service 不像 pod 會調度到特定的 node 上，在本文中你可以假定service 僅在整個集羣的內存中生效。

現在，pod-nginx 總是能夠安全地連接 IP 地址 1.1.10.1 或者域名地址 service-python，然後重定向到一個活躍的 python pod 上。沒有災難，一切美好。

我們來延申下這個示例，將 python 服務擴展到 3 個實例，並且現在我們把 service 和所有 pod 實例的內部 IP 地址以及端口都標註在圖中。

集羣中的所有 pod 都能通過 http://1.1.10.1:3000 或者 http://service-python:3000 訪問到 python pod 的 443 端口。service-python 這個 ClusterIP 類型的 service 將基於隨機或者輪詢方式分發請求。這就是 ClusterIP 類型的 service 要做的事情，它能夠讓集羣中的 pod 通過一個名字或者 IP 達到可用性。

apiVersion: v1
kind: Service
metadata:
    name: service-python
spec:
    ports:
    - port: 3000
      protocol: TCP
      targetPort: 443
    selector:
      run: pod-python
    type: ClusterIP

運行命令 kubectl get svc，結果如下：

NodePort 類型

現在我們想讓 ClusterIP 類型的 service 在集羣外部也能夠使用，所以將其轉換成 NodePort 類型的 service。基於我們的示例，只需將 service-python 的 yaml 文件做兩處簡單的修改，如下所示：

apiVersion: v1
kind: Service
metadata:
  name: service-python
spec:
  ports:
  - port: 3000
    protocol: TCP
    targetPort: 443
    nodePort: 30080
  selector:
    run: pod-python
  type: NodePort

通過 node-2 的外部請求

如上圖所示，現在我們集羣內部的 service-python 也能通過所有 node 的內部以及外部 IP 地址和端口 30080 訪問。

運行命令 kubectl get svc，結果展示了相同的 cluster ip，但類型顯示不一樣了，而且多了個額外的 NodePort 端口。

在集羣內部，NodePort 類型的 service 同樣扮演着之前 ClusterIP 類型 service 的角色。這幫助了我們去想象一個 NodePort 類型的 service 創建了一個 ClusterIP 類型的 service，儘管事實上並沒有額外增加一個 ClusterIP 類型的 service。

LoadBalancer 類型

當我們想通過一個 IP 地址將請求分發到所有 node 節點的外部 IP 地址時，可以使用 LoadBalancer 類型的 service。因此，它是構建於 NodePort 類型的 service 之上，如下圖所示：

我們可以想象成一個 LoadBalancer 類型的 service 創建了一個 NodePort 類型的 service，接着創建了一個 ClusterIP 類型的 service。只需簡單修改下 NodePort 類型的 yaml 文件即可變更爲 LoadBalancer 類型，如下所示：

apiVersion: v1
kind: Service
metadata:
  name: service-python
spec:
  ports:
  - port: 3000
    protocol: TCP
    targetPort: 443
    nodePort: 30080
  selector:
    run: pod-python
  type: LoadBalance

LoadBalancer類型的 service 所要做的就是創建一個 NodePort 類型的 service，然後發消息給部署 Kubernetes 集羣的雲服務提供商，請求其爲所有 node 節點的外部 IP 地址以及設定的 NodePort 端口配置負載均衡。如果雲服務提供商不支持這類請求消息的處理，任何事情都不會發生，LoadBalancer 類型的 service 就會和 NodePort 類型一樣了。

運行命令 kubectl get svc，結果僅多展示了一個 EXTERNAL-IP 字段以及不同的類型。

LoadBalancer 類型的 service 同樣會在所有 node 節點內外 IP 地址上開放 30080 端口。在集羣內部，它和 ClusterIP 類型的 service 作用一樣。

ExternalName 類型

最後介紹下 ExternalName 類型的 service，它可以被認爲是有點分開的，和之前介紹的 3 種不在一個技術棧。簡而言之，它創建了一個內部服務，端點指向了一個 DNS 域名。

基於我們之前的示例，現在假設 pod-nginx 已經遷移到了我們新的 Kubernetes 集羣，但 Python 服務還在外部（原來的地方）：

如上圖所示，pod-nginx 可以直接連接 http://remote.server.url.com，這樣是沒有問題的。但不久之後，我們想將 python 服務也遷移到新的集羣中，到那時就會出問題了，因此我們可以創建一個 ExternalName 類型的 service。

使用的 yaml 文件內容如下：

kind: Service
apiVersion: v1
metadata:
  name: service-python
spec:
  ports:
  - port: 3000
    protocol: TCP
    targetPort: 443
  type: ExternalName
  externalName: remote.server.url.com

現在，pod-nginx 可以簡單地與 http://service-python:3000 建立連接，就像使用 ClusterIP 類型的 service 一樣。當最終我們決定將Python 服務遷移到新的 Kubernetes 集羣中時，我們只需要將 service 的類型改成 ClusterIP 並使用對應的 labels 配置即可。

使用 ExternalName 類型 service 的最大好處在於，你可以先建設好 Kubernetes 集羣基礎設施，並且基於 services 和 IP 地址設定好規則與限制，儘管有些服務依然存在於集羣外部。