kubernetesが
OSの機能を取り揃えつつある。
OSは多義的な用語で、立場によって欠かせない機能が変わる。ソフトウェアやエンジニアから見るときにはCPUやRAM、ディスクといったハードを制御する機能が重要で、kubernetesの設定を通じてリクエストしているのであればkubernetesがOSと言える。
サーバーOSとして確立
2024年現在、広く使われているOSにはWindows・MacOS・Linuxがある。LinuxにはAndroidなどの派生OSが無数にある。
これらの従来型OSは、1台のハードを動作させるための幅広い機能を提供している。
kubernetesは1台構成にとどまらず、複数機器を動作させる機能を提供する。
クラウドサービスなどのデータセンター設備では複数のサーバーを組み合わせる構成を前提としている。LANが非常に高速化したため、1台のハードを高性能化するよりも複数のサーバーに処理を分散させた方が手軽に処理能力を拡張できるシーンが増えた。
LANの加速と同時に、半導体の進歩はPCのような単体の機器も高性能化した。これにより、1台のPC上で従来のデータセンターと同様のサービスを動作させることも現実的になった。
kubernetesは1台構成でも動作するため、開発用PC上に完結したクラウドサービスを構築できる。これがそのままデータセンターで動作する、というシナリオがここまでの簡潔なサクセスストーリーだ。
Dockerの衰微
Dockerは同じレイヤの代替選択肢ではある。未来から振り返るなら「黎明期にはDockerという実装もあった」という存在になろう。
Googleがkubernetesを猛烈な勢いで開発した結果、kubernetesがクリティカルマスを獲得しデファクトスタンダードになった。すでに過去の話題だし、これ以上の話ではない。
数年前には開発PC向けのkubernetesディストリビューションが未登場の時期があったため、開発環境には広くDockerが使われていた。
既述のストーリーのとおり、データセンターと開発機のOSが同一であることが重要であるため、今となってはDockerは単にアノマリーである。
Linuxに寄生して進化
kubernetesはLinux上に実装されており、多くの機能がLinuxそのものである。
Linuxは
Unixのバリアントであり、その地盤を置きかえて統一してきた歴史を考慮に入れると、長い目で見ればkubernetesはUnixの進化した姿である。
LinuxはUnixの initを systemdに置き換えてきたが、kubernetesは独自のプログラム起動方式を提供しており、たがいに別のOSに分岐している。
かつて GNU/Linuxという名称論争があり、エンジニア視点では妥当でもあった。そう考えると、GNU/Linux/kubernetesと認識した方が的確だろう。
たとえばいまkubernetesのLingua francaは、Unixから相変わらずbashである。
オープンソースはプロプライエタリな商用ソフトウェアにくらべて複製機会が格段に高く、進化するOSにミトコンドリアのような共生器官を供給している。
WindowsやMacとは互換性がない
kubernetesは、複数台構成のコンピューターネットワークの分野で既にデファクトOSになっている。
kubernetesは意図的にLinuxを内包しているため、WindowsやMacとの互換性は低い。
低いと言ってもWindowsやMac向けのツールも存在しており、基本的な動作はツールが保証しようとするだろう。
ただしLinuxを
VMで提供する必要上、マトリョーシカのような構造になる。このアーキテクチャは、内部ネットワークやPC上のファイルシステムを利用したい場合に問題が起きやすい。
WindowsやMacOS上のLinuxVMで起きるトラブルには、おそらく生産的な解決方法はない。
2010年代にはエンジニア向けのPCとしてMacが流行っていて、僕も当時はMacbook Airを使っていた。
当初はUnixのツールチェインがそこそこ統合されていたことで足りていたが、やがてコンテナ技術が重要になり不可解なトラブルが増えたことからMacは完全に捨てた。
Linuxの機能を置きかえうる
ここまでの話題はクラスタ構成向けサーバーOSとして先行した経緯を述べた。すでにkubernetesは初期のマイルストーンを通過している。
kubernetes上で動作するアプリケーションはLinuxアプリケーションそのものであり、サーバー向けソフトウェアに限定されているわけではない。
より広汎なツールをkubernetes上に移植して動作させることも可能だ。セキュリティ機構を主とする実装であり、Javaのような中間言語ランタイムのオーバーヘッドがあるわけでもない。
移植の手間はあるものの、コンテナ技術がオープンソースコミュニティの注目を集めたことで、すでにDockerfile形式のビルドスクリプトが相当公開されている。各ツールの開発プロジェクトが提供しているスクリプトもある。
自壊するバベルの塔
単体マシン上でわざわざkubernetes向けにアプリケーションをビルドする主なメリットは動作再現性にある。 Linuxディストリビューション上で素朴に動作しないLinuxアプリケーションが出てきている課題への解決策になる。
ソフトウェアは、非互換なバージョンアップを導入することがよくある。また、あるアプリAとアプリBが同じ前提ライブラリを必要としていて、Aは旧バージョン、Bは新バージョンに依存している状況も無数にある。
ライブラリの非互換がある場合、アプリAとアプリBのいずれかが動作しない展開が生じる。
Ubuntuなどディストリビューションのパッケージマネージャとその開発コミュニティは、このような非互換に統一的に対処している。ただ、組み合わせ爆発に伴う限界はある。
実際に直面した例では、Pythonのツールをセットアップできないケースがあった。
従来から無数のライブラリをPythonのパッケージマネージャpipを用いてインストールできるのだが、いま最新のUbuntu24.04ではpipがインストールを拒否する挙動となり、ディストリビューションが提供するaptパッケージマネージャを使うよう誘導されるようになった。
aptが提供するパッケージを使う場合、状況に応じてライブラリのバージョンを選択する余地はなくなる。
アプリケーションが求める依存ライブラリが複雑な構成になることが分かっているなら、別の手段が必要になるということでもある。
パッケージ管理は、複数ツールを使い分けるより統一した方が手間が減ることは間違いないが、いまやツールが白旗を挙げ始めている。
kubernetesアプリは可能。まだ簡潔とは言えない
Pythonパッケージ管理の限界を見て、じっさいにkubernetes上のパッケージを作成してみた。セットアッププロセスが長いため、 TektonのPipelineを実装した。
このケースではすでにサーバー上で動作実績のあるPipelineを開発向けにカスタマイズした経緯もあり、初回からトラブルなく動作した。
コンテナイメージはホストOSから隔離されており、このイメージではpipを用いた素朴なグローバルインストール方式を利用した。pipなどプログラミング言語が提供するパッケージ管理ツールを直接利用するとトラブルが少ない。
また、サーバー向けのイメージを流用できていることが示すとおり、コンテナイメージはハードを換えてもそのまま動作する。一度イメージをビルドしたなら、従来のようなインストール手順は丸ごと無くなる。
ディストリビューションのアップグレードなど、ホストOSの変更の影響をほぼ受けなくなるメリットも大きい。
ホストLinux上のディレクトリを参照する機能も素朴なhostPathで実装でき、コンテナ内で動作するにも関わらずネイティブのLinuxアプリと同様に扱える。
完成した環境から言えば、すでにLinuxホスト上でkubernetes向けアプリケーションを直接実行できると表現してもそう誤りではない。
ただ、デスクトップアプリケーションやCLIのように使うためのセットアップをサポートするツールは現時点では未整備のため、自らクラフトする必要はある。
hostPathを使うケースでは、ホストとコンテナ内のUnixユーザーIDとアクセス・パーミッションを用途に一致させる必要がある。とくにコンテナ内のuidはイメージ由来であり、自明ではない。
また、コンテナ内で実行するスクリプトにも注意が必要だろう。
素朴にはbashスクリプトに過ぎないのだが、YAMLのマニフェスト内にパックする必要がある。
これはYAMLの限界であり、いずれkubernetesのマニフェストフォーマットの拡張により解決する問題なのだろう。ただ現状はこの分野には焦点が当たっておらず、登場来まったく進展はない。
また、Linuxアプリケーションと同様に利用する場合、コマンドラインオプションを指定する必要に迫られることが多い。この場合、コンテナ内のスクリプトに変数を定義し、何らかの方法で環境から注入する必要がある。
Tektonには
variable substitutionがあり、CLIのtknから指定できる。これはこれで機能するが、tknには長大なパラメータを指定することになるため
tkn-runnerというラッパースクリプトを作った。
今後、コンテナをホストOSから直接する用途のツール登場してくることを期待している。
コンテナのインターフェースは大きく変わらないだろうから、いま作ったものも将来とくに支障なく使えるだろう。
サイロをクラフトする時代
アプリケーションのコンテナ化はデータセンターでは当然の方式となったが、デスクトップアプリケーションの分野は途上である。
すでに別の方式でUbuntuがsnapというパッケージマネージャを導入しているとおり、PCのようなクライアント環境もコンテナ化する合理性がある。
各ディストリビューションはこれまでライブラリの共通化を進めてきたが、現実問題としてアプリ間の不整合を解消しきれなくなったことでコンテナを併用せざるを得なくなった。
カスタマイズする必要がないのであれば引き続きOS標準のパッケージマネージャを利用する方法が手軽だろう。
開発環境のようにみずからクラフトする必要があるなら、Linuxデスクトップではkubernetesの標準化されたプロセスを流用できる。
