OpenshiftへのDatadog Agent導入について

はじめに

本記事はDatadog Japan 2022年アドベントカレンダーの9日目の投稿です。
今回はOpenshift環境にDatadog Agentを導入する流れについてまとめます。

OpenshiftへのDatadog Agentの導入については公式ドキュメントで手順を公開しています。

Openshiftの手順
https://docs.datadoghq.com/ja/integrations/openshift/?tab=helm#pagetitle

Kubernetesの手順
https://docs.datadoghq.com/ja/containers/kubernetes/#%E6%A6%82%E8%A6%81

ただこれ、どれ実施してからどれやって等の順番がわかりづらかったり、色々選択肢があったりで、結局どうすればいいのか理解するのに時間がかります。
（私は時間がかかりました、、、）

みなさんご安心ください。
この記事を読めば、大まかな流れは把握できます。

ちなみにこの記事はKubernetes、Openshift、Datadogの初心者向けです。
なんとなくKubernetesとOpenshiftがどんなものかを知っていて、
なんとなくDatadogについても知っている方を読者として想定して記載してます。

利用環境について

今回はこちらを参考にAzure Redhat Openshift（以後ARO）のクラスター、アプリケーションを作成しました。

Openshiftについて

Openshiftは、Kuberenetesをより簡単に運用できたり、その上でより簡単に開発できたりするためにRedHatさんが手を加えて販売しているものです。

Wikipedia：https://ja.wikipedia.org/wiki/OpenShift

上記Wikipediaに以下の記載があります。

1つはアクセスコントロール、もう1つはコンテナのビルドとデプロイ機能である。アクセスコントロールは、リソース分離と権限分掌によって実現する。ビルドとデプロイの機能は、Kubernetesの機能に追加して、コンテナ型のアプリケーションとして実行するためのDocker Imageの作成やデプロイに関わる機能を追加する。

通常のKubernetesに加えて、アクセスコントロール等があるためDatadg Agentの導入手順にも少し気を使う必要があります。

Datadog Agent導入の流れ

大まかには、以下のような流れです。

• Datadog Agentのインストール
• SCCの構成
• Datadog Agentの設定
  ライブコンテナの設定
  各種環境変数の設定
  Openshift向けの設定
• APMの設定
• ログの設定

それぞれの項目について少し詳細に記載していきます。

Datadog Agentのインストール

Openshift、Kubernetes環境へDatadog Agentを導入するための方法は大きく以下の二つあります。

• Helmで入れる方法
• Daemonsetのマニフェストファイルを作成してapplyする方法
  （最近Operatorでの実施手順が出てきましたが、まだ試してないので無視してます。）

Helmの方が簡単です。
今回はHelmでの方法を解説します。
また、今回はDefaultプロジェクト（namespace）にインストールします。

こちらを参照します。
https://docs.datadoghq.com/ja/containers/kubernetes/installation/?tab=helm

まずは手順通り進めてください。

この手順が注意です。
「4.Agent のインストール手順から Datadog API キーを取得し、次を実行します」

API keyをオプションで指定する手順ですが、value.yamlに記載しましょう。
前の手順でダウンロードしたvalue.yamlファイルの、datadogセクション内にapiKeyという箇所があります。

あと、もしここでDatadogのUS1リージョン以外を利用する場合は同セクション内のsite:という値にも設定が必要です。

例：US3の場合はsite: us3.datadoghq.comとします。

もしHelmではなくDaemonsetのマニフェストファイルを利用してデプロイする場合は、DD_SITE等の環境変数の設定は利用する全てのエージェントコンテナ（agent、process-agent、trace-agent等）のセクションに設定が必要です。

こちらでhelmのinstallコマンドを実行するかと思いますが、Openshift環境においてはこの時点でDatadog Agentの起動は正常に実施されません

こんな感じ

その時のDatadog側はこんな感じ。
※一見リストされてますが情報全然取れてません。

ここでトラブルシューティングに入るとドツボにハマります。
ここでのエラーは無視しましょう。

SCCの構成

次にOpenshift特有の設定です。
https://docs.datadoghq.com/ja/integrations/openshift/?tab=helm
こちらを参考に実施します。
まずは手順通り進めてください。

コンフィギュレーションの項目は何をしたらいいのかよくわからないポイントの一つです。

ここで一度HelmではなくDaemonsetを選択してみると以下のような表が出てきます。

なるほど全て機能を利用するにはカスタムDatadog SCCを利用すればいいのか。
手順にリンクのあるDatadog SCCのマニフェストをダウンロードし、適用しましょう。

※ここではまだエラーは解消されません

Datadog Agentの設定

ここからAgentへ各種設定を実施していきます。

ライブコンテナの設定

こちらを参考に進めて下さい。
https://docs.datadoghq.com/ja/infrastructure/livecontainers/configuration/?tab=helm

ここは特に注意点はないです。

※ここではまだエラーは解消されません

各種環境変数の設定

こちらを参考に進めてください。
https://docs.datadoghq.com/ja/containers/kubernetes/configuration/?tab=helm#%E3%83%A9%E3%82%A4%E3%83%96%E3%82%B3%E3%83%B3%E3%83%86%E3%83%8A

冒頭の設定はデフォルトで有効になっているので、ほとんどここでは実施する手順はないです。

Proxyを利用している場合はここの環境変数を参考に設定を行います。
ただその場合、クラスタの内部通信がProxyを通らないようにDD_PROXY_NO_PROXYの変数を設定し、kubeletのIPをホワイトリストに登録する必要があります。

Openshift向けの設定

こちらを参考に進めてください。
https://docs.datadoghq.com/ja/containers/kubernetes/distributions/?tab=helm#Openshift

これを実施することで一部エラーが解消されます

今回発生しているエラーに触れていないんですが、通信関連のエラーが発生してます。
tlsVerifyをfalseにしたことで、それが解消されるんです。（雑）

というかOpenshiftインテグレーションのページに書いといて欲しいです。
なぜ分けて書かれているのか、、、

APMの設定

こちらを参考に進めてください。
https://docs.datadoghq.com/ja/containers/kubernetes/apm/?tab=helm

TraceをアプリケーションコンテナからAgentが受け取る方法には二種類あります。（UDS or TCP）
手順に注意点があるようにUDSが推奨ではありますが、
OpenshiftではTCPで実装する方が簡単です。

なぜならUDSで実装する場合、アプリケーションPodとDatadog Agent Podそれぞれにhostpathパラメータを設定しますが、このhostpathを利用するために強い権限が必要なためです。

Datadog Agent Podだけならそこにprivilegeを与えてやればいいかもですが、
アプリケーションPodの権限は元々の権限設計があると思うので、そこに影響あると色々面倒だったりしますよね。

（単に私がOpenshift素人で、適切な権限設計、設定のイメージが湧いてないので、正直逃げです。
　UDSを利用した実装の方が良い点もあるので、Openshiftのプロの方、適切にhostpathを利用できるような設定を教えてください。）

ということで、socketEnabledをfalseにして、portEnabledをtrueにしましょう。

※今回はAgentの導入がテーマなので、アプリケーションPodへの設定、トレーサーの仕込みは対象外にします。

これを実施することでたぶん全てのエラーが解消されます！！

ここではtrace-agentの権限関連のエラーが発生してましたが、
socketEnabledをfalseにしたことで、それが解消されるんです。（雑）

こんな感じ

Datadog上はこんな感じ

ログの設定

こちらを参考に進めます。
https://docs.datadoghq.com/ja/containers/kubernetes/log/?tab=helm

こちらの設定を行なっても、おそらくログは収集されません。
ARO上のDatadog Agent PodでDatadog Agentのステータスを確認するコマンドを実行すると、ログのセクションで以下のメッセージを確認しました。

Error: could not find any file matching pattern /var/log/pods/openshift~ホニャララ

Datadog Agentはホストの/var/log/podsを自身の/var/log/podsにマウントするんですが、
Podからホスト上のログにアクセスするためには、PodをPrivilege権限で起動する必要があります、、、と思います。
（もしくはSCCの設定でなんとかできる？）

従って、agents.containers.agent.securityContextでprivileged: trueを設定します。

すると、ログが収集されました！

こんな感じ

ちなみにDaemonsetで実装した時は特にこんなことせずログが収集できてたような記憶があります。
何か違うのかしら、、、今回は深く追求しません。

おわりに

いかがでしたでしょうか。

今回の私の所感は、

• 設定完了しちゃえばDatadogやっぱ便利
• OpenshiftのS2Iすごい
  （今回参考にしたARO workshop内で体験したもので、本記事では全く触れてません）

といったところでしょうか。

Openshiftはその便利さが故のブラックボックスがあり一筋縄ではいかないケースがあると思います。
おそらくみなさんの環境による固有の問題が起きると思います。

この記事が少しでもみなさんの参考になれば幸いです。

またこの設定でOpenshiftにDatadog Agentを導入することができれば、
こんな感じでKubernetesをモニタリングできます。

（これ私です）

それではみなさん
Happy Datadog Life!