Is there an easy way to add all private endpoint host entries to host aliases in values.yaml file for kubernetes deployment?

Question

I know entries from hosts file can be added to pods like below

apiVersion: v1
kind: Pod
metadata:
  name: hostaliases-pod
spec:
  restartPolicy: Never
  hostAliases:
  - ip: "127.0.0.1"
    hostnames:
    - "foo.local"
    - "bar.local"
  - ip: "10.1.2.3"
    hostnames:
    - "foo.remote"
    - "bar.remote"

But I have around 900 IPs in my hosts file and need to add all of them to my values.yaml file.

Is there an easy way to add these to values.yaml without having to manually format each and every one of them like in the below format?

hostAliases:
  - ip: "127.0.0.1"
    hostnames:
    - "foo.local"
    - "bar.local"
  - ip: "10.1.2.3"
    hostnames:
    - "foo.remote"
    - "bar.remote"

Answer 1

Have you considered creating some Service(s), pointing to that list of IPs? Might be easier to deal with, depending on the volume of containers you have to manage ...

Something like this:

---
apiVersion: v1
kind: Endpoints
metadata:
  name: stuff-outside-of-sdn
  namespace: default
subsets:
- addresses:
  - ip: 10.0.0.1
  - ip: 10.0.0.2
  - ip: 10.0.0.3
  - ip: 10.0.0.N
  ports:
  - name: something
    port: 8080
    protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
  name: stuff-outside-of-sdn
  namespace: default
spec:
  ports:
  - name: something
    port: 8080
    protocol: TCP
    targetPort: 8080

Now, containers running in your cluster can resolve "stuff-outside-of-sdn.default.svc.local", pointing them to addresses we've defined in that Endpoints. Changing some IPs in those endpoints don't require restarting all containers / getting rid of hostAliases.

When we don't set a spec.selector to a Service, kubernetes controllers won't change endpoints, we can do pretty much anything.

Keeping in mind those Services would affect resolution for all containers in your cluster, which may not be what you wanted.

Another take on it might be to just setup some DNS server. Which again, would affect resolution for all clients. While may be easier to maintain, depending on who's administering this, ... good old DNS zones could make more sense, less constraints, allows to use a base domain distinct from k8s cluster.

... And if you need those resolution exception to be unique from deployment to deployment ... Then, the solution you have is pretty much all you can do. While obviously suffers from scaling issues. At which point, we might question: why such a workaround, any chance/how could we get rid of this?