1.3 GitOps带给运维的好处
将GitOps方法与Kubernetes的声明式配置和主动协商模型相结合，可以提供许多运维优势，进而提供更可预测和更可靠的系统。
1.3.1 声明式
DevOps中出现的最突出的范式之一是声明式系统和配置模型。简而言之，使用声明式模型，你可以描述想要实现的目标，而不是如何实现目标。相比之下，在命令式模型中，你描述了一系列用于操控系统以达到期望状态的指令。
为了说明这种差异，想象一下两种样式的电视遥控器（见图1.7）：命令式遥控器和声明式遥控器。两种遥控器都可以控制电视的电源、音量和频道。为便于讨论，假设电视只有三个音量设置（响亮、柔和、静音）和三个频道（1、2、3）。
图1.7 此图说明了命令式遥控器和声明式遥控器之间的区别。命令式遥控器可让你执行“将频道增加1”和“切换电源状态”等操作。相比之下，声明式遥控器可让你执行诸如“调谐至频道2”或“将电源状态设置为关闭”等操作
命令式遥控器示例
假设你有一个简单的任务—使用两个遥控器切换到频道3。要使用命令式遥控器完成此任务，你可以使用“频道调高”按钮，它会向电视机发出信号，将当前频道增加1。要切换到频道3，你需要多次按下“频道调高”按钮，直到切换到期望的频道。
声明式遥控器示例
相比前者，声明式遥控器提供了直接跳转到特定频道的单独按钮。在这种情况下，要切换到频道3，你只需按一下“频道3”按钮，电视机就会切换到正确的频道—你正在声明期望的结果状态（希望将电视机调到频道3）。使用命令式遥控器，你描述的是实现期望状态所需要执行的操作（一直按“频道调高”按钮，直到电视机调至频道3）。
你可能已经注意到，在切换频道的命令式方法中，用户必须考虑是否继续按下“频道调高”按钮，这具体取决于电视机当前已调谐到的频道。但是，在声明式方法中，你可以毫不犹豫地按下“频道3”按钮，因为声明式遥控器上的该按钮被认为是幂等的（命令式遥控器上的“频道调高”按钮不是）。
幂等性 幂等性是操作的一种属性，该类操作可以执行任意次数并产生相同的结果。换句话说，如果你执行任意次数的操作，并且系统处于与你只执行一次操作的相同状态，则称该操作是幂等的。幂等性是区分声明式系统和命令式系统的特性之一。声明式系统是幂等的，命令式系统不是。
1.3.2 可观测性
可观测性是检查和描述系统当前运行状态并在发生意外情况时发出告警的能力（见图1.8）。部署的环境应该是可观测的，换句话说，你应该始终能够检查环境，以查看当前正在运行的内容以及是如何配置的。为此，服务本身和云服务商提供了大量方式来提高可观测性（包括CLI、API、GUI、仪表板、告警和通知），使用户尽可能方便地了解环境的当前状态。
尽管这些可观测性机制有助于回答“我的环境中当前运行的是什么？”这个问题，但是无法回答“对于环境中当前配置和运行的资源，它们是否应当以这种方式配置和运行？”。如果你曾担任过系统管理员或操作人员，你可能对这个问题非常熟悉。在某一时刻（通常是在对环境进行故障排除时），你会遇到可疑的配置，觉得它们似乎不太正确。是否有人（可能是你自己）意外或错误地更改了此设置，或者此设置是特意更改的？
图1.8 可观测性是操作员（可能是人工的或自动化的）确定环境运行状态的能力。只有环境当前的运行状态是已知的，操作员才能做出需要对环境进行哪些相关变更的明智决定。环境的合理管控需要可观测性
有可能你已经在实践GitOps的一个基本原则：在源码控制中存储应用程序配置的副本，并将其用作应用程序期望状态的真实来源。你可能没有将此配置存储在Git中来驱动持续部署，而只是在某处有一个副本，以便能够重现环境，例如灾难恢复场景。该副本可以被认为是期望的应用程序状态，除了灾难恢复使用场景外，它还有另一个有用的目的：让操作员能够在任何时间点将实际运行状态与源码控制中保持的期望状态进行比较，以验证状态是否匹配（见图1.9）。
图1.9 如果可以观测到环境的运行状态，并在Git中定义了环境的期望状态，那么就可以通过比较两种状态来验证环境
环境验证能力是GitOps的核心信条，它已经正式成为一种实践。通过将期望状态存储在一个系统（例如Git）中，并定期将期望状态与运行状态进行比较，可以解锁可观测性的新维度。你不仅拥有了提供商提供的标准可观测性机制，而且还能够检测当前状态与期望状态的偏离。
发生与期望状态的偏离（也称为配置漂移）的原因可能有多种，常见例子包括操作人员犯错、自动化导致意外的副作用以及错误的场景。甚至有可被预期的配置漂移，例如由过渡期（例如维护模式）引起的临时状态。
但造成配置差异的最重要原因可能是恶意的。在最坏的情况下，危险分子可能会破坏环境并重新配置系统以运行恶意的镜像。因此，可观测性和可验证性对于系统的安全性至关重要。除非你拥有期望状态的可信来源，并且还有一个机制来验证该可信来源的一致性，否则就不可能知道你的环境是否真正安全。
1.3.3 可审计性和合规性
对于在法律法规影响信息管理和合规性评估框架的国家（当今大多数国家/地区）开展业务的组织而言，可审计性和合规性是必须考虑的。有些行业比其他行业受到的监管力度更强，但几乎所有公司都需要遵守基本的隐私和数据安全法。许多组织必须在其流程和系统上进行大量投资才能实现合规性和可审计性。使用GitOps和Kubernetes，可以轻松满足大部分合规性和可审计性要求。
合规性是指验证组织的信息系统是否符合一组特定的行业标准，这些标准通常侧重于客户数据安全，并遵守组织关于有权访问该客户数据的人员和系统的成文政策。第6章将深入介绍访问控制，第4章将介绍定义和实施部署流程以实现合规性的流水线。
可审计性是一个系统被验证为符合一组标准的能力。如果系统无法向内部或外部审计人员证明其合规性，则无法对该系统做出关于合规性的任何声明。第8章将介绍可观测性，包括使用Git提交历史记录和Kubernetes事件实现可审计性。
案例研究：Facebook和Cambridge Analytica
美国前总统特朗普2016年竞选活动聘用的政治数据公司Cambridge Analytica获得了对超过5000万Facebook用户私人信息的不当访问权。该数据用于为每个用户生成个性评分，并将该用户与美国选民记录相匹配。Cambridge Analytica将这些信息用于其选民分析和有针对性的广告服务。Facebook也被发现没有采取适当控制措施以实施强制性数据隐私政策，最终因违规而被联邦贸易委员会罚款50亿美元。[6]
可审计性还指审计人员对组织的内部控制进行全面检查的能力。在典型的审计（见图1.10）中，审计人员要求提供证据以确保相应规则和政策的执行。证据可能包括限制访问用户数据的过程、个人身份信息（PII）的处理以及软件发布过程的完整性。
图1.10 在传统的审计过程中，通常很难确定系统的期望状态。审计人员可能需要查看此信息的各种来源，包括文档、变更请求和部署脚本
案例研究：支付卡行业数据安全标准
支付卡行业数据安全标准（PCI DSS）是一种信息安全标准，适用于卡支付网络中涉及的品牌信用卡组织。违反PCI DSS可能会导致巨额罚款，在最坏的情况下，会导致信用卡业务暂停。PCI DSS规定“访问控制系统需要配置为强制基于工作分类和职能来分配不同的权限”。在审计期间，组织需要提供证据证明访问控制系统已到位，以符合PCI合规性要求。[7]
这一切与GitOps有什么关系？Git是版本控制软件，可帮助组织管理对其代码的更改和访问控制。Git在一种特殊类型的数据库中跟踪代码的每次修改，该数据库旨在保持托管源代码的完整性。Git仓库中的文件内容以及文件与目录、版本、标签和提交之间的真实关系使用安全哈希算法（SHA）进行保护。该算法保护代码和更改历史免受意外和恶意更改，并确保历史记录完全可追溯。
Git的历史跟踪还包括作者、日期和每次更改目的的书面注释。有了写得很好的提交注释，你就知道为什么要进行特定的提交。Git还可以与项目管理和缺陷跟踪软件集成，允许对所有更改进行全面跟踪，并支持根因分析和其他取证。
如前所述，Git支持拉取请求机制，它可以防止任何人在未经第二人批准的情况下更改系统。拉取请求获得批准后，更改会记录在安全的Git更改历史记录中。Git在变更控制、可追溯性和变更历史真实性方面的优势，加上Kubernetes的声明式配置，自然满足了可审计性和合规性所需的安全性、可用性和过程完整性原则（见图1.11）。
图1.11 使用GitOps可以简化审计过程，因为审计人员可以通过检查源代码仓库来确定系统的期望状态。系统的当前状态可以通过查看托管的服务和Kubernetes对象来确定
1.3.4 灾难恢复
灾难的发生有多种原因，也有多种形式。灾难可能是自然发生的（地震袭击数据中心），由设备故障（存储阵列中的硬盘驱动器丢失）引起的，意外发生的（破坏关键数据库表的软件错误），甚至是恶意造成的（网络攻击导致数据丢失）。
GitOps通过在源代码控制中存储环境的声明式规格配置，作为一个可信来源来帮助恢复基础设施环境。它对“环境应该是什么样”有一个完整的定义，这有助于在发生灾难时重建环境。灾难恢复成为一个应用或重复应用存储在Git仓库中所有配置的简单练习，你可能会察觉到灾难期间遵循的过程与日常升级部署中使用的过程之间没有太大区别。使用GitOps实际上是在定期练习灾难恢复程序，从而为在真正的灾难发生时做好充分的准备。
数据备份的重要性 尽管GitOps有助于简化计算和网络基础设施的灾难恢复，但持久性和有状态应用程序的恢复需要以不同方式处理。备份、快照和副本等存储相关基础设施的传统灾难恢复解决方案不可替代。