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

使用 Puppet 管理 Kubernetes Pod、Service 和 Replication Controller

熟悉 Puppet 的人可能用它來管理主機上的檔案、軟體包和使用者。但 Puppet 首先是一種配置管理工具,配置管理是一個比僅僅管理主機級資源更廣泛的領域。配置管理的一個很好的定義是,它旨在解決四個相關問題:識別、控制、狀態核算以及驗證和審計。這些問題存在於任何複雜系統的操作中,透過新的 Puppet Kubernetes 模組,我們開始研究如何為 Kubernetes 解決這些問題。

Puppet Kubernetes 模組

Puppet Kubernetes 模組目前假定您已經有一個 Kubernetes 叢集 正在執行;它的重點是管理 Kubernetes 中的資源,如 Pod、Replication Controller 和 Service,而不是(尚未)管理底層的 kubelet 或 etcd 服務。以下是 Puppet DSL 中描述 Pod 的一段簡短程式碼片段。

kubernetes_pod { 'sample-pod':
  ensure => present,
  metadata => {
    namespace => 'default',
  },
  spec => {
    containers => [{
      name => 'container-name',
      image => 'nginx',
    }]
  },

}

如果您熟悉 YAML 檔案格式,您可能會立即識別出其結構。為了便於不同格式之間的轉換,該介面特意設計成相同的——事實上,驅動此功能的程式碼是從 Kubernetes API Swagger 定義自動生成的。執行上述程式碼(假設我們將其儲存為 pod.pp)就像以下這樣簡單:

puppet apply pod.pp

身份驗證使用標準的 kubectl 配置檔案。您可以在模組的 README 中找到完整的安裝說明

Kubernetes 有多種資源,從 Pod 和 Service 到 Replication Controller 和 Service Account。您可以在 Puppet 中的 Kubernetes 訪客留言本示例 文章中看到該模組管理這些資源的示例。這演示瞭如何將經典的 hello-world 示例轉換為使用 Puppet 程式碼。

然而,使用 Puppet 的主要優點之一是,您可以為 Kubernetes 管理的應用程式建立自己的更高階、更具業務特定性的介面。例如,對於留言簿,您可以建立類似以下內容:

guestbook { 'myguestbook':
  redis_slave_replicas => 2,
  frontend_replicas => 3,
  redis_master_image => 'redis',
  redis_slave_image => 'gcr.io/google_samples/gb-redisslave:v1',
  frontend_image => 'gcr.io/google_samples/gb-frontend:v3',     
}

您可以在 Puppet 部落格文章 在 Puppet 中為 Kubernetes 構建自己的抽象 中閱讀更多關於使用 Puppet 定義型別的資訊,並檢視更多程式碼示例。

結論

使用 Puppet 而不僅僅是標準的 YAML 檔案和 kubectl 的優點是:

  • 能夠建立自己的抽象,以減少重複並製作更高階的使用者介面,如上面的留言簿示例。
  • 使用 Puppet 的開發工具進行程式碼驗證和編寫單元測試。
  • 與 Puppet Server 等其他工具整合,以確保您的程式碼模型與叢集狀態匹配,並與 PuppetDB 整合,以儲存報告和跟蹤更改。
  • 能夠反覆針對 Kubernetes API 執行相同的程式碼,以檢測任何更改或修復配置漂移。

還值得注意的是,大多數大型組織都會擁有非常異構的環境,執行各種軟體和作業系統。擁有一個統一這些離散系統的單一工具鏈可以使採用 Kubernetes 這樣的新技術變得更加容易。

可以說,Kubernetes 提供了一套出色的原語,可以在其上構建雲原生系統。藉助 Puppet,您可以解決在生產環境中執行任何複雜系統所帶來的一些操作和配置管理問題。如果您嘗試了該模組,請告訴我們您的想法,以及您未來希望看到支援哪些其他功能。