Kubernetes クラスタロギングの基本を簡単に説明します

サーバーおよびアプリケーションのログ記録は、開発者、運用、セキュリティチームが運用環境で実行されているアプリケーションの状態を把握するための重要なツールです。

ログ記録により、オペレーターはアプリケーションと必要なコンポーネントがスムーズに実行されているかどうかを判断し、異常が発生しているかどうかを検出して状況に対応できるようになります。

開発者にとって、ログ記録は開発中および開発後にコードのトラブルシューティングを行うための可視性を提供します。実稼働環境では、開発者はデバッグツールを使用せずにログツールに依存することがよくあります。システムログと組み合わせることで、開発者は運用スタッフと連携して問題を効率的に解決できます。

ログツールの最も重要な受益者は、特にクラウドネイティブ環境のセキュリティチームです。アプリケーションログとシステムログから情報を収集できるため、セキュリティチームは認証、アプリケーションアクセス、マルウェアアクティビティからのデータを分析し、必要に応じて対応できます。

Kubernetes は主要なコンテナプラットフォームであり、Kubernetes を使用して本番環境にデプロイされるアプリケーションが増えています。 Kubernetes のロギングアーキテクチャを理解することは、すべての開発、運用、セキュリティチームが真剣に取り組む必要がある非常に重要なタスクであると私は考えています。

この記事では、Kubernetes でさまざまなコンテナログモードがどのように機能するかについて説明します。

システムログとアプリケーションログ

Kubernetes のロギングアーキテクチャについて詳しく説明する前に、さまざまなロギングアプローチと、これら 2 つの機能が Kubernetes ロギングの重要な機能である理由について説明します。

システムコンポーネントには、コンテナー内で実行されるものと、コンテナー内で実行されないものの 2 種類があります。例えば：

Kubernetes スケジューラと kube-proxy はコンテナ内で実行されます。
kubelet とコンテナランタイムはコンテナ内で実行されません。

コンテナログと同様に、システムコンテナログは /var/log ディレクトリに保存され、定期的にローテーションする必要があります。

ここではコンテナのログ記録について見ていきます。まず、クラスターレベルのログ記録と、それがクラスターオペレーターにとってなぜ重要であるかについて説明します。クラスターログは、クラスターのパフォーマンスに関する情報を提供します。ポッドがオフラインになった理由やノードが停止した理由などの情報。クラスターログでは、クラスターとアプリケーションのアクセス、アプリケーションによるコンピューティングリソースの利用方法などの情報も取得できます。全体として、クラスターログツールは、クラスターオペレーターにクラスターの操作とセキュリティに役立つ情報を提供します。

コンテナログをキャプチャする別の方法は、アプリケーションのネイティブログツールを使用することです。最新のアプリケーション設計には、開発者が標準出力 (stdout) とエラーストリーム (stderr) を通じてアプリケーションのパフォーマンスの問題をトラブルシューティングするのに役立つログ記録メカニズムが備わっている可能性があります。

効果的なログ記録インストルメンテーションを実現するには、Kubernetes 実装にアプリケーションログ記録コンポーネントとシステムログ記録コンポーネントの両方が必要です。

Kubernetes コンテナログの 3 つの種類

今日のほとんどの Kubernetes 実装で見られるクラスターレベルのログ記録には、主に 3 つのアプローチがあります。

ノードレベルのログエージェント
ログ記録用のサイドカーコンテナアプリケーション
アプリケーションログをログバックエンドに直接公開する

ノードレベルのログエージェント

ノードレベルのログエージェントを検討したいと思います。通常、これを実装するには、DaemonSet をデプロイメント戦略として使用し、ポッド (ログエージェントとして機能) をすべての Kubernetes ノードにデプロイします。次に、ログエージェントはすべての Kubernetes ノードからログを読み取るように構成されます。通常、エージェントは、ノードの /var/logs ディレクトリを読み取り、stdout/stderr ストリームをキャプチャして、ログ記録バックエンドストレージに送信するように構成します。

次の図は、すべてのノードでエージェントとして実行されているノードレベルのログ記録を示しています。

ノードレベルのログエージェント

fluentd メソッドを使用してノードレベルのログ記録を設定するには、次の手順を実行する必要があります。

（1）まず、fluentddというサービスアカウントを作成する必要があります。 Fluentd ポッドは、このサービスアカウントを使用して Kubernetes API にアクセスします。ラベル app: fluentd を使用して、ログ名前空間に作成する必要があります。

 #fluentd-SA.yaml
 APIバージョン: v1
種類: サービスアカウント
メタデータ:
  名前: fluentd
  名前空間: ログ記録
  ラベル:
    アプリ: fluentd

完全な例はこのリポジトリでご覧いただけます。

（2）次に、fluentd-configmapという名前のConfigMapを作成する必要があります。これにより、必要なすべてのプロパティを含む fluentd デーモンセットの構成ファイルが提供されます。

 #fluentd-デーモンセット.yaml
 apiバージョン: extensions/v1beta1
種類: DaemonSet
メタデータ:
  名前: fluentd
  名前空間: ログ記録
  ラベル:
    アプリ: fluentd
    kubernetes.io/cluster-service: "true"
仕様:
  セレクタ：
    一致ラベル:
      アプリ: fluentd
      kubernetes.io/cluster-service: "true"
  テンプレート：
    メタデータ:
      ラベル:
        アプリ: fluentd
        kubernetes.io/cluster-service: "true"
    仕様:
      サービスアカウント: fluentd
      コンテナ:
      - 名前: fluentd
        イメージ: fluent/fluentd-kubernetes-daemonset:v1.7.3-debian-elasticsearch7-1.0
        環境:
          - 名前: FLUENT_ELASTICSEARCH_HOST
            値: "elasticsearch.logging.svc.cluster.local"
          - 名前: FLUENT_ELASTICSEARCH_PORT
            値: "9200"
          - 名前: FLUENT_ELASTICSEARCH_SCHEME
            値: "http"
          - 名前: FLUENT_ELASTICSEARCH_USER
            値: "弾性"
          - 名前: FLUENT_ELASTICSEARCH_PASSWORD
            値:
              シークレットキーリファレンス:
                名前: efk-pw-elastic
                キー: パスワード
          - 名前: FLUENT_ELASTICSEARCH_SED_DISABLE
            値: "true"
        リソース：
          制限:
            メモリ: 512Mi
          リクエスト:
            CPU: 100m
            メモリ: 200Mi
        ボリュームマウント:
        - 名前: varlog
          マウントパス: /var/log
        - 名前: varlibdockercontainers
          マウントパス: /var/lib/docker/containers
          読み取り専用: true
        - 名前: fluentconfig
          マウントパス: /fluentd/etc/fluent.conf
          サブパス: fluent.conf
      終了猶予期間秒数: 30
      ボリューム:
      - 名前: varlog
        ホストパス:
          パス: /var/log
      - 名前: varlibdockercontainers
        ホストパス:
          パス: /var/lib/docker/containers
      - 名前: fluentconfig
        構成マップ:
          名前: fluentdconf

完全な例はこのリポジトリでご覧いただけます。

ここで、fluentd デーモンセットをロギングエージェントとしてデプロイする方法のコードを見てみましょう。

 #fluentd-デーモンセット.yaml
 apiバージョン: extensions/v1beta1
種類: DaemonSet
メタデータ:
  名前: fluentd
  名前空間: ログ記録
  ラベル:
    アプリ: fluentd
    kubernetes.io/cluster-service: "true"
仕様:
  セレクタ：
    一致ラベル:
      アプリ: fluentd
      kubernetes.io/cluster-service: "true"
  テンプレート：
    メタデータ:
      ラベル:
        アプリ: fluentd
        kubernetes.io/cluster-service: "true"
    仕様:
      サービスアカウント: fluentd
      コンテナ:
      - 名前: fluentd
        イメージ: fluent/fluentd-kubernetes-daemonset:v1.7.3-debian-elasticsearch7-1.0
        環境:
          - 名前: FLUENT_ELASTICSEARCH_HOST
            値: "elasticsearch.logging.svc.cluster.local"
          - 名前: FLUENT_ELASTICSEARCH_PORT
            値: "9200"
          - 名前: FLUENT_ELASTICSEARCH_SCHEME
            値: "http"
          - 名前: FLUENT_ELASTICSEARCH_USER
            値: "弾性"
          - 名前: FLUENT_ELASTICSEARCH_PASSWORD
            値:
              シークレットキーリファレンス:
                名前: efk-pw-elastic
                キー: パスワード
          - 名前: FLUENT_ELASTICSEARCH_SED_DISABLE
            値: "true"
        リソース：
          制限:
            メモリ: 512Mi
          リクエスト:
            CPU: 100m
            メモリ: 200Mi
        ボリュームマウント:
        - 名前: varlog
          マウントパス: /var/log
        - 名前: varlibdockercontainers
          マウントパス: /var/lib/docker/containers
          読み取り専用: true
        - 名前: fluentconfig
          マウントパス: /fluentd/etc/fluent.conf
          サブパス: fluent.conf
      終了猶予期間秒数: 30
      ボリューム:
      - 名前: varlog
        ホストパス:
          パス: /var/log
      - 名前: varlibdockercontainers
        ホストパス:
          パス: /var/lib/docker/containers
      - 名前: fluentconfig
        構成マップ:
          名前: fluentdconf

これをまとめると、次のようになります:

 kubectl apply -f fluentd-SA.yaml \
              fluentd-configmap.yaml \ を設定します。
              -f fluentd-デーモンセット.yaml

ログ記録用のサイドカーコンテナアプリケーション

もう 1 つの方法は、ログエージェントを備えた専用のサイドカーコンテナーを使用することです。コンテナの最も一般的な実装は、ログコレクターとして Fluentd を使用することです。エンタープライズ展開（コンピューティングリソースのオーバーヘッドを心配する必要がない）では、fluentd（または同様のもの）で実装されたサイドカーコンテナーにより、クラスターレベルのログ記録の柔軟性が実現します。これは、キャプチャする必要があるログの種類、頻度、およびその他の可能な調整に基づいて、コレクターエージェントを調整および構成できるためです。

次の図は、ログ記録エージェントとして機能するサイドカーコンテナーを示しています。

ログエージェントとしてのサイドカーコンテナーたとえば、ポッドは、2 つの異なる形式を使用して 2 つの異なるログファイルに書き込む単一のコンテナーを実行します。ポッドの構成ファイルは次のとおりです。

 # ログサイドカー.yaml
 APIバージョン: v1
種類: ポッド
メタデータ:
  名前: カウンター
仕様:
  コンテナ:
  - 名前: カウント
    画像: ビジーボックス
    引数:
   - /bin/sh
    - -c
    - >  
 i = 0 ;
      真実である一方;
      する
        echo "$i: $(date)" > > /var/log/1.log;
        echo "$(date) INFO $i" > > /var/log/2.log;
 i =$((i+1));
        睡眠1;
      終わり
    ボリュームマウント:
    - 名前: varlog
      マウントパス: /var/log
  - 名前: count-log
    画像: ビジーボックス
    引数: [/bin/sh, -c, 'tail -n+1 -f /var/log/1.log']
    ボリュームマウント:
    - 名前: varlog
      マウントパス: /var/log
  ボリューム:
  - 名前: varlog
    空ディレクトリ: {}

これらすべてを組み合わせると、次のポッドを実行できます。

 $ kubectl apply -f ログサイドカー.yaml

サイドカーコンテナがログエージェントとして動作していることを確認するには、次の操作を実行します。

 $ kubectl ログカウンタ count-log

期待される出力は次のとおりです。

 $ kubectl ログカウンタ count-log-1
 2021年11月4日（木）09:23:21 NZDT
 2021年11月4日（木）09:23:22 NZDT
 2021年11月4日（木）09:23:23 NZDT
 2021年11月4日（木）09:23:24 NZDT

アプリケーションログをログバックエンドに直接公開する

3 番目のアプローチは、Kubernetes コンテナとアプリケーションログに対する最も柔軟なログソリューション (私の意見では) であり、ログをログバックエンドソリューションに直接プッシュすることです。このパターンはネイティブの Kubernetes 機能に依存しませんが、次のようなほとんどの企業が必要とする柔軟性を提供します。

より広範囲のネットワークプロトコルと出力形式に対するサポートが拡張されました。
負荷分散機能を提供し、パフォーマンスを向上させます。
アップストリーム集約を介して複雑なログ記録要件を受け入れるように構成できます。

この 3 番目のアプローチは、各アプリケーションから直接ログをプッシュすることによって Kubernetes 以外の機能に依存しているため、Kubernetes の範囲外となります。

結論は

Kubernetes ロギングツールは、エンタープライズ Kubernetes クラスターのデプロイメントにおいて非常に重要なコンポーネントです。使用できる可能性のある 3 つのモードについて説明しました。ニーズに合ったモデルを見つける必要があります。

前述のように、デーモンセットを使用したノードレベルのログ記録は最も使いやすいデプロイメントモードですが、いくつかの制限もあり、組織のニーズに適さない可能性があります。一方、サイドカーモードでは柔軟性とカスタマイズ性が提供され、キャプチャするログの種類をカスタマイズできますが、コンピューターのリソースオーバーヘッドが増加します。最後に、アプリケーションログをバックエンドログツールに直接公開することは、さらなるカスタマイズを可能にするもう 1 つの魅力的なアプローチです。

選択はあなた次第です。組織の要件に合った方法を見つけるだけです。

<<: プラットフォーム・アズ・ア・サービス（PaaS）環境を保護する方法

>>: 生産失敗 | Kafka のメッセージ送信が数十秒も遅延する原因は、実は...