Zenn
📝

CoreOS社(in Kubernetes)

2020/12/15に公開
Kubernetes
Core OS
idea

君はかつてあったCoeOS社を知っているか？

君はCoreOS社を知っているか？

Linux Containerを安定的に動かすためのOSを開発しているさなかにRed Hatに買収された。
ああ、数年前に買収されたベンチャーかな？ちょっと企業のプレスリリースに詳しいものであればそうであろう。
だがしかし、CoreOS社の魂は今もRed Hatの各プロダクトの中に息づいている。
それこそ数えきれないくらいに息づき、今後もRed HatのOpenShiftの成長を語るうえで書いてはならない名前だ。今はRed Hat社に買収されて、リポジトリや古いコミット履歴、そしてプロダクトの頭文字に名前が残る...その会社の名前を知っておくべきだと思う。

その世界の一端を紹介していきたい。

CoreOS社ってどんな会社？

etcdの歴史を参照する限り、ベンチャーの例にもれなく、とあるガレージから起業した2013年の企業である。

当時2013年に出たばかりのDocker、これを中心としてどのようなエコシステムを実現したらいいのか真剣に考えたことが彼らの将来を変えた。ほどなくしてCoreOS社はRed Hat社に買収されたが、彼らが目指していたもの、目指していた技術はRed Hat社内でも失速することなく花開くこととなった。

パッケージ管理、OS管理にコンテナとgitの考えを導入した

例えば、CoreOS社が提供していた「Container Linux」。

コンテナを動かすためのランタイムとしてのVMならその管理はセキュリティ・パッケージ管理を含めて最低限にすべきだというストイックすぎる考えに紐づいていた。

その思想はRed Hat社が行っていたAtomic Project(OSTreeとよばれるOSにコンテナイメージのような一貫性とバージョン管理という考えをもたらすプロジェクト)とマージされることで、

  • rpm-ostree: コンテナイメージのようなパッケージ全体での安定版を示すレイヤーとrpmのような従来パッケージ管理機能を組み合わせることで依存関係を壊さないで効率的にバージョン管理をできるようにした仕組み
  • 各種OS: OpenShiftのワーカーノードの土台にも使用されるFedoraCoreOS、コンテナのベースイメージとしか機能しないUBIといったランタイム専門のOS
  • といったものを誕生させることになる。

rpm-ostree は Fedoraで使え、RHEL8.3/CentOS Stream 8でもすぐに使えるようになるらしい(2020年当時、この後CentOSは無くなりました…)。

etcdの誕生

Kubernetes業界に関わるものなら、彼らが残したものにまず目を触れないことはない。

We wanted Container Linux to be able to essentially reboot one machine at any time, but we wanted people to be able to have application uptime. So we needed to run multiple copies of Container Linux and have some sort of coordination so an entire user application wouldn’t go down at once. This is a pretty well understood coordination problem, and really the way we worked to solve this is through a consensus database.
「Container Linuxは、基本的にいつでも1台のマシンを再起動できるようにしたかったのですが、アプリケーションの稼働時間を確保できるようにしたかったのです。そのため、Container Linuxの複数のコピーを実行し、ユーザーアプリケーション全体が一度にダウンしないように何らかの調整を行う必要がありました。これは非常によく理解されている調整の問題であり、実際にこれを解決するために取り組んだ方法は、コンセンサスデータベースを使用することです。」
https://coreos.com/blog/history-etcd

そのために開発したコンセンサスアルゴリズム Raftを使用したetcdが Kubernetesのコアになるとは想像しえなかっただろう。だが、現在ではCNCFも卒業するまでに(卒業要件の一つは知名度の向上、いわゆるキャズム越えである)非常に有名なプロダクトになった。

Self Hosting KubernetesとOpenShift Installer

OpenShift4以降のインストーラーがOpenShift3までと方法が変わっているのをご存じだろうか？
OpenShift4では、boot用vmを構築し、それを踏み台にoperatorがクラスターを自動複製する手順となっている。そうすることで、OpenShiftを構成する各コンポーネント(例えばetcd)を全て自分たちで管理するリソース、Podにすることに成功した。

このやり方はOCP4がリリースされた四年前に2016年にCoreOS社が出したKEPが元になっている。

ちなみにCoreOS社が買収されていなかったOpenShift3.Xは、Ansibleを用いた全く違うアプローチ方法がとられており、(OpenShift4.XはTerraformとCoreOSのIgnitionを用いた方式)全然インストーラー方法が違うところは特色かもしれない。

Ignitionと呼ばれるプロビジョニングツールは面白いが、多分昨今はcloud-initのcloud-configと似たような機能と言った方が通じるようになった😭 最もcloud-initの方が先輩で、当時はOpenStackコミュニティを通じて広まっていたはずだが、彼らが知ってたのかは知る由もない。

ただし、確実に言えるのはContainer OSが起動した時には全てが「終わっている」。そのために同種の機能を必要としていたということだ。

所感

第一稿ではべろべろに酔っぱらったままこの文を書き連ねたのだが、よく書けたな、いやタイピングできたな...

Discussion