kube-proxyプロキシモードでのユーザースペースモードとはどういう意味ですか？
kube-proxyには--proxy-modeというオプションがあり、ヘルプメッセージによると、このオプションはserspaceまたはiptablesになります。（以下を参照）
# kube-proxy -h
Usage of kube-proxy:
...
--proxy-mode="": Which proxy mode to use: 'userspace' (older, stable) or 'iptables' (experimental). If blank, look at the Node object on the Kubernetes API and respect the 'net.experimental.kubernetes.io/proxy-mode' annotation if provided. Otherwise use the best-available proxy (currently userspace, but may change in future versions). If the iptables proxy is selected, regardless of how, but the system's kernel or iptables versions are insufficient, this always falls back to the userspace proxy.
...
serspaceモードがここで何を意味するのか理解できません。
Kube-proxyがserspaceモードで実行される場合の動作原理は誰でも教えてくれますか？
ユーザースペースとiptablesは、接続転送を実際に処理するものを指します。どちらの場合も、ローカルiptablesルールがインストールされ、サービスに関連付けられた宛先IPアドレスを持つアウトバウンドTCP接続をインターセプトします。
ユーザースペースモードでは、iptablesルールはgoバイナリ（kube-proxy）が接続をリッスンしているローカルポートに転送します。バイナリ（ユーザースペースで実行）は接続を終了し、サービスのバックエンドへの新しい接続を確立してから、要求をバックエンドに転送し、応答をローカルプロセスに戻します。ユーザースペースモードの利点は、接続がアプリケーションから作成されるため、接続が拒否された場合、アプリケーションが別のバックエンドに再試行できることです。
Iptablesモードでは、iptablesルールがインストールされ、サービス宛てのパケットをサービスのバックエンドに直接転送します。これは、パケットをカーネルからkube-proxyに移動してからカーネルに戻すよりも効率的であるため、スループットが向上し、テールレイテンシが向上します。主な欠点は、ログを/var/log/kube-proxyに書き込むローカルバイナリの代わりに、カーネル処理iptablesルールからログを検査する必要があるため、デバッグがより困難になることです。
どちらの場合も、マシン上でkube-proxyバイナリが実行されます。ユーザースペースモードでは、プロキシとして自分自身を挿入します。 iptablesモードでは、接続自体をプロキシするのではなく、iptablesを構成します。同じバイナリが両方のモードで機能し、動作はフラグを介して、またはノードのapiserverに注釈を設定することによって切り替えられます。