Added some pros/cons of NodePort vs LoadBalancer

Author: fhennig

modules/concepts/pages/service-exposition.adoc

@@ -33,7 +33,7 @@ The `cluster-internal` setting is the default class and, the Service is only exp
 
 External access is needed when a tool needs to be accessed from _outside_ of the Kubernetes cluster. This is necessary for all tools that are used by a user, such as the data visualization tool xref:superset:index.adoc[Apache Superset]. Some tools can expose APIs for data ingestion like xref:kafka:index.adoc[Apache Kafka] or xref:nifi:index.adoc[Apache NiFi]. If data needs to be ingested from outside of the cluster, one of the external listener classes should be chosen.
 
-When to use `stable` and when to use `unstable`? The `external-unstable` setting exposes a NodePort. This means that the service will be exposed at a port on the node that the Pod is running on. (TODO Advantages?) This has the advantage that .... but it the port is not known in advance and is also not stable: After a Pod restart, the port might change. The `external-stable` setting uses a LoadBalancer. The LoadBalancer is running at a fixed adress and is therefore `stable`. But ....
+When to use `stable` and when to use `unstable`? The `external-unstable` setting exposes a NodePort. This settings is always available, it means that the service will be exposed at a port on the node that the Pod is running on. This has the disadvantage that the port is not stable across service restarts, and depending on the cluster topology the service might also be scheduled on a different node, meaning that the IP is also changing. The `external-stable` setting uses a LoadBalancer. The LoadBalancer is running at a fixed adress and is therefore `stable`. Managed Kubernetes services in the cloud usually offer a LoadBalancer, but for an on premise cluster you have to configure a LoadBalancer yourself. For a production setup, it is recommended to use a LoadBalancer or `external-stable` ListenerClass.
 
 == Outlook