所述Kubernetes檔案宣告如下關于metadata.resourceVersion一個K8S物件的
您不能假設資源版本是數字的或可整理的。API 客戶端只能比較兩個資源版本的相等性（這意味著您不得比較資源版本的大于或小于關系）。
我很高興我讀到了這篇文章，因為我正準備做它所說的不做的事情（比較>或<檢查一致性）。
我的問題是：為什么不呢？為什么不允許客戶這樣做？
編輯：澄清一下，這個問題所指的資源版本是metadata.resourceVersionK8s 物件的，而不是apiVersion.
根據我的經驗，資源版本是一個整數，在時間上單調遞增（每次修改資源時遞增）。似乎檔案說這不是保證。
uj5u.com熱心網友回復：
將此作為社區 wiki 發布，請隨意編輯和擴展。
資源版本
我認為最正確的答案是：
Kubernetes 利用資源版本的概念來實作樂觀并發。所有 Kubernetes 資源都有一個“resourceVersion”欄位作為其元資料的一部分。此 resourceVersion 是一個字串，用于標識物件的內部版本，客戶端可以使用它來確定物件何時發生更改。當記錄即將更新時，會根據預先保存的值檢查其版本，如果不匹配，更新將失敗并顯示 StatusConflict（HTTP 狀態代碼 409）。
每次修改物件時，服務器都會更改資源版本。如果在 PUT 操作中包含 resourceVersion，系統將通過驗證 resourceVersion 的當前值與指定值匹配來驗證在讀/修改/寫周期期間沒有其他成功的資源突變。
resourceVersion 目前由 etcd 的 modifiedIndex 支持。但是，需要注意的是，應用程式不應依賴于 Kubernetes 維護的版本控制系統的實作細節。我們將來可能會更改 resourceVersion 的實作，例如將其更改為時間戳或按物件計數器。
客戶端知道 resourceVersion 的預期值的唯一方法是從服務器接收它以回應先前的操作，通常是 GET。這個值必須被客戶端視為不透明的，并且未經修改地傳遞回服務器。客戶端不應該假設資源版本在命名空間、不同型別的資源或不同的服務器之間具有意義。目前，resourceVersion 的值設定為匹配 etcd 的排序器。您可以將其視為 API 服務器可用于對請求進行排序的邏輯時鐘。但是，我們預計 resourceVersion 的實作會在未來發生變化，例如在我們按種類和/或命名空間或埠到另一個存盤系統對狀態進行分片的情況下。
由于此邏輯有可能被更改，因此最好遵循 kubernetes 開發人員提供的內容，因為他們比其他任何人都更了解進一步的更改。
同樣在 API 檔案中，它說它是一種string型別，而不是integer或date，請參見此處。
請查找有關并發控制和一致性的更多詳細資訊。
api版本
簡單而簡短的答案 - 因為版本不是數字，有時它可以非常顯著地改變。
以下是我知道/使用的幾個示例，它們將顯示差異：
ingress：以前是 -
extensions/v1beta1實際版本——
networking.k8s.io/v1istio目前使用兩個版本：networking.istio.io/v1alpha3和networking.istio.io/v1beta1
所以在這一點上比較>還是<不行。更精確的方法是檢查 API 版本是否相同。
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/367695.html
標籤：Kubernetes