這篇文章已經超過一年。較舊的文章可能包含過時的內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

每週 Kubernetes 社群線上交流會議記錄 - 2015年4月10日

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

議程

  • kubectl 工具、滾動更新、部署、命令式指令。
  • 向下 API / env. 替換，以及可能的前提條件/依賴關係。

會議記錄

1. kubectl 改善

  • 使其更易於使用，完成滾動更新，更高等級的部署概念。

  • 滾動更新

    • 今天

      • 可以用檔案指定的另一個 rc 替換一個 rc。

      • 沒有對回滾的明確支援，可以透過對舊版本進行滾動更新來做到。

      • 我們在 rcs 上保留註解以追蹤所需的 # 實例；對於回滾情況將無法運作，因為它不是對稱的。

    • 需要不可變的映像檔 ID；目前沒有對應於映像檔、版本的 uuid，因此如果有人在上面推送，您將重新拉取它；在 API 伺服器中，我們應該將映像檔轉換為 uuid（盡可能靠近邊緣）。

    • 如果可以自動產生新的 rc 而不是讓使用者更新它會很好（例如，當變更容器的映像檔標籤時等等；目前需要變更 rc 名稱和標籤值；可以自動產生新的 rc）。

    • 將 rcs 視為寵物而不是牛。

    • 「將我從 v1 滾動到 v2」（或從 v2 滾動到 v1） - 對於大多數人來說足夠了。不關心過去發生的事情的記錄。

    • 我們正在提供 ansible 可以呼叫以執行某些操作的模組。

    • 如何追蹤多個模板；今天我們使用多個 RCs。

    • 如果我們有一個部署控制器；部署配置產生執行滾動更新的 pos；觸發器是映像檔儲存庫的基於等級的更新。

    • 替代的短期提案：建立一個新的 rc 作為舊 rc 的克隆，使用計數進行調整，使新的 rc 成為舊 rc，反之亦然，將先前命名的 rc（寵物）降至零並使用新的模板將其重新啟動（這非常類似於 Borg 進行工作更新的方式）。

      • 如果我們無論如何都想要進行部署，那麼這是否值得？是的，因為我們已經有很多概念；需要簡化。

    • 部署控制器追蹤多個模板，這是滾動更新和 Canary 發布所需的。

    • 新事物的唯一原因是將流程移至伺服器而不是客戶端嗎？

    • 可能不需要將其設為 API 物件；應該提供一種體驗，使其不是 API 物件，而只是客戶端方面的一些東西。

    • 現在需要一種簡化的體驗，因此需要在客戶端方面進行，因為物件不會在 1.0 之前登陸。

    • 為只想與 RCs 互動的人提供簡化的體驗。

    • 回滾如何運作：ctrl-c，滾動 v2 v1。回滾模式可能存在於人的腦海中。兩種回滾：我處於穩定狀態，想要返回，並且我有一個 Canary 部署並且按下了 ctrl-c，我如何擺脫 Canary 部署（例如，新的失敗）。ctrl-c 可能不起作用。刪除 Canary 控制器及其 Pod。希望有一個命令也可以刪除 Pod（有 -- kbectl stop）。不重複使用名稱的論點：當您向前移動時，您可以停止新事物，並且沒問題，而如果您替換了舊事物並且您建立了一個副本，如果您按下 ctrl-c，您沒有任何可以停止的東西。但是您可以等到最後再翻轉名稱，使用命名約定，以便了解正在發生的事情等等。

    • 兩種不同的體驗：(1) 我正在使用版本控制，有上週的版本歷史，本週滾動推出，使用兩個檔案進行滾動更新 -> 建立 v2，??? v1，沒有寵物 - 進入了版本控制的世界，在其中有累積的歷史記錄；(1) 命令式 kubectl v1 v2，其中系統處理細節，這就是我們使用快照模式的地方。

  • 其他命令式指令

    • run-container（或僅僅 run）：在命令行上指定指令，使其更類似於 docker run；但不是多容器 Pod。

    • --forever vs. not（透過簡單指令進行一次性執行）。

    • 希望它可以互動 - run -it 並且在叢集中運行，但是您有一個與您的進程互動的終端機。

    • 命令行參數如何運作。可以多次說 --image。cobra 會支援嗎？在 openshift 中，我們有巧妙的語法將參數分組在一起。不適用於真正的結構化參數。

    • 替代方案：建立 Pod；新增容器 新增容器 ...；運行 Pod -- 構建並且直到 'run pod' 才運行物件。

      • -- 用於分隔容器參數。

      • 建立一個 Pod，在運行之前對其進行變異 - 就像初始化器模式。

  • 種類探索

    • 如果我們有 run 並且有時它會建立一個 rc，有時則不會，如果使用者想要刪除他們使用 run 建立的任何東西，他們如何知道要刪除什麼。

    • bburns 有一個提案：如果您執行像 stop、delete 這樣的指令，則不要指定種類；讓 kubectl 找出它。

    • 替代方案：允許您定義從名稱到一組資源類型的別名，例如，刪除所有將遵循該別名（所有可能意味著某個命名空間中的所有內容，或者未作用域，等等） - 有人明確地將某些東西新增到集合中，而不是像節點那樣意外地出現。

    • 希望看到擴展以允許工具指定它們自己的別名（不僅僅是使用者）；例如，resize 可以說我可以處理 RCs，delete 可以說我可以處理所有東西，等等，因此我們可以自動執行這些操作而無需使用者指定任何東西。但是正確的機制。

    • resourcebuilder 具有執行那種擴展的概念，具體取決於我們如何適應目標指令。例如，如果您想要將磁碟區新增到 Pod 和 rcs，則需要找到 Pod 模板並變更它。有搜尋部分（刪除 nginx -> 您必須找出它們指的是哪個物件），然後指令可以說我得到了一個 Pod，我知道如何處理 Pod。

    • 替代的啟發式方法：如果所有指令的預設目標都是部署怎麼辦。kubectl run -> 部署。工作量太大，更容易清理現有的 CLI。為此敞開大門。巨集物件是可以的，但是要使其運作需要做更多的工作。最終會希望使用索引來提高效率。可以更多地依賴 swagger 來告訴我們類型。

2. paul/向下 api：env 替換

  • 建立臨時 env var 類似於字串，例如，k8s_pod_name 將被系統在物件中替換。
  • 允許人們建立引用 k8s 物件欄位的 env var，而無需從其容器內部查詢 api；在某些情況下，可以從其容器內部查詢 api（例如，傳遞物件名稱、命名空間）；例如，Sidecar 容器需要它才能從 api 伺服器拉取東西。
  • 另一個類似的提案：不是像名稱這樣的 env var，而是使用類似 JSON 路徑的語法來引用物件欄位名稱；例如，$.metadata.name 引用目前物件的名稱，也許有一些語法可以引用相關物件，例如 Pod 所在的節點。類似 JSON 路徑的語法的優點是它不太臨時。缺點是您只能引用物件的欄位。
  • 對於這兩者，如果您填充了 env var，那麼您會有一個缺點，即欄位僅在建立容器時設定。但至少耦合程度 - 現成的容器，容器不需要知道如何與 k8s API 通訊。將 k8s 概念保留在控制平面中。
  • 我們正在收斂到類似 JSON 路徑的方法。但是需要原型或至少更深入的提案來演示。
  • paul：一個變體是對於 env var，除了值欄位之外，還有不同的來源，您可以在其中插入例如用於描述物件欄位的語法；另一個來源將是描述有關主機資訊的來源。有部分原型。圖像中的內容與控制平面之間的清晰分離。可以使用來源想法作為磁碟區外掛程式。
  • 使用案例：為 Sidecar 容器提供聯絡 API 伺服器的資訊。
  • 使用案例：傳遞唯一標識符或諸如使用 UID 作為唯一標識符之類的東西。
  • clayton：對於每個 Pod 都可以使用的 Rocket 或 GCE 元資料服務，用於更複雜的事情；大多數容器都想找到服務的端點。

3. 前提條件/依賴關係

  • 當你建立會與服務溝通的 Pod 時，服務的環境變數只有在你以正確的順序建立物件時才會被填入。 如果你使用 DNS，這個問題比較不嚴重，但有些應用程式很脆弱。 如果它們所依賴的服務不存在，可能會崩潰，可能需要很長時間才能重新啟動。 提案是加入先決條件 (preconditions)，阻止 Pod 啟動，直到它們所依賴的物件存在為止。
  • 如果我們要求人們宣告他們想要哪些環境變數，或者在 Pod、RC 或物件層級建立依賴機制，來說明這個物件在另一個東西存在之前不會啟動，就可以自動推斷。
  • 可以使用事件 Hook 嗎？ 只有應用程式擁有者知道他們的依賴關係或服務何時準備好提供服務。
  • 一個提案是使用 pre-start Hook。 另一個是 precondition probe (先決條件探測) - pre-start Hook 可以進行探測。 當我訪問此服務位址或 IP 時，是否有任何回應，然後探測失敗。 可以在 pre-start Hook 中實作。 比 post-start 更有用。 這是 rkt 規格的一部分。 具有階段 0、1、2。 今天在 Docker 中很難做到，但在 Rocket 中很容易。
  • 容器中的 pre-start Hook：如果使用 prestart Hook 實作，容器可能會被鎖定，直到滿足某些任意條件，這將如何影響 Readiness Probe？ 如果你有 Hook，kubelet 執行 Readiness/Liveness Probe 時必須有一些補償。 Systemd 對於程序生命週期的各個階段都有超時設定。
  • 如果我們採用容器 pre-start 的黑盒模型，這是有道理的； 如果容器規格變得更像是 Systemd 這種對程序模型有更多描述性的規格，那麼 kubelet 是否需要了解更多關於程序模型的資訊才能做正確的事情。
  • 理想情況下，從容器內部發送訊息來說明我已完成所有 pre-start 動作。 Systemd 的 sdnotify 可以做到這一點。 你告訴 Systemd 你已完成，它會將你已啟動的訊息傳達給其他依賴項。
  • 但是... 有人可以直接在其容器內部實作先決條件。 這樣可以更輕鬆地調整應用程式，而無需更改其映像檔。 另一種選擇是讓他們自己制定一種模式，但我們不為他們做。