<p>I'm wanting to create a service that can do some kind of dynamic proxying back to Kubernetes Pods. Basically I'll have hundreds of K8s Pods that are running the same application that map to a random port on the host (like <code>10456</code>). However, each Pod is unique and I want traffic directed at a specific pod based on hostname. So when a request comes in for <code>abc123.app.com</code>, I'll have a proxy layer that does a lookup in a database to find what host and port that domain is running on (like <code>10.0.0.5:10456</code>), then forward the request there. Is there a service that supports this? I've worked with Nginx a lot before, but I'm not clear if it could support this lookup functionality.</p>

<p>Has anyone built something like this before? what's the best way to build a proxy layer that can do lookups like that? How would I update the database when a pod moves from one host to another?</p>

<p>Thanks in advance!</p>

<p>EDIT:</p>

<p>I should have put this in there the first time, but the types of traffic going to these pods are RPC traffic and Peer to Peer traffic</p>

gkrizek
<p>You're describing something very similar to what kubernetes <a href="https://kubernetes.io/docs/concepts/services-networking/ingress/" rel="nofollow noreferrer">ingress</a> definitions do for http traffic. </p>

<p>An ingress definition configures an <a href="https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/" rel="nofollow noreferrer">ingress controller</a> to point requests for a hostname at a <a href="https://kubernetes.io/docs/concepts/services-networking/service/" rel="nofollow noreferrer">service</a>. The <a href="https://kubernetes.io/docs/concepts/services-networking/service/" rel="nofollow noreferrer">service</a> selects endpoints (pods) via <a href="https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/" rel="nofollow noreferrer">label selectors</a>. When pods move, kubernetes updates the service automatically. </p>

<p>The work on your end just becomes pushing out config changes from your database via one of the <a href="https://kubernetes.io/docs/reference/using-api/client-libraries/" rel="nofollow noreferrer">API clients</a> to kubernetes rather than directing a proxy. If your environment was extremely dynamic requiring reconfiguration all the time or you need to make dynamic decisions about where traffic should go, you might want to continue looking at a custom proxy or <a href="https://istio.io/docs/tasks/traffic-management/request-routing/" rel="nofollow noreferrer">istio</a>, <a href="https://openresty.org/en/dynamic-routing-based-on-redis.html" rel="nofollow noreferrer">openresty</a>.</p>

<p>It sounds like you have unique deployments going to kubernetes already, so in addition to that include a service and ingress definition. </p>

<p>A simple example including a label on the a pod, a service that use the label. Then an ingress definition using the service. </p>

<pre><code>apiVersion: v1
kind: Pod
metadata:
  name: my-app
  labels:
    app: host-abc123
spec:
  containers:
  - name: host-abc123
    image: me/my-app:1.2.1
    ports:
    - containerPort: 10456
</code></pre>

<pre><code>apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: host-abc123
spec:
  rules:
  - host: abc123.bar.com
    http:
      paths:
      - backend:
          serviceName: host-abc123
          servicePort: 80
</code></pre>

<pre><code>apiVersion: v1
kind: Service
metadata:
  name: host-abc123
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 10456
</code></pre>

<p>The single ingress definition could include all hosts but I'm not sure how kubernetes and the ingress controllers would go replacing that regularly.</p>

<p>There are <a href="https://kubernetes.github.io/ingress-nginx/deploy/" rel="nofollow noreferrer">nginx</a> based ingress controllers too. You end up with a nginx <code>server</code> config per ingress/host definition.</p>
