mirror of
https://github.com/kubernetes-sigs/external-dns.git
synced 2025-08-06 01:26:59 +02:00
commit
7fe31aacfa
@ -2,6 +2,7 @@
|
||||
|
||||
- Improve errors context for AWS provider
|
||||
- Scaleway Provider (#1643) @Sh4d1
|
||||
- Fix typos in documentation @ddymko
|
||||
|
||||
## v0.7.3 - 2020-08-05
|
||||
|
||||
|
@ -7,7 +7,7 @@ Akamai FastDNS provider support was added via [this PR](https://github.com/kuber
|
||||
The Akamai FastDNS provider expects that your zones, you wish to add records to, already exists
|
||||
and are configured correctly. It does not add, remove or configure new zones in anyway.
|
||||
|
||||
To do this pease refer to the [FastDNS documentation](https://learn.akamai.com/en-us/products/web_performance/fast_dns.html).
|
||||
To do this please refer to the [FastDNS documentation](https://learn.akamai.com/en-us/products/web_performance/fast_dns.html).
|
||||
|
||||
Additional data you will have to provide:
|
||||
|
||||
@ -18,7 +18,7 @@ Additional data you will have to provide:
|
||||
|
||||
Make these available to external DNS somehow. In the following example a secret is used by referencing the secret and its keys in the env section of the deployment.
|
||||
|
||||
If you happen to have questions regarding authentification, please refer to the [API Client Authentication documentation](https://developer.akamai.com/legacy/introduction/Client_Auth.html)
|
||||
If you happen to have questions regarding authentication, please refer to the [API Client Authentication documentation](https://developer.akamai.com/legacy/introduction/Client_Auth.html)
|
||||
|
||||
## Deployment
|
||||
|
||||
|
@ -58,7 +58,7 @@ You can find the `subscriptionId` by running `az account show --query "id"` or b
|
||||
|
||||
The `resourceGroup` is the Resource Group created in a previous step.
|
||||
|
||||
The `aadClientID` and `aaClientSecret` are assoiated with the Service Principal, that you need to create next.
|
||||
The `aadClientID` and `aaClientSecret` are associated with the Service Principal, that you need to create next.
|
||||
|
||||
### Creating service principal
|
||||
A Service Principal with a minimum access level of `contributor` to the DNS zone(s) and `reader` to the resource group containing the Azure DNS zone(s) is necessary for ExternalDNS to be able to edit DNS records. However, other more permissive access levels will work too (e.g. `contributor` to the resource group or the whole subscription).
|
||||
|
@ -173,7 +173,7 @@ the DNSimple DNS records.
|
||||
|
||||
### Getting your DNSimple Account ID
|
||||
|
||||
If you do not know your DNSimple account ID it can be aquired using the [whoami](https://developer.dnsimple.com/v2/identity/#whoami) endpoint from the DNSimple Identity API
|
||||
If you do not know your DNSimple account ID it can be acquired using the [whoami](https://developer.dnsimple.com/v2/identity/#whoami) endpoint from the DNSimple Identity API
|
||||
|
||||
```sh
|
||||
curl -H "Authorization: Bearer $DNSIMPLE_ACCOUNT_TOKEN" \
|
||||
|
@ -130,7 +130,7 @@ spec:
|
||||
As the DNS name `test-ingress.example.com` matches the filter, external-dns will create two records:
|
||||
a CNAME for test-ingress.example.com and TXT for _dtest-ingress.example.com.
|
||||
|
||||
Create the Igress:
|
||||
Create the Ingress:
|
||||
|
||||
```
|
||||
$ kubectl create -f test-ingress.yaml
|
||||
|
@ -7,7 +7,7 @@ Exoscale provider support was added via [this PR](https://github.com/kubernetes-
|
||||
The Exoscale provider expects that your Exoscale zones, you wish to add records to, already exists
|
||||
and are configured correctly. It does not add, remove or configure new zones in anyway.
|
||||
|
||||
To do this pease refer to the [Exoscale DNS documentation](https://community.exoscale.com/documentation/dns/).
|
||||
To do this please refer to the [Exoscale DNS documentation](https://community.exoscale.com/documentation/dns/).
|
||||
|
||||
Additionally you will have to provide the Exoscale...:
|
||||
|
||||
|
@ -2,7 +2,7 @@
|
||||
|
||||
This tutorial describes how to setup ExternalDNS for usage in conjunction with an ExternalName service.
|
||||
|
||||
## Usecases
|
||||
## Use cases
|
||||
|
||||
The main use cases that inspired this feature is the necessity for having a subdomain pointing to an external domain. In this scenario, it makes sense for the subdomain to have a CNAME record pointing to the external domain.
|
||||
|
||||
|
@ -2,7 +2,7 @@
|
||||
|
||||
This tutorial describes how to setup ExternalDNS for usage in conjunction with a Headless service.
|
||||
|
||||
## Usecases
|
||||
## Use cases
|
||||
The main use cases that inspired this feature is the necessity for fixed addressable hostnames with services, such as Kafka when trying to access them from outside the cluster. In this scenario, quite often, only the Node IP addresses are actually routable and as in systems like Kafka more direct connections are preferable.
|
||||
|
||||
## Setup
|
||||
|
@ -98,7 +98,7 @@ spec:
|
||||
- --source=service
|
||||
- --source=ingress
|
||||
- --provider=oci
|
||||
- --policy=upsert-only # prevent ExternalDNSfrom deleting any records, omit to enable full synchronization
|
||||
- --policy=upsert-only # prevent ExternalDNS from deleting any records, omit to enable full synchronization
|
||||
- --txt-owner-id=my-identifier
|
||||
volumeMounts:
|
||||
- name: config
|
||||
|
@ -116,7 +116,7 @@ spec:
|
||||
value: "YOU_VULTR_API_KEY"
|
||||
```
|
||||
|
||||
## Deploying an Nginx Service
|
||||
## Deploying a Nginx Service
|
||||
|
||||
Create a service file called 'nginx.yaml' with the following contents:
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user