From 0a0e80b8d0dd45996805ce026760258d86343036 Mon Sep 17 00:00:00 2001 From: Niall Thomson Date: Mon, 15 Apr 2024 20:21:06 +0000 Subject: [PATCH] Fix precommit warning --- website/docs/fundamentals/exposing/loadbalancer/ip-mode.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/website/docs/fundamentals/exposing/loadbalancer/ip-mode.md b/website/docs/fundamentals/exposing/loadbalancer/ip-mode.md index 1cf6ab572..1b085f8fe 100644 --- a/website/docs/fundamentals/exposing/loadbalancer/ip-mode.md +++ b/website/docs/fundamentals/exposing/loadbalancer/ip-mode.md @@ -9,9 +9,9 @@ The AWS Load Balancer Controller also supports creating NLBs operating in "IP mo ![IP mode](./assets/ip-mode.png) -The previous diagram explains how application traffic flows differently when the target group mode is instance and IP. +The previous diagram explains how application traffic flows differently when the target group mode is instance and IP. -When the target group mode is instance, the traffic flows via a node port created for a service on each node. In this mode, `kube-proxy` routes the traffic to the pod running this service. The service pod could be running in a different node than the node that received the traffic from the load balancer. ServiceA (green) and ServiceB (pink) are configured to operate in "instance mode". +When the target group mode is instance, the traffic flows via a node port created for a service on each node. In this mode, `kube-proxy` routes the traffic to the pod running this service. The service pod could be running in a different node than the node that received the traffic from the load balancer. ServiceA (green) and ServiceB (pink) are configured to operate in "instance mode". Alternatively, when the target group mode is IP, the traffic flows directly to the service pods from the load balancer. In this mode, we bypass a network hop of `kube-proxy`. ServiceC (blue) is configured to operate in "IP mode".