1

大規模な物理サーバー (24 コア) に kubernetes をデプロイしたいと考えていますが、多くの点で確信が持てません。

ベアメタル以外で k8s クラスター用の仮想マシンを作成することの長所と短所は何ですか。

次の考慮事項があります。

  • VM を作成すると、ワークロードの分離が可能になります。実験用の新しい VM を作成して開発者に割り当てることができます。
  • 一方、ベアメタルで実行される k8s では、各開発者が実験用に新しい NAMESPACE を作成し、そこでコードを実行できます。結局、コードは docker コンテナで実行する必要があります。

安全：

  • VM を使用すると、将来のメンテナーに与えられるアクセスの量が制限され、実行できる損害の量が制限されます。一方、将来のメンテナーの主なタスクはノードの追加/削除であり、そのためにはベア メタル アクセスが必要になります。

認証:

  • 現時点では、開発者は、コードが CI パイプラインを介して実行され、実行中のデプロイが展開されている場合にのみ、サーバーにアクセスします。しかし、ログの表示についてはどうでしょうか。階層化された kubectl 認証をセットアップして、割り当てられている名前空間にのみ開発者がアクセスできるようにすることはできますか (これは、k8s 名前空間認証プラグインで可能になるはずです)。

サーバーにはすでに多数の VM が存在します。これは問題になるでしょうか？

4

3 に答える 3

1

dev と prod を異なる VM の形で分離します。私はかつて、あまりにも多くのスレッドを使用する docker 内の webapp を持っていたので、ホスト上の docker デーモンがクラッシュしました。幸いなことに、ホストは 1 つに限定されていました。制限を設定することでこれを保護できますが、これにはリスクがあります。dev での 1 つのミスが、prod もダウンさせる可能性があります。

于 2017-01-03T03:43:07.550 に答える
1

128コアと疑問....それは、単一のサーバーの多くのコアです。

ただし、kubernetes の場合、これは関係ありません。Kubernetes はさまざまなサイズのサーバーを使用して、それらを最大限に活用できます。ただし、単一サーバー上でマスター サーバー プロセスとノード/ワーカー プロセスを組み合わせると、不要なリソースの問題が発生する可能性があります。すでに述べたように、名前空間でそれらを管理できます。

私たちが行っているのは、単一の dev/qa kubernetes 環境で名前空間との継続的な統合を使用することです。変更には独自の名前空間があり (そのため、多くの名前空間を実行します)、それらの名前空間で完全な環境展開を実行します。これを管理するために、一連のシェル スクリプトが使用されます。これは、あなたが持っているものと同じように大規模なサーバーで機能するだけでなく、小さな（または仮想）ボックスでも機能します. 仮想化の利点は、主に大きなボックスを小さなボックスに分割して、kubernetes だけでなく他の目的にも使用できるようにすることです (はい、kubernetes は MS Windows 以外で実行され、デスクトップはなく、VPN 目的のカーネル モジュールはありません、など)。 ）。

于 2017-01-02T23:16:34.670 に答える
0

答えは「場合による！」だと思います。これは実際には答えではありません。個人的には、VM を使用してマシンを分割し、そのようにデプロイします。サーバーのリソースをどれだけ切り開くかに関して柔軟性が向上し、新しい環境を簡単に作成してから簡単に破棄できます.

これらの VM が非常に大きい場合でも、マシン上に既存の VM があることを考えると、管理はより簡単だと思います。

とは言っても、単一ノード サーバーを実行できないという技術的な理由はありませんが、アップグレードに伴うダウンタイムの問題に遭遇する可能性があります (それが問題である場合)。クラスタがダウンしています。

お客様の環境の HA とアップタイムのニーズ、および VM をデプロイする方法 (そのルートを選択する場合) を調べて、何が最適かを判断します。

于 2017-01-05T01:36:32.990 に答える