物理マシンと仮想マシンでは、K8s 環境でコンテナを実行するのにどちらが適していますか?

[[319956]]

K8S 環境でコンテナを物理マシン上で直接実行するか、分離された仮想マシン上で実行するか、どちらがよいでしょうか?

物理マシン上で実行する場合、リソースは最大限に活用されますが、特に企業内に標準化された CI/CD イメージ配信プロセスがなく、異なるテナントのコンテナが相互に影響を与える場合には、ある程度の分離性とセキュリティが犠牲になります。

仮想マシン上で実行する場合、分離とセキュリティは前者よりも強力になりますが、仮想マシンの管理コストが増加し、リソースの使用率は低下します。

企業はこの分野でどのように意思決定すべきでしょうか?

この質問は金融機関の @sazh さんから寄せられたものです。以下のコンテンツは、twt コミュニティの多くの仲間による実践的な経験の共有から生まれたものです。誰でも交流に参加し、意見を述べることができます。

@gavin_zhang 株式会社銀行のシステムアーキテクト:

質問で述べたように、2 つのソリューションにはそれぞれ長所と短所があります。具体的なソリューションは、企業の実際のニーズに基づいて選択する必要があります。選択する際には以下を参考にしてください。

パフォーマンス: VM + コンテナ ソリューションを使用すると、中間にハイパーバイザーのレイヤーが追加され、パフォーマンスが約 10% ～ 20% 低下します。

コスト: オープンソース ソリューションの場合、追加のソフトウェア コストはかかりません。商用ソリューションの場合、VM にはホスト オペレーティング システムとハイパーバイザー管理ソフトウェアが含まれており、これらはすべて物理マシン ソリューションと比較してコストがかかります。

保守性: VM はエージェントをインストールすることで管理でき、さまざまな管理ソフトウェアとサポート運用・保守ツールが装備されているため、物理マシンよりも保守性に優れています。一方、展開の負荷により、VM ソリューションの問題、特にネットワークとストレージのパフォーマンスの問題を特定することが困難になります。

信頼性: これは 2 つの側面から見る必要があります。 VM にはオペレーティング システムとハイパーバイザーの追加レイヤーがあり、これにより追加の障害ポイントが発生します。ただし、VM は障害移行機能を提供できるため、信頼性の面ではそれぞれに利点があります。

その他: VM ソリューションにより、コンテナーと仮想マシン アプリケーションが同じ物理マシン クラスターを共有できるようになり、リソースの使用率が最大化されます。

要約すれば：

企業がすでに比較的安定した仮想マシン プラットフォームを所有しており、運用および保守の経験がある場合は、仮想マシンを使用して展開することをお勧めします。

コンテナ プラットフォームが物理クラスターのみを使用し、高いパフォーマンス要件 (特にネットワーク) がある場合は、物理クラスターが推奨されます。

コストを重視し、すべてのアプリケーションとサービスをコンテナにデプロイする予定の場合は、物理クラスターをお勧めします。

@某企業の技術部長：

物理マシンを拡張するコストは比較的高く、効率は低くなります。

@Haiyan Lufax システムエンジニア:

リソース使用率の観点では、1. 最も一般的に使用される仮想マシンは VMware です。これにはハイパービジョン オーバーヘッドのレイヤーがあり、通常、システム全体のオーバーヘッドの 10 ～ 15% を占めます。 2. 仮想マシンのディスクとメモリは、マシンが割り当てられているため、排他的に割り当てられます。コンテナの場合、ディスクとメモリが要求され制限されますが、実際に使用される量だけが使用されます。

ネットワークの観点から見ると、仮想マシンは物理マシンのネットワークにレイヤーを追加し、後続のネットワーク ソリューション設計、ネットワーク パフォーマンス転送などにオーバーヘッドのレイヤーが追加されます。

運用および保守コストの観点から見ると、仮想マシンとライセンスの管理には経済的なコストがかかります。

セキュリティの観点から: コンテナはホストマシンのカーネルを共有するため、各アプリケーションが攻撃され、マシン全体がクラッシュする可能性があります。

つまり、それぞれに利点があり、すべてはあなた自身の焦点次第です。

@Garyy 保険システムエンジニア:

仮想マシンはコンテナのように使用できますが、いくつかの重大な欠点があります。重要な点は、仮想化にはオーバーヘッドがあるということです。展開されたゲスト仮想マシンのオペレーティング システム (OS) がどれほど合理化されているとしても、新しい仮想マシンを確立するときには、オペレーティング システムとその構成全体を完全にコピーする必要があります。コンテナーは、仮想マシンまたはベアメタル ホスト オペレーティング システム上で仮想化された独自の初期化プロセス、ファイル システム、およびネットワーク スタックを実行します。コンテナは、その性質上、仮想マシンよりもメモリを少なく使用します。これは、本質的に OS カーネルを共有し、ほとんどの場合、同じライブラリも使用するためです。

ハイパーバイザーはハードウェア インフラストラクチャを共有するために使用され、複数のテナントの分離された仮想マシンを同じ物理マシン上で実行できるようにします。仮想マシンは、コンピューター アーキテクチャに基づいてコンピューター システムをエミュレートし、物理コンピューターの機能を提供します。これにより、基盤となる物理マシンの使用率が向上します。対照的に、ベアメタル サーバーはシングルテナントであるため、リソースの共有はなく、使用可能な CPU と RAM はプロセス専用になります。

たとえば、Hyper-V を使用した場合に報告されるオーバーヘッドは 9 ～ 12% です。つまり、Hyper-V のゲスト OS は通常、使用可能な CPU の 88 ～ 91% で起動します。オペレーティング システムが Hyper-V で実行されている場合のメモリ オーバーヘッドは、メイン メモリの約 340 MB であることが確認されています。もちろん、ゲスト OS 上でプロセスを実行すると、リソース不足に悩まされ、同じプロセスをホスト (物理サーバー) OS 上で直接実行するよりも効率が低下する可能性があります。この仮想化のオーバーヘッドを考慮すると、コンテナの動作方法とその利点から、コンテナをホスト上で直接実行するオプションを検討する必要があります。

仮想マシンを使用すると、ユーザーはゲスト イメージを使用してホスト間でワークロード (コンテナーなど) を簡単に移動できますが、ベア メタル マシンではアップグレードや移動が困難です。良い例はロールバックです。ベアメタル サーバーでは、マシンの状態をロールバックすることは困難な作業です。クラウド プラットフォーム (Amazon Cloud など) でサポートされているバージョン管理およびロールバック機能を使用すると、VM の特定時点のスナップショットを定期的に取得し、必要に応じてそのスナップショットに簡単にロールバックできます。

もう 1 つの例としては、コンテナーの受け入れには制限があり、たとえば、公式の Docker インストールには Windows 10 Pro が必要であり、2012 や 2008 などの他の Windows Server バージョンはサポートされていないことが挙げられます。これにより、オペレーティング システムをアップグレードして構成する必要がある場合、ベア メタル サーバーが面倒になる可能性があります。

一方、シングルテナントのベアメタル サーバーは、厳格なデータ セキュリティとプライバシー制御を必要とするコンプライアンス対策によって制約されている組織にとって、より優れたオプションを提供できます。

@Steven99 ソフトウェア アーキテクト:

まず第一に、絶対的な善悪というものは存在しません。通常、企業自体の実際の状況に基づいて、最も適切なソリューションを選択する必要があります。

物理マシンまたは仮想マシンを選択する際に、最初に考慮すべきことは需要です。ビジネス コンテナーの通常のリソース需要はどのくらいですか?物理マシンはより高度に構成されることが多く、そうしないとコンピュータ室のキャビネット リソースを占有する大きな無駄が生じます。したがって、仮想化レイヤーには仮想化の利点があります。もちろん、パフォーマンスの低下はありますが、比較するとより適しているかもしれません。

物理マシンの構成が高くなく、コンテナ リソース要件が単に少数の弾力性のある複数のインスタンスだけではない場合は、仮想化レイヤーは必要ありません。

もう一つは、企業自体の現状です。最初からやり直すことは不可能なので、現実に基づいて適切な解決策を見つけなければなりません。物理マシンと仮想マシンを並行して実行することも可能です。これは目標ではありません。目標はビジネスをより良くサポートすることです。したがって、ビジネスニーズに焦点を当て、企業の現状に基づいて適切なソリューションを選択することをお勧めします。

@zhuqibs Mcd ソフトウェア開発エンジニア:

私の意見では、これは問題ではなく、ユーザー自身の状況に基づいた選択です。

独自の IDC ルームを構築する場合は、次の理由から物理マシンを使用することをお勧めします。

（１）運用・保守コスト：Kubernetes自体のネットワーク環境は比較的複雑です。この複雑なネットワークに複雑な仮想マシン ネットワークを追加することは、専任の運用および保守担当者がいなければ処理が困難です。

（２）信頼性：仮想マシン上に構築されたKubernetesはCPUを共有する場合があります。ホストノードがクラッシュすると、複数の Kubernetes ノードがクラッシュします。すべてのマスターノードがクラッシュすると、コンテナ クラウドは終了します。

（３）ソフトウェアコスト：IDCコンピュータ室の構築には多額の資金が投入されている。 VMware、Boss、その他の PKS ソフトウェアに投資すると、コストが高くなりすぎます。

（4）需要の不足：仮想マシンを使用してk8sを構築する最大の利点は、カスタマイズできることです。たとえば、5 ノードのクラスターが必要な場合は、仮想マシンとクラスターを自分で構築できます。いい話に聞こえるが、現実は非常に厳しい。ほとんどの企業ではこのような要求はありません。この需要はパブリック クラウド上で発生します。

（５）未熟な技術：私はエンタープライズレベルのコンテナクラウドを個人的に使用した経験があります。ベンダーはソフトウェアとハ​​ードウェアの導入を契約しました。しかし、そこには大きな落とし穴がありました。展開後、NxT ネットワークに問題が発生し、コンテナ クラウド内のアプリケーションの実行速度が遅くなることが多くなりました。ベンダーは半年以上にわたって問題を調査しましたが、解決できませんでした。

ユーザーが独自に構築したコンピュータ ルームを持っていない場合は、仮想マシンの k8s 展開ソリューションを使用する必要があります。どのくらいパフォーマンスが落ちるのかと聞いてくる友人もいますが、私はあまり感じません。ただし、多くの利点があります。

（1）コスト削減：ほとんどのパブリッククラウドベンダーは現在、k8sクラスターに対して課金せず、基盤となるサーバーに対してのみ課金しています。

（2）コストを節約：完全に管理されたk8sの場合、マスターノードはパブリックの大規模プールであり、無料です。

（３）安心：大規模なインターネット企業でない企業にとって、専門的なk8s運用・保守担当者を雇うのは相当な費用がかかりますが、パブリッククラウドではこの心配はありません。

（4）オートスケール：サーバーは自動的に拡張できる仮想マシンです。イベント当日は、k8s 自身のオートスケールだけでなく、仮想マシンのオートスケールも利用できるようになります。後者は物理マシンでは不可能です。

（５）自分の好みに合わせて自分で作ることができます。通常、テストや実験のニーズがたくさんあるので、k8s を構築するだけで済みます。それは物理的なマシンのようなものではありません。リソースがない場合でも、マシンを購入する必要があります。