Rancherを使う

以前挑んで見事に玉砕したことがあるのですが、今回久々にRancherを使ってみることにしました。Rancherは言うなれば「お手軽Kubernetesクラスタ構築・運用管理ツール」みたいなもんで、ブラウザGUIを使って簡単にKubernetesクラスタを組むことが出来るようになります。どちらかというと、PaaS環境をより身近に使えるようにするツールと言っても良いのかもしれません。

個人的にRancherの美味しいところ

Rancherを使っていて嬉しいところは、vSphereクラスタに対して手軽なデプロイメントが行える点です。

ノードテンプレートの設定画面でvSphereを選択することで、vSphereの認証情報や作成先データセンターなどを指定することで手軽にノードを構成することが出来ます。ただし、静的IPアドレスを振るにはvSphereのネットワークプロファイル機能を構成する必要があるわけですが、そこはうまく使いこなせなかったため、私の環境ではDHCPで自動的にIPアドレスを割り当てる設定にしています。

また、作成元となるVMテンプレートにはcloud-initをあらかじめインストールする必要があります。

本来、Kubernetesのインストールや必須環境の構成など結構な手間がかかるんですが、これを使うことでわりかしあっさりと環境を構築することが出来るようになります。かなーりガチで便利なのですよこれが(´∀｀*)ｳﾌﾌ

vSphereと連携してPersistentVolumeを

実は、vSphereと連携するのはクラスタデプロイメント機能だけでなく、動的にPersistent Volumeを構成することが出来ます。以下の画面がそうなんです。

ただ、これだけではPVを動的に払い出すことが実は出来ません。実はクラスタデプロイメントを行う際に必要な設定があります。

Cloud Provider設定

このvSphereとのVMDK連携は、Cloud Providerと言う機能で連携をしています。クラスタデプロイを行う際、一緒にこのクラウドプロバイダー設定を追加する必要があるのです。

（追記）Rancher2.5系だと、まずは以下の赤枠個所にある「CloudProviderを仕込むかどうか？」の選択を行います。

この時、私の場合は「Custom(In-Tree)」を指定しました。クラウドプロバイダーの設定を以下YAMLで中に仕込む場合は、これを選択する必要があるようです。これをしないと設定追加をしてもそれがクラスタに反映されませんでした。

この設定を行った後、YAML表示に切り替えて設定を追加することになります。

上記設定画面にて「YAMLとして編集」というボタンをクリックすることで設定を追加する形になります。そのため、事前にKubernetesのバージョンやCNIの種類など、GUIで設定できるところを一通り設定してからこのボタンを押すと良いかなと思います。

すると、YAML形式で設定が記載されてる状態でエディタが起動しますんで、そこの赤い矢印で示してる箇所（実際にはrancher_kubernetes_engine_config:配下であれば良いんだけど）に以下のような設定を埋め込みます（あくまで一例としてお考えください）

  cloud_provider:
    name: vsphere
    vsphere_cloud_provider:
      global:
        insecure-flag: true
      virtual_center:
        vcsa.bluecore.net:
          datacenters: /BLUE-DC
          port: '443'
          user: "administrator@bluecore.local"
          password: "<password text>"
      workspace:
        datacenter: /BLUE-DC
        default-datastore: /BLUE-DC/datastore/SHARED-STORAGE/NFS-DS29
        folder: /BLUE-DC/vm/Rancher
        server: vcsa.bluecore.net

当方の環境は上記のような構成で記述をしています。このYAML文を挿入した状態で「保存」をクリックすることで、上記vSphere設定が投入された状態でクラスタが構成されます。その後、ストレージクラスを構成し、そのストレージクラスをAppに指定することによってPodのPersistent Volumeが構成されるようになります。

その後、クラスタレイヤーの画面にてストレージクラスを設定するわけですが、ここも注意が必要になります。

いろいろ入力項目あるんですが、入力するのは「ディスクフォーマット」「データストア」だけです。ほかの設定は原則VSANで使用するためのパラメータであり、私の構成のように単純なNFS集約型データストアだと、そこを設定してしまうとプロビジョニング時にエラーが発生してPersistentVolumeを作ってくれません。

個々のパラメータは後で修正することができないので、特に注意が必要です。
あとは、Appsなどでコンテナを作成する際、PVを有効にし、サイズとストレージクラスを指定することにより、データストア上にVMDKファイルが作成されるようになります。

構成されたPVとPVC

現在ぼちぼちコンテナを作成しては遊んでいるのですが、以下のようにPV/PVCは組まれていることを確認しました。

Persistent Volume ClaimはPodに対応するものなので、Apps/名前空間配下に構成されます。「リソース」->「ワークロード」をクリックし、「ボリューム」タブをクリックすることで確認することが出来ます。

Persistent Volume、つまりボリューム本体はクラスタ直下に構成されるリソースですので、クラスタ画面から「ストレージ」→「永続ボリューム」をクリックすることにより一覧表示させることが出来ます。現在の私の構成だと、監視とログ転送、メール発報を有効にしていることもあり、Kube-System名前空間上で動作するprometheusやGrafana用のボリュームも此方に一覧表示されています。

Persistent Volumeの実体は

じゃぁ、Persistent Volumeってどう言う形で払い出されてるんだろう？ということですが、指定したデータストアの中身を調べてみるとありました。

どうやらkubevolsと言うディレクトリが構成され、その配下にPVが眠っているようです。VMDKのプロパティを確認したんですが、特殊な設定は特にして居らず、共有モードも無効になっていました。恐らくは割り当てたPVに関してはコンテナの移動に伴いHotAddによる付け外しを行っているのではないかなと予想しています。

当方の環境ではMaster1台、Worker2台の最低限な内容で稼働させていますが、Masterには1つ、Worker-1には7つ、Worker-2には6つのVMDKが接続されていました。

動的払い出しはやっぱり便利

動的払い出しの設定が有効であるのはやっぱり便利で、特にAppsを払い出すにはストレージクラスの構成が必須だったりします。ストレージクラスの構成が取れる・取れないの差がかなり甚大なユーザビリティの差になるので、やっぱり何らかのストレージ自動構成の仕組みを考える必要があるのだなーと言うのは良く分かりました。

あまり積極的に活用する気はそんなに無いんですが、今後も覚えていくことになりそうな技術なので、取り敢えずこのコンテナ基盤の維持管理を第一に据えてこの環境で学べることは学んでみようと思っています。（いっつもすぐ環境壊しちゃうからね・・・(´･ω･`)）