Skip to content

Latest commit

 

History

History
172 lines (143 loc) · 7.19 KB

agent-install-dns-none.adoc

File metadata and controls

172 lines (143 loc) · 7.19 KB

Platform "none" DNS requirements

In {product-title} deployments, DNS name resolution is required for the following components:

  • The Kubernetes API

  • The {product-title} application wildcard

  • The control plane and compute machines

Reverse DNS resolution is also required for the Kubernetes API, the control plane machines, and the compute machines.

DNS A/AAAA or CNAME records are used for name resolution and PTR records are used for reverse name resolution. The reverse records are important because {op-system-first} uses the reverse records to set the hostnames for all the nodes, unless the hostnames are provided by DHCP. Additionally, the reverse records are used to generate the certificate signing requests (CSR) that {product-title} needs to operate.

Note

It is recommended to use a DHCP server to provide the hostnames to each cluster node.

The following DNS records are required for an {product-title} cluster using the platform none option and they must be in place before installation. In each record, <cluster_name> is the cluster name and <base_domain> is the base domain that you specify in the install-config.yaml file. A complete DNS record takes the form: <component>.<cluster_name>.<base_domain>..

Table 1. Required DNS records
Component Record Description

Kubernetes API

api.<cluster_name>.<base_domain>.

A DNS A/AAAA or CNAME record, and a DNS PTR record, to identify the API load balancer. These records must be resolvable by both clients external to the cluster and from all the nodes within the cluster.

api-int.<cluster_name>.<base_domain>.

A DNS A/AAAA or CNAME record, and a DNS PTR record, to internally identify the API load balancer. These records must be resolvable from all the nodes within the cluster.

Important

The API server must be able to resolve the worker nodes by the hostnames that are recorded in Kubernetes. If the API server cannot resolve the node names, then proxied API calls can fail, and you cannot retrieve logs from pods.

Routes

*.apps.<cluster_name>.<base_domain>.

A wildcard DNS A/AAAA or CNAME record that refers to the application ingress load balancer. The application ingress load balancer targets the machines that run the Ingress Controller pods. The Ingress Controller pods run on the compute machines by default. These records must be resolvable by both clients external to the cluster and from all the nodes within the cluster.

For example, console-openshift-console.apps.<cluster_name>.<base_domain> is used as a wildcard route to the {product-title} console.

Control plane machines

<master><n>.<cluster_name>.<base_domain>.

DNS A/AAAA or CNAME records and DNS PTR records to identify each machine for the control plane nodes. These records must be resolvable by the nodes within the cluster.

Compute machines

<worker><n>.<cluster_name>.<base_domain>.

DNS A/AAAA or CNAME records and DNS PTR records to identify each machine for the worker nodes. These records must be resolvable by the nodes within the cluster.
Note

In {product-title} 4.4 and later, you do not need to specify etcd host and SRV records in your DNS configuration.
Tip

You can use the dig command to verify name and reverse name resolution.

Example DNS configuration for platform "none" clusters

This section provides A and PTR record configuration samples that meet the DNS requirements for deploying {product-title} using the platform none option. The samples are not meant to provide advice for choosing one DNS solution over another.

In the examples, the cluster name is ocp4 and the base domain is example.com.

Example DNS A record configuration for a platform "none" cluster

The following example is a BIND zone file that shows sample A records for name resolution in a cluster using the platform none option.

Sample DNS zone database 
$TTL 1W
@	IN	SOA	ns1.example.com.	root (
			2019070700	; serial
			3H		; refresh (3 hours)
			30M		; retry (30 minutes)
			2W		; expiry (2 weeks)
			1W )		; minimum (1 week)
	IN	NS	ns1.example.com.
	IN	MX 10	smtp.example.com.
;
;
ns1.example.com.		IN	A	192.168.1.5
smtp.example.com.		IN	A	192.168.1.5
;
helper.example.com.		IN	A	192.168.1.5
helper.ocp4.example.com.	IN	A	192.168.1.5
;
api.ocp4.example.com.		IN	A	192.168.1.5 (1)
api-int.ocp4.example.com.	IN	A	192.168.1.5 (2)
;
*.apps.ocp4.example.com.	IN	A	192.168.1.5 (3)
;
master0.ocp4.example.com.	IN	A	192.168.1.97 (4)
master1.ocp4.example.com.	IN	A	192.168.1.98 (4)
master2.ocp4.example.com.	IN	A	192.168.1.99 (4)
;
worker0.ocp4.example.com.	IN	A	192.168.1.11 (5)
worker1.ocp4.example.com.	IN	A	192.168.1.7 (5)
;
;EOF

  1. Provides name resolution for the Kubernetes API. The record refers to the IP address of the API load balancer.

  2. Provides name resolution for the Kubernetes API. The record refers to the IP address of the API load balancer and is used for internal cluster communications.

  3. Provides name resolution for the wildcard routes. The record refers to the IP address of the application ingress load balancer. The application ingress load balancer targets the machines that run the Ingress Controller pods. The Ingress Controller pods run on the compute machines by default.

    Note

    In the example, the same load balancer is used for the Kubernetes API and application ingress traffic. In production scenarios, you can deploy the API and application ingress load balancers separately so that you can scale the load balancer infrastructure for each in isolation.

  4. Provides name resolution for the control plane machines.

  5. Provides name resolution for the compute machines.

Example DNS PTR record configuration for a platform "none" cluster

The following example BIND zone file shows sample PTR records for reverse name resolution in a cluster using the platform none option.

Sample DNS zone database for reverse records 
$TTL 1W
@	IN	SOA	ns1.example.com.	root (
			2019070700	; serial
			3H		; refresh (3 hours)
			30M		; retry (30 minutes)
			2W		; expiry (2 weeks)
			1W )		; minimum (1 week)
	IN	NS	ns1.example.com.
;
5.1.168.192.in-addr.arpa.	IN	PTR	api.ocp4.example.com. (1)
5.1.168.192.in-addr.arpa.	IN	PTR	api-int.ocp4.example.com. (2)
;
97.1.168.192.in-addr.arpa.	IN	PTR	master0.ocp4.example.com. (3)
98.1.168.192.in-addr.arpa.	IN	PTR	master1.ocp4.example.com. (3)
99.1.168.192.in-addr.arpa.	IN	PTR	master2.ocp4.example.com. (3)
;
11.1.168.192.in-addr.arpa.	IN	PTR	worker0.ocp4.example.com. (4)
7.1.168.192.in-addr.arpa.	IN	PTR	worker1.ocp4.example.com. (4)
;
;EOF

  1. Provides reverse DNS resolution for the Kubernetes API. The PTR record refers to the record name of the API load balancer.

  2. Provides reverse DNS resolution for the Kubernetes API. The PTR record refers to the record name of the API load balancer and is used for internal cluster communications.

  3. Provides reverse DNS resolution for the control plane machines.

  4. Provides reverse DNS resolution for the compute machines.

Note

A PTR record is not required for the {product-title} application wildcard.