每週 Kubernetes 社群環聊筆記 - 2015 年 7 月 10 日

每週，Kubernetes 貢獻者社群都會透過 Google Hangouts 進行虛擬會議。我們希望所有感興趣的人都能瞭解這個論壇討論了什麼。

以下是今天會議的筆記

• Eric Paris：用 ansible 替換 salt（如果我們想的話）
  • 在 contrib 中，有一個用 ansible 編寫的 provisioning 工具
  • 重寫的目的是儘可能消除雲提供商相關的部分
  • salt 設定在指令碼中完成大量設定，然後使用 salt 設定環境
    • 這意味著生成證書等操作在 GCE/AWS/Vagrant 上是不同的
  • 對於 ansible，所有操作都必須在 ansible 中完成
  • ansible 背景
    • 沒有客戶端
    • provisioner 透過 ssh 登入機器並在機器上執行指令碼
    • 您定義叢集的所需狀態，執行指令碼，然後它一次性設定所有內容
    • 如果您更改配置檔案中的一處，ansible 會重新執行所有內容（這並非總是理想的）
    • 使用 jinja2 模板
  • 建立最小軟體的機器，然後使用 ansible 使該機器進入可執行狀態
    • 設定所有附加元件
  • 消除了 provisioning shell 指令碼
  • 完整的叢集設定目前大約需要 6 分鐘
    • CentOS 帶有一些軟體包
    • 重新部署到叢集需要 25 秒
  • 給 Eric 的問題
    • 特定於提供商的配置放在哪裡？
      • ansible 配置中唯一的網路設定是 flannel；您可以將其關閉
    • init 與 systemd 如何？
      • 應該能夠透過程式碼支援（尚未實現）
  • 討論
    • 為什麼不將設定工作推送到容器或 kubernetes 配置中？
      • 要引導一個叢集，只需部署一個 kubelet 和一個清單
    • 執行 kubelet 和配置網路應該是唯一需要的事情。我們可以製作一個預配置好的機器映象，只缺少資料包（證書等）
      • 如果 kubelet 和 docker 尚未安裝，ansible 指令碼會安裝它們
    • 每個作業系統（RedHat、Debian、Ubuntu）都可以有不同的映象。我們可以將其視為構建過程的一部分，而不是安裝過程的一部分。
    • 還需要有一個裸機解決方案。
    • 總體目標是減少 salt 配置中的特殊配置
    • 除 kubelet 外的所有內容都應在容器中執行（最終 kubelet 也應如此）
      • 在容器中執行並不能減少我們目前的複雜性
      • 但它更清晰地定義了程式碼所期望的介面
    • 這些工具（Chef、Puppet、Ansible）將二進位制分發與配置混淆
      • 容器更清晰地分離了這些問題
    • mesos 部署尚未完全自動化，但 mesos 部署完全不同：kubelets 部署在現有 mesos 叢集之上
      • bash 指令碼允許 mesos 開發人員檢視每個雲提供商正在做什麼並重用相關部分
      • 有一個很大的逆向工程曲線，但 bash 至少是可讀的，而 salt 則不是
    • Openstack 也使用不同的部署方式
    • 我們需要一個詳細的步驟列表（例如建立證書），這些步驟對於建立叢集是必要的
      • 這將使我們能夠跨雲提供商進行比較
      • 我們應該儘可能減少步驟的數量
      • Ansible 有 241 個步驟來啟動一個叢集
• 1.0 程式碼凍結
  • 我們如何解除程式碼凍結？
  • 這是下週的話題，但初步設想是我們將緩慢推進，而不是完全放開
    • 我們希望儘快清除積壓，同時保持 HEAD 和 1.0 分支的穩定性
    • 積壓了近 300 個 PR，但程式碼凍結期間也開發了各種並行功能分支
  • 今天釋出一個 cherry pick 版本 (1.0.1) 來修復一些問題
  • 下週我們將討論補丁釋出的節奏

• ←上一篇
• 下一篇→