OpenTelemetry Operator について知らないかもしれないこと - OTel Operator Q&A

By Adriana Villela (ServiceNow) | Monday, May 13, 2024

Blog posts are not updated after publication. This post is more than a year old, so its content may be outdated, and some links may be invalid. Cross-verify any information before relying on it.

飛行機から見た雲の上にそびえるシアトルのマウントレーニア。写真: Adriana Villela

OpenTelemetry（OTel）Operator は、Kubernetes クラスター内で OTel を管理し、作業を少し楽にしてくれる Kubernetes Operator です。以下のことを行います。

OpenTelemetry Collector のデプロイメントを管理します。 OpenTelemetryCollector カスタムリソース（CR）によってサポートされています。
OpAMP 統合を通じて、OpenTelemetry Collector のフリートの設定を管理します。 OpAMPBridge カスタムリソースによってサポートされています。
Prometheus Operator の PodMonitor および ServiceMonitor CR との統合を提供します。
自動計装を Pod にインジェクションして設定します。 Instrumentation カスタムリソースによってサポートされています。

この1年で Operator を使う機会があり、いくつかのクールなことを学んだので、Q&A の形式で、OTel Operator に関するちょっとした豆知識を共有するのが役立つと思いました。

この記事は、OpenTelemetry、OpenTelemetry Collector、OpenTelemetry Operator（Target Allocator を含む）、および Kubernetes についてある程度の知識があることを前提としています。

Q&A

Q1: Operator は複数の Collector 設定ソースをサポートしていますか

簡潔な回答: いいえ。

詳細な回答: OTel Collector には複数の Collector 設定 YAML ファイルを渡すことができます。これにより、基本設定を otelcol-config.yaml に保持し、基本設定のオーバーライドや追加を otelcol-config-extras.yaml などに入れることができます。 OTel Demo の Docker compose ファイルでこの例を確認できます。

残念ながら、OTel Collector は複数の Collector 設定ファイルをサポートしていますが、OTel Operator によって管理される Collector はサポートしていません。

これを回避するには、事前に外部ツールを使用して複数の Collector 設定をマージすることができます。たとえば、Helm を使って Operator をデプロイしている場合、複数の –values フラグを使用して複数の Collector 設定ファイルを渡し、Helm にマージを任せることができます。

NOTE: この PR にあるように、将来的には設定を指定するためのより高レベルな構成を提供する計画があります。

参考までに、#otel-operator CNCF Slack チャンネルのこのスレッドをご覧ください。

Q2: Collector の設定でアクセストークンを安全に参照するにはどうすればよいですか

OpenTelemetry データをオブザーバビリティバックエンドに送信するには、少なくとも1つのエクスポーターを定義する必要があります。 OTLP を使用するかベンダー独自のフォーマットを使用するかにかかわらず、ほとんどのエクスポーターでは、ベンダーバックエンドにデータを送信する際にエンドポイントとアクセストークンを指定する必要があります。

OpenTelemetry Operator を使用して OTel Collector を管理する場合、OTel Collector の設定 YAML は OpenTelemetryCollector CR で定義されます。このファイルはバージョン管理されるべきであるため、平文で保存されたアクセストークンを含む機密データを含めるべきではありません。

幸い、OpenTelemetryCollector CR ではその値をシークレットとして参照する方法が提供されています。以下がその方法です。

1- アクセストークン用の Kubernetes シークレットを作成します。シークレットを base-64 エンコードすることを忘れないでください。

2- OpenTelemetryCollector CR の env セクションに追加して、シークレットを環境変数として公開します。例：

env:
  - name: TOKEN_VALUE
    valueFrom:
      secretKeyRef:
        key: TOKEN_VALUE
        name: otel-collector-secret

3- エクスポーターの定義で環境変数を参照します。

exporters:
  otlp:
    endpoint: '<your_backend_endpoint_here>'
    headers:
      '<token_name>': '${TOKEN_VALUE}'

詳細については、完全な例と手順を参照してください。

Q3: Operator のバージョンは Collector のバージョンと同等ですか

Collector のリリースごとに、その Collector バージョンをサポートする Operator のリリースがあります。たとえば、この記事の執筆時点で、最新の Operator バージョンは 0.98.0 です。したがって、Operator が使用する Collector のデフォルトイメージは、コアディストリビューション（contrib ディストリビューションではなく）のバージョン 0.98.0 です。

Q4: ベースの OTel Collector イメージをオーバーライドできますか

はい！実際、オーバーライドすべきかもしれません！

先ほど見たように、コアディストリビューションは OpenTelemetryCollector CR で使用されるデフォルトの Collector ディストリビューションです。コアディストリビューションは、OTel 開発者が開発やテストを行うための最小限の Collector ディストリビューションです。基本的なコンポーネントセット、つまりエクステンション、コネクター、レシーバー、プロセッサー、エクスポーターが含まれています。

コアが提供するコンポーネントよりも多くのコンポーネントにアクセスしたい場合は、かわりに Collector の Kubernetes ディストリビューションを使用できます。このディストリビューションは、Kubernetes クラスター内で Kubernetes およびそこで動作するサービスを監視するために特別に作られています。 OpenTelemetry Collector Core と OpenTelemetry Collector Contrib のコンポーネントのサブセットが含まれています。

独自の特定の Collector コンポーネントを使用したい場合は、OpenTelemetry Collector Builder（OCB）を使用して独自のディストリビューションをビルドし、必要なコンポーネントのみを含めることができます。

いずれの場合も、OpenTelemetryCollector CR では、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 にバンドルされていますが、スタンドアロンでインストールできるため、Target Allocator でこの2つの CR を使用するためだけに Prometheus Operator をインストールする必要はありません。

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

ServiceMonitor を使用した OpenTelemetry Operator の Target Allocator の例を参照してください。

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 を参照してください。

NOTE: これはバージョン 0.100.0 の一部として、近い将来完全に自動化される予定です（付随する PR を参照）。

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 のベースイメージのオーバーライドが推奨されていないなら、なぜオーバーライドしたいのですか

1つのユースケースは、セキュリティ上の理由で、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 チャンネルに質問を投稿することを強くお勧めします。メンテナーやコントリビューターはとても親切で、いつも質問に喜んで答えてくれます！私に連絡していただければ、質問にお答えするか、回答を持っている方をご紹介するよう最善を尽くします！

最終更新 June 28, 2026: [ja] add translation of content/en/blog/2024/otel-operator-q-and-a/index.md (#10561) (ee3ecff1)