Update modules/concepts/pages/service-exposition.adoc

Co-authored-by: Razvan-Daniel Mihai <84674+razvan@users.noreply.github.com>

Author: fhennig

modules/concepts/pages/service-exposition.adoc

@@ -31,7 +31,7 @@ There are three options, one for internal traffic and two for external access, w
 
 === External
 
-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.
+External access is needed when a product needs to be accessed from _outside_ of Kubernetes. This is necessary for all end user products such as 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 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.