每週 Kubernetes 社群聚會記錄 - 2015 年 7 月 17 日

每週 Kubernetes 貢獻社群都會透過 Google Hangouts 進行虛擬會議。我們希望任何有興趣的人都能了解這個論壇中討論的內容。

以下是今天會議的記錄

• Eric Paris：如果我們想要，可以用 ansible 取代 salt

  • 在 contrib 中，有一個用 ansible 撰寫的佈建工具

  • 重寫的目標是盡可能消除雲端供應商的東西

  • salt 設定會在腳本中進行一堆設定，然後使用 salt 設定環境

    • 這表示在 GCE/AWS/Vagrant 上，產生憑證之類的事情會以不同的方式完成

  • 對於 ansible，所有事情都必須在 ansible 內完成

  • ansible 背景介紹

    • 沒有用戶端
    • Provisioner ssh 進入機器並在機器上執行腳本
    • 您定義您希望叢集的外觀，執行腳本，它會一次設定所有內容
    • 如果您在組態檔中進行一項變更，ansible 會重新執行所有內容 (這並不總是理想的)
    • 使用 jinja2 範本

  • 建立具有最少軟體的機器，然後使用 ansible 將該機器置於可執行狀態

    • 設定所有附加元件

  • 消除佈建器 shell 腳本

  • 完整的叢集設定目前大約需要 6 分鐘

    • 具有某些套件的 CentOS
    • 重新部署到叢集需要 25 秒

  • 給 Eric 的問題

    • 供應商特定的組態放在哪裡？

      • ansible 組態執行的唯一網路設定是 flannel；您可以將其關閉

    • init 與 systemd 呢？

      • 應該能夠在程式碼中支援而不會有任何問題 (尚未實作)

  • 討論

    • 為何不將設定工作推送到容器或 kubernetes 組態中？

      • 為了引導叢集，請放置一個 kubelet 和一個 manifest

    • 執行 kubelet 和設定網路應該是唯一需要的。我們可以裁剪一個預先設定但減去資料包 (憑證等) 的機器映像

      • ansible 腳本會安裝 kubelet 和 docker (如果尚未安裝)

    • 每個作業系統 (RedHat、Debian、Ubuntu) 都可能有不同的映像。我們可以將其視為建置過程的一部分，而不是安裝過程。

    • 裸機也需要解決方案。

    • 贊成整體目標 - 減少 salt 組態中的特殊組態

    • 除了 kubelet 之外的所有內容都應該在容器內執行 (最終 kubelet 也應該如此)

      • 在容器中執行並不會減少我們目前擁有的複雜性
      • 但它更清楚地定義了程式碼期望的介面

    • 這些工具 (Chef、Puppet、Ansible) 將二進位發行與組態混為一談

      • 容器更清楚地分離了這些問題

    • mesos 部署尚未完全自動化，但 mesos 部署完全不同：kubelet 被放在現有的 mesos 叢集之上

      • bash 腳本允許 mesos 開發人員查看每個雲端供應商正在做什麼，並重複使用相關位元
      • 存在很大的逆向工程曲線，但 bash 至少是可讀的，而不是 salt

    • Openstack 也使用不同的部署

    • 我們需要一份有充分記錄的步驟清單 (例如，建立憑證)，這些步驟是建立叢集所必需的

      • 這將允許我們跨雲端供應商進行比較
      • 我們應該盡可能減少步驟數量
      • Ansible 有 241 個步驟來啟動叢集

• 1.0 程式碼凍結

  • 我們如何擺脫程式碼凍結？

  • 這是下週的主題，但預覽是我們將緩慢移動，而不是完全打開消防水龍頭

    • 我們希望在保持 HEAD 和 1.0 分支穩定性的同時，盡快清除積壓工作
    • 積壓了將近 300 個 PR，但也存在在凍結期間開發的各種平行功能分支

  • 今天 (1.0.1) 裁剪一個 cherry pick 版本，以修正一些問題

  • 下週我們將討論修補程式版本的節奏

• ←上一篇
下一篇→