GKEでアプリケーションのログを取るためにfluentdをStatefulSetで動かしたので、その忘備録です。
今回はBigQueryにログを加工して流す目的で使用しました。BigQueryへの挿入方法としては、streaming insertではなくloadを使用しています。
ちなみに、StackDriverやPub/Subを利用する方法も検討しましたが、費用が割と高いので、一旦断念しました。
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
fluentd側でバッファを書き込むディレクトリは、/fluentd/logに設定する必要があります。
<buffer>
path fluentd/log/bigquery.*.buffer
flush_at_shutdown true
</buffer>
終わりに
StatefulSetでfluentdを立てるような事例がweb上にあまりなかったので、簡単にまとめてみました。GKEでログ基盤を構築する場合は、StackdriverやPub/Subを利用した方がスマートな構成にできると思います。ただ、私の扱っているシステムはリクエスト数が膨大なため、想像以上に費用が嵩むため断念し、fluentdによる構成で構築しました。kubernetesでサービスを組む場合、状態を持たせる箇所は出来るだけ少なくしたいので、スマートかつ費用を抑えた方法がないか、今後も模索したいです。