これら2つの理由によりKubernetesは非常に複雑になっています

1. Kubernetes はなぜ難しいのでしょうか?

Anthropic はほとんどのシステムを Kubernetes 内で実行しているため、私はこのツールについてより多くの経験と知識を積んできました。素晴らしいのですが、（誰もがそうであるように）非常に複雑でデバッグが難しいと感じました。

新しいシステムを学習するときには、このような感覚はよくあることですが、Kubernetes は、私がこれまで使用した他のシステムよりも大きく、恐ろしく、扱いにくいと感じます。それを学んで使用していくうちに、なぜそのように見えるのか、どのような設計上の決定とトレードオフがそのように見えるようになったのかを理解しようとしました。この投稿では、2 つの具体的なアイデアについて説明し、Kubernetes での作業が難しいと感じることがある理由を説明します。

2. Kubernetesはクラスターオペレーティングシステムです

Kubernetes は、コンテナ化されたアプリケーションや同様の機能説明を展開するためのシステムと考えるのが簡単です。これは便利な視点ではありますが、Kubernetes を汎用のクラスター オペレーティング システム カーネルとして考える方が理にかなっていると思います。この2つの違いは何でしょうか?

従来のオペレーティング システムの役割は、コンピューターとそれに接続されたすべてのハードウェアを取得し、プログラムがそのハードウェアにアクセスするために使用できるインターフェイスを公開することです。正確な詳細はさまざまですが、一般的にこのインターフェースの目的は次のとおりです。

1) リソースの共有- 物理コンピューターのリソースを複数のプログラムに分割して、それらをある程度互いに分離できるようにします。

2) 移植性- 基盤となるハードウェアの正確な詳細をある程度抽象化して、同じプログラムをまったく変更せずに、またはわずかな変更のみで異なるハードウェア上で実行できるようにします。

3) 汎用性- 新しいタイプのハードウェアを考案したり、新しいハードウェアをコンピューターに接続したりするときに、そのハードウェアを抽象化とインターフェースに段階的に適合できるようにする必要があります。インターフェースを大幅に変更したり、そのハードウェアを使用しない既存のソフトウェアを壊したりしないようにアドバイスします。

4) 全体論的- 一般性に関連して、ハードウェアへのすべてのアクセスを OS が仲介することを望みます。ソフトウェアが OS カーネルを完全にバイパスすることはほぼ不可能です。ソフトウェアは OS カーネルを使用してハードウェアへの直接接続を設定し、将来のやり取りが直接行われるようにすることができます (メモリマップされたコマンド パイプラインの設定など)。ただし、初期の割り当てと構成は OS の保護下にあります。

5) パフォーマンス- ハードウェア上で直接実行され、ハードウェアに排他的に直接アクセスする専用のソフトウェアを作成する場合と比較して、この抽象化に支払うパフォーマンス コストは許容できるほど小さく抑えたいと考えています。場合によっては、I/O スケジューラやキャッシュ レイヤーなどの最適化を提供することで、実際にそのようなシステムよりも高いパフォーマンスを実現できることを期待しています。

「プログラミングの容易さ」は多くの場合追加の目標ですが、実際には上記の懸念のために見落とされがちです。オペレーティング システム カーネルは通常、上記の目標を中心に設計され、その後、低レベルで共通の高性能インターフェイスを使いやすい抽象化にカプセル化するためにユーザー空間ライブラリが作成されます。 OS 開発者は、「自分の OS への nginx の移植が何行短くなるのか」よりも、「自分の OS で nginx がどれだけ速く実行されるのか」を重視します。

Kubernetes は非常によく似た設計空間で動作すると思います。ただし、その目的は単一のコンピューターを抽象化することではなく、データ センターやクラウド全体、またはその大部分を抽象化することです。

この視点が役立つ理由は、この問題が「コンテナ内で HTTP アプリケーションをデプロイできるようにする」よりも困難かつ一般的であり、Kubernetes が非常に柔軟である具体的な理由を示しているからです。 Kubernetes は、Kubernetes インターフェースを「バイパス」したり「外部へジャンプ」したりすることなく、あらゆる種類のハードウェア (または仮想マシン インスタンス) にあらゆる種類のアプリケーションをデプロイできるほど汎用的かつ強力になることを目指しています。

ここでは、それがその目標を達成するかどうか（あるいは実際に達成するかどうか）について意見を述べるつもりはありません。それを単純に解決すべき問題として捉えることは、遭遇する多くの設計上の決定を理解するのに役立ちます。

この観点から見ると、Kubernetes のプラグ可能性と構成可能性は、比較的大きな設計上の選択肢となる可能性があります。一般的に、特にパフォーマンスを犠牲にせずに選択したい場合は、すべての人に適した選択をすることは不可能です。特に現代のクラウド環境では、導入されるアプリケーションやハードウェアの種類は多種多様であり、非常に急速な変化の対象となっています。したがって、すべての人にすべての機能を提供するには、高度な構成可能性が必要になります。これにより、最終的には強力なシステムが構築されますが、理解が難しく、「単純な」タスクでさえ複雑になる可能性があります。

もちろん、別の視点もあります。

多くのユーザーは、Kubernetes を本質的に「Heroku」であると考えています。つまり、Kubernetes は本質的に、従来の基盤となるオペレーティング システムと分散システムの詳細のほとんどを抽象化したアプリケーションをデプロイするためのプラットフォームです。

Kubernetes は、インフラストラクチャ全体を定義するのに十分な機能を持つという点で、「CloudFormation」に近い問題を解決していると考えています。また、基盤となるクラウド プロバイダーやハードウェアよりも汎用的な方法で問題を解決しようとしています。

3. Kubernetesのすべては制御ループである

「5 つの CPU 間でコンピューティング能力を分割する」や「新しい仮想ネットワークを作成する」などのプリミティブを公開し、システムの内部抽象化の構成変更や EC2 API (またはその他の基盤となるクラウド プロバイダー) への呼び出しをサポートする、必​​要な「クラスター オペレーティング システム」を想像できます。

Kubernetes は、コア設計上の決定として、このようには機能しません。代わりに、Kubernetes は、すべての構成が宣言的であり、すべての構成が制御ループとして機能する「オペレーター」を通じて実装されるというコア設計上の決定を下しました。オペレーターは、望ましい構成と現実の状態を常に比較し、現実を望ましい状態に一致させるためのアクションを実行しようとします。

これは非常に意図的な設計上の選択であり、それには十分な理由があります。一般的に言えば、制御ループとして設計されていないシステムは、意図した構成から必然的に逸脱するため、大規模なシステムでは、誰かが制御ループを作成する必要があります。これらを内部化することで、Kubernetes は、ほとんどのコア制御ループをドメインの専門家が一度だけ記述できるようにし、その上に信頼性の高いシステムを簡単に構築できるようにしたいと考えています。

これは、本質的に分散されており、分散システムを構築するように設計されたシステムにとっても自然な選択です。分散システムの定義には局所的な障害の可能性が内在しており、一定の規模を超えるシステムは局所的な障害に関係なく自己修復して正しい状態に収束できることが求められます。

ただし、この設計の選択は、非常に複雑で混乱を招く可能性もあります。具体的な例を 2 つ挙げます。

1) エラーが遅延されます。 Kubernetes でオブジェクト (ポッドなど) を作成するには、通常、構成ストアにオブジェクトを作成し、そのオブジェクトの予想される存在をアサートするだけです。リソースの制約のため、またはオブジェクトが何らかの形で内部的に矛盾している (参照されたコンテナ イメージが存在しない) ために、要求を実際に満たすことができないことが判明した場合、このエラーは通常、作成時に検出されません。構成の作成が行われ、関連するオペレーターが起動して変更を実装しようとするとエラーが発生します。

この間接性により、「生成されたオブジェクトが存在する」ことの適切なマーカーとして「作成が成功しました」を使用できないため、デバッグと推論が難しくなります。これは、失敗に関連するログ メッセージやデバッグ出力が、オブジェクトを作成したプロセスのコンテキストに表示されないことも意味します。

適切に記述されたコントローラーは、Kubernetes イベントを発行して何が起こっているかを説明したり、問題のオブジェクトに注釈を付けたりします。ただし、テストが不十分なコントローラやまれな障害の場合は、コントローラ自体のログにログ スパムが記録される可能性があります。一部の変更には、独立してまたは連携して動作する複数のコントローラーが関係する可能性があり、特定のコード セクションを追跡することがより困難になります。

2) オペレーターに脆弱性がある可能性があります。宣言型制御ループ パターンは、ユーザーが状態 A から状態 B に移行する方法について心配する必要がないことを暗黙的に保証します。状態 B を構成データベースに書き込んで待機するだけです。これは、実際にうまく機能すると、大幅な簡素化になります。

ただし、状態 B は単独では達成可能であるにもかかわらず、状態 A から状態 B に到達することが不可能な場合があります。おそらく可能ですが、ダウンタイムが必要になります。これは可能ですが、まれな使用例であるため、コントローラーの作成者はこれを実装するのを忘れました。

Kubernetes のコア組み込みプリミティブについては、十分にテストされ使用されていることが保証され、適切に動作することを期待できます。しかし、サードパーティのリソースを追加し、TLS 証明書やクラウド ロード バランサー、ホストされたデータベース、外部 DNS 名を管理し始めると、通常の方法から外れてしまい、すべてのパスにわたるテストの有効性が不明確になります。

また、遅延エラーに関する前述の点と一致して、障害モードは微妙であり、離れた場所で発生します。 「変更はまだ受け取られていない」と「変更は決して受け取られない」の違いを見分けるのは困難です。

4. 結論

この記事では、これらの設計上の決定が良いか悪いかについて価値判断を下すことを避けようとしました。 Kubernetes がいつ、どのような価値あるシステムになるのかについて議論することは意味があるからです。

Kubernetes を自分なりに理解し、その複雑さがどこから来るのか、そしてどのような目的のためにあるのかをより深く理解できたことは、非常に価値のあることだと分かりました。

この分析は、現在使用されているあらゆるシステムに適用できます。たとえシステムが現在の環境にとって理想的ではない方法で設計されたとしても、必ず何らかの理由があってそのようになってしまいます。対話し、推論し、決定を下す必要があるシステムである限り、システムを即座に却下するのではなく、そのシステムをその地点まで押し上げた理由、動機、内部ロジックを理解できれば、はるかに良い体験が得られます。

この投稿が、Kubernetes がなぜこのような形になっているのか (私がそう思う)、また Kubernetes に対してどのような合理的な期待があるのか​​という有用なフレームワークを提供することで、Kubernetes を本番環境で初めて使用する人や、Kubernetes の導入を検討している人の役に立つことを願っています。

もっと微妙なニュアンスを表現したい場合は、複雑さを追加するのではなく、複雑さを前倒しすると考えることができます。この設計により、長い間無視していた可能性のある実際の問題に積極的に対処できるようになります。これが望ましい選択肢であるかどうかは、目標、規模、時間的範囲、および関連する要因によって異なります。