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

核心工作負載 API GA

作者：Kenneth Owens (Google) |

DaemonSet、Deployment、ReplicaSet 和 StatefulSet 已正式發布 (GA)

編輯註記：我們很高興宣布核心工作負載 API 在 Kubernetes 1.9 中正式發布 (GA)！這篇 Kenneth Owens 的部落格文章回顧了核心工作負載如何從起源發展到 GA，揭示了 1.9 版本中的變更，並闡述了您對未來發展的期望。

在開始時…

當時有 Pod，緊密耦合的容器，它們共享資源需求、網路、儲存和生命週期。Pod 非常有用，但事實證明，使用者希望無縫、可重現且自動地建立許多相同的 Pod 副本，因此我們建立了 ReplicationController。

複製是一個進步，但使用者真正需要的是更高層次的複製 Pod 編排。他們想要滾動更新、回滾和滾動覆蓋。因此 OpenShift 團隊建立了 DeploymentConfig。DeploymentConfigs 也很有用，OpenShift 使用者也很滿意。為了讓所有 OSS Kubernetes 使用者都能分享這份喜悅，並利用 基於集合的標籤選擇器，ReplicaSet 和 Deployment 被添加到 extensions/v1beta1 群組版本中，為所有 Kubernetes 使用者提供滾動更新、回滾和滾動覆蓋。

這在很大程度上解決了在 Kubernetes 上編排容器化 12 要素應用程式的問題，因此社群將注意力轉向了另一個不同的問題。將 Pod 複製 <n> 次並不是適用於叢集中所有問題的正確方法。有時，您需要在每個節點或節點子集上執行 Pod（例如，共享的 side car，如日誌傳輸器和指標收集器、Kubernetes 附加元件和分散式檔案系統）。當時最先進的方法是 Pod 與 NodeSelectors 或靜態 Pod 結合使用，但這很笨拙。在使用過 Deployments 提供的自動化便利性後，使用者要求此類應用程式也具有相同的功能，因此 DaemonSet 也被添加到 extension/v1beta1 中。

有一段時間，使用者很滿意，直到他們認為 Kubernetes 需要能夠編排的不僅僅是 12 要素應用程式和叢集基礎架構。無論您的架構是 N 層、面向服務還是面向微服務，您的 12 要素應用程式都依賴具狀態工作負載（例如，RDBMS、分散式鍵值儲存和訊息佇列）來為終端使用者和其他應用程式提供服務。這些具狀態工作負載可能具有可用性和持久性要求，這些要求只能透過分散式系統實現，而使用者已準備好使用 Kubernetes 來編排整個堆疊。

雖然 Deployments 非常適合無狀態工作負載，但它們並未為分散式系統的編排提供正確的保證。這些應用程式可能需要穩定的網路身分、有序的、循序的部署、更新和刪除，以及穩定、持久的儲存。PetSet 被添加到 apps/v1beta1 群組版本中，以解決此類應用程式的問題。不幸的是，我們在命名時考慮不周，而且，由於我們始終努力成為一個包容性的社群，我們將類型重新命名為 StatefulSet。

最後，我們完成了。

…還是沒有？

Kubernetes 1.8 和 apps/v1beta2

Pod、ReplicationController、ReplicaSet、Deployment、DaemonSet 和 StatefulSet 統稱為核心工作負載 API。我們終於可以編排所有的東西了，但 API 介面分散在三個群組中，存在許多不一致之處，並讓使用者懷疑每個核心工作負載類型的穩定性。現在是停止添加新功能，專注於一致性和穩定性的時候了。

Pod 和 ReplicationController 處於 GA 穩定性，即使您可以在 Pod 中執行工作負載，它也是屬於核心的原子性基本元件。由於 Deployments 是管理無狀態應用程式的建議方式，移動 ReplicationController 將毫無意義。在 Kubernetes 1.8 中，我們將所有其他核心工作負載 API 類型（Deployment、DaemonSet、ReplicaSet 和 StatefulSet）移動到 apps/v1beta2 群組版本。這帶來了更好的 API 介面聚合的好處，並允許我們打破向後相容性以修復不一致之處。我們的計畫是在我們對其完整性感到滿意時，將這個新介面整體且按原樣提升到 GA。此版本中的修改（也在 apps/v1 中實作）如下所述。

Selector 預設值已被棄用

在 apps 和 extensions 群組的先前版本中，當核心工作負載 API 類型的標籤選擇器未指定時，預設為從該類型的範本標籤產生的標籤選擇器。

這與戰略合併修補程式和 kubectl apply 完全不相容。此外，我們發現從同一物件的另一個欄位的值預設欄位的值通常是一種反模式，並且對於用於編排工作負載的 API 物件尤其危險。

不可變的 Selector

Selector 變更雖然允許一些用例，例如可升級的 Deployment Canary 版本，但我們的 workload controller 無法優雅地處理，而且我們始終 強烈警告使用者不要這樣做。為了提供一致、可用且穩定的 API，workloads API 中所有類型的 Selector 都被設為不可變。

我們認為有更好的方法來支援可升級的 Canary 版本和編排的 Pod 重新標記等功能，但是，如果受限的 selector 變更是我們使用者需要的必要功能，我們可以在未來放寬不可變性，而不會破壞向後相容性。

可升級的 Canary 版本、編排的 Pod 重新標記和受限的 selector 可變性等功能的開發是由我們使用者的需求訊號驅動的。如果您目前正在修改核心工作負載 API 物件的 selector，請透過 GitHub issue 或參與 SIG apps 告訴我們您的使用案例。

預設滾動更新

在 apps/v1beta2 之前，某些類型將其更新策略預設為 RollingUpdate 以外的其他策略（例如，app/v1beta1/StatefulSet 預設使用 OnDelete）。我們希望在將 RollingUpdate 作為預設更新策略之前，確信 RollingUpdate 運作良好，並且我們無法在已發布的版本中更改預設行為，而不會違反我們對向後相容性的承諾。在 apps/v1beta2 中，我們預設為所有核心工作負載類型啟用了 RollingUpdate。

CreatedBy 註解已被棄用

「kubernetes.io/created-by」是垃圾收集之前遺留下來的舊功能。使用者應使用物件的 ControllerRef 從其 ownerReferences 判斷物件所有權。我們在 1.8 版本中棄用了此功能，並在 1.9 版本中將其移除。

Scale 子資源

Scale 子資源已添加到 apps/v1beta2 中所有適用的類型（DaemonSet 根據其節點選擇器進行擴展）。

Kubernetes 1.9 和 apps/v1

在 Kubernetes 1.9 中，正如計畫的那樣，我們將整個核心工作負載 API 介面提升到 apps/v1 群組版本中的 GA。我們做了一些更多的更改以使 API 一致，但 apps/v1 大部分與 apps/v1beta2 相同。現實情況是，大多數使用者已經將核心工作負載 API 的 Beta 版本視為 GA 有一段時間了。任何仍然使用 ReplicationControllers 並迴避 DaemonSets、Deployments 和 StatefulSets 的人，由於感覺缺乏穩定性，都應該計畫將他們的工作負載（在適用的情況下）遷移到 apps/v1。升級期間所做的細微更改如下所述。

垃圾收集預設為刪除

在 apps/v1 之前，DaemonSet、Deployment、ReplicaSet 或 StatefulSet 中 Pod 的預設垃圾收集策略是孤立 Pod。也就是說，如果您刪除其中一種類型，除非明確指定級聯刪除，否則它們擁有的 Pod 將不會自動刪除。如果您使用 kubectl，您可能沒有注意到這一點，因為這些類型在刪除之前會縮放到零。在 apps/v1 中，所有核心工作負載 API 物件現在預設情況下，當其擁有者被刪除時，它們也會被刪除。對於大多數使用者來說，此變更是透明的。
狀態條件

在 apps/v1 之前，只有 Deployment 和 ReplicaSet 在其 Status 物件中具有 Conditions。為了保持一致性，所有物件或沒有物件都應該具有條件。經過一番辯論，我們認為 Conditions 是有用的，我們將 Conditions 添加到 StatefulSetStatus 和 DaemonSetStatus。StatefulSet 和 DaemonSet 控制器目前未填充它們，但我們可能會選擇在未來透過此機制向客戶端傳達條件。

Scale 子資源已遷移到 autoscale/v1

我們最初在 apps 群組中添加了一個 scale 子資源。這是與自動縮放整合的錯誤方向，而且在某個時候，我們希望使用自訂指標來自動縮放 StatefulSets。因此，apps/v1 群組版本使用 autoscaling/v1 scale 子資源。

遷移和棄用

您現在可能最常問的問題是：「我遷移到 apps/v1 的路徑是什麼，我應該多久計畫遷移一次？」在 Kubernetes 1.9 中，apps/v1 之前的所有群組版本都已棄用，所有新程式碼都應針對 apps/v1 開發，但是，如上所述，我們的許多使用者都將 extensions/v1beta1 視為 GA。我們意識到這一點，並且我們的 棄用政策 中的最低支援時間表只是最低限度。

在未來的版本中，在完全移除任何群組版本之前，我們將在 API Server 中預設停用它們。屆時，您仍然可以使用該群組版本，但您必須明確啟用它。我們還將提供實用程式來將 API 物件的儲存版本升級到 apps/v1。請記住，核心工作負載類型的所有版本都是雙向可轉換的。如果您現在想要手動更新核心工作負載 API 物件，您可以使用 kubectl convert 在群組版本之間轉換 manifest。

下一步是什麼？

核心工作負載 API 介面是穩定的，但它仍然是軟體，而軟體永遠不會完成。我們經常在穩定的 API 中添加功能以支援新的使用案例，我們也可能會為核心工作負載 API 執行此操作。GA 穩定性表示我們添加的任何新功能都將與現有的 API 介面嚴格向後相容。從現在開始，我們所做的任何事情都不會破壞我們的向後相容性保證。如果您希望參與 API 此部分的演進，請隨時參與 GitHub 或參與 SIG Apps。