feat: add support for externalDNS in sdk

[denis-tingaikin]

Description

Issue link

https://github.com/networkservicemesh/deployments-k8s/issues/5435

How Has This Been Tested?

• [X] Added unit testing to cover
• [X] Tested manually
• [X] Tested by integration testing
• [ ] Have not tested

Types of changes

• [ ] Bug fix
• [X] New functionality
• [ ] Documentation
• [X] Refactoring
• [ ] CI

[codecov[bot]]

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@a8c394e). Click here to learn what that means. Patch has no changes to coverable lines.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1473   +/-   ##
=======================================
  Coverage        ?   70.43%           
=======================================
  Files           ?      248           
  Lines           ?    11185           
  Branches        ?        0           
=======================================
  Hits            ?     7878           
  Misses          ?     2806           
  Partials        ?      501           

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

[edwarnicke]

Am I reading this correctly that this PR is making it possible to set the resolver options to be able to test in sandbox?

Do we anticipate these changes being used for non-testing cases?

[denis-tingaikin]

@edwarnicke The resolver options will be used in registry-proxy-dns to work with externalDNS.

Currently, registry-proxy-dns could work only with k8s cluster DNS.

For example, we're supporting discovery in format cluster-name.k8s-service-name. Where service name is fixed and now its registry and nsmgr-proxy.

With those options we also will support discovery in format any-domain.any-service-name.

[edwarnicke]

OK... I'm a little confused. registry-proxy-dns should be looking up an SRV record via DNS for whatever the domain is. If he network service registry domain is @finance.example.com, it should be looking up:

_nsm_registry._tcp.finance.example.com. 86400 IN SRV 10 5 5223 server.example.com.

(I've forgotten what the string we use for that last part is, but it should be something to indicate that our service is he nsm registry for that registry domain).

So long as the K8s DNS delegates to global DNS, we shouldn't need to point to any other DNS. We should be using the same SRV record pattern to find a registry server no matter where things are running.

[denis-tingaikin]

@edwarnicke It could be diffecult for users whos use externalDNS to make the same scheme as we have with Coredns + k8s_external plugin

At this moment we're working fine with entries

_nsm_registry._tcp.finance.example.com. 86400 IN SRV 10 5 5223 server.example.com.

But what if registry service has another name?

_**my**_nsm_registry._tcp.finance.example.com. 86400 IN SRV 10 5 5223 server.example.com.

The patch in this PR allows to configure services that we're looking

[edwarnicke]

That's the point of an SRV record, the

_nsm_registry._tcp is intended to be a common 'name' for the kind of service. For example, for the SIP protocol the SIP server for a domain is done by looking up the _sip._tcp subdomain of a given domain. So you can always find the SIP server for example.com by looking for:

_sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com.

If you can set the SRV record in finance.example.com for

_**my**_nsm_registry._tcp.finance.example.com. 86400 IN SRV 10 5 5223 server.example.com.

I would expect you would be able to set the SRV record in finance.example.com for:

_nsm_registry._tcp.finance.example.com. 86400 IN SRV 10 5 5223 server.example.com.

If there's an existing _nsm_registry for the finance.example.com domain, and you want a different one, the right solution is to create a subdomain my.finance.example.com and create an SRV record for it:

_nsm_registry._tcp.my.finance.example.com. 86400 IN SRV 10 5 5223 otherserver.example.com.

All of that said... I don't understand what this has to do with external DNS... the "_nsm_registry" part should be the same whether we are running in the cluster or not.

Am I missing something?