コンテナ戦争が始まった。巨額の資金の支援を受けてK8Sは世界を制覇できるのか？

導入

以前の会社で Eru2 を書き終えた後、私は過去 4 年間のコンテナ コミュニティの開発をレビューし、他のシステムの経験から学ぶことに長い時間を費やしました。一方で、CNCF の成長は信じられないほど速いものでした。わずか数年で、ASF と同じくらい重要になりました。同社は、自社のプロジェクトを宣伝したり、さまざまなカンファレンスで他社と競争したりするために努力を惜しまず、業界統一の瀬戸際にいるようだ。一方、Kubernetes のスケジューリングとオーケストレーションの戦いはほぼ終わりました。 CNCFの推進とデファクトスタンダードとなったCNI/CRIなどのインターフェース仕様に依存して、Dockerのコアコンポーネント（containerd）は解体され、CRIで「仕方なく」実装され、次第にCNMモデルを放棄するようになりました。抵抗するのは全く無力であり、わずかにバグが多いデーモンだけが残される。 K8s と直接接続することで国に恥をかかせていた、その息子である Swarm の運命は言うまでもありません。 ASF 傘下の Mesos だけがまだ持ちこたえられる。しかし、その残念なマラソン、隣にある K8S のエコシステムを見れば、何と言えばいいでしょうか。

興味深いのは、2016 年に Docker の将来について書いたとき、私が Docker を理解していないとして誰かから「教育」を受けたことです。残念ですが、あなたの叔父さんは依然としてあなたの叔父さんです。今では、cri-o、rkt、さらにはDocker独自のcontainerdの開発動向を見ると、思いやりのある笑顔で返信し、手動でさよならを言うことしかできません。多数の本番環境で実証済みの定評あるネットワークコンポーネントである calico でさえ、バージョン 3.X 以降は libnetwork CNM モデル下の docker ネットワークインターフェースの保守と更新を停止し、Mesos のサポートを削除し、戦争を終わらせない者は愚か者か邪悪者であるとしています。

戦争が終わったことに疑いの余地はない。 CNCF からの巨額の資金援助を受けた K8s は世界を制覇しましたが、本当に無敵なのでしょうか?

人々！人々！人々！

スケジューリングとオーケストレーション、そしてマクロアーキテクチャ設計の両面において、k8s が非常に優れたシステムであることは否定できません。初期の k8s は、Google の旗の下でほんの数人のエンジニアだけがオープンソース コミュニティに足を踏み入れる方法を見つけた、無視されたプロジェクトだったと言えます。残念ながら、豚相手とG一族のハローがいます。私のようなオープンソースシステムが世界の王者になれるでしょうか?

個人的にはGの輪が眩しすぎるからだと思います。

過去には、Mapreduce、GFS、そして多数の業界論文があり、その後、オーケストレーションを新たな高みに引き上げた魔法の Borg がありました。ほとんどの人は製品を選ぶとき、YoG の製品を見てそれが最高だと考えますが、それだけです。さらに、対戦相手は本当に十分に強くありません。たとえば、Mesos にはまだ統一された言語や完成度がありません (もちろん、その 2 層構造は運命づけられていると言えます)。そして、愚かな Swarm モードがそれを補っています。私はバカではないので、もちろん父から物をもらうのが一番です。

しかし、私が本当に言いたくないのは、オープンソースであるかどうかに関わらず、すべての企業の製品はそれぞれのビジネスに基づいているということです。 G の製品を使用したからといって、あなたのチームが G のチームと同じになるわけではありません。あなたはエンジニアリングの世界のピラミッドの頂点に、G と対等に立つことになります。持っているカードをすべて使ってください。勝てるならそれは優れたスキルがあるからですが、1対3では4対2には勝てません。

k8s を使用するほとんどのチームは、主に k8s をブラック ボックスとして使用していることがわかりました。小規模ビジネスを立ち上げるにはコストが非常にかかります。規模が小さいビジネスに、これほど多くの概念を押し付ける必要は本当にあるのでしょうか? Pod の設計は、コンテナ時代の仮想マシンでのマルチプロセス業務に対する回避策ではないでしょうか?サービス ガバナンスの概念は数多くありますが、本質的にはプロキシで解決できないものはありません。ある場合は、別のプロキシを追加してみてはいかがでしょうか?さらに、規模が大きい場合、このような大きなブラックボックスでは実際に何が問題になるのでしょうか?どうすればいいですか？ cri-o rktnetes containerd docker-shim などのランタイムの実装詳細の比較も含めて、kubelet の実行プロセスと実装を自分で調べましたが、コミュニケーションをとる相手を見つけるのは困難です。さらに、コミュニティのアップデートもあります。彼らをフォローしていますか？これに従わない場合、セキュリティ上の問題が発生した場合はどうなりますか?アップグレード中に何か問題が発生した場合はどうすればよいですか? k8s は厳密な意味ではバイパス オーケストレーションおよびスケジューリング システムではないことを知っておく必要があります。アップグレードの悲劇は多くないですか?

G の製品を使用しているからといって、G のエンジニアと同じレベルになるわけではありません。

Kubernetesの未来

いずれにせよ、k8s は事実上の標準となっています。近い将来、CNCF のサポートにより、コミュニティは最も深い堀となります。コンテナのスケジューリングとオーケストレーション、サービス ガバナンス、リンク制御 (アップグレード、ダウングレード、フロー制御、検出など) を解決でき、一度ですぐに使用できる (さまざまな概念は別として) インフラストラクチャが必要な場合は、これが唯一の選択肢であり、最良の選択肢です。

しかし、それは複雑すぎます。遠くにあるポッドについては話さないようにしましょう。サービス ガバナンスにおける Sidecar コンセプトと、別途開始した SDK ミドルウェアの違いは何ですか?そうですね、言語バインディングが必要ないというのは本当ですが、パフォーマンスの点では、インメモリ設計に勝るものはありませんよね？

istio を使用する場合は、k8s を使用してください。 linkerd を使用したい場合は、k8s に進んでください。個別に使用しても使用可能ですが、k8s でのみ、これらの機能が提供するトリックをうまく活用できます。これと強制バインディングの違いは何ですか?うーん、Apache httpd の新時代の到来のようですね。

ビジネスが成長するにつれて、基本的なプラットフォームは抽象化されますが、維持と学習には依然として多くの人手が必要です。プラットフォーム レベルで何かを開発していたとき、自動化してコストを削減したいと考えていました。現在、フロントエンド業界と同様に、コンセプトは日々変化しており、大勢の人々に依存しています。個人的にはこれは良いことではないと思います。戦前であれば、K8s はそれほど物議を醸すことはなかったかもしれません。しかし、戦後、すべての人を満足させることは難しく、これが唯一残された目標となりました。時間が経つにつれて、K8s の複雑さに関する不満がますます高まると考えられます。同様に、Apache httpd が最終的に nginx に出会ったように、オーケストレーションおよびスケジューリング システム「nginx」も近い将来に私たちの視野に現れると予測しています。これは、旧ブランドの Hashicrop の下にある nomad が K8s と世界を共有するのを待っているのと同じです。

新たな戦場

Docker はオーケストレーションとスケジューリングで負け、世界を支配する覇権も失いました。しかし、K8s にとって最も残念なことは、コンテナを生成するための「ファクトリー」標準が依然として Docker の手に委ねられていることです。

OCI イメージ標準と Docker イメージ標準、または運用レベルの containerd であるかどうか。 K8s は CRI/CNI を開発し、CRI-O と Rkt をサポートしましたが、これらはまったく役に立ちません。まだ誰かが appc の概念について言及しているかどうか見てみましょう。最新の RC では、containerd に CRI サポートが組み込まれており、kubelet の dockershim 実装を直接置き換えて、以前の cri-containerd を履歴のゴミ捨て場に捨てることができます。それは事実上の標準となりました。

CRI-O さんはテストの完全性が高いとおっしゃっていますが、K8s に組み込まれている dockershim/containerd よりも高いのでしょうか? rkt さんは、プロセス ツリーがフラットだと言っていますが、systemd の下にコンテナを直接ハングさせる containerd よりもフラットになるのでしょうか?さらに、どちらもコントロール プレーンを抽象化しており、基盤となるランタイムは runc と runV の混合デプロイメントをサポートしていませんか?そして、cri-o さん、あなたは他のことは何も学ばず、組み込みポッドの作成にこだわります。隣のクベレットに食べ物を与えずに放置したらどうしますか?

インフラストラクチャは安定している必要があります。現時点では、CRI-O Rkt やその他のオプションに明らかな利点がなく、大幅に劣っている場合、containerd が事実上の標準となっています。 Docker は、コンテナ「エンジン」として本来あるべき場所に戻りました。もちろん、containerd の成功は K8s の成功にも依存します。 dockershim の導入により、数千世帯に導入されました。

containerd が成熟するにつれて、新しいオーケストレーション システムと新しいシステム アーキテクチャが登場しました。この上に、K8s を脅かすほど強力な新しいインフラストラクチャ システムが出現する可能性は十分にあります。

終わり

2018 年のこの時点でも、スケジュールとオーケストレーションは実行可能であると私は信じています。 containerd のみでコンテナを駆動する方法、複雑な Pod をネイティブ コンテナ (1 プロセス 1 コンテナ) に分解して上位層の組み合わせで複雑な業務形態を完成させる方法、既存の基本的なネットワーク プラグインを CNI で組み合わせる方法、数万台のマシンのより効率的なオーケストレーションを実現する方法など、まだ想像の余地があります。

古い戦争は終わり、新たな戦場はすでに煙で満たされている。私は個人的に、containerd の将来について楽観的です。歴史的な負担がなく、さまざまなシステムのインターフェースと下位互換性があり、多数の製造実践を通じて安定性が実証されており、簡単に再開発することもできます。おそらく数年後には、新しいスケジューリングとオーケストレーションに基づいた「nginx」が登場するでしょう。