Mixing non-cluster components

Most real-time system components in the Kubernetes cluster will communicate with out-of-cluster components. These could be completely external third-party services which are accessible through some API, but could also be internal services running in the same local network that, for various reasons, are not part of the Kubernetes cluster.

There are two categories here: inside-the-cluster-network and outside-the-cluster-network. Why is the distinction important?

Outside-the-cluster-network components

These components have no direct access to the cluster. They can only access it through APIs, externally visible URLs, and exposed services. These components are treated just like any external user. Often, cluster components will just use external services, which pose no security issue. For example, in my previous job we had a Kubernetes cluster that reported exceptions to a third-party service (https://sentry.io/welcome/). It was one-way communication from the Kubernetes...