Automatic K8s pod placement to match external service zones

Summary

Automatic zone placement service Overview In Kubernetes, it is not possible to schedule Pods for optimal network performance when Pods use resources outside of the cluster. This project offers a solution by making Kubernetes-aware of network topology outside the cluster. A lightweight lookup service provides an endpoint to resolve an external resource's domain name to an IP address and maps it to a known network zone (like an AWS Availability Zone). This data is used with a mutating webhook to inject node affinity rules into Pods at creation time. This ensures Pods are scheduled in the same zone as the external resources they depend on, optimizing for low-latency communication. The mechanism is generic and works for any external resource, on-prem or in the cloud, as long as its FQDN resolves to a single IP in a known subnet. This approach can yield significant performance improvements; a simple pgbench benchmark demonstrates a ~175% to ~375% improvement in TPS. Any workload that is latency-sensitive can benefit from this. Note: This is not a fix for placing related workloads running in the same cluster relatively near each other. That is a problem already solved in Kubernetes with affinity rules and smart use of label selectors. The Problem The basic problem is that the scheduler in Kubernetes is unaware of the network topology it is running on, so node assignment stays random. For instance, assume your RDS Writer Instance is running in AZ C, Kubernetes is not able to determine that it should (ideally) schedule your SQL client Pod in AZ C: --- config: layout: fixed --- flowchart TD subgraph subGraph0["Kubernetes Control Plane"] K8sAPI["K8s API Server"] end subgraph subGraph1["Availability Zone a"] Pod["SQL Client Pod I should be in zone C 🙁"] NodeA["K8s Node"] end subgraph subGraph2["Availability Zone b"] NodeB["K8s Node"] end subgraph subGraph3["Availability Zone c"] RDS[("RDS Writer Instance")] NodeC["K8s Node"] end subgraph subGraph4["AWS Region (eu-central-1)"] ...