從 Beta 走向未來
在 Kubernetes 中，功能遵循定義的生命週期。首先，它可能只是一個感興趣的開發人員的一點點想法。然後，它可能在線上討論中被勾勒出來，就像在咖啡館餐巾紙上畫草圖一樣。這種粗略的工作通常會成為一份Kubernetes 增強提案（KEP），然後通常會轉化為程式碼。
對於 Kubernetes v1.20 及更高版本，我們正致力於幫助這些程式碼升級為穩定功能。
我提到的生命週期執行如下：
通常，alpha 功能預設不啟用。您需要透過設定功能門來啟用它們；通常，透過在每個使用該功能的元件上設定命令列標誌。
（如果您透過 AKS、EKS、GKE 等託管服務產品使用 Kubernetes，那麼執行該服務的供應商可能已經為您決定了哪些功能門已啟用）。
將現有 alpha 功能升級到 beta 階段有一個明確的流程。這很重要，因為**beta 功能預設啟用**，並且功能標誌仍然存在，以便叢集操作員可以根據需要選擇退出。
一套類似但更徹底的升級標準管理著向通用可用性（GA）的過渡，也稱為“穩定版”。GA 功能是 Kubernetes 的一部分，並承諾在當前主要版本中保持不變。
預設啟用 beta 功能可以讓 Kubernetes 及其貢獻者獲得寶貴的實際反饋。然而，存在激勵機制不匹配的問題。一旦功能預設啟用，人們就會使用它。即使可能存在一些細節需要解決，Kubernetes 的 REST API 和約定工作方式意味著任何未來的穩定 API 都將與最新的 beta API 相容：當 beta 功能升級到 GA 時，您的 API 物件不會停止工作。
特別是對於 API 及其資源，將功能從 beta 遷移到 GA 的激勵機制遠不如從 alpha 遷移到 beta 那麼強烈。希望某個特定功能的供應商有充分理由幫助將程式碼開發到預設啟用功能的程度，而在此之後，其過程就不那麼明確了。
KEP 不僅僅追蹤程式碼改進。本質上，任何需要向更廣泛社群傳達的內容都值得一份 KEP。也就是說，大多數 KEP 都涵蓋 Kubernetes 功能（以及實現這些功能的程式碼）。
您可能知道 Ingress 已經在 Kubernetes 中存在一段時間了，但您是否意識到它實際上是在 2015 年才進入 beta 階段？為了推動事情向前發展，Kubernetes 架構特別興趣小組（SIG）有了一個新的方法。
避免永久 Beta
對於 Kubernetes REST API，當新功能的 API 達到 beta 階段時，計時器就開始了。這個 beta 質量的 API 現在有**三個版本**（大約九個日曆月）來決定：
- 達到 GA 並棄用 beta 版本，或者
- 釋出一個新的 beta 版本（並棄用之前的 beta 版本）。
需要明確的是，此時**只有 REST API 受影響**。例如，*APIListChunking* 是一個 beta 功能，但它本身不是一個 REST API。目前還沒有計劃自動棄用 *APIListChunking* 或任何其他非 REST API 的功能。
如果一個 Beta API 在三個 Kubernetes 版本之後仍未升級到 GA，那麼下一個 Kubernetes 版本將棄用該 API 版本。REST API 沒有選項可以在釋出視窗後的第一個 Kubernetes 版本之後繼續停留在相同的 Beta 版本。
這對你意味著什麼
如果您正在使用 Kubernetes，那麼您很有可能正在使用 Beta 功能。正如我所說，這樣的功能有很多。除了 Ingress，您可能還在使用 CronJob，或者 PodSecurityPolicy，或者其他功能。更有可能的是，您正在執行的控制平面至少有一個 Beta 功能已啟用。
如果您正在使用或生成使用 Beta API（如 Ingress）的 Kubernetes 清單，您需要計劃修改這些清單。當前的 API 將按照計劃（我前面提到的 9 個月）被棄用，再過 9 個月後，這些棄用的 API 將被移除。屆時，為了與 Kubernetes 保持同步，您應該已經完成了遷移。
這對 Kubernetes 貢獻者意味著什麼
這裡的動機似乎很明確：讓功能穩定。保證 Beta 功能將被棄用，這提供了一個相當大的激勵，讓希望該功能的人們繼續努力，直到程式碼、文件和測試都準備好讓該功能升級到穩定版，並得到 Kubernetes 多個版本在實際使用中證據的支援。
這對生態系統意味著什麼
在我看來，這些看似嚴厲的措施非常有意義，並且將對 Kubernetes 有益。透過一項適用於所有不同特別興趣小組（SIG）的規則來棄用現有 API，有助於避免停滯並鼓勵修復。
假設一個 API 進入 Beta 階段，然後實際經驗表明它並不正確——也就是說，從根本上講，該 API 存在缺陷。在 9 個月的倒計時中，相關人員有能力和理由修改併發佈一個能夠解決這些問題的 API。任何想要繼續使用已棄用 API 的人都可以這樣做——Kubernetes 是開源的——但他們的需求不應該阻礙該功能的進展。