従来、GKE Standard の Logging エージェントは、ワークロードの出力ログ量に関わらず基本的には同じ設定の Logging エージェント (Fluent Bit) がデプロイされるようになっていました。
今回のアップデートでは、高いログスループットが求められる（1 秒あたりのログの処理量がより多い）ノードのために専用の Logging エージェントをデプロイする機能が追加されました。
Logging エージェントの何がどう変わったのか、実際にクラスタを用意して確認してみました。

今回のアップデートは下記のリリースノートから確認できます。
cloud.google.com

また、図らずも前回と少し関連した内容となったため、ノードあたりのPod数上限の拡張や、それに伴うコントロールプレーンの設定の違いなどにご興味がありましたらこちらも併せてご参照ください。

ユースケース

アップデートに併せて既に公式ドキュメントにも記載がありますが、ノードあたりのログスループットが 100 KB/s 超となるようなノードのために用意されたようです。

ノードプール毎の指定となるため、クラスタ内すべてのノードで高スループット版の Logging エージェントを使うこともできますし、特定のノードプールのノードに限って高スループット版を利用する、といった使い方もできるようになっています。
具体的な差異は後ほどご紹介しますが、高スループット版ではより多くの CPU, メモリを消費します。
そのため、ノードプール毎にログの出力量の異なるワークロードが稼働している場合には、特に高いログスループットが求められるノードプールを指定して利用する、というケースが多いのではないかと思います。

なお、新規クラスタはもちろんのこと、既存クラスタからのアップデートでもデプロイ可能ですが、利用するには GKE Standard のコントロールプレーンが 1.24.2-gke.300 以降である必要があります。
現状 GKE Autopilot では利用できません。

実機検証

それでは、実際にクラスタを構築して、通常の Logging エージェントと高スループット版の Logging エージェントの違いを見ていきたいと思います。

1. クラスタを作成する

今回のアップデートの対応バージョンは 1.24.2-gke.300+ となっていますが、今回は 1.24.2 の最新のパッチバージョンである 1.24.2-gke.1900 を使用して GKE Standard のクラスタを作成しました。

まずは通常の Logging エージェントを利用するためのノードプールを e2-medium で用意しました。
説明の簡単のため、ノード数は 1 としています。

作成したクラスタは以下のとおりです。（見やすさのためリソースの表示順序は入れ替えています）

$ gcloud container clusters describe sample-gke
name: sample-gke
...
currentMasterVersion: 1.24.2-gke.1900
currentNodeCount: 1
currentNodeVersion: 1.24.2-gke.1900
...
loggingConfig:
  componentConfig:
    enableComponents:
    - SYSTEM_COMPONENTS
    - WORKLOADS
loggingService: logging.googleapis.com/kubernetes
...
nodePoolDefaults:
  nodeConfigDefaults:
    loggingConfig:
      variantConfig:
        variant: DEFAULT
nodePools:
- name: default-pool
  initialNodeCount: 1
  config:
    ...
    imageType: COS_CONTAINERD
    machineType: e2-medium
    ...
  maxPodsConstraint:
    maxPodsPerNode: '110'
  ...

2. 高スループット版 Logging エージェントをデプロイする

次に、クラスタに別のノードプールを追加し、高スループット版 Logging エージェントをデプロイすることで、ひとつのクラスタに通常の Logging エージェントと高スループット版の Logging エージェントが 1 ノードずつデプロイされている状態にしていきます。

以下のように、ノードプールの作成時に --logging-variant=MAX_THROUGHPUT オプションを指定することで、高スループット版の Logging エージェントをデプロイするノードプールを作成します。
インスタンスタイプは先ほどよりも大きな e2-standard-4 としました。

$ gcloud container node-pools create "additional-pool" --cluster "sample-gke" --logging-variant=MAX_THROUGHPUT
（他のオプションは割愛）
...
Note: Node version is specified while node auto-upgrade is enabled. Node-pools created at the specified version will be auto-upgraded whenever auto-upgrade preconditions are met.
Creating node pool additional-pool...done.     
Created [https://container.googleapis.com/v1beta1/projects/***********/zones/us-central1-a/clusters/sample-gke/nodePools/additional-pool].
NAME: additional-pool
MACHINE_TYPE: e2-standard-4
DISK_SIZE_GB: 100
NODE_VERSION: 1.24.2-gke.1900

$ gcloud container clusters describe sample-gke
name: sample-gke
...
currentMasterVersion: 1.24.2-gke.1900
currentNodeCount: 2
currentNodeVersion: 1.24.2-gke.1900
...
loggingConfig:
  componentConfig:
    enableComponents:
    - SYSTEM_COMPONENTS
    - WORKLOADS
loggingService: logging.googleapis.com/kubernetes
...
nodePoolDefaults:
  nodeConfigDefaults:
    loggingConfig:
      variantConfig:
        variant: DEFAULT
nodePools:
- name: default-pool
  initialNodeCount: 1
  config:
    ...
    imageType: COS_CONTAINERD
    machineType: e2-medium
    ...
  maxPodsConstraint:
    maxPodsPerNode: '110'
  ...
- name: additional-pool
  initialNodeCount: 1
  config:
    ...
    imageType: COS_CONTAINERD
    loggingConfig:
      variantConfig:
        variant: MAX_THROUGHPUT
    machineType: e2-standard-4
    ...
  maxPodsConstraint:
    maxPodsPerNode: '110'
  ...

なお、GKE クラスタの作成やノードプールの追加は GUI コンソールからも作成が可能ですが、高スループット版の Logging エージェントをデプロイする場合、現状はコマンドラインからの API リクエストが必要です。

3. 通常の Logging エージェントと高スループット版の Logging エージェントを比較する

それでは、各ノードプールにデプロイされた通常の Logging エージェントと高スループット版の Logging エージェントの YAML を取得し、主な差異を比較していきたいと思います。

3.1. イメージの比較

まずは各エージェントのコンテナイメージを確認してみましょう。
以下の図は、左を通常版の Logging エージェント、右を高スループット版の Logging エージェントとして、YAML の差異を VS Code で比較したものです。

高スループット版の Logging エージェントでは、fluentbit-gke-max-... という名前になるようですね。
313 行目 (fluentbit-gke-max では 331 行目) で確認できるとおり、高スループット版 Logging エージェントでも、引き続き Fluent Bit が使われています。
イメージのパスも一致していることから、高スループット版 Logging エージェントは「従来の Logging エージェントと同様に Fluent Bit のイメージを使っており、設定の違い (チューニング) によって高スループットを実現している」ことがわかります。

3.2. Fluent Bit の設定の違い

Logging エージェントのイメージは同一であることがわかったため、次にコンテナ毎の設定の違いを見ていきましょう。
Daemonset でデプロイされる Logging エージェントの Pod には、以下の 3 つのコンテナが定義されています。

ノードからログを収集する Fluent Bit (fluentbit)
収集したログを Cloud Logging に転送する Exporter (fluent-bit-gke-exporter)
初期化処理を行う InitContainer (fluentbit-gke-init)

通常稼働時は Pod に Fluent Bit と Exporter の 2 つのコンテナが存在していることになります。
まずは Fluent Bit の設定の違いを見ていきましょう。
以下の図は、左を通常版の Logging エージェント、右を高スループット版の Logging エージェントとして、 YAML の Fluent Bit の定義付近を比較したものです。

Fluent Bit のコンテナ単位の Request / Limit (特に CPU Request) が大幅に引き上げられていることがわかります。
その他の定義には大きな差異はなく、設定ファイルも同じ ConfigMap を読み込んでいるため、Fluent Bit としては割り当てリソースの引き上げによって高スループット版を実現していると言えそうです。

3.3. Exporter の設定の違い

次に、Exporter の設定の違いを見ていきましょう。
以下の図は、左を通常版の Logging エージェント、右を高スループット版の Logging エージェントとして、 YAML の Exporter の定義付近を比較したものです。

Exporter の CPU Request もまた、大幅に引き上げられていることがわかります。
加えて、コマンドの引数には通常版の Logging エージェントにはなかった --pod-cache-size=512 というオプションが追加されています。
このオプションはノードあたりの Pod 数上限を 111 以上に拡張した場合にも付与されていることから、通常版の Logging エージェントよりもログスループットが要求される場合に設定されるオプションのようです。

その他の定義には大きな差異はなく、設定ファイルも同じ ConfigMap を読み込んでいました。

補足 (fluent-bit-gke-exporter の役割)

fluent-bit-gke-exporter に関しては Google Cloud がプライベートに管理しているイメージのため情報が少ないですが、設定ファイルなどからその役割を推測することができます。
Fluent Bit の設定ファイルである fluent-bit.conf を含む ConfigMap として fluentbit-gke-config-* が Namespace: kube-system にデプロイされており、その OUTPUT セクションの定義を見ると、2020 ポートで稼働している Fluent Bit から、収集したログを 2021 ポートで稼働している Exporter に渡していることがわかります。
設定値からの推測ではありますが、fluent-bit-gke-exporter は収集したログを Cloud Logging に転送する役割を持っていると考えられます。

[SERVICE]
    Flush         5
    Grace         120
    Log_Level     info
    Log_File      /var/log/fluentbit.log
    Daemon        off
    Parsers_File  parsers.conf
    HTTP_Server   On
    HTTP_Listen   0.0.0.0
    HTTP_PORT     2020

...

[OUTPUT]
    Name        http
    Match       *
    Host        127.0.0.1
    Port        2021
    URI         /logs
    header_tag  FLUENT-TAG
    Format      msgpack
    Retry_Limit 2

高スループット版利用時の注意

高スループット版の Logging エージェントを利用する際は、適用先のノードプールのインスタンスタイプに注意が必要です。
Fluent Bit と Exporter がそれぞれ Request で 1 CPU を要求しているため、少なくともスケジュール先のノードが 2 CPU 以上のリソースを持っていなければなりません。

したがって、例えば割当可能な CPU が少ない e2-medium や e2-standard-2 では高スループット版 Logging エージェントが利用できません。
インスタンスタイプが小さい場合は --logging-variant=MAX_THROUGHPUT のオプションを付与してしまうと Logging エージェントが Unschedulable (割り当て不可) の状態となってしまうため、通常の Logging エージェントを利用しましょう。