在OPAMP协议中，我们区分了服务端（通常托管在控制面中）和客户端（想要管理的agent）。例如，使用OPAMP协议管理opentelemetry collector集群，如下所示：
collector向OpAMP控制面报告自身状态，并从中接收配置信息。OpAMP协议是一个通用的与供应商无关的协议，不仅仅是给OTel使用。因此OpAMP服务端可以远程监控和管理一系列的不同的agent。OpAMP支持且不限于以下功能：
- Agent，例如openTelemetry-collector，它们能够上报自身属性（类型/版本号等）以及操作系统详情到服务端（OpAMP控制面）
- 服务端能够推送配置到agent，并且保证这些配置被加载（例如重启agent）。
- 能够在支持OTLP协议的可观测后端查看agent本身的遥测数据（日志、指标等）
- 安全的自动升级能力，同时支持升级和降级
- 内置连接证书管理功能，包括客户端TLS证书吊销、轮换。
现在我们已经大致了解了 OpAMP 是什么以及它支持什么，让我们来看看 了解如何在 OpenTelemetry Collector 中实现它。
在与 OTel 最终用户和收集器贡献者的讨论中，OpAMP团队发现用户希望OpAMP同时具备2种使用方式：作为collector的扩展（OpAMP extension），功能简单；以及作为单独运行的管理程序（OpAMP supervisor），带有OpAMP的大量功能。
要实现以这两种模式运行，需要为collector实现一个带有最小功能的OpAMP扩展。这个collector扩展可以被它自身使用，并且能够创建一个外部管理程序，这个外部管理程序使用内部扩展作为辅助，实现了OpAMP的其余功能，并运行在这些collector之上。
下面首先描述OpAMP extension，然后再描述作为外部管理的OpAMP supervisor。
OpAMP extension
openTelemetry collector OpAMP extension会在collector内部实现一个OpAMP客户端，支持在独立、监督模式中管理collector实例。与supervisor一起工作时，OpAMP extension的功能在supervisor设计文档中定义，它的功能主要用于supervisor的启动信息，以及传递collector的有效配置信息。
OpAMP supervisor
OpAMP supervisor会以独立二进制文件出现，用于运行OpenTelemetry collector 实例，并实现OpAMP客户端，作为OpAMP服务端到collector之间的配置管理中介，合并远程配置以及本地配置到一个文件中，提供给collector在启动时使用。监督模式下，也允许通过OpAMP下载额外的二进制文件和额外的配置文件，用于升级collector。
另外，如果OpAMP下发了一个“坏”的配置给supervisor，以至于collector无法启动，以独立进程运行的supervisor能够与OpAMP服务端通信以告知此事。除了实现OpAMP客户端之外，supervisor还会实现一个OpAMP服务端，用于与collector中的extension通信，从中接收collector信息。在这个设计文档中定义了supervisor的功能，并且基于此提供了一个初始化的实现，带有issue列表用于指导后续的开发工作。
Kubernates中的OpAMP
OTel中，为作为计算平台的k8s做了专门支持。因此OpAMP也会支持K8s，通过使用openTelemetry operator部署一个桥接组件来支持。（注意：当前OpAMP团队并没有支持通过Helm chart来部署，欢迎其他人来做这件事）
OpAMP桥接器是由OTel SIG Kubernetes Operator 开发的一个可执行文件，它负责维护k8s中的OpenTelemetry collector集群。在OpAMP服务端方面看，这个桥接器是一个OpAMP客户端，用于上报collector的有效配置，为collector开启远程配置功能。在未来，基于增强型的状态上报和健康检查功能，这个桥接器可以上报collector的更丰富的信息。用户也可以扩展桥接器，以支持对Instrument资源的远程配置管理功能。此外，OpAMP团队还在开发一个方便的自定义资源定义（CDR），使得用户能够轻松地将这个桥接器部署到k8s集群中。
