<p>Does <code>LoadBalancer</code> use <code>kube-proxy</code> as mentioned <a href="https://gardener.cloud/050-tutorials/content/howto/service-access/" rel="nofollow noreferrer">in this article</a> or is it using <code>NodePort</code> as mentioned <a href="https://rancher.com/blog/2018/2018-06-08-load-balancing-user-apps-with-rancher/" rel="nofollow noreferrer">here</a>?</p>

<p>If it's in fact using <code>NodePort</code>, then why are multiple sources such as <a href="https://metallb.universe.tf/" rel="nofollow noreferrer">MetalLB</a> claiming that using <code>NodePort</code> in production is not a good idea?</p>

<p><code>Ingress</code> also operates using <code>NodePort + nginx</code>. What's so special about <code>LoadBalancer</code> then?</p>

<p>It depends on the cloud provider implementation:</p>

<blockquote>
  <p>Traffic from the external load balancer will be directed at the
  backend Pods, though exactly how that works depends on the cloud
  provider.</p>
</blockquote>

<p><a href="https://kubernetes.io/docs/concepts/services-networking/#loadbalancer" rel="nofollow noreferrer">https://kubernetes.io/docs/concepts/services-networking/#loadbalancer</a></p>

<p>In case of Google Kubernetes Engine (GKE), <a href="https://cloud.google.com/kubernetes-engine/docs/concepts/network-overview#ext-lb-details" rel="nofollow noreferrer">this is how it works</a>:</p>

<blockquote>
  <p>When using the external load balancer, arriving traffic is initially
  routed to a node using a forwarding rule associated with the GCP
  network. After the traffic reaches the node, the node uses its
  iptables NAT table to choose a Pod. kube-proxy manages the iptables
  rules on the node.</p>
</blockquote>
