はじめまして Kubernetes
訳あって、この春から Kubernetes なるものを使うことになった。
これは、ハリー・ポッターで例えると守護霊の呪文くらいハイレベルで（伝われ！）、一朝一夕に使いこなせる代物ではない。
コンテナ技術と Kubernetes
閑話休題。
Kubernetes とは何者かと訊ねると、ある者はコンテナオーケストレーションエンジンだと云う。
つまり、Kubernetes とは複数のコンテナを運用するための道具であるからして、そもそもコンテナが何なのかを前提知識として知っておく必要がある。
ゼロからキャッチアップしようとするとなかなか険しい道のりになりそうだが、千里の道も一歩からということで、今日は「なぜ Kubernetes なのか」について、コンテナという入り口から話していきたい。
そもそもコンテナとは
大雑把な話、コンテナとは「アプリケーションとその実行環境一式をパッケージ化したもの」と僕は理解している。
たとえば、僕が作った Web アプリケーションを、APサーバと一緒にコンテナ化する*1ケースを考えてみよう。 こうすると、いろいろと嬉しいことが起こる。
実行環境の構築がラク
第一に、実行環境の構築がラクになる。
商用の Web アプリケーションは通常、評価環境や本番環境など、複数面の実行環境に展開するケースが多い。
コンテナ技術を利用しない場合、それぞれの環境に割り当てたサーバに Tomcat などの OSS をひとつひとつインストール & 初期設定をしないといけない。
このとき何らかの理由で評価環境と本番環境の構成に差異が生じた場合、アプリが正しく動作する保証は無い。
一方、コンテナ技術を利用する場合は、そのアプリを動かすために必要な環境のすべてが一纏めになっているため、まるでバッテリー内蔵のおもちゃのようにどこへ持っていってもすぐにアプリを動かせる。
煩わしいバージョン合わせなどの手間が省けるし、「開発環境では動いたのに本番環境ではなぜか動かない」といった怪奇現象も起こりにくくなる。
もう少し掘り下げると、コンテナには Immutable Infrastructure という重要な概念がある。
これは、稼働中のインフラに手を加えることは許さない（e.g. 本番環境の DB にパッチ適用などもってのほか）という思想で、どうしてもインフラの構成変更をしたければコンテナから作り直して全置き換えする必要がある。
コンテナの中にまとめられたアプリは、その実行環境もまとめて時が止まり、勝手に環境がブチ壊れることはない。
コンテナは複製・起動・停止がラク
たとえば、僕が作った Web アプリが想定外の利用者数を記録し、急遽サーバを増設することになったとしよう。 まぁそんなことはありえないわけだが。
そのような場合、新しいサーバに僕のコンテナイメージを持ってきて、コンテナを起動しさせれば、その瞬間からアプリは動き出す。
全く同じ環境を別のサーバに構築し、それをワンタッチで起動できるのだ。
コンテナは互いに影響を及ぼさない
もう一つの利点は、コンテナは互いに影響を及ぼさないということである。
具体例を挙げると、1台のサーバで Tomcat を 2つ同時に動かすことなんかもできる*2。
また、1台のサーバにアプリ A と アプリ B をデプロイし、それぞれが同じ OSS の異なるバージョンを利用している場合なども、それぞれ別々のコンテナで動作させることでヘンな事が起こらなくなる。
コンテナは後始末がラク（であると同時にコンテナ内のデータは儚い）
データベースや言語処理系などの中には、インストールは簡単だが、アンインストールが非常に面倒という始末に負えないケースが存在する。
これらもコンテナ化して利用すれば、不要になったときにすぐ潰して更地にできる。 コンテナを止めれば、そこにあったものが綺麗さっぱり跡形なく消え去る。
しかしこれは言い換えると、コンテナ内に保存したデータは永続化されないということにもなる。
たとえばデータベースやファイルサーバ用途のコンテナは、何もしなければコンテナの死と同時にその中のデータも道連れになる。これはまずい。
そのためどうしても永続化が必要なデータは、ボリュームマウントを行うなどしてコンテナと分離する形で管理しなくてはならない点に注意が必要だ。
コンテナ（手動）運用の課題
さて、ここまでのおいしい話を聞くと、実際にシステムをコンテナで運用したくなってくるだろう。
しかし実際の本番環境は、ただ単にシステムが動いてさえいればよいというわけではなく、とにかくシステムを止めないための工夫が必要になる。
そこで可用性を高めるため、複数のサーバにコンテナを展開しようという結論に至る。
だが、丸腰で運用を始めようとするといずれ様々な課題にブチ当たることになる。
コンテナの監視・復旧
どのサーバでどれだけのコンテナが動いているのかを人間が手動で管理するのは現実的ではない。
死んだコンテナを手動で復旧するのは（罰ゲームでやったことあるけど）しんどい。
コンテナの置き換え
先ほども書いたが、原則としてアプリケーションやそれに付随するインフラをアップデートするにはコンテナの置き換えが必要になる。
どのサーバ上でどのコンテナがどのバージョンで動いているかを一つひとつ確認して緊張感を持って切り替える作業などやっていられない。
サーバを跨いだデータの永続化
複数台のサーバでコンテナを運用しようとすると、永続データの置き場が問題になってくる。
前述のとおりボリュームマウントを利用すれば、コンテナとデータを分離し、データのみを永続化できる。
しかし、仮にコンテナを別のサーバに移し、ボリュームは元のサーバに取り残された場合、システムは意図した動きをしなくなる。
こうした課題を解決する一つのソリューションが Kubernetes である、という理解である*3。
やや古い情報だが、Sysdig, Inc が公開している「2019 Docker Usage Report」によると、コンテナオーケストレーションエンジンのシェアは Kubernetes が約77%、次いで OpenShift が約9%、Docker Swarm が約5% であるという（『Kubernetes完全ガイド 第2版 (Top Gear)』より）。
そんなわけでだいぶ長々と書いてきたが、以上が Kubernetes を使う動機付けである。
なっげぇ……。
これだけ長々と話したけど、まだ Kubernetes を使う動機を語っただけに過ぎないという。
これ…… 仕事でやるの？
社内にはコンテナつよつよ部隊を自称するチームがいるので、さすがにガチインフラな領域は彼らに任せるよ。
でも勉強しないと死ぬねこれ。
確かに守護霊の呪文と同じくらい難しそう。
取り急ぎお勉強用に強力な魔導書を買った。読まねば。
Kubernetes完全ガイド 第2版 (Top Gear)
- 作者:青山 真也
- 発売日: 2020/08/07
- メディア: 単行本（ソフトカバー）
*1:より正確には、「コンテナイメージを作る」と表現する。
*2:普通はできない。
*3:AWS が使えるならば ECS: Elastic Container Service や Fargate を使えよというツッコミもあろうが、ちょっと会社の政治的な理由で Kubernetes を使わねばならんらしい。
