Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2022-12-15T05:25:51.620Z
Answers: I can't literally think of any reason why load balancing to a single IP is a good idea in production.
Answers: Chris Becke
Answers: CC BY-SA 4.0
Answers: 2022-12-08T07:43:11.077Z
Answers: 2022-12-08T07:43:11.077Z
Answers: Ali
Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2022-12-15T04:57:18.840Z
Answers: 2022-12-15T04:57:18.840Z
Answers: benjimin
Body: <p>In Kubernetes, is there any general reason to avoid NodePort services? In what particular circumstances are NodePorts appropriate?</p>
  
Tags: <kubernetes>
Title: Why is NodePort discouraged?
UserDisplayName: benjimin
ThreadText: # 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
  
  ```yaml
  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](https://github.com/alifiroozi80/CKA/tree/main/CKA#make-application-accessible-from-outside-the-cluster)
  * [Create Loadbalancer](https://github.com/alifiroozi80/CKA/tree/main/CKA#create-loadbalancer)
  * [Setup ingress](https://github.com/alifiroozi80/CKA/tree/main/CKA#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.
  
  
  ---
  
  