本番環境の Kubernetes ではログ記録はどのように実装されていますか?

[[435371]]

[51CTO.com クイック翻訳]独自のクラスターレベルのログ記録のために、実稼働 Kubernetes クラスターのスケーラブルなログ記録パターンを理解する必要があります。

従来、モノリシックアーキテクチャでは、ログはベアメタルまたは仮想マシンに直接保存され、サーバーディスクから外に出ることはなく、運用チームが必要に応じて各ディスクのログをチェックしていました。

これはオンプレミスのサーバーではうまく機能しますが、クラウド内のログは一時的なものです。ますます多くの企業がコンテナ上でサービスを実行し、Kubernetes を使用してデプロイメントを調整するようになると、ログをサーバーに保存する必要がなくなり、ログ管理戦略の実装が重要になります。

ログはアプリケーションをデバッグおよび監視するための効果的な方法であり、ポッドまたはノードに障害が発生したときにクエリおよび分析できるように、別のバックエンドに保存する必要があります。これらの独立したバックエンドには、Elasticsearch、Google Cloud Platform の Stackdriver、AWS の Cloudwatch などのシステムが含まれます。

クラスターのログをストレージバックエンドに保存することを、クラスターレベルのログ記録と呼びます。この記事では、企業が独自の Kubernetes クラスターにこのアプローチを実装する方法について説明します。

ログアーキテクチャ

Kubernetes クラスターには、アプリケーションコンポーネントとシステムコンポーネントという 2 つの主なログソースがあります。

アプリケーションは Kubernetes クラスター内のコンテナとして実行されます。コンテナランタイムはアプリケーションのログを取得する役割を担い、Docker はこれらのログを stdout (標準出力ストリーム) と stderr (標準入力ストリーム) にリダイレクトします。 Kubernetes クラスターでは、両方のストリームがクラスターノード上の JSON ファイルに書き込まれます。

これらのコンテナログは、次のコマンドを使用していつでも取得できます。

 kubectl ログ ポッド名

ログのもう 1 つのソースはシステムコンポーネントです。一部のシステムコンポーネント (kube-scheduler および kube-proxy) はコンテナーとして実行され、アプリケーションと同じログ記録原則に従います。

その他のシステムコンポーネント (kubelet およびコンテナランタイム自体) はネイティブサービスとして実行されます。マシン上で systemd が使用可能な場合、コンポーネントはログを journald に書き込みます。それ以外の場合は、.log ファイルを /var/log ディレクトリに書き込みます。

アプリケーションとクラスターのどのコンポーネントがログを生成し、どこに保存されるかを理解したところで、これらのログをさまざまなストレージシステムにオフロードするための一般的なパターンを見てみましょう。

ログモード

ログを収集するための最も一般的な 2 つのパターンは、DaemonSet パターンと Sidecar パターンです。

(1)デーモンセットモード

DaemonSet モードでは、ログエージェントは Kubernetes の DaemonSet リソースを通じて Pod としてデプロイされます。 DaemonSet をデプロイすると、クラスター内の各ノードにログエージェントを実行する Pod が存在するようになります。ログエージェントは、/var/logs ディレクトリからログを読み取り、ストレージバックエンドに送信するように構成されています。

（２）サイドカーモード

サイドカーパターンでは、同じ Pod 内の各アプリケーションコンテナーで専用のコンテナーが実行されます。サイドカーモードには、ストリーミングサイドカーとログエージェントサイドカーの 2 種類があります。

ストリーミングサイドカーは、stdout/stderr ストリームではなくファイルにログを書き込むアプリケーション、または非標準形式でログを書き込むアプリケーションを実行する場合に使用されます。この場合、ストリーミングサイドカーコンテナーを使用して、ファイルからのログを独自の stdout/stderr ストリームに公開し、Kubernetes 自体が stdout/stderr ストリームを取得できるようになります。

ストリーミングサイドカーは、ログメッセージを標準のログ形式に変換することで、ログ構造にパリティをもたらすこともできます。

もう 1 つのアプローチは、ログプロキシサイドカーです。これは、ログをストレージバックエンドに送信します。各ポッドには Fluentd や Filebeat などのログエージェントが含まれており、アプリケーションコンテナからログをキャプチャしてストレージバックエンドに直接送信します。

DaemonSet と Sidecar の利点と欠点

DaemonSet と Sidecar のアプローチについて説明したので、それぞれのアプローチの長所と短所を見てみましょう。

(1)デーモンセット（ノードレベル）

アドバンテージ：

ノードレベルのログ記録は、既存のファイルベースのログ記録に結び付けられるため実装が簡単で、各ノードで実行されるコンテナーの数が少ないため、サイドカーアプローチよりもリソースを消費しません。
ログファイルは kubelet で使用でき、ログファイルの内容が返されるため、 kubectl コマンドを介してログをデバッグに使用できます。

欠点:

さまざまなログ構造や、ストリームではなくログファイルに書き込むアプリケーションをサポートする柔軟性が低くなります。パリティを実現するため、またはストレージバックエンドの違いを処理するために、アプリケーションログ構造を変更する必要があります。
ログはノードディスク上に JSON ファイルとして保存されるため、永続的に保存されるわけではありません。古いログをリサイクルするには、ログローテーションメカニズムが必要です。コンテナランタイムインターフェイスを使用している場合は、kubelet がログのローテーションを処理するため、明示的なソリューションを実装する必要はありません。

（２）サイドカー

アドバンテージ：

Sidecar はアプリケーションコンテナーごとに柔軟にカスタマイズできます。たとえば、アプリケーションが stdout/stderr に書き込まなかったり、ログ記録形式が異なっていたりする場合があります。このような場合、サイドカーコンテナーはシステムにパリティをもたらすことができます。
ストリーミングログエージェントサイドカーを使用していない場合は、ノードディスクにログが保存されないため、ログをローテーションする必要はありません。

欠点:

ノードレベルのポッドと比較すると、各アプリケーションコンテナに対してサイドカーを実行すると、大量のリソースが消費されます。
各デプロイメントにサイドカーを追加すると、複雑さが増します。
ログをファイルに書き込むアプリケーションにストリーミングサイドカーを使用する場合、エントリが重複するため、同じログを保存するために 2 倍のストレージ領域が使用されます。
ストリーミングログエージェントサイドカーを使用しない場合、kubectl 経由でログにアクセスすることはできません。これは、kubelet が JSON ログにアクセスできなくなったためです。
ログエージェント Sidecar を使用する場合は、ノードレベルのエージェントも必要です。そうしないと、システムコンポーネントログを収集できません。

理論を実践する

Kubernetes クラスターにログインするための可能なパターンを理解したので、ログを生成する仮想コンテナをデプロイし、Kubernetes リソースを作成して、上で説明したログ記録パターンを実装することで、それを実践できます。

この例では、ログエージェントとして Fluentd を使用し、ログバックエンド用に Elasticsearch をインストールし、視覚化のために Kibana をインストールします。 Elasticsearch と Kibana は、Helm チャートを使用して同じクラスターにインストールされます。ただし、ストレージバックエンドは同じクラスター上に配置しないでください。これはデモンストレーション目的のみです。 Fluentd はプラグ可能なアーキテクチャを採用しているため、さまざまなシンクをサポートします。このため、Elasticsearch バックエンドは、Stackdriver や Cloudwatch などのクラウドネイティブソリューションに置き換えることができます。

（1）ElasticsearchとKibanaをインストールする

こちらにある公式 Helm チャート (Elasticsearch、Kibana) を使用して Elasticsearch と Kibana をデプロイします。 Helm 経由でインストールするには、パス上に Helm バイナリが必要ですが、Helm のインストールはこの記事の範囲外です。

まず、Helm リポジトリを追加してみましょう。

プロパティファイル

1 つの helm リポジトリに elastic を追加します https://helm.elastic.co

次に、Elasticsearch と Kibana チャートをクラスターにインストールします。

プロパティファイル

1 ヘルムインストール elasticsearch elastic/elasticsearch

2 Helm で Kibana Elastic/Kibana をインストールします

これにより、最新バージョンの Elasticsearch と Kibana がクラスターにインストールされ、ログのストレージバックエンドとして使用できるようになります。

チャートではデフォルト値が使用されていますが、本番環境にインストールする際には、必要に応じて任意のパラメータを変更できます。

(2)デーモンセット

ここでは、Fluentd は、個別のサービスアカウントと ClusterRole を作成せずに DaemonSet としてデプロイされます。ただし、実稼働環境では、アクセスが制限された別のサービスアカウントを使用して Fluentd ポッドを実行する必要があります。

Fluentd は、次の Kubernetes リソースを使用して DaemonSet としてデプロイできます。

行く

 API バージョン: extensions/v1beta1
 種類: DaemonSet
  メタデータ:
名前: fluentd
  名前空間: kube-system
 ラベル:
  k8s-app: fluentd-logger
 仕様:
 テンプレート：
  メタデータ:
  ラベル:
  k8s-app: fluentd-logger
  仕様:
  コンテナ:
 -名前: fluentd
  イメージ: fluent/fluentd-kubernetes-daemonset:elasticsearch
  環境:
  -名前: FLUENT\_ELASTICSEARCH\_HOST
  値: "elasticsearch-master"  
  -名前: FLUENT\_ELASTICSEARCH\_PORT
  値: "9200"  
  ボリュームマウント:
 -名前: varlog
  マウントパス: /var/log
  -名前: dockerlogs
  マウントパス: /var/lib/docker/containers
  読み取り専用: true  
   ボリューム:
  -名前: varlog
   ホストパス:
  パス: /var/log
  -名前: dockerlogs
   ホストパス:
   パス: /var/lib/docker/containers

この例では、2 つのボリュームがマウントされています。1 つは /var/log に、もう 1 つは /var/log/docker/containers にマウントされており、それぞれシステムコンポーネントと Docker ランタイムのログが配置されます。

使用されているイメージは、DaemonSets で使用するためのスマートなデフォルトですでに構成されていますが、構成は変更できます。

上記の YAML リソースを fluentd-ds.yaml という名前のファイルに保存し、次のコマンドで適用します。

プロパティファイル

kubectl を適用 -f fluentd-ds.yaml

これにより、Kubernetes クラスター内の各ノードで Fluentd ポッドが起動します。

ここでは、ストリーミングおよびログプロキシサイドカーパターンを実装する方法を説明します。

（３）サイドカー

まず、アプリケーションがストリームではなくファイルにログを書き込む場合のストリーミングサイドカーパターンを見てみましょう。サイドカーを実行してこれらのログを読み取り、stdout/stderr ストリームに書き戻すことができます。

行く

 APIバージョン: v1
 種類: ポッド
 メタデータ:
名前: my-app
 仕様:
 コンテナ:
  -名前: レガシーアプリ
 画像: ビジーボックス
 引数:
  - /bin/sh
 - -c
  ->
 私=0;
 真の場合;
 する
 echo "$i: $(date)" >> /var/log/出力.log;
  i=$((i+1));
 睡眠1;
 終わり
 ボリュームマウント:
  -名前: varlog
  マウントパス: /var/log
 -名前:ストリーミングサイドカー
 画像: ビジーボックス
 引数: \[/bin/sh, -c, 'tail -n+1 -f /var/log/output.log' \]
 ボリュームマウント:
  -名前: varlog
 マウントパス: /var/log
 ボリューム:
 -名前: varlog
 空ディレクトリ: {}

この例では、コンテナの /var/log ディレクトリ内のファイルにログを書き込む仮想コンテナがあります。現在、コンテナランタイムはこれらのログを取得できないため、/var/log の場所からログを追跡し、stdout ストリームにリダイレクトするストリーミングサイドカーが実装されています。

このログストリームはコンテナランタイムによって取得され、ノード上の /var/log ディレクトリに JSON ファイルとして保存され、その後、ノードレベルのログエージェントによって取得されます。

それでは、ログエージェントサイドカーを見てみましょう。このモードでは、Fluentd はサイドカーとしてデプロイされ、Elasticsearch ストレージバックエンドに直接書き込みます。

Elasticsearch プラグインをインストールするビルド済みのイメージは存在せず、カスタム Docker イメージの作成はこの記事の範囲外です。代わりに、DaemonSet の例で使用したのと同じ Fluentd イメージを使用します。

行く

 APIバージョン: v1
 種類: ポッド
 メタデータ:
名前: my-app
 仕様:
 コンテナ:
 -名前:カウント 
 画像: ビジーボックス
 引数:
 - /bin/sh
  - -c
  ->
 私=0;
 真の場合;
 する
  echo "$i: $(date)" >> /var/log/出力.log;
  i=$((i+1));
 睡眠1;
  終わり
 ボリュームマウント:
 -名前: varlog
  マウントパス: /var/log
 -名前: ログエージェント
 イメージ: fluent/fluentd-kubernetes-daemonset:elasticsearch
  環境:
 -名前: FLUENT\_ELASTICSEARCH\_HOST
  値: "elasticsearch-master"  
 -名前: FLUENT\_ELASTICSEARCH\_PORT
   値: "9200"  
  ボリュームマウント:
 -名前: varlog
  マウントパス: /var/log
 ボリューム:
 -名前: varlog
 空ディレクトリ: {}

結論は

Pod と Node の一時的な性質を考慮すると、Kubernetes クラスターからのログを別のストレージバックエンドに保存することが重要です。この記事で説明したログ記録アーキテクチャを設定するために使用できるパターンはいくつかあります。

実稼働システムでは、サイドカーモードとノードレベルモードを組み合わせて使用することをお勧めします。これには、DaemonSet パターンを使用してクラスター全体のノードレベルのログ記録を設定すること、ストリーム (stdout/stderr) へのログの書き込みをサポートしていないアプリケーションや標準のログ形式で書き込まないアプリケーション用のストリーミングサイドカーコンテナーを実装することが含まれます。ストリームコンテナーは、取得するノードレベルエージェントのログを自動的に表示します。

ストレージバックエンドの選択には、Elasticsearch などのセルフホスト型オープンソースソリューションを選択することも、Elasticsearch、Stackdriver、Cloudwatch などのクラウドホスト型オプションを使用したマネージドサービスルートを選択することもできます。適切なバックエンドの選択は、アーキテクチャに実装するコスト、クエリ、およびログ分析の要件によって異なります。

原題: Kubernetes Logging in Production、著者: 若山健太郎

[51CTOによる翻訳。パートナーサイトに転載する場合は、元の翻訳者と出典を51CTO.comとして明記してください。

<<: エッジの台頭 - いつでもどこでも分析とコンピューティング

>>: エッジコンピューティングを採用する3つの理由