情報ガイドステーションメニュー
 |
｜ コンテナデータをvSphereでどう管理する？VCPってご存じ？？ |
|
Dell Technologiesの石井です。モダンデータセンター事業本部にてCI, HCI/SDSとそれらをハイブリッドクラウド化するお手伝いをさせていただいているシステムエンジニアです。自分なりに需要のあるテクノロジーの様子を観ながらキャリアの調整をしてきたつもりでして、VMware Server（懐かしい！）を使ってみた15年ほど前にコレだ！と思ってESX4.0の頃からVMwareに取り組んできました。以降、コンバージドインフラ（CI）であれ、ハイパーコンバージドインフラ（HCI）であれVMwareを中心とした仕事をしております。今から2～3年ほど前に次のテクノロジーはコンテナに移るぞ、と少しずつ勉強を進めてきましたが行きついた先はコンテナ on VMwareでした。。vSphere7からコンテナの運用基盤として快適に使えるよう大きく舵をきりますが、ここでは永続ボリューム（Persistent Volume）についてご紹介します。まだ実機検証できていないため、ところどころvSAN 6.7ベースでのご説明になるこを予めご容赦ください。 ■目次・ クラウドネイティブストレージ機能とは？（実は前バージョンから対応してたんです）・ KubernetesにはvSANボリュームが向いている！？ ・ 永続ボリューム（Persistent Volume/PV）について ・ vSphereだと何がうれしい？？ ・ Kubernetesクラスタ構築は手作業…でも無料！ ■クラウドネイティブストレージ機能とは？（実は前バージョンから対応してたんです）仮想インフラ担当の方が自主的にコンテナを使いたいと言うモチベーションを持つときは、どのようなケースでしょうか？私が考えるに以下の４つがあげられると思います。ケース① 自社アプリケーションをコンテナで換装できるかテストしてみたい。 ケース② セキュリティや予算の都合でパブリッククラウドでは実装はおろかテストもできない。 ケース③ テストはパブリッククラウドで済ませたが、そこでの運用は自社のポリシーに合わないことが判明。 ケース④ テストはパブリッククラウドで済ませたが少し放っておいたら、もしくは同僚と共有したらなぜか動かなくなった、或いはワケがわからなくなった。いずれにせよもう触りたくない。 ケース④は私だけでしょうか。ともあれ勝手知ったる俺の環境でコンテナやKubernetesのテストができたら良いのになぁ、というお声をよく聞きます。その環境にひょっとして3つのvが揃っていませんか？ ・ vSphere v6.7u3以上である。 ・ Ubuntu仮想マシン（Virtual Machine）を3台デプロイできるリソースくらいは余ってる。 ・ vSANを使っている。 もし揃っていればvSphere 7.0を待つ必要はありません。VMwareはv6.7u3でKubernetesを迎える用意を済ませています。vSphere UIに”クラウド プロバイダー” という見慣れぬメニューが現れたのにお気づきでしょうか。と言っているうちにv6.7P1にアップデートするとこれが”クラウドネイティブストレージ”と表示が変わりました。VMwareにはいつものことですが、これからも名称は変更されると思います。名前が何であれ先ずはこの新メニューが何をしてくれるのかをご紹介します。 
■KubernetesにはvSANボリュームが向いている！？前章の3つのvのうちvSANはじつはおまけです。実際にはvvolでもNFSでも構わないんです。しかし今回はvSANにフォーカスします。なぜか。わたしがvSANを採用しているHCIアプライアンスであるVxRailの製品SEであるがためです。仮にそうでなくてもvSANが最もKubernetesに適したストレージと言える理由が有ります。vSANはvSphereのみで完結するSoftware Defined Storageであり、外部ストレージに比して実装作業やI/Oフローがシンプルという利点が有ります。KubernetesのポッドにvSANを永続ボリュームとしてマウントさせるのに必要なvSphere側作業はKubernetes用のvSANポリシーを一つこさえてポリシー名をメモしておくことだけです。 
さらにvSANアーキテクチャを基礎としたアプライアンス製品であるVxRailの場合、vSAN周りを含めて初期設定、拡張、縮小、アップグレードなどほぼ全ての工程は自動化されますので、ストレージインフラに要する工数やカスタムポイントは実質ゼロであり、ただ利用するだけです。vvolやNFSだと、先ずストレージ側で固有の設定を、次にストレージ特性に合わせたベストプラクティスの調査やパラメータ設定、スキャン・マウントなどvSphere側での作業量が結構な量を伴います。VxRailの場合はこの作業は自動で実装されるうえ、ストレージ更改時のマイグレーションや構成変更、トラブル時など異ベンダー間の調整が不要となり、これらの窓口をDell EMC一本に絞ることができます。 ■永続ボリューム（Persistent Volume/PV）についてコンテナ環境は極めてダイナミックでして、何百何千ものコンテナがひっきりなしに作成され、かつ削除されます。とある調べでは50%のコンテナは5分以内に削除（停止）されるようです。コンテナが起動するイメージはそこからpullできるどこかのレジストリに置いてあり、起動する場所はKubernetesワーカーノードとして動作する仮想マシンのメモリ空間上です。起動しているコンテナに対する書き込み先は仮想マシン（ワーカー）にネストしたディレクトリであり、イメージ自体に変更は生じず、起動中に生じた書き込みは停止時に破棄されます。だからこそ何度再起動しても全く同じイメージで起動し、イメージレジストリにアクセスできればどこからでも起動できます。この特性からコンテナは生来”ステートレス”なものであり、可搬性（ポータビリティ）を特長とします。コンテナが当初想定された用途は上記のようにRead Onlyなものでした。例えば静的なウェブコンテンツを想像してみて下さい。レジストリに在る静的コンテンツを4月号から5月号に書き換え、コンテナ（ポッド）をリロードすることでバージョンアップされたイメージ、ウェブサイトの更新を反映させます。4月号で起動しているコンテナ自体に変更は与えません。これが「ステートレス」ということになります。また、Kubernetesのレプリカセットとローリングアップデートを利用してゼロダウンタイムでの切り替えを期待することもできます。 一方でコンテナの特徴である速い起動時間や効率的なリソース利用を期待して、あるいはKubernetesの機能が充実するに従って書き込みを常に保持する必要のあるRDBのような使い方としてもコンテナに有用性は認められています。データの変化を維持する必要があるため、前述のステートレスに対してこちらは「ステートフル」と呼ばれています。但し、”ステートフルなコンテナアプリケーション”を実現するにはステートレスなそれと比べて一点だけ手間が掛かります。永続ボリューム（Persistent Volume）を特定のコンテナに割り当てるステップです。 永続ボリュームはいわゆる普通の書き込み可能なボリュームであり、vSphereにおける実体はVMDKです。これをKubernetesクラスタを構成する仮想マシン経由の一時的なネストでなく、特定のコンテナ（実際にはポッド）に直接マウントさせることでコンテナへの書き込みを普通に、永続的に保持させます。コンテナは再起動時にイメージはレジストリから前回起動時と同じものをロードしつつ、/dateといったそのコンテナ特有のデータは前回停止時のデータをマウントすることが可能になります。 以下に相関図を示しますが、vSANのポリシーがKubernetes側の管理（StorageClass）へ橋渡しされ、続いて永続ボリューム管理（PVC）でボリューム設定が定義されています。その定義された永続ボリュームがコンテナ（POD）でマウントされ、それが結果としてVMDKと言うわけです。 
永続ボリュームはvSphere UIには下のこのように見えてきます。KubernetesオブジェクトであるStorageClassを利用してKubernetesがvSANポリシー名を理解できるようKubernetesにはvSphere用のプラグインをデプロイしています。永続ボリュームには最近はやりの”ラベル”を貼ることができます。 ラベルはKubernetesとvSphereで共通認識されますので、Kubernetesをインフラとして利用しているDevチームが”test”環境の”mongo”DBのうち”MainRepSet”のやつが落ちたよ！と、vSphereをインフラとして利用しているOpsチームに伝えると、Opsチームはそのラベル情報を利用して数百、数千あるvSphereボリュームから目的のボリュームを検索し、vSANコンプライアンス履歴などを追うことでDevOpsができあがるわけです。 
■vSphereだと何がうれしい？？VMDKを手動で作成し生成されたユニークなボリュームIDをyamlに書けば狙ったコンテナに思い通りのVMDKをマウントさせることもできますが、普通はみなさん忙しいのでKubernetesからのストレージ要求（Persistent Volume Claim）に応じてvSphereにオンデマンドで自動的にストレージを払い出させます。いずれの方法でもvSphere UIで普通のvSANオブジェクトと同じように可視化させられます。どうでしょうか。いつものvSphereならではの使い勝手を想像できませんか。・vSphere DRSとKubernetes ReplicaSet、スケジューリング、リソースリミットを組み合わせて最適どころを探る。 （Kubernetesだけでリソースの効率化を図るのは困難） ・vSphereの各種アフィニティとKubernetesのアフィニティを組み合わせて… （Kubernetesのポッドあるいはデプロイメントレベルで都度アフィニティを組むのは困難） ・vSAN SPBMならでは機能を利用したい。QoSや保護レベルのオンライン変更など。 （Kubernetesではボリューム管理がそもそも楽ではない） ■Kubernetesクラスタ構築は手作業…でも無料！ご覧頂きました図表はネイティブのKubernetesです。クラスタのベースとなるLinux仮想マシン（Ubuntu 18.04.1 LTSを推奨）から手作業で構築する必要がありますが、手順はVMware社などから公開されており、基本的にはそれに沿って作業します。基本的には、です。vSphere 7.0はまだGA直後ですし、Tanzuは標準付属品ではありません。vSphere 6.7u3（VxRail 4.7.300）以降、VxRailやvSANはさらに使い勝手が良くなっており、かつ本番でご利用いただける完成版です。少しリソースが空いていればKubernetes環境の構築そのものを含めたテスト及び本番環境としてvSphere クラウドネイティブストレージから始めるKubernetes利用はいかがでしょうか。 ＜vSphere上でのKubernetes導入の参考サイト＞ Deploying a Kubernetes Cluster on vSphere with CSI and CPI Dell Technologies モダンデータセンター事業本部 SE 石井真仁（いしいまさひと） 関連記事はこちらどーなってるの！？vSphere 7 を超速解剖！vSphere 7 What’s New ～vSphere 7 の4大アップデートポイント～ vSphere7で実装されたコンテナ技術のオーバービュー いまさら聞き難い・・・コンテナって何なの？何でvSphere上にコンテナ？？ コンテナデータをvSphereでどう管理する？VCPってご存じ？？ VxRail 7が早くもリリースされました！ 導入とバージョンアップのコツとヒント 話題のvSphere7 を 触ってみた！実際の現場で使う部分にフォーカス！ vSphere 7検証レポート ：vSphere Lifecycle Managerを触ってみた！
|
タグ: HCI, Kubernetes, PowerEdge, VMware, vSAN, vSphere 7, VxRail, コンテナ
