Kubernetes の創設者が語る! K8s が反撃を受けています!

著者 |趙雲

制作 | 51CTO テクノロジースタック (WeChat ID: blog)

Kubernetes は複雑になりすぎており、抑制することを学ぶ必要があります。そうしないと、革新が止まり、基盤を失ってしまいます。

Kubernetes の共同創設者 Tim Hockin 氏はめったに発言しません。今年の KubeCon で、彼は Kubernetes のコアメンテナーは、提案された新機能の利点と、それによってもたらされる追加の複雑さを比較検討すべきだと提案しました。

1. Kubernetes はもうそれほど魅力的ではありません!

オリジナルのコンテナ オーケストレーション プラットフォームは、ますます本来の姿を失いつつあります。 K8s 自体はますます複雑になっています。開発者や運用担当者が圧倒されているだけでなく、K8s の社内スタッフも声を上げ始めています。

Kubernetes の共同創設者であり、Google の著名なソフトウェア エンジニアである Tim Hockin 氏は、K8s の将来について懸念し始めました。

Kubernetes はもともと 2014 年に Google のエンジニアによって作成されました。2 年後には、Cloud Native Computing Foundation の最初のホスト プロジェクトとなり、Linux に次ぐ世界で 2 番目に大きなオープンソース プロジェクトとなりました。

効率性とスケーラビリティは常に K8s のハイライトであり、特にスケーラビリティは、アプリケーションのスケーラビリティの展開と管理を可能にするだけでなく、開発チームが革新的なソフトウェアに集中し、企業が新興技術に備えることも可能にします。

9年半後、ペニーK8はもうそれほど輝いていないかもしれません。 「以前は高度にスケーラブルなアプリケーションをサポートしていましたが、現在では機械学習推論などのより複雑な作業に最適なプラットフォームとして徐々に選ばれるようになっています。」典型的な例としては、2 年前には Tensorflow モデルの展開と推論に Kubeflow が使用され、最近では LLMOps でも Kubernetes が使用されるようになりました。

2. 最も差し迫った課題

「K8s にとって最も差し迫った課題は何だと思いますか？」ホッキン氏は、クラウド ネイティブ コミュニティに率直に質問しました。

はい、その場では予想通りの答えが何度も出てきました。コンテナ オーケストレーション エンジンの導入と保守の複雑さは恐ろしいほどです。この複雑さをすべて DevOps に押し付けるのは悪夢です。これは K8s の「最大の実存的脅威」であると言う人もいます。

「何かを犠牲にしなければならない」とホッキン氏は述べ、これはK8sが長年にわたって多くの複雑さを吸収してきた代償だと指摘した。エンドユーザーだけでなく、コアメンテナーも複雑さの影響を受けます。

複雑さが増すほど、K8s コアメンテナーが将来的に簡単に変更を加える敏捷性は低下します。同時に、ソフトウェアが複雑になるほど、ユーザーの抵抗も大きくなります。

Kubernetes は開発者を圧倒しています。 K8s を使用する前は、開発エンジニアが行う必要があったのは、アプリケーションの開発、記述、テスト、パッケージ化、デプロイでした。しかし、K8s では開発プロセスが完全に覆されました。

開発者にとっては、運用・保守の作業が重荷になります。特にプラットフォーム エンジニアリング チームが関与する場合は、戦いが始まることを意味することがよくあります。彼らはクラスターに成果物を投入していますが、品質に対しても高い期待を抱いています。しかし、開発者にプラットフォーム エンジニアリングの要件に従うよう説得するには、多くの場合、何度も戦いを繰り広げる必要があります。

3. 2つの疲労ギャップ

Kubernetes はコンテナ オーケストレーション プラットフォームから今日の巨大なエコシステムへと進化し、クラウド ネイティブ時代の開発と運用のために克服する必要がある 2 つの「疲労ギャップ」を生み出しています。 DevOps チームは、クラウド ネイティブ アーキテクチャに移行するときに専門分野を拡大する必要がありますが、これは明らかに彼らの快適ゾーンの外です。

両者とも、自分の快適ゾーンで許される以上のスキルを習得する必要があります。インフラストラクチャ チームのメンバーは開発者のニーズにさらに敏感になる必要があり、開発者の作業負荷はインフラストラクチャ関連のタスクをますますカバーするようになります。

具体的には、開発者はインフラストラクチャの問題をより意識する必要があります。一方、Kubernetes リソースや Kubernetes YAML の記述方法は反復を伴うため、必然的にソフトウェア開発の同僚から学ぶ必要があり、運用、インフラストラクチャ、またはシステム エンジニアリング担当者は開発に近づいています。

さらに恐ろしいのは、新しいテクノロジーに夢中になることに対する誤解がまだあることです。つまり、まったく必要がないのに、K8s のために K8s を使用したり、マイクロサービスのためにマイクロサービスを使用したりすることです。

画像出典: Zhihu

4. 複雑さは予算のようなもので、最終的には使い果たされる

Kubernetes ソフトウェアはコミュニティ主導です。現在までに、コミュニティには 74,680 人を超える貢献者と 7,812 社の貢献企業が存在します。これは、第一世代の K8s ユーザーの努力と切り離せないものですが、新しいユーザーが参加し続けると、Kubernetes の仕組みに対する関心は必然的に薄れ、複雑さが増します。

「複雑さが増すほど、消費する予算も増えます。予算がなくなると、悪いことが起こり、K8s のイノベーションは止まり、ユーザーは他のソリューションに移行します。」

したがって、Kubernetes プロジェクト マネージャーは、複雑さを「複雑さの予算」と呼ばれる有限のリソースとして考え、それが無期限に継続することはできないと考える必要があります。

トップクラスの Kubernetes エンジニアは、K8s がエンドユーザーやコアメンテナー自身にとってさえ複雑になりすぎていることに同意しています。予算に複雑さを組み込むときが来ました。

5. K8sの社内スタッフはもっと頻繁に「ノー」と言う必要がある

ホッキン氏は、エンドユーザーが複雑なソフトウェアを扱う際の忍耐力は言うまでもなく、ソフトウェアの複雑さを測定する方法も知らなかったと認めた。しかし、彼は巧みに複雑さの問題を予算の問題に変えます。「エンジニアは通常、予算を超過していることを認識しています。」

したがって、新しい機能の追加を検討するときは、次のような質問をする必要があります。このタスクを実行するのに十分な複雑さの予算がありますか?限られた予算をこれに無駄にすべきでしょうか?

エンジニアの仕事の一部は、あらゆる決定のトレードオフを比較検討することであり、新しい機能によってもたらされる可能性のある追加の複雑さは、評価する必要がある要素の 1 つである必要があります。

コード ベースを拡張すると、ソフトウェアの一部の領域で 5% のパフォーマンス向上が得られるかもしれませんが、それによってメンテナーが対処しなければならない内部の複雑さが増すのであれば、それだけの価値があるでしょうか。特定のユースケースを満たすために API を変更する場合、その変更によって他のすべてのユーザーに負担をかける価値はあるでしょうか?

すべての K8s ユーザーは、基準を引き上げ、「本当に好きなもの、悪いアイデアではないと思われるもの、明白で簡単そうに思えるもの、本当に欲しいものに貢献するもの」に対して「ノー」と言う覚悟を持つ必要があります。

特定の提案に「ノー」と言うことで、複雑性予算に余裕を残し、将来的に関連性の高いプロジェクトを処理することができます。

Hockin 氏は、明日興味深いことを実行できるようにするために、K8s は今日の物事に「ノー」と言う必要があると考えています。

ホッキン氏は、われわれは皆、より多いことは常に良いことだと考えることに慣れているが、Kubernetes は今後、「より少ないことはより多い」ということについてもっと考える必要があるかもしれないと述べた。 Kubernetes ではまだやるべき作業がたくさんありますが、すべてをすぐに行う必要があるわけではありません。

6. K8sが置き換えられる兆候

K8s は Google によって作成されましたが、すべての企業に適しているわけではありません。過去数年間、誰もが新しいテクノロジーを追い求め、K8s をただ K8s のために採用してきましたが、K8s が登場してからほぼ 10 年が経った今、徐々に置き換えられる兆候が見られます。 「Kubernetes が必要ない場合は、使用しないでください。」

コンテナ オーケストレーションの分野でも、Kubernetes は開発者にとって使いにくく、導入、運用、トラブルシューティングに多くの時間と理解が必要であるため、企業は Kubernetes の管理に多くの時間を費やす必要があります。過去2年間、企業は他の選択肢を模索してきました。

• Kubernetes をアウトソーシングしてホストし、クラウド プロバイダーの管理された Kubernetes サービスを使用することを選択する人もいます。
• Red Hat の OpenShift など、K8s 操作を削減するディストリビューションを使用するものもあります。
• HashiCorp の Nomad のような代替手段を使用する人もいます。
• あるいは、Amazon の持続可能なアーキテクチャ担当副社長である Adrian Cockcroft 氏が「サーバーレス ファースト アプローチ」と呼ぶものを採用し、Azure Functions、Amazon Web Services Lambda、Google Cloud Functions などの FaaS サービスに直接移行して、Kubernetes を完全にバイパスすることもできます。

さらに、コンテナ オーケストレーションの王者として K8s に取って代わることに注力する cycle.io などの新製品が市場に登場し、開発や運用の経験が限られている人でも、自分が望むものを記述してプラットフォームに実装させることができます。

7. 結びの言葉

もちろん、継続的な吸収と拡張により、Kubernetes はクラウドネイティブ時代に急成長を遂げてきましたが、新機能を素早く吸収するという「スター吸い上げ方式」も裏目に出始めています。現在、Kubernetes はコンテナ オーケストレーション分野で減速しており、新しい競合他社が Kubernetes に注目し、追い抜こうとしています。

ある業界関係者が Hockin 氏にアドバイスしたように、「満足感を先延ばしにしなさい」。つまり、生き残るためには、Kubernetes は未完成のままでなければならないのです。

参考リンク:

https://thenewstack.io/how-to-fight-kubernetes-complexity-fatigue/

https://thenewstack.io/tim-hockin-kubernetes-needs-a-complexity-budget/

https://blog.container-solutions.com/adrian-cockcroft-on-serverless-continuous-resilience?