你有同感嗎？關于開發，Kubernetes教會了我這些

筆者是一名全棧開發人員，DevOps技術和DevOps開發人員的想法對筆者來說一直是個謎。當筆者工作的公司推出了一個名為Gatekeeper的新指令行界面（CLI）應用程式時，筆者跳進了DevOps和Kubernetes的世界。現在，筆者對Kubernetes和DevOps管道有了更好的了解，并且可以更好地解釋CLI應用程式如何支援它們。

筆者已經做了五年多的全棧開發，幫助開發人員和DevOps工程師防止Kubernetes（K8s）的錯誤配置進入生産。

了解問題

想象一下：你度過了漫長的一周，正準備過周末。然而，在淩晨，你在有15個未接來電後醒來，有人一直給你打電話——你忘記在其中一個部署中添加記憶體限制，這導緻了其中一個容器中的記憶體洩漏，進而導緻所有Kubernetes節點的記憶體不足。

這怎麼會發生？DevOps團隊投入了大量精力來教育開發人員有關K8s和記憶體限制的重要性。

為了避免這樣的事故，你必須為理想的解決方案設定需求，并搜尋有助于防止錯誤配置影響叢集的平台和庫。實際需求可能因基礎設施而異，但這裡有一個很好的示例：

——對開發實施政策限制：在将資源應用到叢集之前實施限制的一種方法。

——啟用限制管理：在整個組織的專用位置靈活管理限制，使管理者能夠完全控制其所有系統。

——關于最佳實踐的教育：将DevOps團隊從審查、隔離和未來驗證所有可能的陷阱的持續需求中解放出來，這些陷阱都是自部署的一部分。

作為一名開發人員，工作就是為了解決現實生活中的問題，但有時環境會起到很大的作用。你必須首先了解問題是如何發生的，然後才能有效地解決它。

為什麼組織會采用K8？

DevOps工程師的角色是什麼？

最重要的是，為誰開發應用程式？

DevOps工程師做什麼？

起初，筆者對DevOps工程師角色知之甚少，對他們的技術幾乎一無所知，尤其是Kubernetes。筆者閱讀、研究并采訪了DevOps朋友，了解他們的工作和責任。筆者問了如下問題：

——你每天的目标是什麼？

——誰是你的客戶？

——工作日是什麼樣子？

幾個月後，筆者終于找到了答案。

令人驚訝的是，最有幫助的是承認我們隻是從不同的角度思考。DevOps工程師必須從最小的應用程式元件開始，然後在上面擴充和建構。

開發人員可以從同一個應用程式元件開始，但他們習慣于朝相反的方向思考：從高層級到軟體的位和位元組。開發人員将從伺服器、服務、函數、變量到記憶體配置設定的各個層剝離開來，直到到達最小的元件。這兩個角色都在同一個管道的不同邊工作。

如果解決方案是在管道的某個地方，雙方都哪些東西可以整合呢？

想知道這個解決方案是否應該成為管道的一部分，這讓筆者想到了DevOps和開發人員還有哪些共同點。筆者将開發人員的工作流程與DevOps工程師的工作流程進行了比較，意識到：我們都有政策。

為什麼不能總是依賴OPA？

開發人員和工程師都有努力維護的标準和最佳實踐。作為一名開發人員，筆者使用可靠且幹淨的代碼原則、單元測試和內建測試，并嘗試學習使用的每項技術的所有最佳實踐。

一天早上，筆者問CEO：“作為一名DevOps工程師，你的政策是什麼？你用什麼來建立和管理政策？”他回答：“OPA。”

什麼是OPA？

OPA是Open Policy Agent的首字母縮寫，就像一個超級引擎。你可以在其中寫入所有政策，然後在每個輸入中執行它，以檢查它是否違反任何政策，如果違反，以何種方式執行。OPA背後的主要思想是能夠将政策決策邏輯與政策執行使用解耦。

假設你在多服務架構中工作。例如，當微服務收到API請求（如授權）時，你可能必須做出政策決策。該邏輯基于組織中的預測規則，是以，在本例中，你可以将所有決策邏輯解除安裝并統一到一個專用服務：OPA。

如何使用OPA？

與OPA內建：如果服務是用Go編寫的，那麼你可以将OPA作為包嵌入到項目中。否則，你可以将OPA部署為主機級守護程式。

編寫和存儲政策：要在OPA中定義政策，你需要在Rego中編寫政策并将其發送給OPA。這樣，無論何時使用OPA執行政策，OPA都會根據這些政策查詢輸入。

請求政策評估：當應用程式需要做出政策決策時，它将使用JSON發送一個API查詢請求，該請求通過HTTP包含所有必需的資料。

當OPA不足時

正如你所看到的，OPA滿足了整個組織對政策管理和實施的需求，因為它是一個優秀的基于實用工具的工具，并提供了出色的基礎設施解決方案。然而，OPA也需要大量的提升和配置，一般來說，對于一家快速增長的公司來說，這太多了。

當涉及到K8s中的政策時，OPA并不是為小型團隊量身定做的，因為DevOps工程師仍然要花太多時間修複緊急情況。使用OPA并不總是執行K8s政策的最佳方式，但它讓筆者了解了DevOps世界中的政策。

用ConfTest

ConfTest使你能夠為任何結構化檔案編寫測試，并專門設計用于CI或本地測試。你可以将其視為結構化檔案的單元測試庫。ConfTest建立在OPA之上。

ConfTest的主要用途是其測試指令：

$ conftest test deployment.yaml

這将接受要測試的檔案的路徑，然後評估這些檔案上的所有政策。預設情況下，所有政策（單元測試）都應放在名為policy的目錄中，但你可以覆寫此目錄。因為它是建立在OPA之上的，是以政策也必須用Rego編寫。

此外，ConfTest還提供了從任何OCI系統資料庫（如Dockerhub、Quay.io和其他）推送和拉取政策的能力。

ConfTest的問題

乍一看，ConfTest似乎是完美的解決方案。你不需要部署像OPA這樣的服務，但從OCI注冊中心拉取和推送的能力意味着你可以在專用空間中統一政策，進而獲得更多控制。ConfTest的真正威力在于它在CI過程中的使用，對于習慣于測試代碼并不斷與之內建的開發人員來說，這使K8s維護更加清晰。

不幸的是，ConfTest沒有提供足夠的政策管理能力。在專用位置統一政策是不夠的。如果要在一個服務上執行一組政策，在另一個服務上執行另一組政策，該怎麼辦？你仍然需要一種方法來利用CI流程中的測試，同時對政策進行分組。

通過研究ConfTest，筆者意識到真正的問題不僅在于實施目前要推送到叢集的内容，還在于實施明天可以或可能推送到叢集的内容。這就像單元測試；它的存在是為了讓你确信目前或将來對代碼的任何更改都不會損害現有的生産。你需要一個解決方案來執行未來和過去的政策。

DevOps，Kubernetes

筆者已經排除了執行政策的其他方法，現在是時候開始研究Kubernetes了。

筆者有三個建議想分享。

開發人員的K8s：提示和指南

了解CI/CD：如果你想開始了解K8s，那麼必須了解CI/CD管道中到底發生了什麼，CI和CD之間的差別，以及為什麼你的公司使用它。筆者從一個最小的元件開始（一個微服務），并繪制了一張圖表，列出了所有與之相關的資源和環境。筆者寫下了從送出代碼到它出現在生産環境中的所有事情。

了解你的平台：使用Kubernetes需要大量與Kubernetes本身無關的配置工作。你需要了解平台是如何工作的，使用和需要哪些資源，以及它們是如何從網絡的角度連接配接起來的。

了解部署：部署可能是在DevOps中聽到的最常見的表達，但它到底是什麼呢？這是Kubernetes的資源嗎？是一個過程？一個工件？在Kubernetes中，部署意味着“應用程式的狀态”。