search

gbif / stackable

GBIF Stackable Infrastructure
Apache License 2.0
4 stars 0 forks source link

Look into posibility for utilizing the internal DNS to allow access to infrastructure components #27

Open zaultooz opened 6 months ago

zaultooz commented 6 months ago

Currently every auto generated address used throughout the cluster is manual manage on the vms outside the cluster. It would be more suitable to at least use Kubernetes own DNS if possible to resolve the IPs.

If this doesn't work, it could be needed with gateway or reserves proxy to for allowing automatic configuration of routes and updates to routes in case stuff is moved around within the cluster.

zaultooz commented 6 months ago

Remember to clean up the hack currently used to resolve addresses on ws, apicache, cli and in dev2 and builds

MattBlissett commented 2 months ago

This was done with configuration in unbound on the local DNS servers:

/etc/unbound/conf.d/cluster.local.conf
# An override of the "public DNS tree" with an "internal view" override.
#
# The stub-zone/stub-addr must point to AUTHORITATIVE servers. If you want to
# point to an internal RECURSIVE server, use forward-zone/forward-addr instead.

stub-zone:
        name: cluster.local
        stub-prime: no
        stub-addr: 130.225.43.217

server:
        domain-insecure: cluster.local

I think the DNS service should be exposed on an additional machine, in case one fails.

And then overrides on the servers needing this, the search part:

/etc/netplan/50-cloud-init.yaml
network:
    version: 2
    ethernets:
        ens2:
            addresses:
            - 130.225.43.204/24
            nameservers:
                addresses:
                - 130.225.43.61
                - 130.225.43.222
                search:
                - .
                - ~cluster.local
            routes:
            -   to: default
                via: 130.225.43.1

If the cluster domain didn't end .local this override wouldn't be needed, .local is a reserved domain and a poor default choice from Kubernetes. I suggest a subdomain of the GBIF environment domains (gbif.org etc) or a subdomain of gbif.net if this will span all environments. (Then we can add NS records and also avoid the custom configuration in unbound.)

zaultooz commented 2 months ago

After this issue: https://github.com/stackabletech/issues/issues/436 is resolved, we would be able to move the cluster to another domain like gbif.org or gbif.net rather than the default cluster.local