CNCF项目汇总2
CloudEvent
简介
CloudEvents三部曲:初识篇-腾讯云开发者社区-腾讯云 (tencent.com)
spec/cloudevents/languages/zh-CN/primer.md at main · cloudevents/spec · GitHub
时间在现代系统无处不在，但不同时间的生产者往往用不同的规范来描述自己的事件。
- 一致性：对事件同意描述的缺乏意味着开发者必须为每个时间原写单独的事件处理逻辑。
- 可达性：缺乏统一的格式意味着确实能够跨华金传输的数据库、根据以及基础设施。CloudEvent针对不同编程语言，提供了用来构建事件的路由、时间追踪和其它根据的多款SDKs包括Go、 JavaScript、 Java、 C#、 Ruby、PHP、PowerShell、Rust、 以及 Python 。
- 可移植性：总体来看，这种对事件的统一描述缺乏严重阻碍了时间数据的可移植性和生产力。
什么是CloudEvents？
CloudEvent是一个以通用格式来描述事件的规范。它旨在简化不同服务、平台时间和传输。
目前各大第三方云提供商都在大力推广落地CloudEvents规范，例如：
- 2018年，微软宣布将通过Event Grid服务（一项由Azure集中管理的事件服务，支持用户通过“发布-订阅”机制发送和接收事件）提供对CloudEvents的支持
- 2019年，阿里云开始推广 OpenMessaging 标准协议，希望让 Apache RocketMQ 兼容 Cloudevent 体系，成为 Serverless 的桥梁
- 2020年，字节跳动在其函数计算产品中利用CloudEvents规范统一事件源标准，极大方便之后的能力扩展。
优势
消费优势
生产者生产事件供消费者使用时，由于使用了 CloudEvents 规范，消费者不再需要为平台或服务的差异性编写特定的消费逻辑，改而使用通用逻辑处理事件数据，方便事件消费者提高开发效率，并降低系统复杂度。例如：阿里云的事件总线EventBridge，微软Azure的Event Grid服务都极大方便了产品的端到端集成。
路由优势
中间件将事件从生产者路由到消费者，或者转发到其他中间件的时，CloudEvents会保留事件的身份和语义完整性。用于事件的分类过滤或元数据的鉴别。例如：消费者利用过滤功能只关注特定用户；或者利用元数据鉴别只接收后缀为 .doc 的新建文件等。
利用 CloudEvents中间件可以在改变事件的语义含义时承担生成器的角色，在基于事件采取行动时承担消费者的角色，或在路由事件不进行语义更改时承担中间件的角色。例如：Apache RocketMQ 社区发布的OpenMessaging 标准协议兼容CloudEvents规范，从而成为 Serverless 的桥梁，更加高效广泛的进行消息路由。
交互优势
利用 CloudEvents系统框架对内解耦各模块的通信能力，提高可维护性；对外与其他事件平台基础设施的交互将更简单，并且方便为其他平台设施提供通用 API，降低交互的复杂性，提高系统平台的扩展性。
CloudEvents提供了各种事件格式（例如JSON）和协议（例如HTTP，AMQP，MQTT和Kafka）序列化事件的规范，同时也提供了多种开发语言的SDK（如：Go、JavaScript、Java、C#、Ruby和Python等），利用SDK可以极大方便开发人员进行集成开发。利用 CloudEvents系统框架对内解耦各模块的通信能力，提高可维护性；对外与其他事件平台基础设施的交互将更简单，并且方便为其他平台设施提供通用 API，降低交互的复杂性，提高系统平台的扩展性。
Clouddevents concepts概念
一个事件包含了
时间发生的上下文和相关数据。时间的相关数据可以用来唯一表示一件事件的发生。
事件代表了已发生的事实，因此它并不包含任何目的地的相关信息，但消息能够传达事件内容，从而将源头传输到指定目的地。
事件通常在服务器端代码中使用来连接不同的系统，其中一个系统中的状态变化会导致代码在另一个系统中执行。 比如，一个事件源，可能会在收到某个外部信号(如 HTTP 或 RPC )或观察到状态变化(如 IoT/ 物联网传感器数据变化或不活跃) 时，生产一个事件。
为了更好地解释一个系统如何使用 CloudEvents，下图展示了一个从事件源生产的事件是如何触发一个行为的。
事件源生产了一条封装了基于某种协议的事件数据的消息。 当载有事件的消息到达目的地时，会触发一个使用了事件数据的行为函数。
一个事件源是那些允许暂存和测试实例的源类型的特定实例。 某个特定源类型的开源软件可能由多个公司或提供商部署。
事件可以通过各种行业标准协议（如 HTTP、AMQP、MQTT、SMTP）、开源协议（例如 Kafka、NATS）或 平台/供应商专有协议（AWS Kinesis、Azure Event Grid）传输。
一个操作函数能够处理那些定义了行为或影响的事件，这些行为和效果由来自特定源的特定事件触发而来。 虽然超出了规范的范围，但生成事件的目的通常是让其他系统能够轻松地对它们无法控制的源中的更改做出反应。 源和操作通常由不同的开发人员构建。 通常，源是托管服务，而操作是 serverless 函数（如 AWS Lambda 或 Google Cloud Functions）中 的自定义代码。
Design Goals设计目标
CloudEvents 通常用于分布式系统，以允许服务在开发过程中松耦合，独立部署，方便之后连接以创建新的应用程序。
CloudEvents 规范的目标是定义允许服务生产或消费事件的事件系统的互操作性， 其中生产者和消费者可以独立开发和部署。 生产者可以在没有消费者监听时就生成事件， 消费者也可以表达对尚未生成的事件或事件类的兴趣。值得注意的是，这项工作产生的规范侧重于事件格式的互操作性 以及它在通过各种协议（例如 HTTP）发送时的显示方式。我们不关注事件生产者或事件消费者的处理模型。
CloudEvents 的核心规范中定义了一组称之为属性的元数据， 它们描述了在系统之间传输的事件以及这些元数据片段应如何显示在该消息中。 这些元数据是，将请求路由到适当组件并帮助该组件正确处理事件所需的最小信息集。 因此，某些事件本身的数据可能会作为 CloudEvent 属性集的一部分而被复制， 但这样做仅是为了能够正确传递和处理消息。那些不用于该目的的数据应放置在事件（数据）本身中。
此外，本规范中假设协议层所需的用来将消息传递到目标系统的元数据应完全由协议处理， 因此不包含在 CloudEvents 属性中。 有关更多详细信息，请参阅非目标部分。
除了这些属性的定义之外，规范还描述了关于如何序列化 不同格式（例如 JSON）和协议（例如 HTTP、AMQP、Kafka）的事件。
一些协议本身支持将多个事件批处理到单个 API 的调用中。 为了提升系统间的互操作性，是否以及如何实现批处理将由协议自己决定。 相关详细信息可以在协议绑定或协议规范中找到。 成批的CloudEvents并没有语义，也没有排序。 中间人可以添加或删除批处理以及将事件分配给不同的批处理。
事件的目的或语义含义超出了 CloudEvents 规范的范围。 只要发送的消息符合规范，那么它就是一个有效的 CloudEvent。 很多人不容易意识到一件事，错误和异常是可以作为CloudEvents来传输的。 接下来应由事件生产者定义将使用的 CloudEvents 属性值，就像它可能生成的任何其他事件一样。
由于并非所有事件生产者都将其事件以CloudEvents的形式发布， 因此我们定义了一组 适配器 来展示如何将事件从一些流行的事件生产者映射到 CloudEvents。 这些适配器是非规范的， 但它们是规范作者对 CloudEvents 属性如何在其它生产者本地生成事件并映射到CloudEvents时的最佳猜测。
CoreDNS
什么是CoreDNS
CoreDNS是一个DNS服务。它是Go编写的。
和其他DNS服务不同例如 BIND, Knot, PowerDNS 和Unbound（从技术上来讲是解析器但是仍值得被提到），因为它非常灵活，并且几乎所有功能都能外置到插件中。
插件可以是独立的，也可以协同工作以执行DNS function。
那么什么是DNS function？对于CoreDNS的用途，我们将其定义为一个实现CoreDNS插件API的软件。实现的功能可能会有很大的偏差。
这个插件本身不创建响应，例如指标和缓存，但是增加了功能。还有一些插件确实会生成响应。他们也可以做任何事情：有一些插件与Kubernetes通信已提供服务发现。还有一些插件可以从文件或数据库中读取数据。
目前默认的CoreDNS安装中包含大约30个插件，但是也有一大堆外部插件可以编译到CoreDNS中以扩展其功能。
CoreDNS由插件提供支持。
编写新的插件很容易，但是需要了解Go和深入了解DNS的工作原理。CoreDNS抽象掉了许多DNS细节。所以你可以只专注编写需要的插件功能。
插件
当CoreDNS启动并解析了配置，它就会运行服务。每个服务都由器服务的区域和端口定义。每个服务都有自己的插件链。
当CoreDNS正在处理查询时，将执行以下步骤：
- 如果配置了多个监听查询端口的服务器，则它将检查哪个服务器具有此查询的最特定区域（后缀匹配最长）例如，如果有两个服务器，一个用于example.org，另一个用于a.example.org，并且查询是针对www.a.example.org的，则它将被路由到后者。
- 一旦找到服务器，它将通过为此服务器配置的插件链进行路由。这种情况总是以相同的顺序发生。这种（静态）排序是在plugin.cfg中定义的。
每个插件都会检查查询并确定是否应该处理它。（一些插件允许你进一步过滤查询名称或者其他属性）有几件事将会发生。
- 查询被插件处理。
- 查询没被插件处理
- 查询被插件处理，但是进行到一半时该插件决定要调用 链中的下一个插件。我们叫做关键字启用后的调用失败（fallthrough）
- 查询由这个插件处理，添加一个“提示”，然后调用下一个插件。这个提示提供了一种“看到”（最终）响应并采取行动的方式。
执行查询意味着插件将以回复的方式响应客户端。
请注意插件可以根据自身需求偏移以上列表。当前CoreDNS福袋的所有插件都属于这四组中的一组。请注意，这篇博客文章)还提供了查询路由的背景信息。
Harbor
Harbor 是由 VMware 公司开源的容器镜像仓库， 它在 Docker Registry 的基础上进行了企业级扩展， 包括基于角色的权限控制、 AD/LDAP集成、
可视化管理界面、 日志审计等，它同 Docker Registry一 样提供容器镜像的存储及分发服务。
Harbor 与 Docker Registry 相比进行的优化和改进
- 传输效率优化： Harbor 根据容器镜像每层的UUID标识进行增量同步， 而不是全量同步， 减少带宽及其他资源占用。
- 镜像仓库水平扩展：由于上传、 下载镜像文件涉及大量的耗时1/0操作， 当用户对性能有较高要求时， 需要创建多个Registry，通过负载均衡器将访问压力分发到不同的Registry，同 时多个Registry存储时进行镜像文件的同步，便于水平扩展。
- 用户认证：Harbor在DockerRegistry的基础上扩展了用户认证授权的功能，用户在Harbor中 进行访问需要携带token，以增强安全性。
- 镜像安全扫描：上传到Harbor上的镜像文件 能够通过clair的安全扫描，以发现镜像中存在的安全漏洞，并提高镜像文件的安全性。
- 提供Web界面以优化用户体验：Registry只提供命令行方式， 没有操作界面， 而Harbor提供用户界面，可以支持登录、 搜索功能，镜像分类管理包括区分 公有、 私有镜像等功能，优化了用户管理及操作体验。
Proxy
Proxy是镜像仓库核心服务（Registry、UI、token等）的前端访问代理， 通过这个代理可统 一 接收客户端发送来的请求，并将此请求转发给后端不同的服务进行处理。
Registry
负责存储docker镜像，处理上传/下载命令。对用户进行访问控制，它指向一个token服务，强制用户的每次docker pull/push请求都要携带一个合法的token，registry会通过公钥对token进行解密验证。
Core service：Harbor的核心功能
- UI：图形界面
- Webhook：及时获取registry上image状态变化情况，在registry上配置 webhook，把状态变化传递给UI模块。
- Token服务：复杂根据用户权限给每个docker push/p/ull命令签发token。Docker客户端向registry服务发起的请求，如果不包含token，会被重定向到这里，获得token后再重新向registry进行请求。
Database
提供数据库服务，存储用户权限，审计日志，docker image分组信息等数据
Log collector
为了帮助监控harbor运行，复责收集其他组件的log，供日后进行分析
KubeVirt
Kubernetes 管理虚拟机之 KubeVirt - 知乎 (zhihu.com)
简介
Kubevirt 是Redhat开源的以容器方式运行虚拟机的项目，以k8s add-on方式，利用k8s CRD为增加资源类型VirtualMachineInstance（VMI）， 使用容器的image registry去创建虚拟机并提供VM生命周期管理。 CRD的方式是的kubevirt对虚拟机的管理不局限于pod管理接口，但是也无法使用pod的RS DS Deployment等管理能力，也意味着 kubevirt如果想要利用pod管理能力，要自主去实现，目前kubevirt实现了类似RS的功能。 kubevirt目前支持的runtime是docker和runv。
为什么使用
KubeVirt 技术可满足已采用或想要采用Kubernetes开发团队的需求，但他们拥有现有的基于虚拟机的工作负载，无法轻松地对其进行容器化。更具体地说，该技术提供了一个统一的开发平台，开发人员可以在该平台上构建，修改和部署驻留在公共共享环境中的应用程序容器和虚拟机中的应用程序。
好处是广泛而重大的。依赖现有基于虚拟机的工作负载团队有权快速将应用程序容器化。通过将虚拟化工作负载直接放置在开发工作流中，团队可以随时间分解它们，同时仍然可以按需使用剩余的虚拟化组件。
KubeVirt 能做什么 ？
- 利用 KubeVirt 和 Kubernetes 来管理虚拟机
- 一个平台上将现有的虚拟化与容器化打通并管理
- 支持虚拟机应用与容器化应用实现内部交互访问
架构
从kubevirt架构看如何创建虚拟机，Kubevirt架构如图所示，由4部分组件组成。从架构图看出kubevirt创建虚拟机的核心就是 创建了一个特殊的pod virt-launcher 其中的子进程包括libvirt和qemu。做过openstack nova项目的朋友应该比较 习惯于一台宿主机中运行一个libvirtd后台进程，kubevirt中采用每个pod中一个libvirt进程是去中心化的模式避免因为 libvirtd 服务异常导致所有的虚拟机无法管理。
虚拟机创建流程
- client 发送创建VMI命令达到k8s API server.
- K8S API 创建VMI
- virt-controller监听到VMI创建时，根据VMI spec生成pod spec文件，创建pods
- k8s调度创建pods
- virt-controller监听到pods创建后，根据pods的调度node，更新VMI 的nodeName
- virt-handler监听到VMI nodeName与自身节点匹配后，与pod内的virt-launcher通信，virt-laucher创建虚拟机，并负责虚拟机生命周期管理
Crossplane
Crossplane（平面，意思是可以跨越多个公有云平台）是一个开源的Kubernetes插件，它允许平台团队组装来自多个供应商的基础设施，并向应用程序团队公开更高级别的自助服务API，而不需要编写任何代码。
Crossplane扩展您的Kubernetes集群，为您提供任何基础设施托管服务的crd。将这些细粒度资源组合成更高级别抽象，这些抽象可以使用您喜欢的根据，也可以集成到集群中现有进行版本管理、部署和使用
同类型产品：Terraform
Terraform
terraform是一种基础设施即代码（infrastructure as Code）根据，旨在帮助开发人员和运维团队自动化基础设施的创建、管理和部署。使用Terraform，可以通过编写简洁的代码来定义和配置云端基础设施，而不必手动操作和配置。示意图如下：
Terraform通过应用程序编程接口（API）在云平台和其他服务商创建和管理资源。提供程序使Terraform能够使用具有可访问API的几乎任何平台或服务。
- 写：您可以定义资源，这些资源可能跨多个云提供商和服务。例如，您可以创建一个配置，以在具有安全组和负载均衡器的 Virtual Private Cloud （VPC） 网络中的虚拟机上部署应用程序。
- 计划：Terraform 会创建一个执行计划，描述它将根据现有基础结构和配置创建、更新或销毁的基础结构。
- 应用：批准后，Terraform 会以正确的顺序执行建议的操作，并尊重任何资源依赖关系。例如，如果您更新了 VPC 的属性并更改了该 VPC 中的虚拟机数量，则 Terraform 将在扩展虚拟机之前重新创建 VPC。
Crossplane 的重点是将基础设施资源抽象为 Kubernetes CRD 对象，并通过 Kubernetes API 进行声明式管理。它提供了一种统一的方式来管理不同云提供商的服务和资源，并与 Kubernetes 生态系统的其他工具和框架集成。
OpenKruise
OpenKruise是一个基于Kubernetes的扩展套件，主要聚焦于云原生应用的自动化，比如部署、发布、运维以及可用性防护。
OpenKruise提供的绝大部分能力都是基于CRD扩展来定义，它们不存在于任何外部依赖，可以运行在春节的Kubernetes环境中。
增强版本的WorkLoads
OpenKruise 包含了一系列增强版本的 Workloads（工作负载），比如 CloneSet、Advanced StatefulSet、Advanced DaemonSet、BroadcastJob 等。它们不仅支持类似于 Kubernetes 原生 Workloads 的基础功能，还提供了如原地升级、可配置的扩缩容/发布策略、并发操作等。
原地升级是一种升级应用容器镜像甚至环境变量的全新方式。它只会用新的镜像重建 Pod 中的特定容器，整个 Pod 以及其中的其他容器都不会被影响。因此它带来了更快的发布速度，以及避免了对其他 Scheduler、CNI、CSI 等组件的负面影响。
应用旁路管理
OpenKruise 提供了多种通过旁路管理应用 sidecar 容器、多区域部署的方式，“旁路” 意味着你可以不需要修改应用的 Workloads 来实现它们。
比如，SidecarSet 能帮助你在所有匹配的 Pod 创建的时候都注入特定的 sidecar 容器，甚至可以原地升级已经注入的 sidecar 容器镜像、并且对 Pod 中其他容器不造成影响。而 WorkloadSpread 可以约束无状态 Workload 扩容出来 Pod 的区域分布，赋予单一 workload 的多区域和弹性部署的能力。
高可用性防护
OpenKruise 在为应用的高可用性防护方面也做出了很多努力。目前它可以保护你的 Kubernetes 资源不受级联删除机制的干扰，包括 CRD、Namespace、以及几乎全部的 Workloads 类型资源。相比于 Kubernetes 原生的 PDB 只提供针对 Pod Eviction 的防护，PodUnavailableBudget 能够防护 Pod Deletion、Eviction、Update 等许多种 voluntary disruption 场景。
Kubeflow
Kubeflow 项目致力于使 Kubernetes 上的机器学习 （ML） 工作流部署变得简单、可移植和可扩展。 我们的目标不是重新创建其他服务，而是提供一种直接的方法，将一流的机器学习开源系统部署到不同的基础设施。
longhorn
适用于 Kubernetes 的高可用性持久性存储
过去，ITOps 和 DevOps 发现很难将复制的存储添加到 Kubernetes 集群。因此，许多非云托管的 Kubernetes 集群不支持持久性存储。外部存储阵列是不可移植的，并且可能非常昂贵。
Longhorn 提供简化、易于部署和升级、100% 开源的云原生持久性块存储，没有开放核心或专有替代方案的成本开销。
轻松的增量快照和备份
Longhorn 内置的增量快照和备份功能可确保卷数据安全进出 Kubernetes 集群。
Longhorn 直观、免费的管理 UI 简化了 Kubernetes 集群中持久存储卷的计划备份。
跨集群容灾
外部复制解决方案将通过重新复制整个数据存储来从磁盘故障中恢复。这可能需要数天时间，在此期间，群集性能不佳，故障风险较高。
使用 Longhorn，您可以最大程度地控制粒度，在另一个 Kubernetes 集群中轻松创建灾难恢复卷，并在发生紧急情况时故障转移到该卷。
如果主集群出现故障，您可以使用定义的 RPO 和 RTO 在 DR 集群中快速启动应用。
特点
Longhorn 是 Kubernetes 的分布式块存储系统。Longhorn 是使用 Kubernetes 和容器原语构建的云原生存储。
Longhorn 重量轻、可靠且功能强大。您可以使用一个命令或使用 Helm 图表在现有 Kubernetes 集群上安装 Longhorn。安装 Longhorn 后，它会向 Kubernetes 集群添加持久卷支持。kubectl apply
Longhorn 使用容器和微服务实现分布式块存储。Longhorn 为每个块存储设备卷创建一个专用的存储控制器，并在存储在多个节点上的多个副本之间同步复制该卷。存储控制器和副本本身是使用 Kubernetes 编排的。以下是 Longhorn 的一些显着特点：
- 无单点故障的企业级分布式存储
- 块存储增量快照
- 备份到基于高效更改块检测的辅助存储（NFSv4 或 S3 兼容对象存储）
- 定期快照和备份
- 自动无中断升级。您可以在不中断运行卷的情况下升级整个 Longhorn 软件堆栈！
- 直观的 GUI 仪表板
cert-manager
cert-manager 将证书和证书颁发者添加为 Kubernetes 集群中的资源类型，并简化获取、续订和使用这些证书的过程。
它支持从各种来源颁发证书，包括 Let's Encrypt （ACME）、HashiCorp Vault 和 Venafi TPP / TLS Protect Cloud，以及本地集群内颁发。
cert-manager 还确保证书保持有效和最新状态，尝试在到期前的适当时间续订证书，以降低中断风险并消除辛苦。
Falco
关于 Falco
Falco 是一款旨在检测应用中反常活动的行为监视器，由Sysdig的系统调用捕获基础设施驱动。您仅需为 Falco 撰写一套规则，即可在一处持续监测并监控容器、应用、主机及网络的异常活动。
Falco 可检测哪些行为？
Falco 可以监测调用 Linux 系统调用的行为，并根据其不同的调用、参数及调用进程的属性发出警告。例如，Falco 可轻松检测：
- 容器内运行的 Shell
- 服务器进程产生意外类型的子进程
- 敏感文件读取（如
/etc/shadow） - 非设备文件写入至
/dev - 系统的标准二进制文件（如
ls）产生出站流量
与其他工具的对比
我们常常会被问到 Falco 与 SELinux、AppArmor、Auditd 或其他 Linux 安全策略工具有何不同。为此，我们在 Sysdig 博客上撰写了一篇博文，并详细对比了多款工具。
如何使用 Falco
Falco 应作为守护程序部署。您可将其作为一款 deb/rpm 软件包安装在主机或容器宿主上，亦或可以作为容器部署。当然，您也可以下载源代码并自己动手编译安装。
您可通过规则文件或通用配置文件定义 Falco 应监视的行为及事件。我们提供了一份示例规则文件 ./rules/falco_rules.yaml，您可随意修改规则来适配您的工作环境。
当您撰写规则时，Falco 可读取由 Sysdig 产生的回溯文件。这一特性可让您在调整规则时“录制”有害行为，并无限次数地回放。
部署后，Falco 将利用 Sysdig 内核模块及用户空间函数库来监控规则文件定义中的任意事件。若异常事件发生，Falco 会将通知信息写入您所配置的输出中。
Falco 行为报警
当 Falco 检测到可疑行为时，报警信息可通过下列渠道输出：
- 写入标准错误
- 写入文件
- 写入系统日志
- 管道至特定程序（如发送电子邮件）
keycLoak
keycloak是一个开源的进行身份认证和访问控制的软件。是由Red Hat基金会开发的，我们可以使用keycloak方便的向应用程序和安全服务添加身份认证，非常的方便。基于 Java 开发，支持多种数据库。
以最少的麻烦为应用程序和安全服务添加身份验证。 不需要处理存储 用户或身份验证用户。 开箱即用。您甚至可以获得高级功能，例如用户联合，身份经纪和社交登录。
KubeEdge
(主要是做边缘计算的)
KubeEdge 是一个开源系统，可将本机容器化的业务流程和设备管理扩展到Edge上的主机。它基于Kubernetes构建，并为网络、应用程序部署以及云与边缘之间的元数据同步提供核心基础架构支持。它还支持MQTT，并允许开发人员编写自定义逻辑并在Edge上启用资源受限的设备通信。KubeEdge由云部分和边缘部分组成，边缘和云部分现已开源。
随着5G通信的商用，万物互联时代快速到来，网络边缘的设备数量、产生的数据爆发增长，集中式的数据中心（包括公有云服务）将面临实时性、带宽、能耗、数据隐私的挑战，越来越多的场景需要应用边缘计算。
在K8s上，可以通过K3s、Microk8s、KubeEdge三种架构实现边缘计算，KubeEdge以边云协同、边缘侧的轻量和边缘自治能力而获得更多应用。
cortex
面向 Prometheus 的水平可扩展、高度可用、多租户的长期存储。
Cortex 为 Prometheus 提供水平可扩展、高度可用、多租户的长期存储。
- 水平可扩展：Cortex 可以在集群中的多台机器上运行，超过了单台机器的吞吐量和存储量。这使您能够将指标从多个 Prometheus 服务器发送到单个 Cortex 集群，并在一个位置对所有数据运行“全局聚合”查询。
- 高可用性：在集群中运行时，Cortex 可以在机器之间复制数据。这使您可以在机器故障中幸存下来，而不会在图表中出现间隙。
- 多租户：Cortex 可以将数据和查询从多个不同的独立数据和查询隔离开来 Prometheus 源位于单个集群中，允许不受信任的各方共享同一集群。
- 长期储存：Cortex 支持 S3、GCS、Swift 和 Microsoft Azure，用于长期存储指标数据。这样一来，您就可以持久地存储数据，使其比任何一台计算机的生存期更长，并将此数据用于长期容量规划。
Chaos Mesh
简介
Chaos Mesh 是一个开源的云原生混沌工程平台，提供丰富的故障模拟类型，具有强大的故障场景编排能力，方便用户在开发测试中以及生产环境中模拟现实世界中可能出现的各类异常，帮助用户发现系统潜在的问题。Chaos Mesh 提供完善的可视化操作，旨在降低用户进行混沌工程的门槛。用户可以方便地在 Web UI 界面上设计自己的混沌场景，以及监控混沌实验的运行状态。
优势
Chaos Mesh 作为业内领先的混沌测试平台，具备以下核心优势：
- 核心能力稳固：Chaos Mesh 起源于 TiDB 的核心测试平台，发布初期即继承了大量 TiDB 已有的测试经验。
- 被充分验证：Chaos Mesh 被众多公司以及组织所使用，例如腾讯和美团等；同时被用于众多知名分布式系统的测试体系中，例如 Apache APISIX 和 RabbitMQ 等。
- 系统易用性强：图形化操作和基于 Kubernetes 的使用方式，充分利用了自动化能力。
- 云原生：Chaos Mesh 原生支持 Kubernetes 环境，提供了强悍的自动化能力。
- 丰富的故障模拟场景：Chaos Mesh 几乎涵盖了分布式测试体系中基础故障模拟的绝大多数场景。
- 灵活的实验编排能力：用户可以通过平台设计自己的混沌实验场景，场景可包含多个混沌实验编排，以及应用状态检查等。
- 安全性高：Chaos Mesh 具有多层次安全控制设计，提供高安全性。
- 活跃的社区：Chaos Mesh 为全球知名开源混沌测试平台，CNCF 开源基金会孵化项目。
- 强大的扩展能力：Chaos Mesh 为故障测试类型扩展和功能扩展提供了充分的扩展能力。
架构
Chaos Mesh 基于 Kubernetes CRD (Custom Resource Definition) 构建，根据不同的故障类型定义多个 CRD 类型，并为不同的 CRD 对象实现单独的 Controller 以管理不同的混沌实验。Chaos Mesh 主要包含以下三个组件:
- Chaos Dashboard：Chaos Mesh 的可视化组件，提供了一套用户友好的 Web 界面，用户可通过该界面对混沌实验进行操作和观测。同时，Chaos Dashboard 还提供了 RBAC 权限管理机制。
- Chaos Controller Manager：Chaos Mesh 的核心逻辑组件，主要负责混沌实验的调度与管理。该组件包含多个 CRD Controller，例如 Workflow Controller、Scheduler Controller 以及各类故障类型的 Controller。
- Chaos Daemon：Chaos Mesh 的主要执行组件。Chaos Daemon 以 DaemonSet 的方式运行，默认拥有 Privileged 权限（可以关闭）。该组件主要通过侵入目标 Pod Namespace 的方式干扰具体的网络设备、文件系统、内核等。
Chaos Mesh 的整体架构如上图所展示，可以自上而下分为三个部分：
- 用户输入和观测的部分。用户输入以用户操作 (User) 为起点到达 Kubernetes API Server。用户不直接和 Chaos Mesh 的 Controller 交互，一切用户操作最终都将反映为某个 Chaos 资源的变更（比如 NetworkChaos 资源的变更）。
- 监听资源变化、调度工作流和开展混沌实验的部分。Chaos Mesh 的 Controller 只接受来自 Kubernetes API Server 的事件，这种事件描述某个 Chaos 资源的变更，例如新的工作流对象或者 Chaos 对象被创建。
- 具体节点故障的注入部分。该部分主要由 Chaos Daemon 组件负责，接受来自 Chaos Controller Manager 组件的指令，侵入到目标 Pod 的 Namespace 下，执行具体的故障注入。例如设置 TC 网络规则，启动 stress-ng 进程抢占 CPU 或内存资源等。