「Kubernetesで運用する」その前に Kubernetesを本番環境で利用する際のポイント：キャッチアップが大切（2/3 ページ）

[石川俊明，＠IT]

Kubernetesをバージョンアップした後にコンテナが動く保証はない

　Microsoft Azureが提供する「Azure Kubernetes Service」（AKS）は、Kubernetesクラスタを止めずに、クラスタ本体をアップデートする「ローリングアップデート機能」を備えている。管理画面のドロップダウンメニューや、コマンドラインから利用できる。

AKSの管理画面

　しかし、寺田氏は「ローリングアップデート機能を本番環境で安易に利用すること、またマネージドサービスが提供するGUIを通じて、Kubernetesを安易にアップデートすることはやめた方がいい」と強調する。

　以前のバージョンのKubernetesでローリングアップデート機能を利用した結果、クラスタにアクセスできなくなったことがあったという。原因は、Kubernetesのバージョンアップによって管理サーバとノード管理が正しく引き継げなかったためだ。またそれ以外にも、クラスタのバージョンアップによって、それまで動いていたコンテナが起動しなくなった経験もあるという。これは、マニフェストファイルの記述方法や仕様が変わったためだ。

　「動く保証を持たないまま、本番環境で動いているKubernetesクラスタのアップデートはお勧めできない。もし、Kubernetes本体をアップデートする場合は、新規クラスタの構築を推奨する。最新バージョンのKubernetesで、利用していたマニフェストファイルが動作することを確認し、ロードバランサーを用いて移行するようなブルーグリーンデプロイメントをする方がより安全だろう」

「Persistent Volumes」の利用を極力避ける

　コンテナで稼働するアプリケーションのデータは、ストレージ設定を行わない場合、Podの再起動とともに消失してしまう。そこで、データを保存できるように、「Volumes」の設定を用いてデータの保存領域を指定できる。その際、「Persistent Volumes Claim」（PVC：永続ボリューム要求）という項目を利用すれば、ストレージの容量などを指定して、外部の永続ストレージサービスなどの「Persistent Volumes」（PV：永続ボリューム）を利用できる。

　寺田氏は「PVの利用はできれば避けた方がいいだろう」と説明する。

　VolumesやPV、PVCを扱うためには、ストレージのバックアップ、リストア、ボリュームのサイズ調整方法などを自身で考える必要があるからだ。また、アプリケーションをスケールさせる際、VolumesやMySQLのようなDBMSをKubernetesで管理していると、スケールが困難になる場合もある。

　寺田氏は代替案として、プログラム側で処理することや、ストレージの切り分けを提案する。

　「もし、ファイルを保存する場合は、Kubernetesで管理するのではなくプログラム側でSDKなどを用いてCRUD操作の実装を推奨する。複数起動していたPodの内、1つが落ちたという場合でも、プログラム側で実装した場合はPodの起動、停止に対する影響を受けないためだ。DBMSを利用する場合は、仮想ネットワークを通じてKubernetesとDBMSを接続する環境を構築するなど、Kubernetesでは管理しない方法を採る方がよいだろう。Kubernetesクラスタに状態やデータを持たせないことで、クラスタのバージョンアップ、テストなどが容易になり、クラスタの入れ替え、切り替えも容易になる」