3

kubernetes クラスターを試しているときに、スケーラビリティの問題が発生しました。テスト マシンのトポロジを簡素化するために、NodePort タイプを使用して個々のサービスを外部に公開します。ノードとマスターをホストするベアメタルは、24 個の CPU と 32G RAM を搭載した RHEL 7 です。専用のロード バランサーやクラウド プロバイダーのようなインフラストラクチャはまだありません。サービス定義のスニペットは以下のようになります

    "spec": {       
         "ports": [{
             "port": 10443,             
             "targetPort": 10443,               
             "protocol": "TCP",                                
             "nodePort": 30443
    } ],
   "type": "NodePort",

このようにして、アプリケーションは次の方法でアクセスできますhttps://[node_machine]:30443/[a_service]

このようなサービスは、1 つの Pod によってのみサポートされます。理想的には、複数のサービスを同じノードにデプロイし (ただし異なる NodePort を使用)、同時に実行したいと考えています。

同様のワークロードの場合、展開されるサービスの数を増やすと (したがってバックエンド ポッドも)、アプリケーションのパフォーマンスが低下することが明らかになるまで、物事はうまく機能していました。驚いたことに、サービスの読み込み時間を分析すると、「ネットワーク」レイヤーのどこかで速度が低下していることを示しているように見える「接続時間」が劇的に低下していることに気付きました。負荷はまだノードの CPU の多くを駆動するほど高くないことに注意してください。ドキュメントの欠点について読みましたが、ヒットしたものがそこに記載されている kube-proxy/Service の制限であるかどうかはわかりません。

質問は次のとおりです。

  1. よりスケーラブルにする方法について何か提案はありますか? つまり、アプリケーションのパフォーマンスを犠牲にすることなく、より多くのサービス/Pod をサポートできるようにするには? NodePort タイプは、サービスの「パブリック」アドレスを設定する最も簡単な方法ですが、すべてのサービスと Pod がこの方法で設定されている場合、スケーラビリティまたはパフォーマンスに制限はありますか?

  2. タイプを LoadBalancer に変更すると、違いはありますか? 「タイプ」：「ロードバランサー」

  3. さらに、外部からバックエンド Pod (またはサービス) にトラフィックをルーティングする HAProxy など、スケーラビリティを向上させる専用の LoadBalancer またはリバース プロキシを使用する利点はありますか? Nginx darkgaro/kubernetes-reverseproxy に対していくつかの作業が行われていることに気付きました。残念ながら、ドキュメントは不完全なようで、具体的な例はありません。他のスレッドで Vulcan について話している人がいますが、これは kubernetes に推奨される LB ツールですか?

あなたの推薦と助けは大歓迎です！

4

2 に答える 2

1

こんにちは、kubernetes の初心者ですが、同様の質問と懸念があります。それらのいくつかに答えるか、ユーザー ガイドの関連するセクションにリダイレクトしようとします。

vagrant /local などの非クラウド対応プロバイダーに Kubernetes をデプロイする場合、一部の機能は現在、プラットフォームによって提供または自動化されていません。

その 1 つが「LoadBalancer」タイプのサービスです。PUBLIC IP のサービスへの自動プロビジョニングと割り当て (LB として機能) は、現在、Google コンテナ エンジンなどのプラットフォームでのみ行われます。

ここ とここで問題を参照してください。

公式ドキュメントの状態

外部ロード バランサーをサポートするクラウド プロバイダーでは、type フィールドを「LoadBalancer」に設定すると、Service のロード バランサーがプロビジョニングされます。

現在、代替案が開発され、文書化されています。 HAProxyの使用については、こちらを参照してください。

おそらく近い将来、kubernetes は最終的に、展開して操作できるすべての利用可能なプラットフォームでその種の機能をサポートするようになるため、更新された機能を常に確認してください。

パフォーマンスの低下として言及しているのは、おそらく PublicIP (バージョン 1.0 以降の NodePort) 機能が機能しているためです。つまり、NodePort サービス タイプを使用することで、kubernetes はこの種のサービス用にクラスターのすべてのノードにポートを割り当てます。次に、kube-proxy は、このポートへの呼び出しを実際のサービスなどにインターセプトします。

まったく同じ問題を解決しようとする HaProxy の使用例は、こちらにあります。

それが少し役立ったことを願っています。

于 2015-09-01T12:58:22.033 に答える
0

私は同じ問題に直面しています。内部 kube-proxy は、外部ロード バランサーを意図していないようです。具体的には、kube-proxy でタイムアウトを設定したり、再試行したりしたいと考えていました。

同様の問題について説明しているこの記事を見つけました。内部でetcdを使用しているため、彼は vulcan を検討することを推奨しています。おそらく、このプロジェクトの方向性は、将来的に k8s に完全な機能を備えた LB を提供することです。

于 2015-11-05T08:58:15.203 に答える