「オープンソースカンファレンス 2020 Online/Spring セミナー」が4月24日、25日の両日オンラインで開催され、CNBF（Cloud Native Bright Future）発起人の高良真穂氏が講演。コンテナやKubernetesを “ライブ施設”に例えて、わかりやすく解説した。その内容を、ダイジェストで紹介する。（今回は後編。前編はこちら）
ポッドとコントローラー
Kubernetesのステージ上ではポッドが動いています。ポッドの中にはコンテナが入ってアプリケーションが動いているので、いろんな人がKubernetes上のアプリケーション（ポッドのコンテナ）にアクセスして、アプリケーションを利用します。このコンテナは、図３で説明したレジストリから来ています。
図３：Kubernetesが、レジストリサービスからコンテナを出庫
もう少し詳しくポッドについて見ていきましょう。ポッドは 英語で“エンドウ豆の鞘”を意味します。豆にあたるのがコンテナで、それを包んで保護しているのがポッドです。コンテナをそのまま実行させないのが特徴です。ポッドはIPアドレスを持っていて、ワーカーノードを横断するクラスタ（ポッド）ネットワークに接続し、外部からの通信を受け取ります。またポッドは内部で通信できる環境を提供します。さらにポッドには健康チェックの定義を入れることができ、コンテナがハングアップしている、動きがおかしい、遅い場合など、再スタートさせることができます。つまり、動作が保証されるということです。
またポッドによって、いろいろなキャラクターのコンテナを組み合わせて動かすことが可能になります。例えばログを収集するコンテナ、Javaを動かす（サーブレット）コンテナなどを共存させることができ、ポッドの中でチームを組み連携して目的とすることができるようになります。いろいろなコンテナを組み合わせて再利用する時に、効率良く使えるということになります。なおコンテナ連携の具体例についてはB.Burnsらの論文があり、その要約をQiitaに投稿しているので参考にしてください。（https://qiita.com/MahoTakara/items/03fc0afe29379026c1f3）
図４：ポッドが連携してアプリケーションを実行
次に、コントローラーの役割について解説します。ポッドはさまざまなワークロード（目的）で動きます。例えば、守り神のようにじっと世話をする（デーモン）、バッチ処理のように全力で走って結果を出す（バッチジョブ）、クライアントサーバーシステムのように注文を受けたら処理する（デプロイメント）、データベースのように貴重なデータを保管しておく（ステートフル）などのポッドに対して、それぞれのコントローラーが存在します。ポッドの仕事のニーズに合わせて管理してくれるのがコントローラーなのです。
このコントローラーは、マスターノードの中にいて、ポッドと連携します。コントローラーは処理能力や負荷状態に応じてポッドを増やしたり、もしポッドがなくなったら次のポッドを起動して必要な能力を維持したりします。また、ポッドの調子（パフォーマンス）が悪い場合など、別のポッドを起動して入れ替えることもできます。つまり、無停止でメンテナンスして能力を向上させられるということです。このように、コントローラーは可用性、スケール、無停止など、非機能要件をすべてお任せできるのです。
マスターノードとワーカーノード
マスターノードはコントロールして管理する立場で、ワーカーノードは力仕事を担当します。ワーカーノードの上にはポッドがいて、アプリケーションが動いているという構造になっています。もしワーカーノードが1つで、それが死んでしまったらすべて終わってしまいます。そこでマスターノードの配下には複数のワーカーノードが支えています。つまり、１つの神輿（ワークロード）を複数のワーカーノードで担いでいるというのが、Kubernetesのクラスタのイメージです。
このクラスタたちに命令を与える司令官は、あなた自身です。司令官は複数あるクラスタのチームに指令書を渡します。指令書が、マスターノードの中にあるAPIサーバーで受け付けられると、スケジューラーとコントローラーが連携して動きだします。スケジューラーは時間のスケジューリングではなく、リソース（仕事する人）を管理するためのもので、コントローラーは先述したように仕事の種類に応じた管理をします。
スケジューラーは「etcd」という台帳（データベース）を持っています。また、クベレットと会話してレジストリからコンテナを出庫してポッドを生成します。ワークロードに合わせたワーカーノードを選びます。ワーカーノードは多数のコアやGPUを持ちパワフルで機械学習のモデルを作成するもの、できたモデルを識別するだけのもの、ネットワーク的に振り分けするだけのものといったように、さまざまなものを作ることができます。これによって複数の環境を動かしていけるのです。
図５：マスターノードの役割
（実際には、マスター上の小人とワーカ上の小人の会話は、必ずAPIサーバーを介します。）
Kubernetesでマイクロサービスを効率的に運用
ここで、「サービス」について、説明しておきます。サービスを、 “お店”に例えてみましょう。ワンピースを作るお店（サービス）なら、注文が来たら裁縫するポッドに渡して処理してもらいます。実際にサービスにリクエストがかかると、サービスはetcdを検索して裁縫ポッドのIPアドレスを探し、リクエストを送るという動きをします。これにより、サービスとポッドの組み合わせを柔軟に切り替えることができます。Kubernetes のサービスは、柔軟なロードバランサーだということができます。
図６：柔軟なサービスが可能
例えば、ハンバーガーサービスを考えてみると、代表して受けるファーストフードポッドがあり、その下に肉屋、八百屋、パン屋などいろいろな注文（リクエスト）を受けて結果を返すポッドがいます。もし、自分のネットワークに必要なものがないときには、外部に依頼することもできます。ここまで話を聞くと、これがマイクロサービスだということが分かりますよね。Kubernetesはマイクロサービスを効率良く運用することを念頭に置いた仕組みだと言えるのです。各ワーカーノードの中に「クベプロキシ」という機能があり、どこにリクエストが来ても振り分けてくれます。これが、Kubernetesだとマイクロサービスを容易に動かせる理由の１つになっています。
図７：ポッドを連携したマイクロサービス
小さなマイクロサービスだとポッドの連携ですみますが、大きくなると付帯する仕組みが必要になります。これが「Istio」というサービスメッシュの仕組みになります。サービスが大きくなったら、Istioが便利だと覚えておくとよいでしょう。
監視についても、ポッドの中にはいろんなコンテナがあり、それぞれログを管理すると大変です。そこで、ポッドがログを集めて、ログ専門ツールやメトリックス専門ツール（Grafana、Elasticsearchなど）につなげて一元管理をします。従って司令官であるあなたは監視が楽になり、全体の大局を把握することに専念できるようになります。
KubernetesとRed Hat OpenShift
先述したように、CNCFのアップストリームが共通のKubernetesコアを流してくれています。このソースコードを利用したダウンストリーム（製品版）の1つが「Red Hat OpenShift」です。
KubernetesとOpenShiftを図で比較するとこうなります。Kubernetesのコアは同じで、これにさまざまな機能を拡張して製品化し、サポートも提供してくれています。企業がシステムを運用する時にやりやすいものとなっています。
図８： Kubernetes とRed Hat OpenShift
いかがでしたか。Kubernetesを好きになれたでしょうか。本日は、どうもありがとうございました。
関連動画
