kube-proxy プロキシモードの詳細な説明
kube-proxy は現在、次のプロキシ モードをサポートしています。
1. ユーザー空間: 最も初期の負荷分散ソリューション。ユーザー空間のポートをリッスンし、すべてのサービスが iptables を通じてこのポートに転送され、内部負荷が実際のポッドに分散されます。この方法の主な問題は、効率が低く、明らかなパフォーマンスのボトルネックであるため、現在は推奨されていません。
たとえば、サービスを作成するには、対応する IP: 1.2.3.4、ポート: 8888、kube-proxy によってランダムに選択されたポートは 32890 で、iptables に追加されます。
-A PREROUTING -j KUBE-PORTALS-CONTAINER
-A KUBE-PORTALS-CONTAINER -d 1.2.3.4/32 -p tcp --dport 8888 -j REDIRECT --to-ports 32890
KUBE-PORTALS-CONTAINER は、iptable の kube-proxy によって作成されるルール チェーンであり、PREROUTING フェーズで実行されます。
実装プロセス:
- サービスへのアクセス要求があると、PREROUTING ステージで、jumpKUBE-PORTALS-CONTAINER が要求されます。
- KUBE-PORTALS-CONTAINER のこのレコードは機能し、kube-proxy がリッスンしていたポート 32890 にリクエストをリダイレクトし、データ パケットが kube-proxy プロセスに入ります。
- 次に、kube-proxy は、実際のサービスの応答要求として、SessionAffinity に従ってサービスに対応するエンドポイントから 1 つを選択します。
2. iptables: 現在推奨されているソリューションでは、iptables ルールを使用してサービスの負荷分散を実現します。この方法の主な問題は、サービスが多い場合に生成される iptables ルールが多すぎること、非増分更新では一定の遅延が発生すること、そして大規模な場合には明らかなパフォーマンスの問題が発生することです。
たとえば、対応する IP: 1.2.3.4、ポート:8888、および対応するバックエンド アドレス: 10.1.0.8:8080 のサービスが作成された場合、そのサービスは iptables (メイン ルール) に追加されます。
-A PREROUTING -j KUBE-SERVICES
-A KUBE-SERVICES -d 1.2.3.4/32 -p tcp –dport 8888 -j KUBE-SVC-XXXXXXXXXXXXXXXX
-A KUBE-SVC-XXXXXXXXXXXXXXXX -j KUBE-SEP-XXXXXXXXXXXXXXXX
-A KUBE-SEP-XXXXXXXXXXXXXXXX -p tcp -j DNAT –to-destination 10.1.0.8:8080
KUBE-SERVICES は、iptable の kube-proxy によって作成されるルール チェーンであり、PREROUTING ステージで実行されます。
実装プロセス:
- サービスへのアクセスをリクエストすると、iptables はプレルーティング段階で KUBE-SERVICES にジャンプします。
- KUBE-SERVICES の上記の最初の基準に一致し、引き続き KUBE-SVC-XXXXXXXXXXXXXXXX にジャンプします。
- このルールに従って、KUBE-SEP-XXXXXXXXXXXXXXXX にジャンプします。
- KUBE-SEP-XXXXXXXXXXXXXXXX ルールでは、DNAT アクションを通じて実際のポッド アドレス 10.1.0.8:8080 にアクセスします。
3. ipvs: iptables モードのパフォーマンスの問題を解決するために、v1.11 では増分更新を使用して ipvs モード (v1.8 はベータ版のサポートを開始し、v1.11 GA) を追加し、サービス中の接続を保証できます。更新 壊れないように保ちます。
IPVS モードでは、kube-proxy は Kubernetes のサービスとエンドポイント オブジェクトの変更を監視し、ネットリンク インターフェイスを呼び出して対応する IPVS ルールを作成し、Kubernetes のサービス、エンドポイント、および IPVS ルールを定期的に同期します。サービスにアクセスするとき、IPVS はサービスを選択する責任があります。サービスを提供するための実際のバックエンド。
IPVS モードも netfilter のフック関数 (INPUT ステージ) に基づいていますが、これは iptables モードと同じですが、保存されたデータ構造としてカーネル ワークスペースのハッシュ テーブルを使用します。このモードでは、iptables は ipset によって検証できます。リクエストはルールを満たしています。サービスが変更された場合、iptables のルール チェーンを変更せずに、ipset 内のレコードのみを更新する必要があるため、サービスの増加に伴って iptables 内のルールが増加することはなく、ウルトラ サービスの場合には一貫したパフォーマンスを提供することが保証されます。 -大規模サービスクラスターの効果。
ルールを同期するときのパフォーマンスも iptables よりも高いため (iptables モードでルール テーブル全体を操作するのではなく、特定のハッシュ テーブルのみが更新されます)、より高いネットワーク トラフィックを提供できます。
IPVS は、バックエンド サービスの選択において、より柔軟なアルゴリズムも提供します。
- rr: ラウンドロビン (ラウンドロビン アルゴリズム)
- lc: 最小接続 (最小接続数アルゴリズム)
- dh: 宛先ハッシュ (宛先アドレス ハッシュ アルゴリズム)
- sh: ソースハッシュ (独自のアドレスハッシュアルゴリズム)
- sed: 最短予想遅延 (最短予想遅延アルゴリズム)
- nq: ネバーキュー (ネバーキューアルゴリズム)
4. winuserspace: ユーザー空間と同じですが、Windows ノードでのみ動作します。
今日のシェアはこれで終わりです
