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

每週 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（如果尚未安裝）
    • 每個 OS（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)，修復了一些問題
  • 下週我們將討論修補程式版本的節奏

• ←上一篇
下一篇→