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

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

以下是今天會議的筆記

• Eric Paris：用 ansible 替換 salt（如果我們想的話）

  • 在 contrib 中，有一個用 ansible 編寫的供應工具

  • 重寫的目的是儘可能消除雲提供商的內容

  • salt 設定在指令碼中進行了一系列設定，然後使用 salt 設定環境

    • 這意味著在 GCE/AWS/Vagrant 上生成證書等操作方式不同

  • 對於 ansible，所有操作都必須在 ansible 中完成

  • ansible 背景

    • 沒有客戶端
    • 配置器透過 ssh 連線到機器並在機器上執行指令碼
    • 您定義您希望叢集是什麼樣子，執行指令碼，它會一次性設定所有內容
    • 如果您在配置檔案中進行一次更改，ansible 會重新執行所有內容（這並不總是可取的）
    • 使用 jinja2 模板

  • 使用最少的軟體建立機器，然後使用 ansible 使該機器達到可執行狀態

    • 設定所有附加元件

  • 消除了配置器 shell 指令碼

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

    • CentOS 和一些軟體包
    • 重新部署到叢集需要 25 秒

  • 提問 Eric

    • 提供商特定的配置在哪裡？

      • ansible 配置中唯一的網路設定是 flannel；您可以關閉它

    • 關於 init vs. systemd 呢？

      • 應該能夠在程式碼中支援，沒有任何麻煩（尚未實現）

  • 討論

    • 為什麼不將設定工作推送到容器或 kubernetes 配置中？

      • 要引導叢集，只需放置一個 kubelet 和一個清單

    • 執行 kubelet 和配置網路應該是唯一需要做的事情。我們可以建立一個預配置的機器映象，減去資料包（證書等）

      • ansible 指令碼會在未安裝的情況下安裝 kubelet 和 docker

    • 每個作業系統（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）

  • 下週我們將討論補丁釋出的節奏

• ←上一篇
• 下一篇→