dokku、 dcos 、 deis 、 flynn 、 docker swarmなどの他のオーケストレーション ツールを考慮すると、Kubernetes はコード行の点でそれらに近いものではなく、平均してこれらのツールは約 10 万から 20 万行のコードです。
直観的には、コンテナーの管理、つまり、コンテナーの状態のチェック、コンテナーのスケールアップとスケールダウン、強制終了、再起動などを行うのに、 240 万行以上のコード(オペレーティング システム全体の規模) で構成する必要がないことは奇妙に感じられます。コードベース)、それ以上の何かがあるように感じます。
Kubernetes を大きくする他のオーケストレーション ソリューションと比較して、Kubernetes の違いは何ですか?
5 ～ 6 台以上のサーバーを維持する知識はありません。なぜそんなに大きいのか、どのような機能が大きな役割を果たしているのかを説明してください。
@abronan によって与えられた理由は別として、Kubernetes コードベースには、人為的にコード サイズを増加させる多くの重複および生成されたファイルが含まれています。「実際の作業」を行うコードの実際のサイズは、はるかに小さくなります。
たとえば、ステージング ディレクトリを見てみましょう。このディレクトリは 500,000 LOC ですが、元のコードは何もありません。それはすべて、Kubernetes リポジトリの別の場所からコピーされ、再配置されます。これにより、合計 LOC が人為的に膨らみます。
OpenAPI形式で Kubernetes API を記述する自動生成ファイルである Swagger API 生成のようなものもあります。これらのファイルを見つけた場所は次のとおりです。
これらのファイルを合わせて最大 116,000 の LOC を占め、OpenAPI 形式で Kubernetes API を記述するだけです!
そして、これらは単なる OpenAPI 定義ファイルです。OpenAPI をサポートするために必要な LOC の総数は、おそらくそれよりはるかに多くなります。たとえば、Swagger/OpenAPI のサポートに関連する~ 12,000 の LOC ファイルと~13,000 の LOC ファイルを見つけました。この機能に関連するファイルは他にもたくさんあると思います。
重要なのは、舞台裏で実際に重労働を行うコードは、Kubernetes を保守可能でスケーラブルなプロジェクトにするために必要なサポート コードのごく一部である可能性があるということです。