The k8s docs aren't very clear what happens with routing when using the different service types, leading me to a series of questions:
To help the question, assume the following cluster setup:
N_a, N_b, N_cS_1P_x1, P_x2 that are part of the service S_1P_x1 is running on N_aP_x2 is running on N_b1) When using a NodePort for S_1 using port x, do ALL nodes in a cluster make the service available on port x? OR do ONLY the nodes running the pods that make up the service make the service available on port x? So in both scenarios, N_a and N_b will make S_1 available on port x, but can I hit N_c on port x?
2) Using NodePort for S_1 still, if I hit N_a on port x, will I only be routed to P_x1 (e.g., the pods for that service running locally on the Node), or may I be routed to P_x2, so off the Node and over the network again?
3) If I run S_1 as a LoadBalanced service, will the load-balancer provisioned only route requests to N_a and N_b? With those requests when hitting N_a and N_b only being routed to pods P_x1 and P_x2 respectively? So one hop over the network, or will it talk to all three nodes and rely on them each doing a second level of routing/load-balancing? (Which seems quite inefficient).
4) Does the Ingress controller function any differently for routing (other than being L7 rather than L4) than a LoadBalanced service?
1) Yes. NodePort opens a port on all worker nodes. When you create a Service, an iptables rule is created on all worker nodes. When a pod on any node accesses this Service's IP, the iptables rule on the physical node where the pod resides will redirect its packets accordingly.
2) Both. A Service does WRR load-balancing across all the associated pods.
3) I do bare-metal deployments so I can't answer this qn.
4) Afaik, Ingress is a replacement to the LoadBalancer. Instead of depending on the cloud provider's reverse proxy, you deploy your own Ingress that runs in the k8s cluster.