[k8s][rancher][vSphere] PVをvSphereから払い出して貰うの巻

Rancherを使う

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

Rancherで構築されたクラスタの簡易ダッシュボード

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

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

vSphereと連携したクラスタデプロイ設定画面

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

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

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

vSphereと連携してPersistentVolumeを

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

ProvisionerにvSphereが選べる

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

Cloud Provider設定

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

クラスタデプロイメントにて、「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が構成されるようになります。

構成されたPVとPVC

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

Persistent Volume Claim一覧

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

Persistent Volume

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

Persistent Volumeの実体は

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

kubevolsディレクトリ配下に配置されているVMDK群

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

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

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

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

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