2019.10.02

「Kubernetesで初めてのアプリを作ろう」パート2: プロセスの設定 #docker #kubernetes #k8s

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

このブログシリーズのパート1では、Kubernetesでの初めてのアプリ構築の基本をご紹介しました。今回の記事では、アプリケーションを管理するための拡張可能なプロセスを作るために、PodやControllerをどのように使うべきかをご説明します。

KubernetesにおけるPodとControllerとしてのプロセス

いかなるアプリケーションもその核となるのは実行プロセスです。そしてKubernetesでは基本的に Pod としてプロセスを作成します。Podは個々のコンテナに比べて、少し手が込んでいます。すなわち、コンテナの一群としてまとめてスケジュールでき、単一ホストにまとめて配置できます。これが最初の判断ポイントとなります:

判断ポイントその1: プロセスはどのようにPodにまとめるべきか？

Podの背景にある元の考え方は、VMのように 論理ホスト をエミュレートすることでした。Pod内のコンテナは常に同じKubernetesノード上にスケジュールされ、localhostを通じてお互いに通信可能となります。これによりPodは、互いに密接に動作する必要のあるプロセスの集合をうまく表現することができます。

ここで考慮すべき重要な点があります: 1つのPod内にある個々のコンテナを別々にスケールすることは不可能ではありません。 アプリケーションのスケールアップが必要な場合、Podを追加しなければなりません。それにはPodが有する各コンテナの複製が伴います。どのアプリケーションコンポーネントが同様の割合でスケーリングするのか、また反対に同様の割合でスケーリングしないコンポーネントはどれか、あるいはどのコンポーネントが同じホストに同居すべきなのか、といった要因によって、プロセスをどのようにPodにまとめるべきかが決まります。

私たちのウェブアプリで考えてみます。おそらく私たちは、フロントエンドのコンテナのみを有するPodを作成することから始めるでしょう。このフロントエンド用コンテナを、残りのアプリケーションから独立してスケーリングできるようにしたければ、フロントエンド用コンテナのみがPod内に存在するはずです。

一方で、データベース用のコンテナとAPI用のコンテナを一緒に有するもう1つのPodを設計するかもしれません。この方法では、同じ物理ホスト上でAPIがデータベースに通信できることを保証でき、APIとデータベース間のネットワークレイテンシを除外し、最大効率化が可能です。前述の通り、これは独立したスケーリングを犠牲にしてしまいます。APIコンテナとデータベースコンテナを同じPodとしてスケジュールする場合、データベースコンテナの新しいインスタンスが欲しいときは毎回、APIコンテナの新しいインスタンスも一緒に増えてしまいます。

この選択が正しいか間違っているかは、それぞれの場合で議論となるでしょう: APIとデータベース間のレイテンシは本当に主要なボトルネックなのでしょうか？APIとデータベースを別々にスケーリングすることの方がより重要である可能性はないでしょうか？最終的な判断はユーザによって異なるでしょう。しかし同じ判断ポイントが多くのアプリケーションに一般的に適用可能です。

さあ、Podについては計画を練りました（フロントエンドに1つのPod、APIとデータべースの組み合わせに1つのPod）。次は、これらのPodをどのように管理するかについて決めます。実質的には、Podを直接的にスケジュールすることは望ましくありません（これを「ベア・ポッド（Bare Pod）」と呼びます）。ここでは Kubernetes controllers の利点を活かします。障害を起こしたPodを自動で再スケジュールしてくれます。また、Podをどこでどのようにスケジュールするか簡単に作用できるようにし、それらのPodをどのように更新・維持するための機能もあります。 ここでは、少なくとも2つの主要な種類のControllerの中から選択します:

判断ポイントその2: それぞれのPodにどのよう種類のControllerを使うべきか: DeploymentかDaemonSetか？

Deployment

もっとも一般的な種類のControllerです。リソースが利用可能な場所ならどこでもスケジュールが可能であるステートレスなPodにとって、最も典型的で最適な選択です。

DaemonSet

1つのホストに対して1つ 実行するためのPodに最適です。これらは一般的に、Kubernetesクラスタ内のすべてのホストそれぞれにぴったり1つずつ存在することに適している、ログアグリゲータ、ファイルシステム管理、システムモニターなど、デーモンのようなプロセスに使われます。

すべてではありませんが、ほとんどの場合Podはこの2つのControllerで最適にスケジュールできます。なかでもDeploymentが主力です。私たちのウェブアプリコンポーネントのどちらも、クラスタ全体のデーモンでは理に適わないため、私たちは両者をDeploymentでスケジュールします。のちにロギングまたはモニタリングのアプライアンスをデプロイしたい場合は、クラスタ内の各ノードで実行できるdaemonSetが一般的な方法でしょう。

これまでに、コンテナをどのようにPodにまとめるかと、Controllerを使用してPodをどのように管理するかについて判断してきました。では次に、これらのオブジェクトを作成するためのKubernetes yamlをいくつか書いてみましょう。Kubernetesドキュメントや、Dockerのトレーニングマテリアルで、手順や例が紹介されています。

命令的なkubectlコマンド ではなく 、Kubernetes yaml定義を用いて、アプリケーションを定義することを強くお勧めします。最初の記事でお伝えしたように、コンテナ化したアプリケーションのオーケストレーションにおいて最も重要な側面の1つは、共有性です。バージョン管理システムにチェックイン・配布できるyamlファイルはとても簡単に共有できるのです。一連のCLIコマンドでは、すぐに読み込みや追跡が困難となってしまいます。