Helmで Collector for Kubernetes を設定する

OpenTelemetry Collector for Kubernetes の Splunk ディストリビューションのオプション設定。

Collector for Kubernetes をインストールした後、どの設定を構成できるかを学ぶには、続けてお読みください。

さらに、次を参照してください。

Kubernetes 用に Collector を設定する方法の実践的な例については「チュートリアル：Kubernetes での OpenTelemetry Collector の Splunk 配布の設定」を参照してください。

注意: values.yaml ファイルには、Helm チャートの各コンポーネントで設定可能なすべてのパラメータが一覧と説明付きで記載されています。詳しくは「Helm chart architecture and components」を参照してください。このグラフの設定方法を理解するために内容を確認してください。また、この Helm グラフは、トレースサンプリングやプロキシサーバー経由でのデータ送信など、さまざまなユースケースに対応するよう設定することもできます。詳細については、「チャートの設定例」を参照してください。

Kubernetesディストリビューションを設定する

該当する場合は、distribution パラメータを使用して、基礎となる Kubernetes デプロイメントに関する情報を指定します。このパラメータにより、コネクタは追加のメタデータを自動的に取得できます。次のオプションがサポートされます。

Azure AKS 用 aks
Amazon EKS用 eks
Amazon EKS (Fargate プロファイルあり) 用 eks/fargate
Amazon EKS（Auto Mode あり）用 eks/auto-mode
Google GKE または標準モード用 gke
Google GKE またはオートパイロットモード用 gke/autopilot
Red Hat OpenShift 用 openshift

以下を適用してディストリビューションを設定してください：

# aks deployment
--set distribution=aks,cloudProvider=azure

# eks deployment
--set distribution=eks,cloudProvider=aws

# eks/fargate deployment (with recommended gateway)
--set distribution=eks/fargate,gateway.enabled=true,cloudProvider=aws

# eks/auto-mode deployment
--set distribution=eks/auto-mode

# gke deployment
--set distribution=gke,cloudProvider=gcp

# gke/autopilot deployment
--set distribution=gke/autopilot,cloudProvider=gcp

# openshift deployment (openshift can run on multiple cloud providers, so cloudProvider is excluded here)
--set distribution=openshift

例：

splunkObservability:
  accessToken: xxxxxx
  realm: us0
clusterName: my-k8s-cluster
distribution: gke

Google Kubernetes Engineを設定する

GKE オートパイロットを設定する

Collector を GKE オートパイロットモードで実行するには、distribution オプションを gke/autopilot に設定します：

distribution: gke/autopilot

詳細については、Google Cloud ドキュメントサイトで「Autopilot overview」と検索してください。

注: GKE Autopilot は、ネイティブの OpenTelemetry ログ収集をサポートしていません。

Collector エージェントの DaemonSet では、Autopilot モードでのスケジュールに問題が発生する場合があります。問題が発生した場合は DaemonSet に高い優先度クラスを割り当てて、DaemonSet のポッドが各ノードに常に存在するようにしてください。

Collector エージェントに新しい優先クラスを作成します：

cat <<EOF | kubectl apply -f -
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: splunk-otel-agent-priority
value: 1000000
globalDefault: false
description: "Higher priority class for the Splunk Distribution of OpenTelemetry Collector pods."
EOF

作成した優先度クラスをhelm install/upgradeコマンドで --set="priorityClassName=splunk-otel-agent-priority" 引数を使用して使用するか、カスタムvalues.yamlに以下の行を追加します：
```
priorityClassName: splunk-otel-agent-priority
```

GKE ARM サポート

Helm チャートのデフォルト設定は、GKE 上の ARM ワークロードをサポートしています。distribution の値を必ず gke に設定してください。

distribution: gke

Amazon Elastic Kubernetes Service Fargateを設定する

Amazon EKSでFargateプロファイルを使用してCollectorを実行するには、次の例に示すように、必要な distribution 値を eks/fargate に設定します：

distribution: eks/fargate

注: FluentdとネイティブのOpenTelemetryログ収集は、Fargateプロファイルを持つEKSでは自動的に設定されません。

この分布は、eks の分布と同様に機能するが、次のような違いがあります：

Fargate は DaemonSet をサポートしていないため、Collector エージェントの DaemonSet は適用されません。エージェントとして実行する必要がある Collector インスタンスは、カスタムデプロイメント内でサイドカーコンテナとして手動で設定する必要があります。これには、Fluentd などのアプリケーションロギングサービスが含まれます。gateway.enabled を true に設定し、インストルメンテーションされたアプリケーションがメトリクス、トレース、およびログをゲートウェイの <installed-chart-name>-splunk-otel-collector サービスアドレスに報告するように設定します。DaemonSet として実行したいエージェントインスタンスは、代わりにポッドのサイドカーコンテナとして実行する必要があります。
Fargate ノードは VM 境界を使用して他のポッドが使用するホストベースのリソースへのアクセスを防止するため、ポッドは独自の kubelet に到達できません。Fargate ディストリビューション向けのクラスターレシーバには、この制限を回避するために通常の eks と比べて主に2つの違いがあります。
- 構成されたクラスターレシーバは、Deployment ではなく 2 つのレプリカを持つ StatefulSet としてデプロイされ、Kubernetes Observer 拡張機能を使用します。この拡張機能は、クラスターのノードと、2 番目のレプリカのポッドを検出し、ユーザー設定可能なレシーバクリエーターの追加を可能にします。この Observer を使用すると、観測されたすべての Fargate ノードの kubelet メトリクスを報告する Kubelet Stats レシーバインスタンスが動的に作成されます。最初のレプリカは、k8s_cluster レシーバでクラスターを監視し、2 番目のクラスターは（EKS/Fargate のネットワーキング制限により）自分自身を除くすべての Kubelet を監視します。
- 最初のレプリカの Collector は、2 番目の Kubelet を監視します。これは、Fargate 固有の splunk-otel-eks-fargate-kubeletstats-receiver-node ノードラベルによって実現されています。eks/fargate の Collector ClusterRole は、デフォルトの API グループの nodes リソースに対する patch 動詞を許可します。これにより、クラスターレシーバの init コンテナが、指定された自己監視用にこのノードラベルを追加できるようになります。

クラスター名の設定

Kubernetes クラスターの名前を指定するには clusterName パラメータを使用します。このパラメータは eks、eks/fargate、gke、gke/autopilot のディストリビューションではオプションですが、その他のディストリビューションでは必須となります。

以下を適用してクラスター名を設定します：

--set clusterName=my-k8s-cluster

例：

clusterName: my-k8s-cluster

デプロイ環境を設定する

該当する場合は、environment パラメータを使用して、すべてのテレメトリデータに追加する追加の deployment.environment 属性を指定します。この属性は、Splunk Observability Cloud のユーザーが、さまざまなソースからのデータを個別に調査するのに役立ちます。値の例として、development、staging、productionなどがあります。

splunkObservability:
  accessToken: xxxxxx
  realm: us0
environment: production

クラウドプロバイダーを設定する

該当する場合は、cloudProvider パラメータを使用して、クラウドプロバイダに関する情報を提供します。次のオプションがサポートされます。

aws アマゾンウェブサービス
gcp for Google Cloud Platform
azure for Microsoft Azure

クラウドプロバイダを設定し、リソース検出プロセッサーに cloud.platform を構成するには、次を使用します：

--set cloudProvider={azure|gcp|eks|openshift}

例：

splunkObservability:
  accessToken: xxxxxx
  realm: us0
clusterName: my-k8s-cluster
cloudProvider: aws

エージェントのホストネットワークの使用を設定する

デフォルトでは agent.hostNetwork は true に設定されています。これにより、エージェントの DaemonSet ポッドにノードのホストネットワークへのアクセス権が付与され、特定の要素をモニターできるようになります。ホストネットワークへのアクセスが必要な一部のコントロールプレーンコンポーネントやインテグレーションを監視する場合は、この設定を有効にしてください。

ホストネットワークへのアクセスをオフにするには、agent.hostNetwork を false に設定してください。これは、特定の組織のセキュリティポリシーに準拠するために必要な場合があります。ホストネットワークアクセスが無効化されている場合、エージェントのモニタリング機能が制限される可能性があります。

Windowsではこの値は無視されます。

AlwaysOn Profilingの有効化

Splunk APM の AlwaysOn プロファイリングではスタックトレースが継続的にキャプチャされるため、コードにおけるパフォーマンスのボトルネックや問題を特定するのに役立ちます。プロファイリングを有効にすると、Kubernetes アプリケーションがこのデータを生成し、可視化のために Splunk Observability Cloud に転送できるようになります。

Collectorは、logs パイプラインを使用してプロファイリングデータをインジェストします。

詳細については、「アプリケーションとサービスの自動検出」および「Splunk APM 向けの AlwaysOn プロファイリングの概要」を参照してください。

プロファイリングのセットアップ

UIウィザードを使用して Collector for Kubernetes をインストールする際、または設定ファイルを変更することで、プロファイリングを有効にできます。

プロファイリングには2つの主要コンポーネントが使用されます: プロファイリングデータの受信と Splunk Observability Cloud へのエクスポートを担当する Collector と、プロファイリングデータとともにトレースを生成および出力できるようにアプリケーションを自動インストルメンテーションする Operator です。

主に2つのシナリオがあります：

CollectorとOperatorの両方を使用したプロファイリング：Operatorはアプリケーションを自動インストルメンテーションし、プロファイリングデータをCollectorに送信します。
Collectorのみを使用したプロファイリング：アプリケーションを手動でインストルメンテーションしてプロファイリングデータを生成し、Collectorに直接送信します。

CollectorとOperatorでプロファイリングを有効にする

CollectorとOperatorでプロファイリングを有効にするには、UIで Profiling オプションを有効にするか、次の設定でHelmチャートをデプロイします：

Collectorの場合：

splunkObservability:
  accessToken: CHANGEME
  realm: us0
  logsEnabled: true
  profilingEnabled: true

Operatorのために

operatorcrds:
  install: true
operator:
  enabled: true

以上のような設定により：

Collectorはプロファイリングデータを受信するように設定されています。
Operatorはデプロイされ、ターゲットポッドのアノテーションに基づいてアプリケーションを自動インストルメンテーションし、これらのアプリケーションがプロファイリングデータを生成できるようにします。

Collectorでのみプロファイリングを有効にする

Collectorのみを使用し、アプリケーションを手動でインストルメンテーションする場合は、splunkObservability.logsEnabled=true および splunkObservability.profilingEnabled=true が設定されていることを確認してください。

注意: このオプションを使用すると、インストルメンテーションされたアプリケーションを手動でセットアップして、プロファイリングデータをCollectorに直接送信する必要があります。

トークンをシークレットとして提供する

トークンを設定ファイルにクリアテキストとして持つ代わりに、チャートをデプロイする前に作成されたシークレットとして提供することができます。必須フィールドについては「secret-splunk.yaml」を参照してください。

secret:
  create: false
  name: your-secret

Windowsワーカーノードを設定する

OpenTelemetry Collector for Kubernetes の Splunk Distribution は、Windows ノードからのメトリクス、トレース、ログ（OpenTelemetry ネイティブログ収集のみを使用）の収集をサポートしています。すべての Windows イメージは quay.io/signalfx/splunk-otel-collector-windows リポジトリから入手可能です。

以下の設定を使用して、WindowsワーカーノードにHelmチャートをインストールします：

isWindows: true
image:
  otelcol:
    repository: quay.io/signalfx/splunk-otel-collector-windows
logsEngine: otel
readinessProbe:
  initialDelaySeconds: 60
livenessProbe:
  initialDelaySeconds: 60

Kubernetes クラスターに Windows と Linux の両方のワーカーノードがある場合は、Helm チャートを 2 回インストールする必要があります。デフォルト設定が isWindows: false に設定されているインストールの 1 つが Linux ノードに適用されます。values.yaml 構成を使用した 2 番目のインストール（前の例に示したもの）は、Windows ノードに適用されます。

クラスター全体でメトリクスの重複が起きることを避けるために、いずれかのインストールで clusterReceiver を非アクティブにします。これを行うには、インストールのいずれかの構成に次の行を追加します。

clusterReceiver:
  enabled: false