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將使用服務器端應用！
