我們開始使用 Helm 管理 Kubernetes 資源，並且我們有一些使用者習慣使用kubectl edit.我們希望 Helm 在每次執行時清理已部署的資源，使它們恢復到已知的良好狀態。
我發現這helm upgrade不會覆蓋我的 ConfigMap。相反，它合併了已部署的 ConfigMap 和 Helm 模板之間的屬性，為我提供了模板化 ConfigMap 的片段和手工編輯的 ConfigMap 的片段。如果 Helm ConfigMap 範本中沒有更改，則 Helm 會更改不是將我部署的 ConfigMap 的任何部分重置回已知良好的狀態。
如何指示 Helm 始終將整個 Kubernetes 資源重設為 Helm 模板化版本？
答案1
這不是 Helm 的設計目標，而且仍然不是。操縱不是由 Helm 創建的對象，或者忽略對其“控制”下的對象的帶外更改，不屬於 Helm 的權限範圍 - 這是一個使 Helm 與可能更改清單的其他系統兼容的功能，並且使Helm 可以安全使用。請記住，它是一個 YAML 渲染系統，而不是像 Puppet 或 SaltStack 這樣的設定管理系統。它不“強制”配置。
如果您希望完成您所描述的行為，您可以先刪除有問題的對象，然後再使用 Helm 重新建立它們。您可以使用 Kubernetes 命名空間來可靠地完成此操作，方法是為每個圖表提供自己的命名空間，並在圖表安裝之前以「硬重置」的形式刪除命名空間。
或阻止那些習慣於編輯清單的使用者kubectl這樣做，而是引導他們將這些變更推送到圖表或值中。如果需要進行更改，則放棄這些更改似乎並不合理 - 這正是 Helm 首先對清單執行三向合併操作的原因。我理解在單點編排中保留配置的願望，但不要指望透過不使用單點編排來實現這一點。
當將更高層級的編排實踐應用於習慣於較低階編排方法的團隊時，這個問題總是會出現，並且在概念上不受 Helm 的限制。 Helm 擅長透過執行合併操作來優雅地處理這種情況，但會導致編排方法的功能混亂（至少它不會破壞事物或簡單地失敗）。首先不要製造混亂，或將混亂限制在臨時環境中，然後將其收集到 Helm 圖表中進行生產。