APIServer dry-run和kubectl diff

• 2019 年 12 月 5 日
• 筆記

作者：Antoine Pelisse（Google Cloud，@apelisse）

聲明式（Declarative）配置管理，也稱為配置即程式碼（configuration-as-code），是Kubernetes的關鍵優勢之一。它允許用戶提交所需的集群狀態，並跟蹤不同的版本，通過CI/CD管道改進審計和自動化。Apply工作組正在努力修復一些差距，而很高興地宣布Kubernetes 1.13將伺服器端干運行（server-side dry-run）和kubectl diff升級到beta。這兩個特性是Kubernetes聲明模型的重大改進。

挑戰

為了在Kubernetes保持無縫的聲明體驗，仍然缺少一些部分，我們試圖解決其中的一些問題：

• 雖然編譯器（compiler）和品質器（linter）可以很好地檢測程式碼拉取請求中的錯誤，但Kubernetes配置文件缺少良好的驗證。現有的解決方案是運行kubectl apply –dry-run，但這會運行本地（local）干運行而不與伺服器通訊：它沒有伺服器驗證，也沒有通過驗證許可控制器（validating admission controller）。例如，自定義資源名稱僅在伺服器上驗證，因此本地干運行無濟於事。
• 由於多種原因，很難知道伺服器將如何應用你的對象：
  • 默認會將某些欄位設置為潛在的意外值，
  • 變異（mutating）webhook可能會設置欄位或更改某些值，
  • 修補（patch）和合併（merge）可能會在對象產生令人驚訝的效果和導致意外。例如，一旦合併，很難知道列表將如何排序。

工作組試圖解決這些問題。

APIServer dry-run

實施APIServer dry-run來解決這兩個問題：

• 它允許對apiserver的個別請求標記為「dry-run」，
• apiserver保證干運行請求不會被持久存儲，
• 請求仍然作為典型請求處理：欄位是默認的，對象是經過驗證的，它通過驗證准入鏈（validation admission chain），並通過變異准入鏈（mutating admission chain），然後最終的對象像往常一樣返回給用戶，沒有被持久存儲。

雖然動態准入控制器（dynamic admission controller）不應對每個請求產生副作用，但只有當所有準入控制器（admission controller）明確宣布它們沒有任何干運行副作用時，才會處理干運行請求。

如何啟用它

通過功能門（feature-gate）啟用伺服器端干運行。現在該功能在1.13中是Beta，默認情況下應該啟用，但仍然可以使用kube-apiserver –feature-gates DryRun=true啟用/禁用功能。

如果你有動態准入控制器，則可能必須將它們修復為：

• 當webhook請求中指定dry-run參數時，刪除任何副作用，
• 在admissionregistration.k8s.io/v1beta1.Webhook對象的sideEffects欄位中指定，指示該對象在干運行上沒有副作用。

如何使用它

你可以使用kubectl apply –server-dry-run在kubectl觸發該功能，它將使用dryRun標誌裝飾請求，並返回應用的對象，如果失敗則返回錯誤。

Kubectl diff

APIServer dry-run很方便，因為它可以讓你看到如何處理對象，但如果對象很大，很難準確識別出改變了什麼。kubectl diff可以滿足這方面的需要，通過顯示當前「實時」對象與新「干運行」對象之間的差異。只關注對對象所做的更改，伺服器如何合併這些更改，以及變異webhook如何影響輸出，這非常方便。

如何使用它

kubectl diff希望與kubectl apply儘可能相似：kubectl diff -f some-resources.yaml將顯示yaml文件中資源的差異。甚至可以使用KUBECTL_EXTERNAL_DIFF環境變數來使用他們選擇的diff程式，例如：

KUBECTL_EXTERNAL_DIFF=meld kubectl diff -f some-resources.yaml

接下來是什麼

工作組仍在忙著改進其中一些事情：

• 伺服器端應用試圖通過向欄位添加所有者語義來改進應用（apply）方案！它還將改善對CRD和工會的支援！
• diff中缺少某些kubectl apply可能很有用的功能，例如按標籤過濾或顯示已修剪資源的功能。
• 最終，kubectl diff將使用伺服器端應用！