Azure の Kubernetes に関するハッカソンを実施


このポストは、8 月 28 日に投稿した Hackathon with Kubernetes on Azure の翻訳です。

マイクロソフトは初めて全社規模でハッカソンを実施 (英語) し、Kubernetes による Azure へのデプロイを視覚化するツールを新しく作成しました。今回、Kubernetes を Microsoft Azure の Docker コンテナーの管理に使用できることを発表 (英語) しましたが、それと同時に視覚化ツール用のコードも公開しました。このコードは Azure Kubernetes Visualizer の GitHub リポジトリ (英語) からダウンロードできます。

ハッカソン プロジェクトの詳細

今回のプロジェクトは、Azure で Docker の管理を行っているときに Kubernetes がどのような処理を実行しているかを視覚化するシステムを構築するというものでした。Kubernetes (英語) は宣言型のクラスター管理システムで、Docker (英語) と呼ばれるコンテナー化テクノロジをサポートします。こちらのページ (英語) でも紹介されているように、Docker は「ポータブルで軽量なランタイム」で、「アプリケーションの迅速な組み立てが可能」です。このプロジェクトの目的は、Container (コンテナー) や Pod (ポッド)、Label (ラベル)、Minion (ミニオン)、Replication Controller (レプリケーション コントローラー) などの Docker および Kubernetes のコンセプトを視覚的に表示することでした。その成果が、次のスクリーンショットです。

Kubernetes のクラスターは、1 つの Master (マスター) と複数の Minion で構成されます。Master はクラスター全体の管理を担当するものであり、Minion で実行する要求を発行し、Kubernetes の API 層を提供します。Minion は Docker を実際に実行する (つまりエンド ユーザーのワークロードを実行する) 部分です。Pod はコンテナー内の Minion 上で実行され、Master が各 Minion に Pod を分散させます。Kubernetes Visualizer では、名前を割り当てて Pod を作成し、その Pod をコピーする数を指定できます。

[Create!] ボタンをクリックすると、JSON の “Pod テンプレート” を更新できます。このテンプレートは、Pod とコンテナーの関連付け、各コンテナーで実行されるイメージ、および外部からサービスにアクセスする際に使用するポートのマッピングを定義します。

この Kubernetes Visualizer では、Kubernetes の理解を促進するために、バックエンドで自動的に作成された Pod テンプレートを編集できるようになっています。編集するには、[Pod Source] ボタンと [RC Source] ボタンをクリックします。下図のように、[Pod Source] では、Nginx インスタンス、および自動的に割り当てられたポート番号が表示されます。

この Pod テンプレートを編集すると、Kubernetes Visualizer の最初のスクリーンショット (Nginx と Redis の両方を実行している青やピンクの Pod を表示) にあるような、他の構成の Pod を作成できます。次の図は同じ Pod テンプレートを含む同等の Replication Controller のソースですが、Replication Controller ではコピーする Pod の数を指定します。

Kubernetes Visualizer には、Kubernetes の Label というコンセプトの表示を支援する役割があります。Label を使用すると、Pod に任意のキーと値のペアを割り当てて、Kubernetes で実行するすべての処理を体系化することができます。Kubernetes Visualizer は、Pod に関連付けられた Label に格納されている名前 (ユーザーが指定したもの) に従ってポッドを色分けします。名前ごとに色が変わります。

Kubernetes と Docker による学習

Kubernetes と Docker を使用していると、Docker が Pod の作成手順をキャッシュしてコンテナーの繰り返し処理の速度が向上することにすぐに気付くでしょう。最初に Minion 上に Pod を作成するときには、処理に数分ほどかかります。これは、主に Docker が Ubuntu および Nginx のイメージをダウンロードする間待機するためです。しかし、それ以降 Minion に Pod を作成するときには、イメージが既にキャッシュされているため大幅に処理が速くなります。これは、Kubernetes で実行されるアプリケーションのアーキテクチャのうち中核となるコンポーネントはほとんど変更されないことが予測できる場合は便利な機能です。たとえば、今回の例ではソース コードが変更されるだけで、常に Ubuntu および Nginx をベースとします。つまり、たいていの場合は Docker のキャッシュ機能により Kubernetes でのアプリケーションのセットアップと実行は非常に高速に行われます。

先日チームは、クラスターのストレス テストを実施し、多数の Pod を作成したときに Kubernetes がどのような挙動をするかを確認することにしました。このテストでは、初回に実施した 30 ~ 50 個の Pod での結果は非常に良好で、200 までのスケール アップが可能でした。次のスクリーンショットは、Nginx のコピーを 200 個作成した 3 回目のテストを実施しているようすです。回転する青いアイコンが表示されている黒いボックスは、起動処理中の Pod を示しています。1 番上の行は、Pod の作成要求は終了しているが Minion にはまだ割り当てられていない Pod を示しています。また各列は、既に Minion に割り当てられた Pod です。色付けされた Pod は、起動処理が終了し準備が完了した Pod を表しています。

参考情報

さらに詳細な情報をご希望の方は、このツールを動画で説明している Channel 9 の最新の Cloud Cover シリーズ (英語) をぜひご覧ください。また、GitHub からコードをダウンロード (英語) して、お客様の Azure のクラスターでこのツールをお試しください。チームでは、このツールが初めて Kubernetes や Docker、Azure をご利用になる方のお役に立てることを願っています。

最後までお読みいただきありがとうございました。

Michael Blouin、Madhan Arumugam Ramakrishnan (ハッカソン チームを代表して)

Comments (0)

Skip to main content