本番環境の 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として明記してください。