Kubernetes への OpenTelemetry Collector のデプロイ

1. EC2 インスタンスへの接続

Mac、Linux、またはWindowsデバイスからSSHを使用してワークショップインスタンスに接続できます。インストラクターから提供されたシートへのリンクを開いてください。このシートには、ワークショップインスタンスのIPアドレスとパスワードが記載されています。

2. Helm を使用した Splunk OTel のインストール

Splunk Helmチャートを使用してOpenTelemetry Collectorをインストールします。まず、Splunk Helmチャートリポジトリを追加して更新します:

helm repo add splunk-otel-collector-chart https://signalfx.github.io/splunk-otel-collector-chart && helm repo update

Using ACCESS_TOKEN=<REDACTED>
Using REALM=eu0
"splunk-otel-collector-chart" has been added to your repositories
Using ACCESS_TOKEN=<REDACTED>
Using REALM=eu0
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "splunk-otel-collector-chart" chart repository
Update Complete. ⎈Happy Helming!⎈

以下のコマンドでOpenTelemetry Collector Helmをインストールします。編集しないでください:

helm install splunk-otel-collector --version 0.136.0 \
--set="splunkObservability.realm=$REALM" \
--set="splunkObservability.accessToken=$ACCESS_TOKEN" \
--set="clusterName=$INSTANCE-k3s-cluster" \
--set="splunkPlatform.endpoint=$HEC_URL" \
--set="splunkPlatform.token=$HEC_TOKEN" \
--set="splunkPlatform.index=splunk4rookies-workshop" \
splunk-otel-collector-chart/splunk-otel-collector \
-f ~/workshop/k3s/otel-collector.yaml

3. デプロイの確認

kubectl get pods を実行してデプロイの進行状況を監視できます。通常、約30秒後に新しいPodが起動して実行中であることが報告されます。

続行する前に、ステータスが Running と報告されていることを確認してください。

kubectl get pods

NAME                                                         READY   STATUS    RESTARTS   AGE
splunk-otel-collector-agent-ks9jn                            1/1     Running   0          27s
splunk-otel-collector-agent-lqs4j                            0/1     Running   0          27s
splunk-otel-collector-agent-zsqbt                            1/1     Running   0          27s
splunk-otel-collector-k8s-cluster-receiver-76bb6b555-7fhzj   0/1     Running   0          27s

helm インストールで設定されたラベルを使用してログを追跡します（終了するには ctrl + c を押す必要があります）。

kubectl logs -l app=splunk-otel-collector -f --container otel-collector

または、インストール済みの k9s ターミナルUIを使用します。

helm delete splunk-otel-collector

K8s Namespaces と DNS

1. Kubernetes における Namespaces

多くのお客様は、Kubernetesを実行するために何らかのプライベートまたはパブリッククラウドサービスを利用しています。一元管理が容易であるため、少数の大規模なKubernetesクラスターのみを持つことを選択することが多いです。

Namespacesは、これらの大規模なKubernetesクラスターを仮想的なサブクラスターに整理する方法です。異なるチームやプロジェクトがKubernetesクラスターを共有する場合に役立ちます。これにより、自分のリソースだけを簡単に表示して作業できるようになります。

クラスター内では任意の数のNamespacesがサポートされており、それぞれが論理的に分離されていますが、相互に通信する機能を持っています。コンポーネントは、Namespaceを選択した場合、または kubectl に --all-namespaces フラグを追加した場合にのみ表示されます。Namespaceを選択することで、プロジェクトに関連するコンポーネントのみを表示できます。

ほとんどのお客様は、アプリケーションを別のNamespaceにインストールすることを望んでいます。このワークショップでは、そのベストプラクティスに従います。

2. Kubernetes における DNS とサービス

Domain Name System（DNS）は、IPアドレスなどのさまざまな情報を覚えやすい名前にリンクするメカニズムです。DNSシステムを使用してリクエスト名をIPアドレスに変換することで、エンドユーザーは目的のドメイン名に簡単にアクセスできます。

ほとんどのKubernetesクラスターには、サービスディスカバリのための軽量なアプローチを提供するデフォルトで設定された内部DNSサービスが含まれています。Podやサービスが作成、削除、またはノード間で移動された場合でも、組み込みのサービスディスカバリにより、アプリケーションはKubernetesクラスター上のサービスを識別して通信することが簡素化されます。

簡単に言えば、KubernetesのDNSシステムは、各Podとサービスに対してDNSエントリを作成します。一般的に、Podは以下のDNS解決を持ちます:

pod-name.my-namespace.pod.cluster-domain.example

例えば、default Namespace内のPodが my_pod というPod名を持ち、クラスターのドメイン名が cluster.local の場合、Podは以下のDNS名を持ちます:

my_pod.default.pod.cluster.local

サービスによって公開されるPodは、以下のDNS解決が利用可能です:

my_pod.service-name.my-namespace.svc.cluster-domain.example

詳細については、こちらを参照してください: DNS for Service and Pods

Apache OTel Receiver

1. PHP/Apache 用の OTel Receiver の確認

YAMLファイル ~/workshop/k3s/otel-apache.yaml を確認し、以下のコマンドで内容を検証します:

cat ~/workshop/k3s/otel-apache.yaml

このファイルには、PHP/Apacheデプロイメントを監視するためのOpenTelemetryエージェントの設定が含まれています。

agent:
  config:
    receivers:
      receiver_creator:
        receivers:
          apache:
            rule: type == "port" && pod.name matches "apache" && port == 80
            config:
              endpoint: http://php-apache-svc.apache.svc.cluster.local/server-status?auto

2. OpenTelemetry 設定における観測ルール

上記のファイルには、OTel receiver_creator を使用したApacheの観測ルールが含まれています。このReceiverは、観測されたエンドポイントが設定されたルールに一致するかどうかに基づいて、実行時に他のReceiverをインスタンス化できます。

設定されたルールは、検出された各エンドポイントに対して評価されます。ルールがtrueと評価された場合、そのルールのReceiverは、一致したエンドポイントに対して設定どおりに開始されます。

上記のファイルでは、OpenTelemetryエージェントに対して、名前が apache に一致し、ポート 80 が開いているPodを探すように指示しています。見つかると、エージェントは設定されたURLからApacheメトリクスを読み取るApache Receiverを設定します。上記のYAML内のサービス用のK8s DNSベースのURLに注目してください。

Apache設定を使用するには、以下のコマンドで既存のSplunk OpenTelemetry Collector Helmチャートをアップグレードして otel-apache.yaml ファイルを使用します:

helm upgrade splunk-otel-collector \
--set="splunkObservability.realm=$REALM" \
--set="splunkObservability.accessToken=$ACCESS_TOKEN" \
--set="clusterName=$INSTANCE-k3s-cluster" \
--set="splunkPlatform.endpoint=$HEC_URL" \
--set="splunkPlatform.token=$HEC_TOKEN" \
--set="splunkPlatform.index=splunk4rookies-workshop" \
splunk-otel-collector-chart/splunk-otel-collector \
-f ~/workshop/k3s/otel-collector.yaml \
-f ~/workshop/k3s/otel-apache.yaml

Release "splunk-otel-collector" has been upgraded. Happy Helming!
NAME: splunk-otel-collector
LAST DEPLOYED: Mon Nov  4 14:56:25 2024
NAMESPACE: default
STATUS: deployed
REVISION: 2
TEST SUITE: None
NOTES:
Splunk OpenTelemetry Collector is installed and configured to send data to Splunk Platform endpoint "https://http-inputs-workshop.splunkcloud.com:443/services/collector/event".

Splunk OpenTelemetry Collector is installed and configured to send data to Splunk Observability realm eu0.

3. Kubernetes ConfigMaps

ConfigMapは、アプリケーションに注入できるキーと値のペアで構成されるKubernetesのオブジェクトです。ConfigMapを使用すると、設定をPodから分離できます。

ConfigMapを使用すると、設定データのハードコーディングを防ぐことができます。ConfigMapは、機密性のない暗号化されていない設定情報を保存および共有するのに便利です。

OpenTelemetry Collector/エージェントは、ConfigMapを使用してエージェントとK8s Cluster Receiverの設定を保存します。変更後にエージェントの現在の設定を確認するには、以下のコマンドを実行します:

kubectl get cm

NamespaceからConfigMapのリストを取得したら、otel-agent 用のものを選択し、以下のコマンドで表示します:

kubectl get cm splunk-otel-collector-otel-agent -o yaml

Apache のデプロイ

1. PHP/Apache デプロイメント YAML の確認

YAMLファイル ~/workshop/k3s/php-apache.yaml を確認し、以下のコマンドで内容を検証します:

cat ~/workshop/k3s/php-apache.yaml

このファイルには、PHP/Apacheデプロイメントの設定が含まれており、PHP/Apacheイメージの単一レプリカを持つ新しいStatefulSetを作成します。

ステートレスアプリケーションは、どのネットワークを使用しているかを気にせず、永続ストレージを必要としません。ステートレスアプリの例としては、Apache、Nginx、TomcatなどのWebサーバーがあります。

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: php-apache
spec:
  updateStrategy:
    type: RollingUpdate
  selector:
    matchLabels:
      run: php-apache
  serviceName: "php-apache-svc"
  replicas: 1
  template:
    metadata:
      labels:
        run: php-apache
    spec:
      containers:
      - name: php-apache
        image: ghcr.io/splunk/php-apache:latest
        ports:
        - containerPort: 80
        resources:
          limits:
            cpu: "8"
            memory: "8Mi"
          requests:
            cpu: "6"
            memory: "4Mi"

---
apiVersion: v1
kind: Service
metadata:
  name: php-apache-svc
  labels:
    run: php-apache
spec:
  ports:
  - port: 80
  selector:
    run: php-apache

2. PHP/Apache のデプロイ

apache Namespaceを作成し、PHP/Apacheアプリケーションをクラスターにデプロイします。

apache Namespaceを作成します:

kubectl create namespace apache

PHP/Apacheアプリケーションをデプロイします:

kubectl apply -f ~/workshop/k3s/php-apache.yaml -n apache

デプロイメントが作成されたことを確認します:

kubectl get statefulset -n apache

PHP/Apache の問題の修正

1. Kubernetes リソース

特に本番環境のKubernetesクラスターでは、CPUとメモリは貴重なリソースと見なされています。クラスター運用者は通常、デプロイメントでPodまたはサービスが必要とするCPUとメモリの量を指定するよう求めます。これにより、クラスターがソリューションを配置するノードを自動的に管理できます。

これは、アプリケーション/Podのデプロイメントにリソースセクションを配置することで行います。

例:

resources:
  limits:         # Maximum amount of CPU & memory for peek use
    cpu: "8"      # Maximum of 8 cores of CPU allowed at for peek use
    memory: "8Mi" # Maximum allowed 8Mb of memory
  requests:       # Request are the expected amount of CPU & memory for normal use
    cpu: "6"      # Requesting 4 cores of a CPU
    memory: "4Mi" # Requesting 4Mb of memory

詳細については、こちらを参照してください: Resource Management for Pods and Containers

アプリケーションまたはPodがデプロイメントで設定された制限を超えると、Kubernetesはクラスター上の他のアプリケーションを保護するためにPodを強制終了して再起動します。

もう1つのシナリオは、ノードに十分なメモリまたはCPUがない場合です。その場合、クラスターはより多くのスペースがある別のノードにPodを再スケジュールしようとします。

それが失敗した場合、またはアプリケーションをデプロイするときに十分なスペースがない場合、クラスターはワークロード/デプロイメントをスケジュールモードにして、利用可能なノードのいずれかに制限に従ってPodをデプロイするのに十分なスペースができるまで待機します。

2. PHP/Apache デプロイメントの修正

PHP/Apache StatefulSetを修正するには、以下のコマンドを使用して ~/workshop/k3s/php-apache.yaml を編集し、CPUリソースを削減します:

vim ~/workshop/k3s/php-apache.yaml

リソースセクションを見つけて、CPU limitsを 1 に、CPU requestsを 0.5 に削減します:

resources:
  limits:
    cpu: "1"
    memory: "8Mi"
  requests:
    cpu: "0.5"
    memory: "4Mi"

変更を保存します（ヒント: Esc を押してから :wq! を入力して変更を保存します）。

次に、既存のStatefulSetを削除して再作成する必要があります。StatefulSetは不変（イミュータブル）であるため、既存のものを削除して新しい変更で再作成する必要があります。

kubectl delete statefulset php-apache -n apache

次に、変更をデプロイします:

kubectl apply -f ~/workshop/k3s/php-apache.yaml -n apache

3. 変更の検証

以下のコマンドを実行して、変更が適用されたことを確認できます:

kubectl describe statefulset php-apache -n apache

PodがSplunk Observability Cloudで実行中であることを確認します。

数分間、Apache web servers Navigatorダッシュボードを監視してください。

4. メモリの問題の修正

Apacheダッシュボードに戻ると、メトリクスが送信されなくなっていることに気付くでしょう。別のリソースの問題があり、今回はメモリ不足です。StatefulSetを編集して、以下に示す値にメモリを増やしましょう:

kubectl edit statefulset php-apache -n apache

resources:
  limits:
    cpu: "1"
    memory: 16Mi
  requests:
    cpu: 500m
    memory: 12Mi

変更を保存します。

StatefulSetは不変（イミュータブル）であるため、既存のPodを削除して、StatefulSetが新しい変更で再作成できるようにする必要があります。

kubectl delete pod php-apache-0 -n apache

以下のコマンドを実行して、変更が適用されたことを確認します:

kubectl describe statefulset php-apache -n apache

ロードジェネレーターのデプロイ

それでは、php-apache Podに負荷をかけてみましょう。これを行うには、クライアントとして動作する別のPodを起動する必要があります。クライアントPod内のコンテナは無限ループで実行され、php-apache サービスにHTTP GETを送信し続けます。

1. loadgen YAML の確認

YAMLファイル ~/workshop/k3s/loadgen.yaml を確認し、以下のコマンドで内容を検証します:

cat ~/workshop/k3s/loadgen.yaml

このファイルには、ロードジェネレーターの設定が含まれており、ロードジェネレーターイメージの2つのレプリカを持つ新しいReplicaSetを作成します。

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: loadgen
  labels:
    app: loadgen
spec:
  replicas: 2
  selector:
    matchLabels:
      app: loadgen
  template:
    metadata:
      name: loadgen
      labels:
        app: loadgen
    spec:
      containers:
      - name: infinite-calls
        image: busybox
        command:
        - /bin/sh
        - -c
        - "while true; do wget -q -O- http://php-apache-svc.apache.svc.cluster.local; done"

2. 新しい Namespace の作成

kubectl create namespace loadgen

3. loadgen YAML のデプロイ

kubectl apply -f ~/workshop/k3s/loadgen.yaml --namespace loadgen

ロードジェネレーターをデプロイすると、loadgen NamespaceでPodが実行されているのを確認できます。以前と同様のコマンドを使用して、コマンドラインからPodのステータスを確認してください。

4. ロードジェネレーターのスケール

ReplicaSetは、Podの複数のインスタンスを実行し、指定された数のPodを一定に保つプロセスです。その目的は、Podが失敗したりアクセスできなくなったりした場合でも、ユーザーがアプリケーションにアクセスできなくならないように、クラスター内で指定された数のPodインスタンスが常に実行されている状態を維持することです。

ReplicaSetは、既存のPodが失敗した場合に新しいインスタンスを起動し、実行中のインスタンスが指定された数に達していない場合にスケールアップし、同じラベルを持つ別のインスタンスが作成された場合にPodをスケールダウンまたは削除するのに役立ちます。ReplicaSetは、指定された数のPodレプリカが継続的に実行されることを保証し、リソース使用量が増加した場合の負荷分散に役立ちます。

以下のコマンドを使用して、ReplicaSetを4レプリカにスケールしましょう:

kubectl scale replicaset/loadgen --replicas 4 -n loadgen

コマンドラインとSplunk Observability Cloudの両方からレプリカが実行されていることを確認します:

kubectl get replicaset loadgen -n loadgen

ロードジェネレーターを約2〜3分間実行し、Kubernetes NavigatorとApache Navigatorでメトリクスを観察し続けてください。

Horizontal Pod Autoscaling (HPA) のセットアップ

Kubernetesでは、HorizontalPodAutoscalerがワークロードリソース（DeploymentやStatefulSetなど）を自動的に更新し、需要に合わせてワークロードを自動的にスケーリングします。

水平スケーリングとは、負荷の増加に対応してより多くのPodをデプロイすることを意味します。これは垂直スケーリングとは異なります。Kubernetesにおける垂直スケーリングは、ワークロードですでに実行されているPodにより多くのリソース（メモリやCPUなど）を割り当てることを意味します。

負荷が減少し、Podの数が設定された最小値を超えている場合、HorizontalPodAutoscalerはワークロードリソース（Deployment、StatefulSet、またはその他の類似リソース）にスケールダウンするよう指示します。

1. HPA のセットアップ

~/workshop/k3s/hpa.yaml ファイルを確認し、以下のコマンドで内容を検証します:

cat ~/workshop/k3s/hpa.yaml

このファイルには、Horizontal Pod Autoscalerの設定が含まれており、php-apache デプロイメント用の新しいHPAを作成します。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
  namespace: apache
spec:
  maxReplicas: 4
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        averageUtilization: 50
        type: Utilization
  - type: Resource
    resource:
      name: memory
      target:
        averageUtilization: 75
        type: Utilization
  minReplicas: 1
  scaleTargetRef:
    apiVersion: apps/v1
    kind: StatefulSet
    name: php-apache

デプロイされると、php-apache は平均CPU使用率が50% を超えるか、デプロイメントの平均メモリ使用率が75% を超えると自動スケールします。最小1 Pod、最大4 Podです。

kubectl apply -f ~/workshop/k3s/hpa.yaml

2. HPA の検証

kubectl get hpa -n apache

Kubernetesの Workloads または Node Detail タブに移動し、HPAデプロイメントを確認します。

3. HPA レプリカ数の増加

maxReplicas を8に増やします

kubectl edit hpa php-apache -n apache

変更を保存します（ヒント: Esc を押してから :wq! を入力して変更を保存します）。

おめでとうございます！ ワークショップが完了しました。