Tech Sketch Bucket of Technical Chips by TIS Inc.

OpenStack MagnumでKubernetesのexampleを動かしてみる

Pocket

10月末に都内でOpenStack summit Tokyoが開催されました。同サミットではOpenStackの開発者やユーザによる基調講演が行われました。OpenStack FoundationのエグゼティブディレクターであるJonathan Bryce氏は基調講演の中で、Libertyで追加されたコンテナ管理の『Magnum』に非常に大きな関心が集まっていると語っていました。(引用元:クラウドWatch
OpenStack MagnumはOpenStack Containers Teamによって開発されたもので、Dockerコンテナを扱うための機能です。Magnumを使うことによって、コンテナクラスタのデプロイおよび制御をOpenStack上で行えるようになります。

そこで、本記事では実際にOpenStack Magnumを使ってkubernetesのexampleを動かしてみたいと思います。
サムネイル

仕組み

800px-Magnum_architecture.png
(出典:https://wiki.openstack.org/wiki/Magnum)
Magnumは、既存のAPIであるNova、Neutron、Glance、Cinderなどよりも上位のレイヤーに存在しています。Magnum APIのBayは、OpenStackのオーケストレーション機能であるHeatによりNovaやNeutron、Glance、Cinderを操作して、コンテナをクラスタリングするための環境を構築し提供する機能などを備えています。環境が提供された後はMagnum APIのNode、Pod、Service、RC等を使ってコンテナを制御できます。また、Magnumによるコンテナのオーケストレーション処理は、既存のオーケストレーションツールのKubernetesやDocker Swarmを、OpenStackに取り込むことで実現しています。

準備

今回は以下の記事を参考にOpenStack Magnumの導入をしたところから準備を開始していきます。
ThinkIT Dockerコンテナのオーケストレーション機能を実現するOpenStack Magnumを触ってみた
また、この記事にはMagnumのコマンドや用語の説明が書かれていますので一度確認しておくことをおすすめします。

まずはBaymodelを作成し、それをもとにBayを作成していきます。
bayとbaymodel
(出典:http://thinkit.co.jp/story/2015/10/28/6553)
図に記載されているBayという枠は、Magnumで構築するクラスタの単位であり、Baymodelという「ひな形」をもとに作成されます。Baymodelには構築するノードのOSやネットワーク、使用するクラウドオーケストレーションエンジンなどを指定します。Bayを作成すると、Baymodelをもとにインスタンス、ネットワーク、オーケストレーションエンジンを動かすための環境などを自動的に設定、構築してくれます。Bayという単位で管理することによって、クラスタごとの削除、ノード数の変更を容易に行うことができます。今回はKubernetesのエンジンを使用するため、作成されるインスタンスはコンテナを配置する場所となるMinionと、APIを実行してMinionに対してコンテナの制御などをさせるMasterです。

Baymodelで使用する鍵を作成します。

novaに公開鍵を登録します。

Baymodelの作成を行います。

baymodel-createコマンドで使用したオプションの一覧を、以下の表にまとめます。

オプション名 説明
name Baymodelの名前を指定します
image-id 作成するノードのマシンイメージを指定します。今回はデフォルトで入っているFedoraのイメージを使用します
keypair-id ノードの認証に使用する鍵を指定します。今回はひとつ前の手順で作成したtestkeyを使用します
external-network-id 外部ネットワークを指定します。今回はデフォルトで入っているpublicを使用します
dns-nameserver DNSサーバを指定します。今回はGoogle public DNSを指定します
flavor-id 作成するノードの構成を指定します。今回はデフォルトで入っているm1.smallを使用します
docker-volume-size Dockerで使用するボリュームサイズを指定します
network-driver コンテナ間で通信するためのネットワークドライバを指定します。
coe Cloud Orchestration Engineの略で、使用するエンジンを指定します。今回はKubernetesを使用します(現時点では他にswarmとmesosが指定できます)

Bayの作成を行います。今回はノードの数を2つとします。

bayコマンドで使用したオプションの一覧を、以下の表にまとめます。

オプション名 説明
name Bayの名前を指定します
baymodel Bayの作成時に使用するBaymodelを指定します。今回は先ほど作成したk8sbaymodelを使用します
node 作成するノード数を指定します

exampleを入手するためにKubernetesをダウンロードして、解凍します。

exampleを動かしてみる

今回はKubernetesのexampleにあるredisとstormを動かしてみたいと思います。

redis編

redisはKeyValue形式によって高速なアクセスが可能なNoSQLです。
今回はredisクラスタを作成して、値の登録と取り出しを行ってみたいと思います。

今回作成するコンテナを以下の4つとします。

コンテナ名 個数 説明
redis-master 1 redisのマスターノード
redis-sentinel 2 redisの監視、通知を行いフェイルオーバを実現します
redis-slave 1 redisのスレイブノード

redis構成図.png
今回作成するredisクラスタはこのような構成とします。
左側のノードではredis-masterとredis-masterを監視するためのredis-sentinelを1つのPodにまとめます。右側のノードは、redis-slaveのPodとredis-slaveを監視しているredis-sentinelのPodとします。Podがどのノードに振り分けられるかは、Kubernetesが自動で決めますので今回と同じ配置にはならないことがあります。また、Serviceとしてsentinel用のServiceを登録します。

redis-masterのPodを作成します。

replicaの数を2に変更して、redis-sentinelを作成します。
※今回のケースではreplica数を1のまま作成すると、対象のPodが作成されないことがあります。replica数を2にすると1つだけ対象のPodが作成されるので、今回はそれで対処します。

同じくreplicaの数を2に変更して、redis-controllerを作成します。

redis-sentinelのServiceを登録します。

bayの状態を表示して、ノードのIPアドレスを確認します。

sshでノードにログインします。

コンテナの一覧を表示させます。

コンテナ一覧のNAMESの項目で「k8s_master~」と書かれているコンテナがある場合そのコンテナに入ります。-itの後はCONTAINER IDを指定します。文字列「true」を登録します。
※もし、NAMESの項目で「k8s_master~」と書かれているコンテナがなかった場合はもう一方のノードにログインして「k8s_master~」と書かれているコンテナに接続します。

コンテナおよびノードから抜けます。

もう一方のノードにログインします。

コンテナの一覧を表示させます。

コンテナ一覧のNAMESの項目で「k8s_redis~」と書かれているコンテナに入ります。

文字列「true」が取り出せることを確認します。

storm編

stormは非言語依存でリアルタイムな分散処理を実現するOSSです。
今回はstormクラスタを構築して、zookeeperが接続しているクライアントを表示してみます。

今回作成するコンテナを以下の4つとします。

コンテナ名 個数 説明
zookeeper 1 複数サーバの協調動作を実現します
storm-nimbus 1 stormクラスタにおけるマスターノード
storm-worker 2 stormクラスタにおけるスレイブノード

storm構成図.png
今回はつのPodに対して一つのコンテナを割り当てます。
また、Serviceに関してはzookeeper用のServiceとnimbus用のServiceを登録します。

zookeeperのPodを作成します。

zookeeperのServiceを登録します。

storm-nimbusのPodを作成します。

storm-nimbusのServiceを登録します。

workerの数をノードの数を合わせるためにreplicaの数を2に変更して、storm-worker-controllerを作成します。

インスタンスの一覧を表示してmasterのIPを確認します。
インスタンスの名前で「k8--kube_master-」と書かれたものがmasterです。

masterにログインします。※今回のログイン先はmasterですが、接続する際に指定するユーザ名は「minion」となります。

登録したzookeeper ServiceのIPを確認します。

masterからログアウトします。

ノードにログインします。

クラスタの確認をします。
storm-workerの2つとstorm-nimbusおよびzookeeperの合計4つのクライアントと接続できていることが確認できます。

まとめ

今回はOpenStack Magnumで、redisとstormのexampleを動かしてみました。
OpenStack Magnumを使うことによって様々なクラスタのデプロイを簡単に行えることを確認しました。
また、今回OpenStack Magnumを触ってみて以下の点をメリットとして感じました。

オーケストレーションツールの選択が可能

今回はKubernetesを使用しましたが、そのほかにもDocker SwarmやMesosなどにも対応しています。今後は、Magnumで対応するオーケストレーションエンジンが、さらに増えることを期待しています。

オーケストレーションツールの導入が不要

Kubernetesのようなツールは、導入するだけでも多くの時間を必要とする可能性がありますので、OpenStackの導入さえ乗り越えればツール導入の手間を省けるのはありがたく感じます。

クラスタごとのテナント管理が実現

MagnumでBayを作成する際は、OpenStackの認証機能であるKeystoneの認証を通して行います。Kubernetes単体ではクラスタに認証をかけることはできませんでしたが、Magnumで扱うクラスタはテナントごとに管理されているため、セキュアなものとなります。

このようにOpenStack Magnumを使うことによって多くのメリットを感じることができました。
しかし問題点も存在し、redisのexampleを動かした際に、指定したreplica数に対して作成されるPod数が異なる現象が発生するなど不完全な部分も見受けられます。OpenStack Magnumはまだまだ発展途上であり、実用に供するにはまだ早い感じがします。今後は現状抱えているいくつかの問題点が修正されて安定したプロダクトとなり、多くの人々がOpenStack Magnumを使い始めることに期待しています。

エンジニア採用中!私たちと一緒に働いてみませんか?