Konnectivityサービスの概要
KubernetesにおけるKonnectivityサービスは、コントロールプレーン（APIサーバー）からクラスター（ノード）への通信を中継する プロキシサービス です。もともとKubernetesではSSHトンネルによってマスター⇔ノード間の通信を行っていましたが、KonnectivityはそのSSHトンネルを置き換える新しい仕組みとして導入されました (Communication between Nodes and the Control Plane | Kubernetes)。Konnectivityサービスはコントロールプレーン側で動作する「Konnectivityサーバー」と、各ノード側で動作する「Konnectivityエージェント」の2つのコンポーネントから構成されます (Communication between Nodes and the Control Plane | Kubernetes)。ノード上のエージェントがコントロールプレーン上のKonnectivityサーバーに対して接続を 確立・維持 し、この接続を通じてAPIサーバー→ノードへのあらゆる通信（例：kubectlポートフォワードやログ取得、exec実行などノード上のkubeletやPodと通信する操作）がトンネリングされます (Communication between Nodes and the Control Plane | Kubernetes)。エージェントが接続を開始することで、ファイアウォール環境下でもノードからマスターへの 一方向の発信 を利用し、結果として 双方向の通信路 を確保します。このようにKonnectivityはL4(TCP)レベルのプロキシとして機能し、コントロールプレーンとノード間の通信を間接化・安全化します (Communication between Nodes and the Control Plane | Kubernetes)。
APIサーバーとKonnectivityサーバー間のプロトコル
APIサーバー と Konnectivityサーバー の間の通信プロトコルとしては、Konnectivityサービスでは gRPC か HTTP CONNECT のいずれかが使用されます (Set up Konnectivity service | Kubernetes)。Kubernetes 1.32時点でもこの方針に変わりはなく、公式ドキュメントの設定例でも proxyProtocol に "GRPC"（gRPCモード）または "HTTPConnect"（HTTP CONNECTモード）を指定できると記載されています (Set up Konnectivity service | Kubernetes)。gRPCモードの場合、APIサーバーはKonnectivityサーバーに対してgRPC（HTTP/2ベース）のインターフェース経由で接続し、HTTP CONNECTモードの場合はHTTP/1.1のCONNECTメソッドを用いたトンネルとして通信します (What is the konnectivity service for Kubernetes? - Stack Overflow)。ユーザーから見た機能上の差異はなく、どちらのモードでもコントロールプレーンからノードへの通信を同様にプロキシできます (Set up Konnectivity service | Kubernetes)。Kubernetesの一般的なセットアップではデフォルトでgRPCモードが使われることが多く、Unixドメインソケット(UDS)を介してAPIサーバーとKonnectivityサーバー間を直接接続する構成が推奨されています (Set up Konnectivity service | Kubernetes)。UDSを利用することで同一マシン内で安全に通信でき、余分なTCPポートを開く必要がありません。TCP経由で接続する場合（例えば別ホスト上でKonnectivityサーバーを動かす場合など）は、TLSによる暗号化設定が必要とされています (Set up Konnectivity service | Kubernetes)。KonnectivityサーバーはAPIサーバーからの接続を待ち受ける「サーバーポート」を持ちます（UDS利用時はこのポートを使用しない構成も可能）。設定例ではUDSを使うために--server-port=0（無効化）とし、代わりにソケットファイル経由で接続しています (Set up Konnectivity service | Kubernetes)。
重要な点として、Konnectivityのこの通信経路ではWebSocketは使用されていません。 サポートされるプロトコルは上述のとおりgRPCまたはHTTP CONNECTのみであり (Set up Konnectivity service | Kubernetes)、WebSocketによるAPIサーバー⇔Konnectivityサーバー間トンネル機能は公式には提供されていません。実際、Kubernetes 1.31でkubectlによるログ・Execなどのストリーミング通信がSPDYプロトコルからWebSocketプロトコルに変更されましたが、それはkubectlとAPIサーバー間の通信についての変更です。Konnectivityサービス自体の内部実装には依然としてgRPC/HTTP CONNECTベースのトンネリングが使われており、WebSocketはKonnectivityの内部通信には関与しません (Set up Konnectivity service | Kubernetes)。
Konnectivityサーバーとエージェント間の通信
Konnectivityサーバーと各ノード上のKonnectivityエージェントとの間では、エージェント側からサーバーへの長寿命の接続が張られます (Communication between Nodes and the Control Plane | Kubernetes)。各エージェントは起動時にコントロールプレーン上のKonnectivityサーバー（通常はコントロールプレーンのURLもしくは内部サービスIP）に対して接続を確立し、この接続を維持します。Konnectivityサーバー側では複数エージェント（各ノード）からの接続を受け入れ、それぞれを通じて該当ノードへの通信経路を確保します。エージェント→サーバーの接続は双方向通信可能なトンネルとして機能し、APIサーバーからノード上のkubeletやPodへのリクエストは一旦Konnectivityサーバーに渡され、対応するエージェント経由で目的のノードに転送されます (Communication between Nodes and the Control Plane | Kubernetes)。逆方向の応答データも同じ経路を辿ってAPIサーバーに戻ります。このように一度確立されたトンネル上でコントロールプレーンとノード間の双方向通信が行われるため、**各エージェント接続はフルデュープレックス（二方向同時通信）**です。特にgRPCモードの場合、HTTP/2ストリームを用いて一つのTCPコネクション上で複数のリクエストを多重化して転送できます（HTTP CONNECTモードでも複数トンネルを扱えますが実装方法が異なります）。Konnectivityではエージェント接続が切れた場合に再接続するリトライ機能や、複数コネクションを張って冗長化するオプション（代理サーバーの負荷分散/フェイルオーバー設定）も提供されていますが、基本的な通信方式は常時接続のトンネルを用いる形です。
セキュリティとポート番号
Konnectivityエージェントとサーバー間の通信はセキュアなチャネル上で行われます。典型的には、Konnectivityサーバー側でクラスタCAによる証明書を用意し（例：system:konnectivity-serverというCNの証明書を発行）、エージェントはサービスアカウントTokenやクライアント証明書を用いて認証を行います。通信内容自体もTLS暗号化され、第三者に傍受されないようになっています (Set up Konnectivity service | Kubernetes)。KonnectivityサーバーはデフォルトでTCPポート8132でエージェントからの接続を受け付け、加えて8133番ポートに管理用インターフェース（Adminサーバー）、8134番ポートにヘルスチェック用インターフェースを持ちます (Set up Konnectivity service | Kubernetes)。これらのポート番号はKonnectivityの標準設定であり、必要に応じて変更可能ですが、Kubernetes公式のマニフェスト例でも8132/8133/8134が使用されています (Set up Konnectivity service | Kubernetes)。一方、APIサーバーとKonnectivityサーバー間は前述の通り同一マシン上ならUDS経由、それ以外の場合は適宜設定したポート（例：Konnectivityサーバーの--server-portで指定）で通信します。Konnectivity導入時にはこれらポートへのアクセスが適切に許可されている必要があります（コントロールプレーンが外部からエージェント接続を受け入れる場合は8132を開放、内部接続のみならUDS利用など）。
まとめ
以上より、Kubernetes 1.32におけるKonnectivityの通信方式は以下の通りです：
- プロトコル: APIサーバーとKonnectivityサーバー間は gRPC (HTTP/2) または HTTP CONNECT プロトコルを使用します (Set up Konnectivity service | Kubernetes)。Konnectivityエージェントとサーバー間も同様にこれらプロトコル上でトンネリングを行います（gRPCモードが一般的）。
- WebSocketの不使用: Konnectivityでは WebSocketは利用しません (Set up Konnectivity service | Kubernetes)。サポートされる通信はgRPC/HTTP CONNECTに限定されており、kubectlストリーミング等で使用されるWebSocketはKonnectivity内部には登場しません。
- 接続方式: ノード側のエージェントがコントロールプレーン側のKonnectivityサーバーに対してアウトバウンド接続を確立し、その単一のコネクションを通じて双方向の通信（コントロールプレーン→ノードおよびノード→コントロールプレーン）を行います (Communication between Nodes and the Control Plane | Kubernetes)。この接続は長時間維持され、必要に応じて再接続や複数確立も行われます。
- TLSセキュリティ: Konnectivityの通信は基本的にTLSで保護されています。特にTCP上でAPIサーバー↔Konnectivityサーバーを接続する場合や、ノード↔サーバー間接続には証明書やトークンによる認証とTLS暗号化が適用されます (Set up Konnectivity service | Kubernetes)。
- 使用ポート: デフォルトではKonnectivityサーバーは 8132/TCP でエージェント接続を待ち受けます（管理用に8133、ヘルスチェックに8134も使用） (Set up Konnectivity service | Kubernetes)。APIサーバーとの間は同一ホストならUDS、それ以外では適宜設定されたポート（例: 8132や任意のポート）で接続します。
以上のように、Kubernetes 1.32環境におけるKonnectivityはgRPCまたはHTTP CONNECTベースのトンネルによって実装されており、WebSocketは使用されていないことが確認できます。これにより、安全で効率的なコントロールプレーン↔ノード間の通信チャネルが提供されています。 (Set up Konnectivity service | Kubernetes) (Communication between Nodes and the Control Plane | Kubernetes)