【ITニュース解説】Day 55: Kubernetes Sidecar Containers

Kubernetesというシステムでアプリケーションを動かす際、メインとなるアプリケーションに加えて、そのアプリケーションの機能を補助する役割を担う別のコンテナを同じPod内に配置することがある。この補助的なコンテナを「サイドカーコンテナ」と呼ぶ。サイドカーコンテナは、メインのアプリケーション自体に変更を加えることなく、追加の機能を提供したり、特定のタスクを専門的に処理したりする目的で利用される。

メインのアプリケーションは、本来の目的であるウェブページの提供やデータ処理といった、一つだけの主要な仕事に集中させたいという設計思想がある。もしログの収集や設定の同期といった補助的な機能をメインのアプリケーションに直接組み込んでしまうと、アプリケーションのコードが複雑化し、開発や保守が困難になる可能性がある。そこで、補助的な機能は別のコンテナに任せることで、それぞれのコンテナが自分の専門分野に特化し、シンプルさを保つことが可能になる。この考え方は「分離の原則」と呼ばれ、サイドカーパターンを採用する主要な理由の一つである。

具体的な例として、ウェブサーバーであるNginxが生成するアクセスログやエラーログの扱いを考えてみる。これらのログは、ウェブサイトの運用状況の把握や問題発生時の原因究明に不可欠だが、Nginx自身にログを外部のログ集約サービスへ送信する機能を実装するのは、Nginx本来の役割とは異なる。この場合、Nginxのログファイルを読み込み、それをログ集約サービスに転送する専用のコンテナを、Nginxコンテナと同じPod内に配置することで、Nginx本体に一切手を加えることなくログ転送の仕組みを構築できる。

Kubernetesでは、アプリケーションを動かす最小単位をPodと呼ぶ。一つのPodの中には、一つまたは複数のコンテナが配置され、それらのコンテナは共通のネットワーク空間やストレージを共有できる。今回の例では、「webserver」という名前のPodを作成し、その中にウェブサーバーとして動作する「nginx-container」と、ログを処理する「sidecar-container」の二つのコンテナを配置する。さらに、これら二つのコンテナ間でログファイルを共有するために、「shared-logs」という名前の「emptyDir」ボリュームを活用する。

emptyDirボリュームは、Podが起動する際に自動的に作成される一時的なストレージ領域である。このボリュームはPodが稼働している間のみデータが保持され、Podが削除されると同時にそのデータも失われる特性を持つ。そのため、永続的なデータの保存には適さないが、同じPod内の複数のコンテナ間で一時的なファイルを共有する用途には非常に有効だ。今回の構成では、このshared-logsボリュームを、両方のコンテナから/var/log/nginxという同じファイルパスでアクセスできるように設定する。

「nginx-container」はNginxの最新バージョンイメージを基に動作し、ウェブサーバーとして機能しながら、ウェブアクセスやエラー情報をログとして共有ボリューム上の/var/log/nginxディレクトリに書き込む。一方、「sidecar-container」は軽量なUbuntuイメージを基に動作し、メインのNginxコンテナと同じ共有ボリューム上の/var/log/nginxディレクトリから、Nginxが書き出したログファイルを定期的に読み取る役割を担う。

KubernetesのPodには、通常のアプリケーションコンテナの他に、「初期化コンテナ（initContainer）」という種類のコンテナがある。初期化コンテナは、Pod内の通常のコンテナが起動する前に一度だけ実行され、メインのアプリケーションが動作するために必要な初期設定や準備作業を終えると終了するのが一般的だ。しかし、サイドカーコンテナの場合は、単なる初期準備だけでなく、メインコンテナの稼働期間を通じて並行して動作し続ける必要がある。この継続的な動作を実現するために重要なのが、サイドカーコンテナをPodの「initContainers」セクションで定義し、さらにそのコンテナに「restartPolicy: Always」という設定を適用することだ。この特別な設定の組み合わせにより、通常は一度きりで終了する初期化コンテナが、メインコンテナと同様にPodが存在する間ずっと稼働し続けるようになる。これがサイドカーコンテナを機能させるための決定的な要素である。

「sidecar-container」の中で実行されるコマンドは、「while true; do cat /var/log/nginx/access.log /var/log/nginx/error.log; sleep 30; done」というものである。このスクリプトは非常にシンプルで、「while true; do ...; done」の部分が無限ループを意味し、コンテナが停止しない限りこの処理を繰り返し実行する。ループの中では、「cat /var/log/nginx/access.log /var/log/nginx/error.log」というコマンドが、Nginxが書き込んだアクセスログとエラーログの内容を読み取り、その結果をコンテナの標準出力に表示する。この標準出力へ出力されたログは、Kubernetesのログ収集機構によって捕捉され、最終的に外部のログ集約サービスへと転送される仕組みを想定している。そして、「sleep 30」によって30秒間待機した後、再びログを読み取るという一連の処理が繰り返される。このように、「sidecar-container」はNginxに直接的な変更や負荷をかけることなく、ログの収集と転送という専門的な役割を継続的に果たす。

これらのサイドカーパターンを実現するための設定は、KubernetesのPodリソースを定義するYAMLファイルに記述される。YAMLファイルのspecセクションでは、まずvolumesフィールドで共有ボリュームの設定を行い、次にinitContainersフィールドでサイドカーコンテナの設定を、そしてcontainersフィールドでメインのNginxコンテナの設定をそれぞれ記述する。特に、initContainers内で定義されるサイドカーコンテナのrestartPolicy: Alwaysという設定と、両方のコンテナがvolumeMountsによって同じボリュームを共通のパスでマウントしている点に注目することで、この構成の全体像とコンテナ間の連携がより明確に理解できるだろう。

このサイドカーパターンを適用することで、Nginxというメインアプリケーションに手を加えることなく、ログ収集という補助機能を独立して実装し、運用することが可能になる。これにより、Nginxのアップデートや設定変更が容易になり、ログ収集機能だけの更新も独立して行えるため、システムの柔軟性と保守性が向上する。このサイドカーの考え方は、ログ収集だけでなく、アプリケーションの設定を動的に同期させたり、ネットワークプロキシを配置したり、アプリケーションの監視エージェントを組み込んだりするなど、様々な場面で活用できる非常に強力で汎用的なパターンである。