关于 OpenTelemetry Operator，您可能不知道的事情 - OTel Operator 问答
博客文章在发布后不会更新。这篇文章已经发布一年多了，其内容可能已过时，部分链接可能无效。在依赖任何信息之前，请务必核实。
OpenTelemetry (OTel) Operator 是一个 Kubernetes Operator，它为您管理 Kubernetes 集群中的 OTel，以使生活更轻松。它执行以下操作：
- 管理 OpenTelemetry Collector 的部署，该部署由
OpenTelemetryCollector自定义资源 (CR) 支持。 - 通过 OpAMP 集成管理 OpenTelemetry Collector 舰队的配置，该集成由
OpAMPBridge自定义资源支持。 - 提供 与 Prometheus Operator 的
PodMonitor和ServiceMonitorCR 的集成。 - 将 自动注入 (autoinstrumentation) 注入您的 Pod 并进行配置，该注入由
Instrumentation自定义资源支持。
在过去一年中，我曾有机会使用 Operator，并学到了一些非常酷的东西，因此我想以问答的形式分享一些我一路走来学到的小 OTel Operator 技巧。
请注意，本文假定您对 OpenTelemetry、OpenTelemetry Collector、OpenTelemetry Operator（包括 Target Allocator）以及 Kubernetes 有一定的了解。
问答
Q1: Operator 是否支持多个 Collector 配置源？
简短回答：否。
更长的回答：OTel Collector 可以接收多个 Collector 配置文件。这样，您可以将基础配置保留在 otelcol-config.yaml 中，而对基础配置的覆盖或添加可以放在 otelcol-config-extras.yaml 中。请参阅 OTel Demo 的 Docker compose 文件 中的示例。
不幸的是，虽然 OTel Collector 支持多个 Collector 配置文件，但 OTel Operator 管理的 Collector 不支持。
要解决此问题，您可以通过外部工具预先合并多个 Collector 配置。例如，如果您 通过 Helm 部署 Operator，则可以通过 使用多个 –values 标志传递多个 Collector 配置文件，并让 Helm 为您完成合并。
注意： 如 此 PR 所述，未来有计划提供更高级别的构造来指定配置。
作为参考，请 查看 CNCF Slack 上的 #otel-operator 频道中的此讨论串。
Q2: 如何在 Collector 的配置中安全地引用访问令牌？
为了将 OpenTelemetry 数据发送到可观察性后端，您必须至少定义一个 exporter。无论您使用 OTLP 还是 某种专有供应商格式，大多数 exporter 在发送数据到供应商后端时通常都需要您指定端点和访问令牌。
当使用 OpenTelemetry Operator 管理 OTel Collector 时，OTel Collector 配置 YAML 定义在 OpenTelemetryCollector CR 中。此文件应进行版本控制，因此不应包含任何敏感数据，包括明文存储的访问令牌。
幸运的是，OpenTelemetryCollector CR 为我们提供了一种引用该值的 secret 的方法。方法如下：
1. 为您的访问令牌创建一个 Kubernetes secret。请记住 base-64 编码此 secret。
2. 将 secret 公开为环境变量，方法是将其添加到 OpenTelemetryCollector CR 的 env 部分。例如：
env:
- name: TOKEN_VALUE
valueFrom:
secretKeyRef:
key: TOKEN_VALUE
name: otel-collector-secret
3. 在您的 exporter 定义中引用环境变量。
exporters:
otlp:
endpoint: '<your_backend_endpoint_here>'
headers:
'<token_name>': '${TOKEN_VALUE}'
Q3: Operator 版本是否与 Collector 版本同步？
对于每一次 Collector 发布，都会有一个 Operator 版本支持该 Collector 版本。例如，在撰写本文时，最新的 Operator 版本是 0.98.0。因此，Operator 使用的 Collector 的默认镜像版本是 0.98.0 的 核心发行版（而不是 contrib 发行版）。
Q4: 我可以覆盖 OTel Collector 的基础镜像吗？
是的！事实上，您可能应该这样做！
如前所述，核心发行版是 OpenTelemetryCollector CR 使用的默认 Collector 发行版。核心发行版是 Collector 的基本发行版，供 OTel 开发人员进行开发和测试。它包含一组基本组件 - 即 extensions、connectors、receivers、processors 和 exporters。
如果您希望访问比核心发行版提供的组件更多的组件，可以使用 Collector 的 Kubernetes 发行版。此发行版专为在 Kubernetes 集群中使用而设计，用于监控 Kubernetes 和在 Kubernetes 中运行的服务。它包含 OpenTelemetry Collector Core 和 OpenTelemetry Collector Contrib 中的组件子集。
如果您想使用自己的特定 Collector 组件，您可以使用 OpenTelemetry Collector Builder (OCB) 构建自己的发行版，并仅包含您需要的组件。
无论哪种方式，OpenTelemetryCollector CR 都允许您通过在 OpenTelemetryCollector YAML 中 添加 spec.image 来覆盖默认 Collector 镜像，以更好地满足您的需求。此外，您还可以通过 添加 spec.replicas 来指定 Collector 副本数量。这与您是否覆盖 Collector 镜像完全无关。
您的代码看起来会像这样：
apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
name: otelcol
namespace: mynamespace
spec:
mode: statefulset
image: <my_collector_image>
replicas: <number_of_replicas>
其中：
<my_collector_image>是来自容器仓库的有效 Collector 镜像名称。<number_of_replicas>是底层 OpenTelemetry Collector 的 Pod 实例数量。
请记住，如果您是从私有容器注册表中拉取 Collector 镜像，您将需要使用 imagePullSecrets。由于私有容器注册表需要身份验证，这将使您能够对该私有注册表进行身份验证。有关如何为 Collector 镜像使用 imagePullSecrets 的更多信息，请参阅 说明。
有关更多信息，请查阅 OpenTelemetryCollector CR API 文档。
Q5: Target Allocator 是否适用于所有部署类型？
否。Target Allocator 仅适用于 StatefulSet 和 DaemonSet（新引入的）。有关更多信息，请参阅 collector_webhook.go。
Q6: 如果我在 Target Allocator 中启用了 prometheusCR，我是否需要在我的 Kubernetes 集群中安装 PodMonitor 和 ServiceMonitor CR？
是的，您需要。这些 CR 与 Prometheus Operator 一起提供；但是，它们可以独立安装，这意味着您无需安装 Prometheus Operator 即可将这两个 CR 与 Target Allocator 一起使用。
安装 PodMonitor 和 ServiceMonitor CR 的最简单方法是获取单个 PodMonitor YAML 和 ServiceMonitor YAML 自定义资源定义 (CRD) 的副本，如下所示：
kubectl --context kind-otel-target-allocator-talk apply -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/main/example/prometheus-operator-crd/monitoring.coreos.com_servicemonitors.yaml
kubectl --context kind-otel-target-allocator-talk apply -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/main/example/prometheus-operator-crd/monitoring.coreos.com_podmonitors.yaml
请参阅我关于 OpenTelemetry Operator 的 Target Allocator 与 ServiceMonitor 的示例。
Q7: 我需要创建服务账户来使用 Target Allocator 吗？
不，但您需要做一些额外的工作。情况是这样的...虽然您需要一个 服务账户来使用 Target Allocator，但您不必创建自己的。
如果您启用 Target Allocator 并且不创建服务账户，那么系统会自动为您创建一个。该服务账户的默认名称是 Collector 名称（OpenTelemetryCollector CR 中的 metadata.name）和 -collector 的连接。例如，如果您的 Collector 名为 mycollector，那么您的服务账户将命名为 mycollector-collector。
默认情况下，此服务账户没有任何已定义的策略。这意味着您仍然需要创建自己的 ClusterRole 和 ClusterRoleBinding，并通过 ClusterRoleBinding 将 ClusterRole 关联到 ServiceAccount。
有关 Target Allocator RBAC 配置的更多信息，请参阅 Target Allocator 的 readme。
注意： 在不久的将来，这将完全自动化（请参阅附带的 PR），作为版本
0.100.0的一部分。
Q8: 我可以覆盖 Target Allocator 的基础镜像吗？
就像您可以在 OpenTelemetryCollector CR 中覆盖 Collector 的基础镜像一样，您也可以覆盖 Target Allocator 的基础镜像。
请记住，通常最好保持 Target Allocator 和 OTel Operator 版本相同，以避免任何兼容性问题。如果您确实选择覆盖 Target Allocator 的基础镜像，可以通过在 OpenTelemetryCollector CR 中添加 spec.targetAllocator.image 来实现。您还可以通过添加 spec.targetAllocator.replicas 来指定副本数量。这与您是否覆盖 TA 镜像完全无关。
您的代码看起来会像这样：
apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
name: otelcol
namespace: mynamespace
spec:
mode: statefulset
targetAllocator:
image: <ta_image_name>
replicas: <number_of_replicas>
其中：
<ta_image_name>是来自容器仓库的有效 Target Allocator 镜像。<number_of_replicas>是底层 Target Allocator 的 Pod 实例数量。
Q9: 如果不建议覆盖 Target Allocator 的基础镜像，那么您为什么要这样做？
一个用例可能是 如果您需要将 Target Allocator 镜像托管在自己的私有容器注册表中以提高安全性。
如果您确实需要引用来自私有注册表的 Target Allocator 镜像，您将需要使用 imagePullSecrets。有关详细信息，请参阅 说明。请注意，您不需要为 Target Allocator 创建 serviceAccount，因为如果您不自己创建，它会自动为您创建一个（请参阅 Q7）。
有关更多信息，请查阅 Target Allocator API 文档。
Q10: OTel Operator 的自动注入与支持语言的自动注入之间是否存在版本滞后？
如果存在滞后，则非常小，因为维护者会尝试在每个发布周期中保持这些更新。请记住，某些语义约定会发生破坏性更改，团队正试图避免破坏用户的代码。有关详细信息，请参阅此 #otel-operator 讨论串。
最后的思考
希望这能帮助您更清晰地了解 OTel Operator。它确实涉及很多内容，而且 OTel Operator 一开始肯定会让人有些畏惧，但了解一些基本知识将使您能够熟练掌握这个强大的工具。
如果您对 OTel Operator 有任何疑问，我强烈建议您在 CNCF Slack 的 #otel-operator 频道上提问。维护者和贡献者非常友好，并且一直非常乐意回答我的问题！您也可以 联系我，我会尽力回答您的问题，或将您引荐给有答案的人！