Kubernetesがついに仕事に。ペリーの黒船状態。
うーん、この日が来てしまったかというべきか。仕事にて数々のインフラ設計を見積もるのですが、仕様にKubernetesがついに入ってきてしまいました。
今日のこの日まで、「まあ、使うシーンなんて、開発業務や軽いWEBシステム中心で、本番のミッションクリティカルな使い方なんかまだまだ先だろう」と思っていたら早くも要求仕様に含まれてきました。
しかも最近のトレンドの、パブリッククラウドで利用できるKubernetesを使ったコンテナ基盤って、ワーカーノードは自動でクラウド側が作ってくれるので、インフラエンジニアの作業ってかなり省力化される感じです。
仮想サーバーのOSセットアップ、という次元だとお決まりの作業がいろいろとあったのですが、コンテナになると全自動。むしろノードにはログインすらする必要もなく、コンテナ基盤を開発者に引き渡せばいいという始末です。
ただ今のところ、「どうやってコンテナの状況をインフラ面から監視するか」という運用設計の部分は調べてもまた最適解は見つかっていない模様です。調べるたびにいろんな方法が出てきます。しかし、逆に、絶対これ、というものは見当たりません。例えば、旧来のシステムならZabbixを使う、などのオーソドックスな方法がまだ確立してなさそうです。
ただ、今後いろいろな事例が出ていく中で間違いなく運用設計もこなれていくでしょうし、時間の問題だなとも思いました。いざKubernetesで本番運用する企画自体はどんどんと開発者に今後浸透し、むしろインフラエンジニアは追い立てられるように適応していかなければいけないシナリオが見え、正直慌てています。
おそらく、いろいろな現場に、Kubernetes絡みの話がさみだれに来るんでしょうね。インフラエンジニア側が何もバリューを生み出せないと、勝手に話が進んでいって立場が悪化することも考えられ、対応が急務のように思います。
Kubernetesの現状
今日のはてなブックマークを見ていたら、現状がよくわかる記事がありました。
これを読んでわかることは、おそらく「監視」「バックアップ」「障害の切り分け」といった運用設計の部分がもっと自動化され、代表的かつ生産性の高い方法が確立してくると、本番環境に爆発的に導入されるんだろうということです。
本番システムの構築において、運用設計はなくともシステムは動きます。もちろんテストを精緻に行ってリリースするので基本的にはシステム障害は起こらない前提で構築するためです。しかし、システム障害はほぼ間違いなく1度以上は発生します。その際に、監視ができていること、バックアップができていること、また障害の切り分け方法が確立していることは、相当大事なことです。また、リリース後手を加えなければいけないことも多く、何を持って安全に作業できるか、という運用手順も確立しなければいけません。
Kubernetes絡みのインフラ基盤においては、まだこのあたりの運用設計が私の中で腹落ちできていません。いろんな記事が「こうやってるよ」と書いてあるのですが、記事の数が少ないこともありまだ確信できない状況です。
ただ、開発者は「使えるよね！」って目をキラキラして要件を出してくるので、どうにかフォローしなければいけない時期に来ていると思います。たくさんのインフラエンジニアが問題意識を共有化すれば現在を乗り切れるのではないかと思う次第です。
過去VMware（仮想基盤）が出てきた時も、「本番で使うには危険」って言い続けたエンジニアもいたでしょうが現状は今の通りです。いずれ覇権を取るのがわかっているプラットフォームなのでここはやるしかないでしょう。
仕事だとおぼえられるかな
座学だと、なかなか頭に定着しないので、こうやって無理やり仕事に登場してもらって、危機感を持ってあれこれ調べて行くと、気づいたらKubernetesのインフラが得意になっている可能性もあります。
とりあえずは、「ああ、来ちゃった」と思うより、「よし、ついにおぼえるぞ」と言った気持ちで取り組んでみたいかと思います。
コンテナ・ベース・オーケストレーション Docker/Kubernetesで作るクラウド時代のシステム基盤
