KubernetesAWS@mosuke5です。Kubernetes上でのアプリケーションのロギングについてFluentdを使ってどうできるか考えていきます。logsへ集約することについてやってみました。FluentdとAWSの連携については、以前にそういえばこんなものもかきましたので、参考にしてください。自分も復習で見返しました。logsに送ることです。アプリケーションは、ブログでの例ではNginxにしました。実際にはNginxや独自のアプリケーションだったり様々かなと思います。背景としては、ロギングの方法についてはいくつかあるが、それぞれを実際に行うとどんな印象か・使い勝手かといったところが知りたいので行いました。Kubernetesでのロギングについての考え方は英語ですがこちらを参考にするといいです。本ブログは、ロギングはサイドカーでやるのがいい!、という話ではありませんので注意してください。ログの送付先ですが、いろいろと選択肢があると思います。Kubernetesクラスター上にElasticSearchなどを立てる、DatadogのようなSaaSを使うなどなど。logsにしてみました。他のサービスでも基本的な考え方は一緒なので応用できると思います。先にこちらをやってみた結果を書くと、やってみた感じアプリケーションのログをサイドカーのFluentdで収集するのは場面によりますがあまり得ではないと現時点で考えました。理由は、サイドカーのデメリットはPod毎にサイドカーコンテナが必要だということです。Fluentdもまあまあメモリを食うので、ロギングというほぼどんなアプリケーションにも必要なものについてサイドカーで載せる必要はないと思っています。サイドカーではなくDaemonSetとしてFluentdを動かすのが一番よさそうです。Twitterで聞いてみたところ、標準出力以外に複数のファイルにログを吐く場合にサイドカーでのFluetndを使うという意見もありました。fluentdの設定についてコンテナ化する場合はまずは通常のサーバなりローカルで設定や概念を理解することをおすすめします。自分もこちらを実施するに当たり、一度テスト用のEC2の上で動作など確認しました。fluent.conf利用するfluent.confは次のようなものとします。true</match>sourceNginxのaccess.logを対象としました。流れとしてはでまず対象のログをどう取得するかを決めます。この場合はTailというプラグインを使った収集を使っています。この対象になったログにはnginx.accessというタグをつけました。これは後ほどフィルターしたり他の場所に転送するための判断材料になります。fileterはあとからつけました。なくても動作はします。これをつけた理由はKubernetesのLivenessProbeでのヘルスチェックのログを排除するためです。match転送先を設定します。logsに送りたかったので、プラグインをインストールする必要があります。こちらのプラグインを利用しました。利用するには、下記のようにgemでインストールします。DockerHubで公開されているfluentdのコンテナイメージには当然インストールされておらず、都度インストールするのはめんどくさいので、プラグインがインストールされた状態のコンテナイメージを作っておきました。(個人で遊びで使うときはいつもGitlabのイメージレジストリを使っています。Gitlabを使ったコンテナイメージの自動ビルドについては過去にこちらの記事の一部として書いています。fluent-plugin-cloudwatch-logsFluentdは、AWSに送付するので、AWSへのアクセス権限が必要です。Keyを環境変数で渡すことにしました。こちらは次のDeploymentの部分で説明します。Deploymentに組み込むKubernetes上のDeploymentに組み込むわけですが、サイドカー方式での基本的なロギングの考え方は以下のようになります。最終的には下記のようなマニフェストになりますが、ポイントは次の3つです。PodはKubernetesのデプロイの最小単位ではありますが、そのなかにコンテナは複数配備することができます。メインはNginxなのですが、サイドカーとしてFluentdコンテナを配備しています。各コンテナでログを共有できるように、ボリューム共有(EmptyDir)をマウントしています。KeyなどをSecretとして環境変数で渡しています。その他下記コメントをまぜました。{}動作確認podを確認すると、2/2とふたつのコンテナが起動していることがきちんと確認できる。logsでログは確認できないことは要注意しておきましょう。22hまたAWSコンソール側にも少しラグはあるものの、送付されていることが確認できました。AWS側に来ない場合には、fluentdコンテナのログを確認してエラーが出てないかなど確認してみましょう。worker=0まとめKubernetes上のアプリケーションについて、Sidecar方式でのロギングをやってみました。冒頭の結果のところにも書きましたが、ロギングという観点でいうとSidecarではない方法でのアプローチのほうが便利そうでした。一方でこういったアプローチが必要な場面もあることがわかり、1つの選択肢として重要かなと考えています。Shopを使ったマイクロサービス体験のハンズオン「捉」2019年振り返り「LeanとDevOpsの科学」を読んで。