GKEでstatefulなfluentdを設置

GKEでアプリケーションのログを取るためにfluentdをStatefulSetで動かしたので、その忘備録です。

背景

今回はBigQueryにログを加工して流す目的で使用しました。BigQueryへの挿入方法としては、streaming insertではなくloadを使用しています。

StatefulSetでfluentdを動かす利点

BigQueryに限らず、fluentdで何かしらのデータストアにログを送信する際は、ファイルバッファを用いて定期的に送信するのが一般的かと思います。

しかし、k8sで普通にdeploymentを使ってfluentdのPodを配置する場合、何かしら不慮の事故でPodが再起動してしまうと、バッファしていたデータが失われてしまいます。Podが1台の構成であれば単純に永続ボリュームをマウントすれば良いですが、複数のPodで負荷分散・冗長化が必要なことの方が多いでしょう。

StatefulSetならPodが再起動した場合でも、再起動前にマウントされていた永続ボリュームを再度マウントできます。つまり、再起動前のバッファファイルを引き継ぐことができるということです。

StatefulSetの定義

以下がStatefulSetのサンプルです。

apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
  name: app-name
spec:
  serviceName: app-name
  replicas: 2
  selector:
    matchLabels:
      app: app-name
  updateStrategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: app-name
    spec:
      securityContext:
        fsGroup: 1000
      containers:
        - name: app-name
          image: gcr.io/:project_id/:image_name
          ports:
            - containerPort: 24224
          volumeMounts:
            - name: app-name-pvc
              mountPath: /fluentd/log
  volumeClaimTemplates:
  - metadata:
      name: app-name-pvc
    spec:
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 10Gi
      storageClassName: standard

StatefulSetはデフォルトでローリングアップデートが出来ないので、updateStrategyを設定します。

updateStrategy:
  type: RollingUpdate

バッファファイルの書き込みを許可するために、securityContextを設定しています(もっといい方法があるかも？)。

securityContext:
  fsGroup: 1000

10GBストレージのvolumeClaimTemplatesを定義して、/fluentd/logのパスにマウントしています。

volumeMounts:
  - name: app-name-pvc
    mountPath: /fluentd/log

volumeClaimTemplates:
- metadata:
    name: app-name-pvc
  spec:
    accessModes:
      - ReadWriteOnce
    resources:
      requests:
        storage: 10Gi
    storageClassName: standard

終わりに

StatefulSetでfluentdを立てるような事例がweb上にあまりなかったので、簡単にまとめて見ました。今回はStatefulSetの設定のみ記載しましたが、fluent.confとDockerfileも合わせて説明した方が分かり易かったかなーという気もするので、近いうちにそちらもまとめたいと思います。