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 つの魅力的なアプローチです。

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