<p>First, let's review quickly what is <code>NodePort</code> service.</p>
<h3>What is NodePort? How does it work?</h3>
<ul>
<li><strong>Internal Service</strong> accessible on <code>Service IP address + Port</code></li>
<li>NodePort also creates ClusterIP internal Service</li>
<li>NodePort, Opens Port on <strong>each Worker Node</strong></li>
<li>External traffic has access to a fixed port on each Worker Node!
Range: <code>30000-32676</code></li>
</ul>
<p>NodePort Service Accessibility:</p>
<ul>
<li>NodePort accessible from outside the cluster</li>
<li>On IP address of <code>Node IP + The NodePort</code></li>
<li>NodePort accessible from outside the cluster</li>
</ul>
<hr />
<p>Well, it is an excellent choice for testing purposes.</p>
<p>But in production is not a good choice.</p>
<p>Why?</p>
<p>Because you should type each worker node IP with the corresponding NodePort.</p>
<p>InProduction, we want only 1 Ip that automatically LoadBalance between each worker Node.</p>
<p>So, let's quickly review the <code>LoadBalancer</code> type.</p>
<h3>Why LoadBalancer?</h3>
<p>At this point, our application is accessible from the outside, but it has a couple of downgrades:</p>
<ul>
<li>Not user-friendly (<code>Node IP:NodePort</code>)</li>
<li>Insecure &amp; messy!</li>
<li>is it OK to test</li>
<li>Better Alternative: LoadBalancer Service Type</li>
</ul>
<pre class="lang-yaml prettyprint-override"><code>apiVersion: v1
kind: Service
metadata:
  name: nginx-service
  labels:
    app: nginx
    svc: nginx-test
spec:
  type: LoadBalancer # The configuration of Loadbalancer is exactly like NodePort except for this part...
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 80
      nodePort: 30000 # Notice we still have a nodePort!
</code></pre>
<h4>How LoadBalancer works?</h4>
<ul>
<li>LoadBalancer outside of K8s cluster</li>
<li>Which accepts traffic as an entry point</li>
<li><strong>LoadBalances to 1 of Worker Node on the NodePort</strong></li>
<li>Then gets forward to ClusterIP</li>
<li>Accessible at own IP address &amp; port</li>
<li>LoadBalancer is not created inside the cluster</li>
</ul>
<hr />
<p>Okay, so we learned that LoadBalancer is a better alternative in production.</p>
<p>But, still, it is not the Best practice and the best solution in <strong>Production</strong>.</p>
<p>The Best Practice in the Production environment is the <code>Ingress</code> type.</p>
<hr />
<h3>Why Ingress?</h3>
<ul>
<li><p>Self-Managed K8s cluster: Create LoadBalancer yourself</p>
</li>
<li><p>Managed K8s cluster: Creates LoadBalancers automatically</p>
</li>
<li><p>Loadbalancer Disadvantages:</p>
<ul>
<li>LoadbBlancer that all become entry points</li>
<li>Configure the Domain Name</li>
<li>Each LoadBalancer exposes new NodePort</li>
<li>Each Loadbalancer increases the cloud bill</li>
<li>Configure everything outside the cluster</li>
</ul>
</li>
<li><p>Isn't it good:</p>
<ul>
<li>Having this as part of the K8s cluster?</li>
<li>Configure secure connection</li>
<li>LoadBalancing to different services</li>
</ul>
</li>
</ul>
<h4>Ingress</h4>
<ul>
<li>A K8s component</li>
<li>Configure <code>Routing</code></li>
<li>Configure <code>HTTPS</code></li>
<li>Ingress is deployed and available inside the cluster</li>
<li>We need to expose it either as NodePort or LoadBalancer</li>
<li>1 NodePort or LoadBalancer, which is the single entry point</li>
</ul>
<hr />
<h3>Summary</h3>
<ul>
<li><code>ClusterIP</code>: <code>Internal</code> Access</li>
<li><code>NodePort</code>: <code>External</code> Access / Testing</li>
<li><code>LoadBalancer</code>: <code>External</code> Access / Production</li>
<li><code>Ingress</code>: <code>External</code> Access / Production / Best Practice</li>
</ul>
<hr />
<p>Be sure to check these resources as well:</p>
<ul>
<li><a href="https://github.com/alifiroozi80/CKA/tree/main/CKA#make-application-accessible-from-outside-the-cluster" rel="nofollow noreferrer">Make application accessible from outside the cluster</a></li>
<li><a href="https://github.com/alifiroozi80/CKA/tree/main/CKA#create-loadbalancer" rel="nofollow noreferrer">Create Loadbalancer</a></li>
<li><a href="https://github.com/alifiroozi80/CKA/tree/main/CKA#setup-ingress" rel="nofollow noreferrer">Setup ingress</a></li>
</ul>

CC BY-SA 4.0
2022-12-15T05:25:51.620Z
I can't literally think of any reason why load balancing to a single IP is a good idea in production.
Chris Becke
CC BY-SA 4.0
2022-12-08T07:43:11.077Z
2022-12-08T07:43:11.077Z
Ali
<p>NodePorts are discouraged by sources such as <a href="https://oteemo.com/think-nodeport-kubernetes/" rel="nofollow noreferrer">this article</a>.</p>
<p>Some problems:</p>
<ul>
<li>Nonstandard port numbers get assigned to services. These are undesirable to use, due to lack of human readability and potential to be blocked by firewalls/gateways.</li>
<li>Services may clobber each other. (For example, if a service gets randomly assigned a port number that another service was going to request.)</li>
<li>Security may be more difficult to verify, with direct external traffic to many nodes (and ports).</li>
<li>DNS may behave poorly (hostnames of different services may be synonymous, and address record sets may become too large to fit in UDP query responses).</li>
</ul>
<p>Situations where NodePort is still justified:</p>
<ul>
<li><p>With a gateway (such as a load balancer) that translates automatically between external hostnames and internal port numbers.</p>
</li>
<li><p>For temporary testing, although <code>kubectl port-forward</code> is preferred where possible.</p>
</li>
</ul>

CC BY-SA 4.0
2022-12-15T04:57:18.840Z
2022-12-15T04:57:18.840Z
benjimin
<p>In Kubernetes, is there any general reason to avoid NodePort services? In what particular circumstances are NodePorts appropriate?</p>

<kubernetes>
Why is NodePort discouraged?
benjimin
# Why is NodePort discouraged?

(Asked by: username_0 on 2022-12-08)

In Kubernetes, is there any general reason to avoid NodePort services? In what particular circumstances are NodePorts appropriate?

**Tags:** kubernetes


---

## 2 answers

### Answer by username_1 on 2022-12-08. Score: 2

First, let's review quickly what is NodePort service.
What is NodePort? How does it work?

Internal Service accessible on Service IP address + Port
NodePort also creates ClusterIP internal Service
NodePort, Opens Port on each Worker Node
External traffic has access to a fixed port on each Worker Node!
Range: 30000-32676

NodePort Service Accessibility:

NodePort accessible from outside the cluster
On IP address of Node IP + The NodePort
NodePort accessible from outside the cluster


Well, it is an excellent choice for testing purposes.
But in production is not a good choice.
Why?
Because you should type each worker node IP with the corresponding NodePort.
InProduction, we want only 1 Ip that automatically LoadBalance between each worker Node.
So, let's quickly review the LoadBalancer type.
Why LoadBalancer?
At this point, our application is accessible from the outside, but it has a couple of downgrades:

Not user-friendly (Node IP:NodePort)
Insecure & messy!
is it OK to test
Better Alternative: LoadBalancer Service Type

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
  labels:
    app: nginx
    svc: nginx-test
spec:
  type: LoadBalancer # The configuration of Loadbalancer is exactly like NodePort except for this part...
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 80
      nodePort: 30000 # Notice we still have a nodePort!

How LoadBalancer works?

LoadBalancer outside of K8s cluster
Which accepts traffic as an entry point
LoadBalances to 1 of Worker Node on the NodePort
Then gets forward to ClusterIP
Accessible at own IP address & port
LoadBalancer is not created inside the cluster


Okay, so we learned that LoadBalancer is a better alternative in production.
But, still, it is not the Best practice and the best solution in Production.
The Best Practice in the Production environment is the Ingress type.

Why Ingress?

Self-Managed K8s cluster: Create LoadBalancer yourself

Managed K8s cluster: Creates LoadBalancers automatically

Loadbalancer Disadvantages:

LoadbBlancer that all become entry points
Configure the Domain Name
Each LoadBalancer exposes new NodePort
Each Loadbalancer increases the cloud bill
Configure everything outside the cluster


Isn't it good:

Having this as part of the K8s cluster?
Configure secure connection
LoadBalancing to different services



Ingress

A K8s component
Configure Routing
Configure HTTPS
Ingress is deployed and available inside the cluster
We need to expose it either as NodePort or LoadBalancer
1 NodePort or LoadBalancer, which is the single entry point


Summary

ClusterIP: Internal Access
NodePort: External Access / Testing
LoadBalancer: External Access / Production
Ingress: External Access / Production / Best Practice


Be sure to check these resources as well:

Make application accessible from outside the cluster
Create Loadbalancer
Setup ingress

> **Comments:**
> **username_2**: I can't literally think of any reason why load balancing to a single IP is a good idea in production.  

---

### Answer by username_0 on 2022-12-15. Score: 0

NodePorts are discouraged by sources such as [this article](https://oteemo.com/think-nodeport-kubernetes/).

Some problems:

* Nonstandard port numbers get assigned to services. These are undesirable to use, due to lack of human readability and potential to be blocked by firewalls/gateways.
* Services may clobber each other. (For example, if a service gets randomly assigned a port number that another service was going to request.)
* Security may be more difficult to verify, with direct external traffic to many nodes (and ports).
* DNS may behave poorly (hostnames of different services may be synonymous, and address record sets may become too large to fit in UDP query responses).

Situations where NodePort is still justified:

* With a gateway (such as a load balancer) that translates automatically between external hostnames and internal port numbers.
* For temporary testing, although `kubectl port-forward` is preferred where possible.


---

