問題タブ [cloud-bare-metal]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
2 に答える
10912 参照

virtual-machine - ベアメタル (ハイパーバイザーベース) とホスト仮想化タイプの違い

ベアメタル (ハイパーバイザーベース) とホスト仮想化タイプの違いは何ですか?

0 投票する
3 に答える
582 参照

virtual-machine - kubernetes デプロイメント用のベア メタル サーバーを仮想化するか、仮想化しないか

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

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

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

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

安全:

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

認証:

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

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

0 投票する
2 に答える
182 参照

ibm-cloud - IBM Bluemix でベア メタル サーバーにセキュリティ グループを割り当てることができない

IBM Bluemix で 1 つのベア メタル サーバーを開始しました。サーバーは稼働中です。しかし、ポートを開くことができません。ベア メタル サーバーで allow_all トラフィックを有効にしたいと考えています。構成済みのセキュリティ グループがあることはわかりますが、それらのグループをサーバーに割り当てることができません。

正しい方向へのポインタは高く評価されます。

0 投票する
1 に答える
735 参照

kubernetes - Kubernetes ベアメタルでのアプリケーションの負荷分散

ベアメタル Kubernetes クラスター用の Ingress コントローラーのセットアップを検討しています。Ingress コントローラーを調べ始めましたが、これらはポート 80 または 443 経由で到達可能な HTTP サービスに対してのみうまく機能するようです。任意のポートで TCP または UDP サービスを公開する必要がある場合は、Nginx またはHAProxy Ingress コントローラーですが、クラスターは単一のポート範囲を共有することになります。これを誤解している場合はお知らせください。

任意のポートで TCP または UDP サービスを公開して負荷分散する必要がある場合、どのようにしますか? サービスが独自の VIP を取得し、必要なポートを使用できるように ClientIP を使用することを考えていましたが、問題は、これらの VIP にトラフィックをルーティングし、フレンドリな DNS 名をどのように付けるかということです。これに対する解決策は既にありますか、それとも自分で構築する必要がありますか? NodePort または名前空間が単一のポート範囲を共有する必要があることを意味するソリューションを使用することは、実際にはスケーラブルでも望ましいことでもありません。特に、名前空間 1 のボブが自分のサービスにポート 8000 でアクセスできるようにする必要があるのに、名前空間 2 のリンダがすでにそのポートを使用している場合。

明確化、潜在的な解決策、または一般的なヘルプは大歓迎です。