本文最后更新于 2025-03-16，文章内容可能已经过时。
1、混沌工程介绍
混沌工程（That which does not kill us makes us stronger）是对系统进行实验的学科，目的是建立对系统承受生产中动荡条件的能力的信心，主要目的是：
受控和计划的工程试验；
为不可预知的故障做准备；
然工程师为失败做好准备；
为冲刺时间做好准备；
通过强化系统改进 SLQ 的方法。
1.1 流程和困难
上图便是混沌工程的一个执行过程，主要是通过已猜想的问题来校验系统是否能够在这个条件下正常的完成验证流程，完成还行，如果不行的话需要进行记录问题然后再验证，这是一个迭代的工作流程，这样来不断地提高系统对于未知问题的一个健壮性。
但是在日常的项目迭代过程中我们很少会有人去进行这样的一个混沌工程的推进任务，阻力体现在下面的几个方面：
没有时间或灵活性来模拟灾难；
团队总是会花时间修复问题并构建新功能；
这在组织内部可能非常政治化；
修复和模拟灾难所涉及的成本；
还有更多与公司相关的事情会产生阻力。
1.2 优点原则
高级原则
建立一个围绕稳定状态行为的假说、多样化真实世界的事件、在生产环境中运行实验、持续自动化运行实验、最小化爆炸半径。
优点：能发现系统的弱点
当服务不可用时的不正确回滚设置、不当的超时设置导致的重试风暴、由于下游依赖的流量过载导致的服务终端、单点故障时的级联失败等。
2、Chaos Mesh
Chaos Mesh 建立在 Kubernetes CRD（自定义资源定义）之上。为了管理不同的 Chaos 实验，Chaos Mesh 根据不同的故障类型定义了多种 CRD 类型，并为不同的 CRD 对象实现了单独的 Controller。Chaos Mesh 主要包含三个组件：
Chaos Dashboard：Chaos Mesh 的可视化组件。Chaos Dashboard 提供了一组用户友好的 Web 界面，用户可以通过这些界面操作和观察 Chaos 实验。同时，Chaos Dashboard 还提供了 RBAC 权限管理机制。
Chaos Controller Manager：Chaos Mesh 的核心逻辑组件。Chaos Controller Manager 主要负责 Chaos 实验的调度和管理。该组件包含多个CRD Controller，例如Workflow Controller、Scheduler Controller，以及各种故障类型的Controller。
Chaos Daemon：主要执行组件。Chaos Daemon 运行在 DaemonSet 模式下，默认拥有 Privileged 权限（可以禁用）。该组件主要通过侵入目标 Pod 命名空间来干扰特定的网络设备、文件系统、内核。
如上图所示，Chaos Mesh 的整体架构从上到下可以分为三个部分：
用户输入和观察：用户输入从用户操作（User）开始到达 Kubernetes API Server。用户不直接与 Chaos Controller Manager 交互。所有的用户操作最终都会体现为一次 Chaos 资源的变化（比如 NetworkChaos 资源的变化）。
监控资源变化，安排工作流程，进行混沌实验：混沌控制器管理器只接受来自 Kubernetes API 服务器的事件。这些事件描述了某个 Chaos 资源的变化，例如新的 Workflow 对象或 Chaos 对象的创建。
特定节点故障注入：Chaos Daemon 组件主要负责接受来自 Chaos Controller Manager 组件的命令，侵入目标 Pod 的命名空间，并执行特定的故障注入。比如设置TC网络规则，启动stress-ng进程抢占CPU或内存资源。
3、FinOps
FinOps 是将 DevOps、财务和业务整合在一起的变革，其目标在于优化一个组织在云计算上的支出的财务规范和技术解决方案，及根据支出的历史记录和来自预期负载的信息，FinOps 可以在需要是时预分配资源或估算成本。FinOps 可以成为财务运营，或者更直白成为成本优化，是将财务问责制引入云的 IT 支持，进行调整以优化质量和支出。
FinOps 的应用不是个人能够完成的，需要多组织、多部门的协调管理才行。
3.1 kube cost
该工具就是上面的 FinOps 的一个实践应用，也是一个云原生的支持版的，使用的时候直接在底座上面进行安装即可，主要的架构就是用过 API 获取到应用的信息，并且获取到外界的 bill 账单信息，在通过应用的 metrics 来获取相关的监控信息（包括物力资源的消耗数据这些），以此来分析相关的 cost ，从而得到一个比较好的消费方案。
