As a Cloud Solution Architect for Microsoft, I'm privileged to work with some great companies which have unique challenges.
One of our large partners was migrating their solution from AWS to Azure. Their configuration exposes 10+ services inside Azure Kubernetes Service (AKS) to their customer inside a different Azure Tenant and Subscription through Private Link Service and Private Endpoints.
The issue is that at this time is:
A single AKS cluster can only have 1 Internal Standard Load Balancer
This means that they could expose 8 services, but not the rest of them.
Unfortunately, the feature to enable Multiple LB's is not currently available in AKS.
After talking to other AKS experts, we proposed the following:
- Use 1 PLS
- Use 1 LB
-
Specify the SAME IP ADDRESS as part of
spec.loadBalancerIPin the Service YAML and use different ports for each service
This allowed them to reduce the number of Private Endpoints, reduce their operational complexity as well as use Kubernetes native Port Mapping with minimal architectural change.
We reviewed this with the partner and after some Helm chart + Terraform work, this met their needs swimmingly.
Mission Accomplished.
Top comments (1)
We have deployed Postgres instances for customers in Kubernetes in individual namespaces. Some of our customers want to access these from their own Azure tenants, which are not administered by us. For this, we thought of providing a Kubernetes-internal load balancer with a private links service, to which the customer was offered a private endpoint in their Azure environment.
This is working in a test environment with two test customers so far, but currently, customers could establish a network connection to both PostgreSQL instances because they are connected via the same private link service. Since the source IP address of the load balancer arrives in the Kubernetes cluster, it is difficult to define network rules for this.
Can we somehow distinguish the incoming connections so that we can create network rules to grant customers access only to their own Postgres instance?
Right now, we´re stuck with either having very limited scaling capacity (8 PrivateLinks) or limited security (segregation only via port assignment)