ようこそ、Kubernetes沼へ。商用サービスSREの現場から

筆者がIIJでパブリッククラウドビジネスを率いていた2010〜2015年頃、今後のITインフラはしばらくIaaSを中心に回っていくのだと考えていたものですが、Docker, Kubernetesという爆弾が投下されました。10年、20年は続くと思われたIaaSの時代がまさか早々に色あせて見えるとは。相変わらずIT業界にも思いもよらないことが突然起こるものです。これだからIT業界はおもしろい。

本連載は、現在IIJでSREを率いている筆者がどのようにしてSREチームを立ち上げ、Kubernetes沼へ飛び込み、悪戦苦闘していったのか実体験に基づいて語りつつ、プロダクション環境でKubernetesを活用するための実践的な情報をお伝えしていきます。

まずは第0回ということで、Docker, KubernetesとIIJの馴れ初め的な話から始めたいと思います。先に白状してしまいますが、最初はKubernetesに懐疑的な見方をしていました…。

2015年〜 Docker登場の衝撃

コンテナ技術に本気で興味を覚えた最初のきっかけは、2015年頃に今ではdeprecatedとなっているDockerのコンテナリンクと呼ばれる機能の存在を知ったことでした。当時のDockerはまだマルチノードに対応しておらずシングルノードでしか動きませんでしたが、複数コンテナを起動したとき、環境変数で互いのコンテナをアドレスする情報（IPアドレスやポート番号）が渡される、気の利いた機能が提供されていました。コンテナリンクを利用すると、例えばデータベースコンテナのIPアドレスやポート番号を参照元であるアプリケーションサーバコンテナに環境変数として渡すことができます。つまり、アプリケーションサーバ側では環境変数の値を元に設定ファイルを作れば、構成管理が自動化されるということです。機能としては実にささやかなものでしたが、「コンテナリンクがマルチノードで動いたらすごいのでは？」と感じたことが、後にKubernetesの採用に至る最初のモチベーションだったように思います。

というのも、当時IIJのサービスシステムはご多分に漏れずマイクロサービス化が進み、連携するシステムが増加し、構成管理が複雑化する一方でした。手順書にしたがい構築したシステムの多くはアップデートするたびに再現が難しくなり、本番環境の状態を変更するには例えようのない恐怖心と戦うはめになるような状態でした。当然ながらAnsible, Chef, Puppet, RSpec等々、数々の技術を導入したもののインベントリの管理が人力のままでは、作業が省力化され、オペミスが減るだけで、本質的には何も変わらないということがとうにわかっていました。便利なので使いますけどね。不安を感じることなく、確実にシステムをアップデートする手段が切実に必要とされていました。

そこに登場したのがDockerでした。Dockerにはいくつもの優れたアイディアが実装されていましたが、もっとも重要に感じられたのは、

• ひとつのコンテナにはひとつのプロセスしか含めない
• 各コンテナに固有のIPアドレスをアサインする

というデザインです。たったこれだけのアイディアで積年の課題が解消してしまうとは！

なにしろ、コンテナ（≒プロセス）とIPアドレスが一対一に対応していれば、そのコンテナはネットワーク上のどこにいても期待どおりに機能します。そして、オーケストレータによってIPアドレスが自動的に管理され、コンテナが起動するたびにDNSへ登録されれば、人は完全にコンテナ名（DNSドメイン名）だけ把握していれば、構成管理が可能です。おまけに、DNSドメインを変えてデプロイすれば、同一システムを開発環境、ステージング環境、プロダクション環境のように複数立ち上げることが可能で、しかも環境ごとの差異はオーケストレータが吸収してくれるので、人間の管理は極小になるはずです。さらに発展すれば、データセンター全体がひとつの巨大なリソースプールとして扱えるようになるのでは？もちろん、ネットワークのコンフィグレーションが自動化されればすべて解決というわけではありませんが、もっとも苦労していた部分であったため、期待も大きかったのです。

2015年の時点ではそうなればいいなあ、ぐらいにぼんやり考えていた程度でしたが、その後半年もせずにSwarmが登場し、まさにその環境がリリースされたものですから、ああこれは来るな、と確信したことを覚えています。

2017年〜 本命 Kubernetes

まだDockerの話しかしていませんが、白状するとこの時点ではまさかKubernetesがここまでのものになるとは全く想像できていませんでした。2015年といえば、確かまだKubernetes 1.0がリリースされたばかりの頃で、初めてKubeConが開催された年です。そして、KubeConの参加者に「今後Kubernetesがコンテナオーケストレータの主流になると思うか」とアンケートが行われたのですが、「そう思う」と回答した人が50%にも満たなかったことに驚いた記憶があります（当時の記録が見つけられず、記憶に頼っています）。そんな状況でしたので、2016年あたりまではどちらかと言えばDocker, Swarmを中心に考えていたものです。

ところが、その後の発展の速度はまるで違いました。3ヶ月おきにアップデートされ着々と発展を遂げていくKubernetesに対して、遅々として進まないDockerの姿を見て、それなりに愛着を持って接していた身としては寂しい思いをしたものです。とはいえ、我々のビジネスを預けるに足るプラットフォームがどちらかは、すでに明らかであるように見えました。

ですが、言い訳するわけではありませんが、Kubernetesを理解するのは容易なことではなく、すぐさま採用に走ったわけではありません。kubeadmのようなツールを使えば苦もなくKubernetesクラスタを立ち上げることはできました。しかし、service type LoadBalancerを作っても、Ingressを作っても、PVCを作っても、Kubernetesはうんともすんとも言ってくれません。今となっては笑い話でしかありませんが、そういうとっつきの悪さがKubernetesを必要以上に難しく感じさせている面は今でもあるように思えます。Kubernetesというのは、例えるならOSのカーネルのようなもので、インフラに合わせてデバイスドライバに相当するプラグインやコントローラをインストールしなければ何もできないのだ、ということがもっと最初にはっきり書かれていればよかったのですけれど。

そんな試行錯誤から始まったIIJのKubernetesプラットフォームですが、今では自社クラウドサービス用にCSIプラグインを実装し、仮想アプライアンスロードバランサ向けにCloud Controller ManagerとIngress Controllerを実装し、その他数々のコントローラを実装し、充実したプラットフォームが整備されるに至りました。ですが、だからこそわかるのですが、今のKubernetesはまだまだ黎明期にすぎません。

先程KubernetesをOSのカーネルに例えましたが、現在のKubernetesにはLinuxが登場した直後の1990年代とよく似た雰囲気を感じます。当時のLinuxにもディストリビューションは存在していましたが、満足のいく環境を整えるには多くの労力を必要としていましたし、カーネルのソースコードを読むのは当たり前でした。Kubernetesにしても、今本気で運用しようと思ったらソースコードを読むのは避けられません。正確には、一番早く正確に情報を得る手段がソースコードだということです。そして、IIJのKubernetesクラスタを動かすためには少なくとも8個のIIJ製コントローラをデプロイする必要があります。これはKubernetesをプロダクション環境で効果的に利用するには既製品だけでは足りず、ある程度自力で環境を整える必要があるということです。Linuxは30年かけてここまで来ましたが、Kubernetesはまだ出航した直後なのでしょう。

そういう意味では、KubernetesがCNCF（Linux Foundation）にホストされているのは納得のいく話です。

さて、それでは2017年からIIJが本格的にKubernetesを活用しはじめたかといえば、まったくそんなことはなく。むしろそこからが苦難の道の始まりで、SREを発足し、プロダクション環境として使いこなしていくまでには紆余曲折がありました。その辺は今後の連載と2021年3月に開催するIIJ Technical NIGHT vol.10でお話したいと思います。