背景
弊社ではさまざまなログを DataDog に集約しているのですが、一部サービスで EKS on Fargate を利用しており、datadog-agent + fluent-bit のサイドカー構成で DataDog にログを送っています。
その中でも Job を使用した場合にうまく DataDog にログが送れず、困っていました。 Job だとサイドカーが動いてくれない + Job終了時にサイドカーが終了してくれない という状況で、Jobに関してはDataDogを諦めて kubectl や ArgoCD 経由でログを一生懸命読む、という運用が続いていました。
結論
k8s 1.29 からデフォルトで有効となったサイドカーコンテナの機能を使用することで問題は解決しました。正解は公式ドキュメントにバッチリ書いてあり、今まで我々は何をそんなに困っていたんだろう？ということをつらつらと言い訳していこうと思います。
詳細
サイドカーが機能しない件
DataDog にログが出ず...これは、起動順序に問題があるようでした。メインのコンテナよりもサイドカーを先に起動させる必要があるところまでわかり、manifest の containers で記載順序を変えて対応しようとしました。実際このとき DataDog にログは出たのですが、サイドカーが終了しない問題の解決が難しくなりました。
サイドカーが停止しない件
Job の場合、仕事を完了したメインコンテナは仕事中のサイドカーを残して一人で終了してしまいます。これだと、終わった Job がいつまでも生き残ってしまいます。
そこでメインが終了する際にサイドカーを終了したり、逆にサイドカーがメインコンテナを監視してメイン終了を検知したら自分も終了する command を書いたりの工夫をしてみたのですが、サイドカーが機能しない件の対応で containers の記載順序を変更したところうまくいかなくなりました。
サイドカーコンテナ機能の使用
行き詰ったので心を落ち着けて公式ドキュメントをじっくり読むことにしたところ、わりとすぐに答えが見つかりました。結論にも記載した通り、k8s 1.29 からはデフォルトでサイドカーコンテナの機能が使用できるようになっていて、containers ではなく initContainers にサイドカーを指定するだけでOKでした。
サイドカーコンテナは initContainrs として指定するため、起動順序はメインコンテナよりも先となります。また、サイドカーの restartPolicy は Always を指定します。こうするとメインコンテナが終了した場合のみサイドカーが停止するようになります。
なぜ自前で四苦八苦していたのか
事前に軽く調べた際に「Job には自動でサイドカーを終わらせる方法がなく、自前で用意する必要がある」というブログを参照しており、ちょっと古い記事ではあったのですが、他に情報もなく、鵜呑みにしていたんですね。
公式ドキュメントを読み込んでおくのは基本のようにも思えますが、現場でスピード感を持って判断していく上で、ライトに読めてしまうブログやAIの回答を参考にして済ませてしまうことは実際よくあると思います。
そんな忙しい我々のためにも、軽く調べたら出てくるように情報発信をしていくことが大切だなと感じました。さらに言えば、不思議な力でこの記事が数ヶ月前の我々に届いてくれたらとても嬉しい。そういったサービスには対応していませんか？サンタさん、何卒宜しくお願い致します。
以上
