k3sからRancher Labsの戦略を考える

Rancher LabsのDarrenとShannonのcncfのウェビナーを見た(ただし途中で寝落ちしたので実際には喋ってる内容が多々含まれてるかもしれません)わけですが何となく点と線が繋がってきたので整理しておきます。

75%くらいは深夜の狂ったノリ+勢いで記述したものなので適当に”お前の中ではそうなんだろお前の中ではな”と言う感じで聞き流してください。

ちなみに私の予想は高確率で外れます。

k3sの意義

https://k3s.io/にもある通り、Light weight k8sです。

そこまで深いEdgeとかIoTやARMをテーマに上げていて1GB未満のRAMでも動くと言うところのデバイスを狙っています。その上でk8sを動かす意義って何なんだろうとちょっと整理して見ます。

k8sがきちんとクラスタリングでき額面通りにクラスタとして高い可用性を維持できると言う意味であれば、安いARMデバイスを並べてクラスタ化して少々壊れても総体として機能し続けるというところに期待できます。

Rancher and Arm Partner to Deliver a Kubernetes-based Platform for IoT and Edge Computing Deploymentsの記事にあるように中国のスマートシティ計画向けにARMと共同でKubernetesベースのIoT,エッジコンピューティング向けのプラットフォームを提供するとのことなのでまずはこれがターゲットでしょう。2/26に実施されたCNCFのウェビナーでもゴールドウインドがIoT,エッジコンピューティングの事例として上がっていました。

スマートシティで特にやりたいこととは何だろうと考えてみましょう。IoTデバイスを使って監視カメラ映像の収集や、環境(温度、湿度などの大気の状態などなど)情報の収集に利用するということが真っ先に浮かびます。

なるべく手間をかけずに少々壊れた状態でも総体として情報を収集し続けることができるという風に考えるとk8sの軽量版を作成してIoTエッジでKubernetesクラスタを動かすというのはロジックとしては理解できます。

他プロダクトとの連携(Longhorn)

おそらく、エッジのクラスタについては有線で接続しても良いし、無線であってもひらけた場所かつ短い距離で繋ぐのでさほど通信面では問題にはなりづらいでしょう。

一方で上流のネットワークは無線で繋ぐことになり、必ずしも安定しているわけではありません。

一時的にエッジ側に情報を蓄積して送るといったことが必要になります。(個人的にはこの上流ネットワーク部分には5G規格を用いて低遅延・大容量の通信を実現することも狙っていると思いますが)

おそらくここでポイントになるのがLonghornでしょう。

いわゆる一時的にせよエッジ側に情報をに保存せざるを得ない状況が起こることは予測できます。保存するデータの完全性や信頼性を高めるために、エッジデバイス間でレプリケーションし完全性や信頼性を高めつつ、分散I/Oで大容量の読み書きを実現するといった用途を狙っているのではないかと考えます。

一時的にこのような方法で高精細な画像・動画、高分解能なセンサー情報を蓄えて上流ネットワークが安定次第一気に送ってしまおうみたいな意図があるのかなと推測しています。

他プロダクトとの連携(Rancher OS)

では、エッジ端末の管理について少し視点を移して見ましょう。軽量なコンテナ向けOSとしてRancher OSを持っています。先にあげた記事にある通り、Rancher OS自体がARM上でも動作するようポートされています。

これによってエッジのARMハードウェア上でRancherOSを動かすことには大きな示唆が存在します。ある意味偏執的にRancherOSは全てのプロセスをコンテナ化することに注力しています。では、全てのプロセスをコンテナ化することのメリットとは何でしょう？これはコンポーネントのアップデートを安全に行うことを意図していると考えれます。アップデート後にコンテナが正常動作していればそのまま、動かなければ容易にロールバックといったことが可能なので、管理対象が大幅に増えるエッジコンピューティングでは、そのアップデート管理が煩雑になるため、コンテナを前提としたOSは相性がよいと言えます。

最後にRancher本体との連携

最後にRancher本体との連携です。

スマートシティにおけるIoTとかエッジコンピューティングという観点での活用になるので、大量のk8sクラスタ(厳密にはk3sクラスタ)がばら撒かれることになります。これを束ねるのにRancher本体を使う。クラスタ上で動作するアプリケーションの配布にはRnacherのカタログアプリケーション機能を用いる。Rancher 2.2ではさらに複数クラスタに対してアプリケーションを一括配布するといった機能も含まれる予定なのでこれも今回の発表と深く関連しているでしょう。

さらに、監視・モニタリングにはRancher 2.2以降に統合される予定のPrometheusを用いるといった形の実現方法になるかもしれないといった部分になってきます。

実際には管理対象のクラスタの位置情報などの情報をどうやって収集するかといった課題もあり、それは別の手段を用いて実現するのかもしれません。

まとめと懸念

まとめとしては創業から10年も経っていない企業がよくもここまでのものを揃えたなという印象です。とは言え慌てて作っている感があるのも拭えず、buggyな部分も多々残っています。

今後はこれを改善できるかというのは一種の分水嶺になるでしょう。個人的な意見としてRancher Labsはかなり健闘していると思いますし、Kubernetesの民主化には大きな貢献を果たしていると思っています。

懸念としてはRancher JPのSlackでも議論としてjacopenさんがだしていたのですが、開発体制の弱さ(バス係数の低さ)でしょう。先進プロダクトについてはDarrenにかなりの部分を頼っており、安定したプロダクトについてもAlenaが中心で引っ張っているような状態です。LonghornについてもSheng(CEOでない方)が孤軍奮闘で作っている状態に近いです。カバーする範囲が広いため、全体的に手薄になってしまうというのは懸念としては大きいかなと感じています。

とは言えRancher Labs自体は今後もエンジニアの数については拡充していくでしょうし、数が増えればプロダクトリードレベルの人材も増えるでしょう。

どちらにせよ正気にて大義はならずなんて言葉もありますし、利用するかは別にせよ、継続してウォッチは必要そうです。

意図したものか偶然なのかはわからないですがここまでのエコシステムを小規模組織で組み上げる力は見習いたいですね。