Kubernetesと本番運用の話
日本マイクロソフトのKubernetesを本番運用する際のレポートが@ITで紹介されています。有用な記事ですので共有します。
日本マイクロソフトは2018年11月5～7日に「Microsoft Tech Summit 2018」を開催した。本稿では、Microsoft Cloud Developer Advocateの寺田佳央氏の講演「Javaを活用したマイクロサービスのためのKubernetes活用」の内容を要約してお伝えする。
本番運用する際の注意点
安易にKubernetesを選択すると、予想以上に大変な思いをする
私も何度かこの話を書いていますし、もはや真実なんだと思います。
数年後はもっとstableなものになっていると思うのですが、現状は地雷がたくさん残っています。
ただし、いいところもたくさんあるKubernetesなので明確なメリットを定義して取り組むべき技術だと思います。
世の中の情報をうのみにしない
「Kubernetesを試しに使ってみるというような“Hello Worldレベル”の記述は容易で、世の中にはそうした情報があふれている。しかし、このような情報をうのみにして、本番環境に使い回すのは避けるべきだろう。本番環境で運用するために必要な設定が記述できているのかどうかを理解する必要がある」
Kubernetesは「YAML形式で記述されたマニフェストファイル」を読み込ませて動かすことが基本です。
このyamlファイルがインターネット上にはたくさん落ちているのですが、Google CloudのKunbernetes Engineの例であったり、AzureのAKSであったり、IBM Cloud Kubernetes Serviceであったり。またはMinikubeというスタンドアローンでテストできるものであったり。環境依存の実例があるので注意したいところです。
または、Kubernetesのバージョンが異なるため動かないものもあります。
ベンダーのオンラインマニュアルが一番確かなのですが、そのベンダーのKuberenetesのバージョンやマネージドサービスの内容も時とともに変わっていきますので、それすらもうのみできないところがありますので注意です。とくに日本語訳は情報が古くて、英語のドキュメントを見ると最新情報が掲載されていたということはざらです。
一つ一つ、理解しながら進めていかないと、落とし穴を作りこんでしまうことになるので注意です。
本番環境ではどのような設定が必要なのかを十分理解する必要がある
「リソースやネットワーク、パフォーマンス、死活監視などを考えてマニフェストファイルを作成することも重要だ。labels以外にも、さまざまな設定項目が用意されているため、本番環境ではどのような設定が必要なのかを十分理解する必要がある」
こちらはとても痛感するところなのですが、ところが「本番環境で必要な設定」とは何かまだ定まっていないところが問題だと思います。
モノリシック、つまりこれまでのインフラの仕組みならば、リソース監視・ログ監視・プロセス監視・サービス監視といった部分を抑えれば問題ないのは肌感覚になっています。しかし、コンテナになった瞬間に常識が通用しなくなります。早く「常識」が共有知になってほしいところではあるのですが、基盤となるKuberenetesがどんどん変化していっている状況においては、その場その場で、何が必要かを考えていかねばならないと思います。
Kubernetesをバージョンアップした後にコンテナが動く保証はない
「ローリングアップデート機能を本番環境で安易に利用すること、またマネージドサービスが提供するGUIを通じて、Kubernetesを安易にアップデートすることはやめた方がいい」
これは金言ですね・・。黙って私も従おうと思います。
しかし、たまにこういう話が出てくるんです。
アップデートは危険なのでバージョンは上げないで運用しよう。と思ったら、バージョンを上げないと危険みたいな話が急に出てくるのがセキュリティーの世界です。この件だけを考えても、バージョンを上げないで運用することはほぼ不可能だと思います。
一方で他のソフトウェアのように、互換性は担保して脆弱性対策だけ進めるようなLTS（長期サポート）が存在すれば楽なんですが現状そうなっていません。下手にJava 8のような存在を作り出し長年機能追加ができなくなるような目に合わないようバージョンアップしやすいリリース体系になっていると思います。でも、「バージョンアップすると動かなくなるかもよ」と言われると、
「動く保証を持たないまま、本番環境で動いているKubernetesクラスタのアップデートはお勧めできない。もし、Kubernetes本体をアップデートする場合は、新規クラスタの構築を推奨する。最新バージョンのKubernetesで、利用していたマニフェストファイルが動作することを確認し、ロードバランサーを用いて移行するようなブルーグリーンデプロイメントをする方がより安全だろう」
ですよね、ということになります。
したがって、いくらクラスターを作成した際にテストを厳重に行ってもバージョンアップ時にはクラスターの再作成と移行が必要になるということです。インフラチームがクラスターを構築したら、あとは開発チームにコンテナーのデプロイはおまかせ！、と行かないのが現状の悩ましいところと理解しました。
PVの利用はできれば避けた方がいい
寺田氏は「PVの利用はできれば避けた方がいいだろう」と説明する。
VolumesやPV、PVCを扱うためには、ストレージのバックアップ、リストア、ボリュームのサイズ調整方法などを自身で考える必要があるからだ。また、アプリケーションをスケールさせる際、VolumesやMySQLのようなDBMSをKubernetesで管理していると、スケールが困難になる場合もある。
今のKubernetesの抽象化が足りていないところの一つはこれです。
PVやPVCという概念は、インフラでいうストレージ管理そのものです。
Kubernetesを考えた人は、PV（物理ボリュームの定義）はインフラチームが定義して、PVC（物理ボリュームから必要な量を切り出してほしいという定義）は開発チームが定義、ということで抽象化しました。しかし、結局本番運用では失敗は許されないのでPVCは100%成功する必要があります。とすれば開発チームもインフラを気にしなければいけないということで、抽象度が足りないという評価です。
コンテナではPVを触る書き方はしない。APIでKubernetes外にあるデータベースサーバーなどに通信で接続し、データの作成・保存・更新・削除は依頼するようにする、ということです。
こういう話もベストプラクティスだなあと思う反面、PVやPVCは使えるようになっているので迷う人、苦労するひともいらっしゃるんだろうなと思います。
「大変な思い」を共有していく
私自身の経験から言えば、Kubernetesはインターネットにも書籍にも、求める情報を正しくすぐ見つけ出すのが難しい状況にあると思います。
試行錯誤して正しい情報を見つけ出すことが最短ルートなため、冒頭の「予想以上に大変な思い」につながります。
この状況を中期的に打開する方法は、経験したシステムエンジニアが、その試行錯誤した結果をどんどんインターネットにアップロードすることだと思います。オープンソースへの貢献としても理にかなっていると思います。そのうちに、ベストプラクティスが醸成され書籍になったり常識となったりします。
私も気が付いたことがあればアップロードしていきたいと思います。本当に便利になったKuberenetesの先の世界を見てみたいです。
