In traditional pre-Kubernetes operations, a common pattern (and this one is highly recommended by AWS) is to have separate subnets, one for public facing web services, and a more secure private subnet for the database, like the highly performant distributed HA database Dgraph. In this scenario, only specific clients are allowed to access the cluster, while everything else is blocked.
So how can you do something like this for Kubernetes?
Answer: Network Policies.
So I endeavored to tinker with this, using my free eval Azure account, and wrote this:
Though this is for Azure, as long as you have a K8S cluster with Calico installed and a handy KUBECONFIG that allows for deploying things, most of the content is the same. The specifics on the particular network plugin, such as Azure CNI, may differ, but this understanding, though useful in designing overall topology, is not required to go through the mechanics network policies usage with Dgraph.