mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
158 lines
6.9 KiB
Plaintext
158 lines
6.9 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * installing/installing_bare_metal/upi/installing-bare-metal-network-customizations.adoc
|
|
// * installing/installing_bare_metal/upi/installing-bare-metal.adoc
|
|
// * installing/installing_bare_metal/upi/installing-restricted-networks-bare-metal.adoc
|
|
// * installing/installing_ibm_power/installing-ibm-power.adoc
|
|
// * installing/installing_ibm_power/installing-restricted-networks-ibm-power.adoc
|
|
// * installing/installing_ibm_z/installing-restricted-networks-ibm-z-kvm.adoc
|
|
// * installing/installing_ibm_z/installing-ibm-z-kvm.adoc
|
|
// * installing/installing_ibm_z/installing-ibm-z.adoc
|
|
// * installing/installing_ibm_z/installing-restricted-networks-ibm-z.adoc
|
|
// * installing/installing_ibm_z/installing-ibm-z-lpar.adoc
|
|
// * installing/installing_ibm_z/installing-restricted-networks-ibm-z-lpar.adoc
|
|
// * installing/installing_platform_agnostic/installing-platform-agnostic.adoc
|
|
// * installing/installing_vmc/installing-restricted-networks-vmc-user-infra.adoc
|
|
// * installing/installing_vmc/installing-vmc-user-infra.adoc
|
|
// * installing/installing_vmc/installing-vmc-network-customizations-user-infra.adoc
|
|
// * installing/installing_vsphere/upi/upi-vsphere-installation-reqs.adoc
|
|
|
|
ifeval::["{context}" == "installing-ibm-z"]
|
|
:ibm-z:
|
|
endif::[]
|
|
ifeval::["{context}" == "installing-ibm-z-kvm"]
|
|
:ibm-z-kvm:
|
|
endif::[]
|
|
ifeval::["{context}" == "installing-ibm-z-lpar"]
|
|
:ibm-z:
|
|
endif::[]
|
|
ifeval::["{context}" == "installing-restricted-networks-ibm-z"]
|
|
:ibm-z:
|
|
endif::[]
|
|
ifeval::["{context}" == "installing-restricted-networks-ibm-z-kvm"]
|
|
:ibm-z-kvm:
|
|
endif::[]
|
|
ifeval::["{context}" == "installing-restricted-networks-ibm-z-lpar"]
|
|
:ibm-z:
|
|
endif::[]
|
|
|
|
:prewrap!:
|
|
|
|
:_mod-docs-content-type: CONCEPT
|
|
[id="installation-dns-user-infra_{context}"]
|
|
= User-provisioned DNS requirements
|
|
|
|
[role="_abstract"]
|
|
In {product-title} deployments, you must ensure that cluster components meet certain DNS name resolution criteria for internal communication, certificate validation, and automated node discovery purposes.
|
|
|
|
The following is a list of required cluster components:
|
|
|
|
* The Kubernetes API
|
|
* The {product-title} application wildcard
|
|
* The bootstrap and control plane machines
|
|
ifeval::["{context}" != "installing-two-node-fencing"]
|
|
* The compute machines
|
|
endif::[]
|
|
|
|
ifeval::["{context}" == "installing-two-node-fencing"]
|
|
Reverse DNS resolution is also required for the Kubernetes API, the bootstrap machine, and the control plane machines.
|
|
endif::[]
|
|
|
|
ifeval::["{context}" != "installing-two-node-fencing"]
|
|
Reverse DNS resolution is also required for the Kubernetes API, the bootstrap machine, the control plane machines, and the compute machines.
|
|
endif::[]
|
|
|
|
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.
|
|
|
|
ifndef::ibm-z,ibm-z-kvm[]
|
|
[NOTE]
|
|
====
|
|
It is recommended to use a DHCP server to provide the hostnames to each cluster node. See the _DHCP recommendations for user-provisioned infrastructure_ section for more information.
|
|
====
|
|
endif::ibm-z,ibm-z-kvm[]
|
|
|
|
The following DNS records are required for a user-provisioned {product-title} cluster 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>.`.
|
|
|
|
.Required DNS records
|
|
[cols="1a,3a,5a",options="header"]
|
|
|===
|
|
|
|
|Component
|
|
|Record
|
|
|Description
|
|
|
|
.2+a|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.
|
|
ifeval::["{context}" == "installing-two-node-fencing"]
|
|
By default, the Ingress Controller pods run on compute nodes. In cluster topologies without dedicated compute nodes, such as two-node or three-node clusters, the control plane nodes also carry the worker label, so the Ingress pods are scheduled on the control plane nodes.
|
|
endif::[]
|
|
ifeval::["{context}" != "installing-two-node-fencing"]
|
|
The Ingress Controller pods run on the compute machines by default.
|
|
endif::[]
|
|
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.
|
|
|
|
|Bootstrap machine
|
|
|`bootstrap.<cluster_name>.<base_domain>.`
|
|
|A DNS A/AAAA or CNAME record, and a DNS PTR record, to identify the bootstrap
|
|
machine. These records must be resolvable by the nodes within the cluster.
|
|
|
|
|Control plane machines
|
|
|`<control_plane><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.
|
|
|
|
ifeval::["{context}" != "installing-two-node-fencing"]
|
|
|Compute machines
|
|
|`<compute><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.
|
|
endif::[]
|
|
|
|
|===
|
|
|
|
[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. See the section on _Validating DNS resolution for user-provisioned infrastructure_ for detailed validation steps.
|
|
====
|
|
|
|
|
|
ifeval::["{context}" == "installing-ibm-z"]
|
|
:!ibm-z:
|
|
endif::[]
|
|
ifeval::["{context}" == "installing-ibm-z-kvm"]
|
|
:!ibm-z-kvm:
|
|
endif::[]
|
|
ifeval::["{context}" == "installing-ibm-z-lpar"]
|
|
:!ibm-z:
|
|
endif::[]
|
|
ifeval::["{context}" == "installing-restricted-networks-ibm-z"]
|
|
:!ibm-z:
|
|
endif::[]
|
|
ifeval::["{context}" == "installing-restricted-networks-ibm-z-kvm"]
|
|
:!ibm-z-kvm:
|
|
endif::[]
|
|
ifeval::["{context}" == "installing-restricted-networks-ibm-z-lpar"]
|
|
:!ibm-z:
|
|
endif::[]
|