本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

Rancher 中的 Kubernetes：進一步演進

作者：Alena Prokharchyk (Rancher Labs) |

Kubernetes 是 Rancher 支援的第一個外部編排平臺，自發布以來，它已成為我們使用者中使用最廣泛的平臺之一，並且仍在迅速普及。隨著 Kubernetes 的發展，Rancher 也在適應新的 Kubernetes 功能方面不斷發展。我們從支援 Kubernetes 1.1 版本開始，然後在 1.2 釋出後立即切換到 1.2，現在我們正在努力支援 1.3 中令人興奮的新功能。我想向您介紹我們在每個階段中新增支援的功能。

Rancher 和 Kubernetes 1.2

Kubernetes 1.2 引入了增強的 Ingress 物件，以簡化允許入站連線到達叢集服務：這是一篇關於 Ingress 策略的優秀部落格文章。Ingress 資源允許使用者以使用者友好的方式定義負載均衡器的主機名路由規則和 TLS 配置。然後，它應該由 Ingress 控制器支援，該控制器將使用 Ingress 規則配置相應的雲提供商的負載均衡器。由於 Rancher 已經包含了基於 HAproxy 的軟體定義負載均衡器，我們已經支援 Ingress 資源的所有配置要求，並且無需在 Rancher 端進行任何更改即可採用 Ingress。我們需要做的是編寫一個 Ingress 控制器，它將監聽 Kubernetes Ingress 特定的事件，相應地配置 Rancher 負載均衡器，並將負載均衡器公共入口點傳播回 Kubernetes。

Screen-Shot-2016-05-13-at-11.15.56-AM.png

現在，Ingress 控制器作為 Rancher Kubernetes 系統堆疊的一部分進行部署，並由 Rancher 管理。Rancher 監控 Ingress 控制器的健康狀況，並在發生任何故障時重新建立它。除了標準的 Ingress 功能外，Rancher 還允許您透過 Ingress 註釋指定規模來橫向擴充套件支援 Ingress 服務的負載均衡器。例如：

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

 name: scalelb

 annotations:

 scale: "2"

spec:

  rules:

  - host: foo.bar.com

    http:

      paths:

      - path: /foo

        backend:

          serviceName: nginx-service

          servicePort: 80

上述操作的結果是，將在單獨的主機上啟動 2 個 Rancher 負載均衡器例項，並且 Ingress 將使用 2 個公共 IP 地址進行更新。

kubectl get ingress

NAME      RULE          BACKEND   ADDRESS

scalelb      -                    104.154.107.202, 104.154.107.203  // hosts ip addresses where Rancher LB instances are deployed

          foo.bar.com

          /foo           nginx-service:80

有關 Rancher Ingress 控制器在 Kubernetes 中的實現詳情，請參見此處：

Rancher 和 Kubernetes 1.3

我們對 Kubernetes 1.3 版本的釋出及其包含的所有新功能感到非常興奮。其中有兩項是我們特別感興趣的：有狀態應用程式和叢集聯邦。

Kubernetes 有狀態應用程式

有狀態應用程式是 Kubernetes 中的一個新資源，用於表示有狀態應用程式中的一組 Pod。這是使用複製控制器的替代方案，複製控制器最適合用於執行無狀態應用程式。此功能對於依賴於具有領導者選舉的仲裁（例如 MongoDB、Zookeeper、etcd）和去中心化仲裁（Cassandra）的應用程式特別有用。有狀態應用程式建立並維護一組 Pod，每個 Pod 都具有穩定的網路身份。為了提供網路身份，必須能夠為 Pod 提供一個可解析的 DNS 名稱，該名稱與 Pod 身份相關聯，如 Kubernetes 設計文件所述。

# service mongo pointing to pods created by PetSet mdb, with identities mdb-1, mdb-2, mdb-3


dig mongodb.namespace.svc.cluster.local +short A

172.130.16.50


dig mdb-1.mongodb.namespace.svc.cluster.local +short A

# IP of pod created for mdb-1


dig mdb-2.mongodb.namespace.svc.cluster.local +short A

# IP of pod created for mdb-2


dig mdb-3.mongodb.namespace.svc.cluster.local +short A

# IP of pod created for mdb-3

上述內容透過 Pod 上的註釋實現，該註釋會顯示在端點上，並最終作為 DNS 顯示在公開這些 Pod 的服務上。目前，Rancher 透過利用 Rancher DNS 作為 SkyDNS 的替代品來簡化 DNS 配置。Rancher DNS 快速、穩定且可擴充套件——叢集中的每個主機都執行著 DNS 伺服器。Kubernetes 服務被程式設計到 Rancher DNS，並解析為 10.43.x.x 地址空間中的服務叢集 IP，或解析為無頭服務的一組 Pod IP 地址。為了使 PetSet 與 Rancher 中的 Kubernetes 配合使用，我們必須在 Rancher DNS 配置中新增對 Pod 身份的支援。我們正在為此努力，並應在即將釋出的 Rancher 版本之一中支援它。

叢集聯邦

叢集聯邦是 Kubernetes 中叢集聯邦的控制平面。它透過將應用程式分佈到多個叢集中，提高了應用程式的可用性（下圖由 Kubernetes 提供）。

Screen Shot 2016-07-07 at 1.46.55 PM.png

每個 Kubernetes 叢集公開一個 API 端點，並作為聯邦物件的一部分註冊到叢集聯邦。然後，使用叢集聯邦 API，您可以建立聯邦服務。這些物件由多個等效的底層 Kubernetes 資源組成。假設上圖中的 3 個叢集屬於同一個聯邦物件，則透過叢集聯邦建立的每個服務都將在每個叢集中建立等效的服務。此外，叢集聯邦服務將獲得可公開解析的 DNS 名稱，該名稱解析為 Kubernetes 服務的公共 IP 地址（DNS 記錄將被程式設計到以下公共 DNS 提供商之一）。

Screen Shot 2016-07-07 at 1.24.18 PM.png

為了透過 Rancher 支援 Kubernetes 中的叢集聯邦，需要進行某些更改。目前，每個 Kubernetes 叢集都表示為一個 Rancher 環境。在每個 Kubernetes 環境中，我們都會建立一個完整的 Kubernetes 系統堆疊，該堆疊由多個服務組成：Kubernetes API 伺服器、排程器、Ingress 控制器、持久化 etcd、控制器管理器、Kubelet 和代理（最後兩個在每臺主機上執行）。為了設定叢集聯邦，我們將建立一個額外的環境，在該環境中執行叢集聯邦堆疊。

Screen Shot 2016-07-07 at 1.23.14 PM.png

然後，由 Rancher 環境表示的每個底層 Kubernetes 叢集都應該註冊到特定的叢集聯邦。Rancher 叢集聯邦環境可能透過 Kubernetes 叢集上的聯邦名稱標籤自動發現每個叢集。我們仍在最終確定我們的設計，但我們對這個功能感到非常興奮，並看到了它可以解決的許多用例。叢集聯邦文件參考資料：

Kubernetes 1.4 的計劃

當我們在 Rancher 中推出 Kubernetes 支援時，我們決定維護自己的 Kubernetes 發行版，以支援 Rancher 的原生網路。我們知道，透過擁有自己的發行版，每次 Kubernetes 發生變化時都需要更新它，但我們認為為了支援我們為使用者解決的用例，這是必要的。作為 1.4 版工作的一部分，我們再次審視了我們的網路方法，並重新分析了最初需要我們自己分叉 Kubernetes 的原因。除了網路整合，我們所有與 Kubernetes 相關的工作都已開發為 Kubernetes 外掛。

  • Rancher 作為 CloudProvider（支援負載均衡器）。
  • Rancher 作為 CredentialProvider（支援 Rancher 私有登錄檔）。
  • Rancher Ingress 控制器，用於支援 Kubernetes Ingress 資源。

因此，我們決定消除 Rancher Kubernetes 發行版的必要性，並嘗試將我們所有的更改上游到 Kubernetes 倉庫。為此，我們將重新設計我們的網路整合，並支援 Rancher 網路作為 Kubernetes 的 CNI 外掛。有關詳細資訊將在功能設計最終確定後儘快分享，但預計將在未來 2-3 個月內推出。我們還將繼續投資 Rancher 與 Kubernetes 整合的核心功能，包括但不限於：

  • 透過表示 Kubernetes 叢集的 Rancher 環境進行訪問許可權管理
  • 憑證管理和易於使用的基於 Web 的標準 kubectl CLI 訪問
  • 負載均衡支援
  • Rancher 內部 DNS 支援
  • Kubernetes 模板的目錄支援
  • 增強的 UI 以表示更多 Kubernetes 物件，例如：Deployment、Ingress、Daemonset。

所有這些都是為了讓 Kubernetes 體驗更加強大和使用者直觀。我們對 Kubernetes 社群的所有進展感到非常興奮，並很高興能參與其中。Kubernetes 1.3 是一個極其重要的版本，您很快就能在 Rancher 中升級到它。

Rancher-and-Kubernetes.png