This section covers the design for how external DNS are updated.

The following sequence diagram illustrates the approach:


Elements of the DNS update design

external-dns-agent

This is deployed as part of the Edge Cluster.  Essentially, it is an instance of external-dns configures with istio-gateway as the source and uses a DNS CRD as the provider (i.e. detected DNS records are just saved as a CRD).  h

DNS CR

The DNS CRD can be based on the examples here:  https://github.com/kubernetes-sigs/external-dns/tree/master/docs/contributing/crd-source

The above can already be used as a DNS source for exteranal-dns.  The new work here is to make an external-dns provider that saves these CRD.

DNS Provider Intent

The intents for the distributed application provide DNS Provider information.

  • Cluster ID
  • Project ID
  • DNS Provider Type (e.g. coredns, aws route 53, ...)
  • DNS Provider locatoin (e.g. IP, hostname)
  • DNS Provider credentials (e.g. username, pw, TLS credentials)
  • DNS Provider other parameters (maybe provider specific)

Question:  Is the DNS Provider information really an Intent ? which is associated with resource bundle, or is it a set of information associated with the edge cluster / project that is common across resource bundles for that project?

external-dns-controller

This component operates at the centralized controller.  The function of the external-dns-controller is to periodically start external-dns jobs which will connect to specific edge clusters to query the DNS CRD on the edge cluster and then update the actual DNS provider configured (per the intent) for that edge cluster.

DNS Intent API

DNS provider intent

result:
- an instance of external-dns is running in the centralized controller for each cluster of a project which is hosting a user facing service
- the source for the external-dns instance is the DNS CRD on the specific cluster for that project. The external-dns instance will be supplied the clusters K8S API server and kubeconfig
- the provider for the external-dns instance will be the DNS Provider provided in the intent
- ? what if a given project has multiple services (from different resource bundles) - in principle, a single external-dns instanace should be able to handle all services on that cluster as long as the same provider is used.
- it is kicked off by the external-dns-controller plugin when intents for a deployed app are processed.

assumptions:
- could be multiple dns-providers for a given service
- different clusters may update different set of dns-providers

need to know:
- need to know which clusters have the service deployed
- need to identify which dns-providers are associated with the cluster

POST
URL: /v2/project/{project-name}/rb/{rb-name}/{rb-version}/traffic-intent-sets/{traffic-intent-set-name}/dnsproviders:
{
  "name": "dns-provider-intent-name1",
  "description": "dns provider intent for updating user facing microservice FQDNs to external DNS providers",
  "dnsProvider": [
    {
      "id": "microservice01", // unique name of the microservice - provides association to other connectivity intents
      "externalName": "service1.example.com",  // redundant ? - this name should be deployed to istio gateway on microservice deployment (this may not be the right spot)
      "cluster-selector": "label1, label2, ...",  // labels to select which clusters this dns provider is to be used
      "externalDnsParameters": {   // list will be supplied to external-dns as parameters.
                                   // for example ...
        "aws-zone-type": "",          When using the AWS provider, filter for zones of this type (optional, options: public, private)
        "aws-zone-tags": "",          When using the AWS provider, filter for zones with these tags
        "aws-assume-role":"",         When using the AWS provider, assume this IAM role. Useful for hosted zones in another AWS account. Specify the full ARN, e.g. `arn:aws:iam::123455567:role/external-dns` (optional)
        "aws-batch-change-size":"1000",  When using the AWS provider, set the maximum number of changes that will be applied in each batch.
        "aws-batch-change-interval":"1s", When using the AWS provider, set the interval between batch changes.
        "aws-evaluate-target-health":"enabled", When using the AWS provider, set whether to evaluate the health of a DNS target (default: enabled, disable with --no-aws-evaluate-target-health)
        "aws-api-retries":"3",           When using the AWS provider, set the maximum number of retries for API calls before giving up.
        "aws-prefer-cname":"disabled"           When using the AWS provider, prefer using CNAME instead of ALIAS (default: disabled)
      }
      providerCredentials: {
        ...
      }
    }
  ]
}

Example DNS Update diagram



  • No labels