Kubernetesのログはこう取れ！
『IT自動化の力でビジネス加速を全ての企業に』
はじめまして。リアルグローブ・オートメーティッド(RGA)技術ブログ編集部の馬塚です。RGAはSHIFTのグループ会社の１つで「IT自動化の力でビジネス加速を全ての企業に」をメインテーマとした ”IT自動化の専門会社” です。
RGA技術ブログ編集部の投稿では、IT自動化を導入すると「どんな良いことがあるのか」について紹介しつつ、RGAメンバーの技師たちが日々の業務を通じて培った技術情報や参考情報を読者の皆様にお届けします！
記念すべき（？）第１回目となる今回は、ビジネス加速にも大きく関わるコンテナ技術の１つであるKubernetesに関する記事をお送りします。すでにご存じの方もいらっしゃるかと思いますが、Kubernetesは大規模システム環境の管理を行っている運用担当者にとって、開発からデプロイまでを短いサイクルで回したいという要望を実現するための有用な手段の一つとして、最近注目を集めているコンテナ技術です。そのKubernetesを初めて導入した際に必ずと言っていいほど直面する問題の１つに、ログ取得の問題があります。そこで、Kubernetes環境におけるログ取得についてRGAの技師がまとめた技術レポートをご紹介いたします！
――――――――――――――――――――――――――――――――――
Kubernetesでログを取る
今回はKubernetes（以下、k8s）におけるコンテナログの収集の仕方についてご紹介します。
k8sでのログの取り方は、物理サーバーのときのそれとは大きく異なるので注意が必要です。
特にコンテナアプリケーションのログのとり方は、k8sクラスタの管理者だけではなく、k8s上で動くアプリケーションの開発者にも知っておいてもらいたい内容です。
Kubernetesにおけるログの種類
一口に「ログ」と言っても、k8sにおけるログには以下のような種類があります。
・コンテナログ（アプリケーションログ）
… k8s上で動いているコンテナアプリケーションのログ
・システムコンポーネントログ
… クラスタコンポーネント（kubeletなど）のログ
・監査ログ（Audit Log）
… 誰がどんな操作をしたか（このPodいつ誰が消したの？）といったログ
コンテナログ以外のログは基本的にはクラスタ管理者が知っていれば良いものですので、今回はコンテナログについて取り上げます。
コンテナログの取り扱いの難しさ
物理サーバーで障害が起こったときには、対象サーバーにログインしてログファイルを確認すればよいですよね。
しかし、k8sで同じようにログファイルを探そうとすると次のような理由でうまくいきません。
・トラブルが発生したらコンテナごと消えている（ことが多い）ため、障害が起こったコンテナにログインしてログを見ることができない。
・k8sの運用において、ユーザーはコンテナがどのサーバーで動いているか意識しないため、障害が発生したコンテナがどこのサーバーで動いていたのかわからない。
つまり、k8sでコンテナ運用をするのであれば、k8sのロギングアーキテクチャを理解して、ログをちゃんと保存する設計をしておく必要があります。
一般的なログ確認方法
基本的にコンテナログは以下のような方法で出力・確認することができます。
ログの出力
アプリケーションのログはコンテナ内にログファイルとして出力するのではなく、標準出力・標準エラー出力に出します。
ログの保存場所
コンテナが動いているサーバーの /var/logs/pods/<コンテナ名> にコンテナの標準出力・標準エラー出力の内容が保存されています。（ちなみに、/var/logs/pods/<コンテナ名> 以下にあるのはリンクで、実体は /var/lib/docker/containers/ 以下のログファイルです）
ログの確認方法
各ノードにSSHでログインして上記のログファイルを確認すればログを見ることはできますが、それはあまりにも面倒ですので、ちゃんとログを確認するコマンドがあります。
$ kubectl logs <Pod名>
または
$ kubectl logs <Pod名> -c <コンテナ名>
このコマンドにより、kube-api経由で各Podやコンテナのログを確認することができます。
しかし、この方法にも次のような問題が残っています。
・管理するPodやコンテナ数が増えるとログを追いかけるのが辛い。
・ノードが消えるとログも消えてしまう。
※後者については、k8sでは負荷に応じて自動でノードを増やしたり減らしたりする運用もよく行うので、これは結構重大な問題です。
このため、しっかりと運用するためにはノードの /var/logs/pods にログファイルを置いておくだけではなく、ログを別の場所に収集して保存する仕組みを用意するべきです。
ログの収集と保存
そこで出てくるのが「fluentd」です。fluentd というログ収集管理ツールを使うと、ノードのログファイルの内容をクラスタ外部のログ収集基盤に転送することができるのです。
まず、fluentdエージェントをDaemonSetでデプロイします。
※DaemonSetは全nodeに1Podずつ配置するk8sリソースです。
各ノードにデプロイされたfluentdエージェントは、そのノードのログファイルをログ収集基盤に自動的に転送します。こうすることで、k8sクラスタ上にデプロイされた全てのコンテナログを集約することができます。
この際のログ収集基盤としてよく使われるものとしては以下のものがあります。これらのサービスを使うと、ログを保存するだけではなくログの検索やフィルタリングもできるようになるので便利です。なお、Elasticsearchの場合には一般的に「Kibana」という可視化ツールとセットで利用します。
・Elasticsearch
・CloudWatch（AWSのマネージドサービス）
・Stackdriver Logging（GCPのマネージドサービス）
【ログ収集イメージ】
他のログ収集方法
上記の方法以外では、
・アプリケーションが（標準出力ではなく）ログファイルを出力する。
・アプリケーションが直接外部にログを転送する。
といった運用が考えられます。
ログファイルを出力する場合は、アプリケーションと同一Pod内にサイドカーコンテナを配置し、ログファイルを読み込んで外部に転送する仕組みを取ることもできます。この場合、既存のアプリケーションを変更する必要が無く、Podの外側の部分は前述の統一された収集基盤に載せることができます。
また、アプリケーションが直接外部にログを転送する場合は、アプリケーションが自分でログ転送をしてくれるので、k8s側で何か対応をする必要がありません。
しかし、どちらの方法にも、
・各アプリケーションごとにログ転送する仕組みを導入する必要があるため、管理コストが高くなる。
・kubectl logs でログが確認できなくなる。
といったデメリットがあります。
コンテナで動かすことを意識せずに開発したアプリケーションなどは、標準出力にログを出力する機能がないこともあり、そういったアプリケーションをコンテナ化してk8s上で動かす場合は上記のような対応をとることがあります。しかし、可能な限りログは標準出力に出力させておくと開発も運用も楽になります。
まとめ
コンテナログはとりあえず標準出力・標準エラー出力に出しましょう！
執筆者：株式会社リアルグローブ・オートメーティッド技師 青島
――――――――――――――――――――――――――――――――――
執筆者プロフィール：青島 秀治
九州大学大学院理学府博士課程中退。
大学院では理論天文学が専門。数値計算プログラム開発の傍ら、研究用の計算機郡や学内システムの開発・運用を経験。
2019年よりAnsibleを用いた運用作業自動化や自社サービスのKubernetes移行、OpenShiftのインフラCI実装などの業務に従事。
【ご案内】
ITシステム開発やITインフラ運用の効率化、高速化、品質向上、その他、情シス部門の働き方改革など、IT自動化導入がもたらすメリットは様々ございます。
IT業務の自動化にご興味・ご関心ございましたら、まずは一度、IT自動化の専門家リアルグローブ・オートメーティッド(RGA)にご相談ください！
お問合せは以下の窓口までお願いいたします。
【お問い合わせ窓口】
株式会社リアルグローブ・オートメーティッド
代表窓口：info@rg-automated.jp
URL: https://rg-automated.jp
（編集：馬塚勇介／校正：水谷裕一）
#IT Automation