ログ収集

Kubernetesは、クラスタの監視システム、クラスタに加えて、アラーム監視を構築、運用、保守作業が収集ログことが非常に重要であるがあります。

入門

アプリケーションおよびシステムログは、私たちは、内部クラスタの動作を理解するのに役立つことができ、我々は問題をデバッグするためにログインして、クラスタの状況を監視するにも非常に便利です。そして、アプリケーションのほとんどは、最も伝統的なアプリケーションのログをローカルログファイルに書き込まれますがあります。さらに簡単なアプリケーションのコンテナについては、単に情報がstdoutとstderrに書き込まれるログはすることができ、それは下のホスト血管デフォルトのJSONファイルへの出力、ログ、私たちができるのと同じでしょうドッキングウィンドウのログやkubectlログによってログに対応する情報を表示します。

しかし、一般的には、コンテナまたはランタイムエンジン機能を提供し、コンテナが折りたたまれている場合など、ポッドが追放されたり、ノードがハングアップする、完全なログ情報を記録するのに十分ではありませんが、我々はまだそれがアプリケーションにアクセスログを願っています。そのため、ログはノード、ポッドまたはコンテナのライフサイクルの独立している必要があり、この設計は、クラスタレベルのロギングと呼ばれ、それがKubernetesシステムから完全に独立して、あなたは自分の別のログのバックエンド・ストレージ、分析およびクエリツールを提供する必要があります。

基本的なロギングKubernetes

次のように次の例では、標準出力ストリームに直接出力データにおける基本的なロギングKubernetesの一例です。

apiVersion: v1
kind: Pod
metadata: name: counter spec: containers: - name: count image: busybox args: [/bin/sh, -c, 'i=0; while true; do echo "$i: $(date)"; i=$((i+1)); sleep 1; done']

ポッドを作成し、カウンターpod.yaml、第二出力あたりポッド一部のテキスト情報として上記のファイルを保存します。

$ kubectl create -f counter-pod.yaml
pod "counter" created

作成したら、あなたはkubectlログは、ログ情報を表示するコマンドを使用することができます：

$ kubectl logs counter
0: Thu Dec 27 15:47:04 UTC 2018
1: Thu Dec 27 15:47:05 UTC 2018
2: Thu Dec 27 15:47:06 UTC 2018
3: Thu Dec 27 15:47:07 UTC 2018
......

Kubernetesログ収集

Kubernetesクラスタ自体は、一般的に、そこにプログラムの三つの主要な種類があり、コレクションのログを行い、ログ収集のためのソリューションを提供していません。

ログを収集するために、ノード・エージェントで実行されています
アプリケーションログのポッドを収集するための容器を含むサイドカー
収集したログ情報に直接適用は、後端に押し込ま

ノードログ収集機関

ノード・エージェント

、ログデータを収集する収集エージェントのログを記録するために、各ノード上のログ収集エージェントを実行することにより、特殊なツール、後端ログデータは、統一にプッシュです。一般的には、このエージェントは、コンテナで実行するために、ログファイルには、コンテナ・ノード・ディレクトリーのすべてのアプリケーションにアクセスすることができます。

この薬剤の各ノード上で実行されなければならないので、コントローラは、アプリケーションに直接DaemonSetを実行します。ノードでこのように実行するログ収集エージェントが各ノード上で実行中のエージェントを必要とするため、最も一般的な方法は、行われていないされているノード上で実行中のアプリケーションに変更を必要としない、何のアプリケーション任意の侵襲、このメソッドは、コレクション内のアプリケーションログ出力stdoutとstderrにのみ適用されます。

ログを収集するためにサイドカーコンテナ

私たちは、あなたは明らかに問題がある見ることができる上記のチャートを見ては、私たちは、この情報は、ローカルコンテナ上の対応するJSONログファイルにディレクトリ内に保持されますので、容器内部のstdoutとstderrへのログ情報の取得により直接的であるということですノード上で実行中のエージェントがログに取得することができます。しかし、私たちのアプリケーションログは、ログファイルコンテナに出力された場合には、その後、何？このログデータは、上記のスキームの取得よりも少ないことで、明らかです。

コンテナは、サイドカー出力ログで再びでした

サイドカーエージェント

彼らは上記のノードのログ収集プログラムによって完了することができないように、上記のために、私たちは、このような場合には直接、さらにサイドカーポッドコンテナ、コンテナを通じてstdoutに直接ログアプリケーションを起動することができます。

これはメインのロジックサイドカーコンテナアプリケーションであるので、その背後にあるロジックは、低オーバーヘッドが非常に簡単ですので、印刷ログをリダイレクト、およびので、出力をstdoutまたはstderrに、私たちは、ログを表示するkubectlログを使用することができます。

次の例では、2つのローカル容器にログファイルにポッドにあります。

apiVersion: v1
kind: Pod
metadata: name: counter spec: containers: - name: count image: busybox args: - /bin/sh - -c - > i=0; while true; do echo "$i: $(date)" >> /var/log/1.log; echo "$(date) INFO $i" >> /var/log/2.log; i=$((i+1)); sleep 1; done volumeMounts: - name: varlog mountPath: /var/log volumes: - name: varlog emptyDir: {}

（2-のファイルを次のようにコンテナポッドの性質のために、我々は、別の容器に別のサイドカーコンテナを取得ログファイル、およびYAMLファイルを変更することができる上に、ログ標準出力ストリームをリダイレクトするために使用することができます-Counter-ポッドストリーミング-sidecar.yaml）

apiVersion: v1
kind: Pod
metadata: name: counter spec: containers: - name: count image: busybox args: - /bin/sh - -c - > i=0; while true; do echo "$i: $(date)" >> /var/log/1.log; echo "$(date) INFO $i" >> /var/log/2.log; i=$((i+1)); sleep 1; done volumeMounts: - name: varlog mountPath: /var/log - name: count-log-1 image: busybox args: [/bin/sh, -c, 'tail -n+1 -f /var/log/1.log'] volumeMounts: - name: varlog mountPath: /var/log - name: count-log-2 image: busybox args: [/bin/sh, -c, 'tail -n+1 -f /var/log/2.log'] volumeMounts: - name: varlog mountPath: /var/log volumes: - name: varlog emptyDir: {}

ポッドの上に直接作成：

$ kubectl create -f two-files-counter-pod-streaming-sidecar.yaml
pod "counter" created

操作が成功した後、私たちは、次のコマンドにより、ログ情報を表示することができます。

$ kubectl logs counter count-log-1
0: Mon Jan  1 00:00:00 UTC 2001
1: Mon Jan  1 00:00:01 UTC 2001
2: Mon Jan  1 00:00:02 UTC 2001
...
$ kubectl logs counter count-log-2
Mon Jan  1 00:00:00 UTC 2001 INFO 0
Mon Jan  1 00:00:01 UTC 2001 INFO 1
Mon Jan  1 00:00:02 UTC 2001 INFO 2
...

したがってフロントログ収集エージェント・ノード上で自動的に追加の構成を必要とせず、ログ情報を取得することができます。

このアプローチは、上記の問題を解決することができますが、明らかな欠陥がありますがするだけではないログは、元のコンテナファイルに保存されることがあり、出力は標準出力により、ディスクスペースを取るので、事実上のディスク容量を倍増します。

サイドカーは、ログ収集エージェントを実行して使用します

サイドカーエージェント

あなたはノードのログ収集機関で実行されていることは十分に柔軟ではないと思う場合は、別のログ収集サイドカーコンテナエージェントを作成することができますが、別の用途の必要性が設定し、一緒に実行します。

これは、より柔軟ではあるがしかし、しかし、ログがアクセスするためのコマンドkubectlを使用することはできませんまた、あなたがエージェントを実行する必要がどのように多くのコレクションで、ポッドを収集するための番号を持っているので、リソース消費の多くを引き起こす可能性がサイドカーコンテナログ収集エージェントで実行され、これらのログは、彼らがコントロールをkubeletされていないため。

たとえば、あなたがのStackdriverを使用することができ、それが記録剤として使用fluentd。この方法を実現するための2つのプロファイルは、次のとおりです。最初のファイルは、設定流暢ConfigMapが含まれています。

以下は、保持するためにConfigMapオブジェクトを使用し、Kubernetes公式のサンプル設定ファイルfluentdであります：

apiVersion: v1
kind: ConfigMap
metadata: name: fluentd-config data: fluentd.conf: | <source> type tail format none path /var/log/1.log pos_file /var/log/1.log.pos tag count.format1 </source> <source> type tail format none path /var/log/2.log pos_file /var/log/2.log.pos tag count.format2 </source> <match **> type google_cloud </match>

上記構成プロファイルを収集し、元のファイル/var/log/1.log /var/log/2.logログデータ、及びその後プラグを通してのStackdriver後端にデータをプッシュgoogle_cloudれます。

ここでは、ログデータを読み取るために、コンテナfluentdアプリケーションで上記のプロファイルの実行を使用します。

apiVersion: v1
kind: Pod
metadata: name: counter spec: containers: - name: count image: busybox args: - /bin/sh - -c - > i=0; while true; do echo "$i: $(date)" >> /var/log/1.log; echo "$(date) INFO $i" >> /var/log/2.log; i=$((i+1)); sleep 1; done volumeMounts: - name: varlog mountPath: /var/log - name: count-agent image: k8s.gcr.io/fluentd-gcp:1.30 env: - name: FLUENTD_ARGS value: -c /etc/fluentd-config/fluentd.conf volumeMounts: - name: varlog mountPath: /var/log - name: config-volume mountPath: /etc/fluentd-config volumes: - name: varlog emptyDir: {} - name: config-volume configMap: name: fluentd-config

作成された上記ポッドた後、コンテナカウントエージェントは、コンテナのログに収集され、アップロードされますカウントされます。もちろん、これは単なる一例であり、我々は、このようなようにlogstash、流暢ビット、およびとして、fluentdを置き換えるために、他のログ収集ツールを使用することができます。

アプリケーションから直接ログを収集

アプリのログ

k8s-ログ収集インフラストラクチャー