Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs/user/aws/install_upi: Explain DNS-zone lookup #2420

Merged
merged 1 commit into from
Oct 14, 2019
Merged

docs/user/aws/install_upi: Explain DNS-zone lookup #2420

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
66 changes: 23 additions & 43 deletions docs/user/aws/install_upi.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -65,9 +65,30 @@ data["spec"]["mastersSchedulable"] = False;
open(path, "w").write(yaml.dump(data, default_flow_style=False))'
```

### Remove DNS Zones
### Adjust DNS Zones

If you don't want [the ingress operator][ingress-operator] to create DNS records on your behalf, remove the `privateZone` and `publicZone` sections from the DNS configuration:
[The ingress operator][ingress-operator] is able to manage DNS records on your behalf.
Depending on whether you want operator-managed DNS or user-managed DNS, you can choose to [identify the internal DNS zone](#identify-the-internal-dns-zone) or [remove DNS zones](#remove-dns-zones) from the DNS configuration.

#### Identify the internal DNS zone

If you want [the ingress operator][ingress-operator] to manage DNS records on your behalf, adjust the `privateZone` section in the DNS configuration to identify the zone it should use.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK ingress-operator adds the dns records to for clusterdomain only. Can it handle any other?

Copy link
Member Author

@wking wking Oct 11, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK ingress-operator adds the dns records to for clusterdomain only.

Ingress is filling DNSRecord requests. In most cases now this is just going to be the default-wildcard record, and I dropped an example YAML dump of that into the 14e0691 commit message for the curious ;). But folks pushing new DNSRecords will probably get them filled, because I don't think the ingress operator has (or should have) guards about which DNSRecords it should or should not fill. If you're authorized to push a DNSRecord where ingress is looking, you should get it filled.

Copy link
Contributor

@abhinavdahiya abhinavdahiya Oct 11, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But in case where the private dns zone id is for not-clusterdomain. then the DNSRecord created by default would fail right.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But in case where the private dns zone id is for not-clusterdomain. then the DNSRecord created by default would fail right.

Ah, probably. Although it depends on the zone domains. So you could have an example.com zone, and Ingress could create an a.example.com record even if your cluster was c.d.e.example.com (I think ;). But yeah, I expect it would fail to create example.edu. Does that matter? We aren't telling them to create DNSRecords here, we're just telling them how to feed zones to the ingress operator, which can have its own docs about what it can and cannot support.

By default it will use a `kubernetes.io/cluster/{infrastructureName}: owned` tag, but that tag is only appropriate if `openshift-install destroy cluster` should remove the zone.
For user-provided zones, you can remove `tags` completely and use the zone ID instead:

```sh
python -c '
import yaml;
path = "manifests/cluster-dns-02-config.yml";
data = yaml.load(open(path));
del data["spec"]["privateZone"]["tags"];
data["spec"]["privateZone"]["id"] = "Z21IZ5YJJMZ2A4";
open(path, "w").write(yaml.dump(data, default_flow_style=False))'
```

#### Remove DNS zones

If you don't want [the ingress operator][ingress-operator] to manage DNS records on your behalf, remove the `privateZone` and `publicZone` sections from the DNS configuration:

```sh
python -c '
Expand Down Expand Up @@ -215,47 +236,6 @@ CSRs can be approved by name, for example:
oc adm certificate approve csr-bfd72
```

## Configure Router for UPI

The Ingress operator manages DNS and LoadBalancers. It makes use of tags on HostedZones to identify which public and
private zones are to be updated from the cluster by the operator as objects are created in the cluster. It makes use
of tags on subnets to identify those to associate with Service objects of type LoadBalancer created in the cluster.

The tags used for finding HostedZones used by the operator
are fulfilled by the CloudFormation template [here](../../../upi/aws/cloudformation/02_cluster_infra.yaml).

An example of the `spec` for DNS configuration is below:

```
$ oc get dns -o yaml
apiVersion: v1
items:
- apiVersion: config.openshift.io/v1
kind: DNS
metadata:
creationTimestamp: 2019-03-28T12:31:10Z
generation: 1
name: cluster
namespace: ""
resourceVersion: "395"
selfLink: /apis/config.openshift.io/v1/dnses/cluster
uid: 5e51dd25-5155-11e9-befc-02d75ce1a902
spec:
baseDomain: test.example.com
privateZone:
tags:
Name: test-r69hh-int
kubernetes.io/cluster/test-r69hh: owned
publicZone:
id: Z21IZ5YJJMZ2A4
status: {}
kind: List
metadata:
resourceVersion: ""
selfLink: ""

```

## Add the Ingress DNS Records

If you removed the DNS Zone configuration [earlier](#remove-dns-zones), you'll need to manually create some DNS records pointing at the ingress load balancer.
Expand Down