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

核心工作負載 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。DeploymentConfig 也很有用，OpenShift 使用者對此很高興。為了讓所有開源 Kubernetes 使用者都能分享這份喜悅，並利用 基於集合的標籤選擇器，ReplicaSet 和 Deployment 被新增到 extensions/v1beta1 組版本，為所有 Kubernetes 使用者提供滾動更新、回滾和翻轉功能。

這在很大程度上解決了在 Kubernetes 上編排容器化 12 因素應用程式的問題，因此社群將注意力轉向了另一個問題。將 Pod 複製 次並非叢集中所有問題的正確解決方案。有時，您需要在每個節點或節點子集上執行 Pod（例如，像日誌轉發器和指標收集器這樣的共享邊車、Kubernetes 附加元件和分散式檔案系統）。現有的技術是 Pod 與 NodeSelector 或靜態 Pod 結合，但這很不方便。在習慣了 Deployment 提供的自動化便利性之後，使用者要求為這類應用程式提供相同的功能，因此 DaemonSet 也被新增到 extension/v1beta1 中。

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

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

最後，我們完成了。

……或者我們還沒有？

Kubernetes 1.8 和 apps/v1beta2

Pod、ReplicationController、ReplicaSet、Deployment、DaemonSet 和 StatefulSet 統稱為核心工作負載 API。我們終於可以編排所有事物了，但 API 介面分散在三個組中，存在許多不一致之處，讓使用者對每個核心工作負載型別的穩定性感到疑惑。是時候停止新增新功能，轉而關注一致性和穩定性了。

Pod 和 ReplicationController 已達到 GA 穩定級別，儘管您可以在 Pod 中執行工作負載，但它是一個屬於核心的原子原語。由於 Deployment 是管理無狀態應用程式的推薦方式，因此移動 ReplicationController 將毫無意義。在 Kubernetes 1.8 中，我們將所有其他核心工作負載 API 型別（Deployment、DaemonSet、ReplicaSet 和 StatefulSet）移至 apps/v1beta2 組版本。這樣做的好處是可以在 API 介面上提供更好的聚合，並允許我們破壞向後相容性以修復不一致之處。我們的計劃是在我們對其完整性感到滿意時，將這個新介面整體原樣提升到 GA 級別。此版本中的修改（也在 apps/v1 中實現）將在下面描述。

選擇器預設值棄用

在 apps 和 extensions 組的早期版本中，當未指定時，核心工作負載 API 型別的標籤選擇器會預設生成自型別模板的標籤。

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

不可變選擇器

選擇器變動雖然允許某些用例，如可提升的 Deployment 金絲雀，但我們的工作負載控制器無法優雅地處理它，我們一直強烈建議使用者不要這樣做。為了提供一致、可用和穩定的 API，選擇器在工作負載 API 中的所有型別中都被設定為不可變。

我們相信有更好的方法來支援可提升的金絲雀和編排 Pod 重新貼標籤等功能，但是，如果受限的選擇器變動是使用者必需的功能，我們可以在未來放寬不可變性而不會破壞向後相容性。

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

預設滾動更新

在 apps/v1beta2 之前，某些型別的更新策略預設設定為 RollingUpdate 以外的值（例如，app/v1beta1/StatefulSet 預設使用 OnDelete）。我們希望在將 RollingUpdate 設定為預設更新策略之前，確保它能正常工作，並且我們無法在已釋出的版本中更改預設行為而不違反我們對向後相容性的承諾。在 apps/v1beta2 中，我們預設啟用了所有核心工作負載型別的 RollingUpdate。

createdBy 註解棄用

“kubernetes.io/created-by”是垃圾回收時代之前的遺留物。使用者應該使用物件的 ownerReferences 中的 ControllerRef 來確定物件所有權。我們在 1.8 中棄用了此功能，並在 1.9 中將其移除。

Scale 子資源

在 apps/v1beta2 中，所有適用型別都添加了 scale 子資源（DaemonSet 根據其節點選擇器進行伸縮）。

Kubernetes 1.9 和 apps/v1

在 Kubernetes 1.9 中，按計劃，我們將整個核心工作負載 API 表面提升到 apps/v1 組版本中的 GA 級別。我們做了一些額外的更改以使 API 保持一致，但 apps/v1 大體上與 apps/v1beta2 相同。實際情況是，大多數使用者已經將核心工作負載 API 的 Beta 版本視為 GA 一段時間了。任何仍在使用 ReplicationController 並因感知到的穩定性不足而避開 DaemonSet、Deployment 和 StatefulSet 的人，都應該計劃將其工作負載（在適用情況下）遷移到 apps/v1。在升級過程中所做的次要更改如下所述。

垃圾回收預設為刪除

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

在 apps/v1 之前，只有 Deployment 和 ReplicaSet 在其 Status 物件中具有 Conditions。為了保持一致性，所有物件或所有物件都不應具有 Conditions。經過一番爭論，我們認為 Conditions 很有用，因此我們將 Conditions 新增到了 StatefulSetStatus 和 DaemonSetStatus。StatefulSet 和 DaemonSet 控制器目前不填充它們，但我們將來可能會選擇透過此機制將 Conditions 傳遞給客戶端。

Scale 子資源遷移到 autoscale/v1

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

遷移和棄用

您現在可能最想問的問題是：“我如何遷移到 apps/v1？我應該多久計劃遷移一次？”從 Kubernetes 1.9 開始，所有早於 apps/v1 的組版本都已棄用，所有新程式碼都應針對 apps/v1 進行開發，但是，如上所述，我們的許多使用者將 extensions/v1beta1 視為 GA。我們意識到這一點，並且我們棄用策略中的最短支援時間線只是最短時間線。

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

接下來會發生什麼？

核心工作負載 API 介面是穩定的，但它仍然是軟體，而軟體永無止境。我們經常為穩定的 API 新增功能以支援新的用例，我們很可能也會為核心工作負載 API 這樣做。GA 穩定性意味著我們新增的任何新功能都將嚴格向後相容現有的 API 介面。從現在開始，我們所做的一切都不會破壞我們的向後相容性保證。如果您希望參與此 API 部分的演進，請隨時參與 GitHub 或參與 SIG Apps。