1.3 GitOps帶給運維的好處

將GitOps方法與Kubernetes的聲明式配置和主動協商模型相結合，可以提供許多運維優勢，進而提供更可預測和更可靠的系統。

1.3.1 聲明式

DevOps中出現的最突出的范式之一是聲明式系統和配置模型。簡而言之，使用聲明式模型，你可以描述想要實現的目標，而不是如何實現目標。相比之下，在命令式模型中，你描述了一系列用于操控系統以達到期望狀態的指令。

為了說明這種差異，想象一下兩種樣式的電視遙控器（見圖1.7）：命令式遙控器和聲明式遙控器。兩種遙控器都可以控制電視的電源、音量和頻道。為便于討論，假設電視只有三個音量設置（響亮、柔和、靜音）和三個頻道（1、2、3）。

命令式遙控器示例

假設你有一個簡單的任務—使用兩個遙控器切換到頻道3。要使用命令式遙控器完成此任務，你可以使用“頻道調高”按鈕，它會向電視機發出信號，將當前頻道增加1。要切換到頻道3，你需要多次按下“頻道調高”按鈕，直到切換到期望的頻道。

聲明式遙控器示例

相比前者，聲明式遙控器提供了直接跳轉到特定頻道的單獨按鈕。在這種情況下，要切換到頻道3，你只需按一下“頻道3”按鈕，電視機就會切換到正確的頻道—你正在聲明期望的結果狀態（希望將電視機調到頻道3）。使用命令式遙控器，你描述的是實現期望狀態所需要執行的操作（一直按“頻道調高”按鈕，直到電視機調至頻道3）。

你可能已經注意到，在切換頻道的命令式方法中，用戶必須考慮是否繼續按下“頻道調高”按鈕，這具體取決于電視機當前已調諧到的頻道。但是，在聲明式方法中，你可以毫不猶豫地按下“頻道3”按鈕，因為聲明式遙控器上的該按鈕被認為是冪等的（命令式遙控器上的“頻道調高”按鈕不是）。

冪等性 冪等性是操作的一種屬性，該類操作可以執行任意次數并產生相同的結果。換句話說，如果你執行任意次數的操作，并且系統處于與你只執行一次操作的相同狀態，則稱該操作是冪等的。冪等性是區分聲明式系統和命令式系統的特性之一。聲明式系統是冪等的，命令式系統不是。

1.3.2 可觀測性

可觀測性是檢查和描述系統當前運行狀態并在發生意外情況時發出告警的能力（見圖1.8）。部署的環境應該是可觀測的，換句話說，你應該始終能夠檢查環境，以查看當前正在運行的內容以及是如何配置的。為此，服務本身和云服務商提供了大量方式來提高可觀測性（包括CLI、API、GUI、儀表板、告警和通知），使用戶盡可能方便地了解環境的當前狀態。

盡管這些可觀測性機制有助于回答“我的環境中當前運行的是什么？”這個問題，但是無法回答“對于環境中當前配置和運行的資源，它們是否應當以這種方式配置和運行？”。如果你曾擔任過系統管理員或操作人員，你可能對這個問題非常熟悉。在某一時刻（通常是在對環境進行故障排除時），你會遇到可疑的配置，覺得它們似乎不太正確。是否有人（可能是你自己）意外或錯誤地更改了此設置，或者此設置是特意更改的？

有可能你已經在實踐GitOps的一個基本原則：在源碼控制中存儲應用程序配置的副本，并將其用作應用程序期望狀態的真實來源。你可能沒有將此配置存儲在Git中來驅動持續部署，而只是在某處有一個副本，以便能夠重現環境，例如災難恢復場景。該副本可以被認為是期望的應用程序狀態，除了災難恢復使用場景外，它還有另一個有用的目的：讓操作員能夠在任何時間點將實際運行狀態與源碼控制中保持的期望狀態進行比較，以驗證狀態是否匹配（見圖1.9）。

環境驗證能力是GitOps的核心信條，它已經正式成為一種實踐。通過將期望狀態存儲在一個系統（例如Git）中，并定期將期望狀態與運行狀態進行比較，可以解鎖可觀測性的新維度。你不僅擁有了提供商提供的標準可觀測性機制，而且還能夠檢測當前狀態與期望狀態的偏離。

發生與期望狀態的偏離（也稱為配置漂移）的原因可能有多種，常見例子包括操作人員犯錯、自動化導致意外的副作用以及錯誤的場景。甚至有可被預期的配置漂移，例如由過渡期（例如維護模式）引起的臨時狀態。

但造成配置差異的最重要原因可能是惡意的。在最壞的情況下，危險分子可能會破壞環境并重新配置系統以運行惡意的鏡像。因此，可觀測性和可驗證性對于系統的安全性至關重要。除非你擁有期望狀態的可信來源，并且還有一個機制來驗證該可信來源的一致性，否則就不可能知道你的環境是否真正安全。

1.3.3 可審計性和合規性

對于在法律法規影響信息管理和合規性評估框架的國家（當今大多數國家/地區）開展業務的組織而言，可審計性和合規性是必須考慮的。有些行業比其他行業受到的監管力度更強，但幾乎所有公司都需要遵守基本的隱私和數據安全法。許多組織必須在其流程和系統上進行大量投資才能實現合規性和可審計性。使用GitOps和Kubernetes，可以輕松滿足大部分合規性和可審計性要求。

合規性是指驗證組織的信息系統是否符合一組特定的行業標準，這些標準通常側重于客戶數據安全，并遵守組織關于有權訪問該客戶數據的人員和系統的成文政策。第6章將深入介紹訪問控制，第4章將介紹定義和實施部署流程以實現合規性的流水線。

可審計性是一個系統被驗證為符合一組標準的能力。如果系統無法向內部或外部審計人員證明其合規性，則無法對該系統做出關于合規性的任何聲明。第8章將介紹可觀測性，包括使用Git提交歷史記錄和Kubernetes事件實現可審計性。

可審計性還指審計人員對組織的內部控制進行全面檢查的能力。在典型的審計（見圖1.10）中，審計人員要求提供證據以確保相應規則和政策的執行。證據可能包括限制訪問用戶數據的過程、個人身份信息（PII）的處理以及軟件發布過程的完整性。

這一切與GitOps有什么關系？Git是版本控制軟件，可幫助組織管理對其代碼的更改和訪問控制。Git在一種特殊類型的數據庫中跟蹤代碼的每次修改，該數據庫旨在保持托管源代碼的完整性。Git倉庫中的文件內容以及文件與目錄、版本、標簽和提交之間的真實關系使用安全哈希算法（SHA）進行保護。該算法保護代碼和更改歷史免受意外和惡意更改，并確保歷史記錄完全可追溯。

Git的歷史跟蹤還包括作者、日期和每次更改目的的書面注釋。有了寫得很好的提交注釋，你就知道為什么要進行特定的提交。Git還可以與項目管理和缺陷跟蹤軟件集成，允許對所有更改進行全面跟蹤，并支持根因分析和其他取證。

如前所述，Git支持拉取請求機制，它可以防止任何人在未經第二人批準的情況下更改系統。拉取請求獲得批準后，更改會記錄在安全的Git更改歷史記錄中。Git在變更控制、可追溯性和變更歷史真實性方面的優勢，加上Kubernetes的聲明式配置，自然滿足了可審計性和合規性所需的安全性、可用性和過程完整性原則（見圖1.11）。

1.3.4 災難恢復

災難的發生有多種原因，也有多種形式。災難可能是自然發生的（地震襲擊數據中心），由設備故障（存儲陣列中的硬盤驅動器丟失）引起的，意外發生的（破壞關鍵數據庫表的軟件錯誤），甚至是惡意造成的（網絡攻擊導致數據丟失）。

GitOps通過在源代碼控制中存儲環境的聲明式規格配置，作為一個可信來源來幫助恢復基礎設施環境。它對“環境應該是什么樣”有一個完整的定義，這有助于在發生災難時重建環境。災難恢復成為一個應用或重復應用存儲在Git倉庫中所有配置的簡單練習，你可能會察覺到災難期間遵循的過程與日常升級部署中使用的過程之間沒有太大區別。使用GitOps實際上是在定期練習災難恢復程序，從而為在真正的災難發生時做好充分的準備。

數據備份的重要性 盡管GitOps有助于簡化計算和網絡基礎設施的災難恢復，但持久性和有狀態應用程序的恢復需要以不同方式處理。備份、快照和副本等存儲相關基礎設施的傳統災難恢復解決方案不可替代。