Skip to content

Commit c2549fb

Browse files
skopacz1skopacz1
authored
Merge pull request #113474 from skopacz1/OSDOCS-17038_4
OSDOCS-17038: Agent preparing docs CQA
2 parents 79cb1b6 + 04d1131 commit c2549fb

15 files changed

Lines changed: 254 additions & 214 deletions

‎installing/installing_with_agent_based_installer/preparing-to-install-with-agent-based-installer.adoc‎

Lines changed: 17 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -6,11 +6,10 @@ include::_attributes/common-attributes.adoc[]
66

77
toc::[]
88

9-
[id="about-the-agent-based-installer_{context}"]
10-
== About the Agent-based Installer
9+
[role="_abstract"]
10+
The Agent-based Installer provides the flexibility to boot your on-premise servers in any way that you choose. It combines the ease of use of the Assisted Installation service with the ability to run offline, including in air-gapped environments.
1111

12-
The Agent-based installation method provides the flexibility to boot your on-premise servers in any way that you choose. It combines the ease of use of the Assisted Installation service with the ability to run offline, including in air-gapped environments.
13-
Agent-based installation is a subcommand of the {product-title} installer.
12+
The Agent-based Installer uses a subcommand of the {product-title} installation program.
1413
It generates a bootable ISO image containing all of the information required to deploy an {product-title} cluster, with an available release image.
1514

1615
The configuration is in the same format as for the installer-provisioned infrastructure and user-provisioned infrastructure installation methods.
@@ -56,6 +55,8 @@ include::modules/understanding-agent-install.adoc[leveloffset=+1]
5655

5756
* xref:../../installing/overview/cluster-capabilities.adoc#cluster-capabilities[Cluster capabilities]
5857
58+
* link:https://access.redhat.com/articles/4207611[Deploying OpenShift 4.x on non-tested platforms using the bare metal install method (Red{nbsp}Hat Knowledgebase article)]
59+
5960
* xref:../../installing/installing_with_agent_based_installer/preparing-to-install-with-agent-based-installer.adoc#installation-requirements-platform-none_preparing-to-install-with-agent-based-installer[Requirements for a cluster using the platform "none" option]
6061
6162
* xref:../installing_bare_metal/ipi/ipi-install-prerequisites.adoc#network-requirements-increase-mtu_ipi-install-prerequisites[Increase the network MTU]
@@ -88,22 +89,22 @@ include::modules/agent-install-ipi-install-root-device-hints.adoc[leveloffset=+2
8889
//About networking
8990
include::modules/agent-install-networking.adoc[leveloffset=+1]
9091

91-
[id="installation-requirements-platform-none_{context}"]
92-
== Requirements for a cluster using the platform "none" option
93-
94-
This section describes the requirements for an Agent-based {product-title} installation that is configured to use the platform `none` option.
95-
96-
[IMPORTANT]
97-
====
98-
Review the information in the link:https://access.redhat.com/articles/4207611[guidelines for deploying {product-title} on non-tested platforms] before you attempt to install an {product-title} cluster in virtualized or cloud environments.
99-
====
92+
//Requirements for a cluster using the platform "none" option
93+
include::modules/agent-install-requirements-none.adoc[leveloffset=+1]
10094

10195
//Platform "none" DNS requirements
10296
include::modules/agent-install-dns-none.adoc[leveloffset=+2]
10397

10498
//Platform "none" Load balancing requirements
10599
include::modules/agent-install-load-balancing-none.adoc[leveloffset=+2]
106100

101+
[role="_additional-resources"]
102+
.Additional resources
103+
104+
* xref:../../installing/overview/cluster-capabilities.adoc#cluster-capabilities[Cluster capabilities]
105+
106+
* link:https://access.redhat.com/articles/4207611[Deploying OpenShift 4.x on non-tested platforms using the bare metal install method (Red{nbsp}Hat Knowledgebase article)]
107+
107108
//Example: Bonds and VLAN interface node network configuration
108109
include::modules/agent-install-sample-config-bonds-vlans.adoc[leveloffset=+1]
109110

@@ -121,8 +122,9 @@ include::modules/installation-bare-metal-agent-installer-config-yaml.adoc[levelo
121122
//Validation checks before agent ISO creation
122123
include::modules/validations-before-agent-iso-creation.adoc[leveloffset=+1]
123124

124-
[id="agent-based-installation-next-steps_{context}"]
125-
== Next steps
125+
[role="_additional-resources"]
126+
[id="additional-resources_{context}"]
127+
== Additional resources
126128

127129
* xref:../../installing/installing_with_agent_based_installer/installing-with-agent-basic.adoc#installing-with-agent-basic[Installing a cluster]
128130

‎modules/agent-host-config.adoc‎

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -8,9 +8,10 @@
88

99
// Starting with whatever content I could find just to have something for feedback, but any additions or replacements are welcome.
1010

11+
[role="_abstract"]
1112
You can make additional configurations for each host on the cluster in the `agent-config.yaml` file, such as network configurations and root device hints.
1213

1314
[IMPORTANT]
1415
====
15-
For each host you configure, you must provide the MAC address of an interface on the host to specify which host you are configuring.
16+
For each host you configure, you must specify which host you are configuring by providing the MAC address of an interface on the host.
1617
====

‎modules/agent-host-roles.adoc‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -6,6 +6,7 @@
66
[id="agent-host-roles_{context}"]
77
= Host roles
88

9+
[role="_abstract"]
910
Each host in the cluster is assigned a role of either `master` or `worker`.
1011
You can define the role for each host in the `agent-config.yaml` file by using the `role` parameter.
1112
If you do not assign a role to the hosts, the roles will be assigned at random during installation.

‎modules/agent-install-dns-none.adoc‎

Lines changed: 33 additions & 33 deletions
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,10 @@
22
[id="agent-install-dns-none_{context}"]
33
= Platform "none" DNS requirements
44

5-
In {product-title} deployments, DNS name resolution is required for the following components:
5+
[role="_abstract"]
6+
In {product-title} deployments, DNS name resolution is required for several components.
7+
8+
The following components need DNS name resolution:
69

710
* The Kubernetes API
811
* The {product-title} application wildcard
@@ -75,13 +78,11 @@ This section provides A and PTR record configuration samples that meet the DNS r
7578

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

78-
.Example DNS A record configuration for a platform "none" cluster
81+
Example DNS A record configuration for a platform "none" cluster::
7982

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

8285
.Sample DNS zone database
83-
[%collapsible]
84-
====
8586
[source,text]
8687
----
8788
$TTL 1W
@@ -101,41 +102,39 @@ smtp.example.com. IN A 192.168.1.5
101102
helper.example.com. IN A 192.168.1.5
102103
helper.ocp4.example.com. IN A 192.168.1.5
103104
;
104-
api.ocp4.example.com. IN A 192.168.1.5 <1>
105-
api-int.ocp4.example.com. IN A 192.168.1.5 <2>
105+
api.ocp4.example.com. IN A 192.168.1.5
106+
api-int.ocp4.example.com. IN A 192.168.1.5
106107
;
107-
*.apps.ocp4.example.com. IN A 192.168.1.5 <3>
108+
*.apps.ocp4.example.com. IN A 192.168.1.5
108109
;
109-
master0.ocp4.example.com. IN A 192.168.1.97 <4>
110-
master1.ocp4.example.com. IN A 192.168.1.98 <4>
111-
master2.ocp4.example.com. IN A 192.168.1.99 <4>
110+
master0.ocp4.example.com. IN A 192.168.1.97
111+
master1.ocp4.example.com. IN A 192.168.1.98
112+
master2.ocp4.example.com. IN A 192.168.1.99
112113
;
113-
worker0.ocp4.example.com. IN A 192.168.1.11 <5>
114-
worker1.ocp4.example.com. IN A 192.168.1.7 <5>
114+
worker0.ocp4.example.com. IN A 192.168.1.11
115+
worker1.ocp4.example.com. IN A 192.168.1.7
115116
;
116117
;EOF
117118
----
119+
where:
118120

119-
<1> Provides name resolution for the Kubernetes API. The record refers to the IP address of the API load balancer.
120-
<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.
121-
<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.
121+
`api.ocp4.example.com.`:: Provides name resolution for the Kubernetes API. The record refers to the IP address of the API load balancer.
122+
`api-int.ocp4.example.com.`:: 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.
123+
`*.apps.ocp4.example.com.`:: 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.
122124
+
123125
[NOTE]
124126
=====
125127
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.
126128
=====
127129
+
128-
<4> Provides name resolution for the control plane machines.
129-
<5> Provides name resolution for the compute machines.
130-
====
130+
`master0.ocp4.example.com.`-`master2.ocp4.example.com.`:: Provides name resolution for the control plane machines.
131+
`worker0.ocp4.example.com.`-`worker1.ocp4.example.com.`:: Provides name resolution for the compute machines.
131132

132-
.Example DNS PTR record configuration for a platform "none" cluster
133+
Example DNS PTR record configuration for a platform "none" cluster::
133134

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

136137
.Sample DNS zone database for reverse records
137-
[%collapsible]
138-
====
139138
[source,text]
140139
----
141140
$TTL 1W
@@ -147,24 +146,25 @@ $TTL 1W
147146
1W ) ; minimum (1 week)
148147
IN NS ns1.example.com.
149148
;
150-
5.1.168.192.in-addr.arpa. IN PTR api.ocp4.example.com. <1>
151-
5.1.168.192.in-addr.arpa. IN PTR api-int.ocp4.example.com. <2>
149+
5.1.168.192.in-addr.arpa. IN PTR api.ocp4.example.com.
150+
5.1.168.192.in-addr.arpa. IN PTR api-int.ocp4.example.com.
152151
;
153-
97.1.168.192.in-addr.arpa. IN PTR master0.ocp4.example.com. <3>
154-
98.1.168.192.in-addr.arpa. IN PTR master1.ocp4.example.com. <3>
155-
99.1.168.192.in-addr.arpa. IN PTR master2.ocp4.example.com. <3>
152+
97.1.168.192.in-addr.arpa. IN PTR master0.ocp4.example.com.
153+
98.1.168.192.in-addr.arpa. IN PTR master1.ocp4.example.com.
154+
99.1.168.192.in-addr.arpa. IN PTR master2.ocp4.example.com.
156155
;
157-
11.1.168.192.in-addr.arpa. IN PTR worker0.ocp4.example.com. <4>
158-
7.1.168.192.in-addr.arpa. IN PTR worker1.ocp4.example.com. <4>
156+
11.1.168.192.in-addr.arpa. IN PTR worker0.ocp4.example.com.
157+
7.1.168.192.in-addr.arpa. IN PTR worker1.ocp4.example.com.
159158
;
160159
;EOF
161160
----
161+
where:
162+
163+
`api.ocp4.example.com.`:: Provides reverse DNS resolution for the Kubernetes API. The PTR record refers to the record name of the API load balancer.
164+
`api-int.ocp4.example.com.`:: 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.
165+
`master0.ocp4.example.com.`-`master2.ocp4.example.com.`:: Provides reverse DNS resolution for the control plane machines.
166+
`worker0.ocp4.example.com.`-`worker1.ocp4.example.com.`:: Provides reverse DNS resolution for the compute machines.
162167

163-
<1> Provides reverse DNS resolution for the Kubernetes API. The PTR record refers to the record name of the API load balancer.
164-
<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.
165-
<3> Provides reverse DNS resolution for the control plane machines.
166-
<4> Provides reverse DNS resolution for the compute machines.
167-
====
168168

169169
[NOTE]
170170
====

‎modules/agent-install-ipi-install-root-device-hints.adoc‎

Lines changed: 4 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,10 @@
66
[id='root-device-hints_{context}']
77
= About root device hints
88

9-
The `rootDeviceHints` parameter enables the installer to provision the {op-system-first} image to a particular device. The installer examines the devices in the order it discovers them, and compares the discovered values with the hint values. The installer uses the first discovered device that matches the hint value. The configuration can combine multiple hints, but a device must match all hints for the installer to select it.
9+
[role="_abstract"]
10+
The `rootDeviceHints` parameter enables the installation program to provision the {op-system-first} image to a particular device.
11+
12+
The installation program examines the devices in the order it discovers them, and compares the discovered values with the hint values. The installation program uses the first discovered device that matches the hint value. The configuration can combine multiple hints, but a device must match all hints for the installation program to select it.
1013

1114
.Subfields
1215

‎modules/agent-install-load-balancing-none.adoc‎

Lines changed: 13 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -2,17 +2,14 @@
22
[id="agent-install-load-balancing-none_{context}"]
33
= Platform "none" Load balancing requirements
44

5-
5+
[role="_abstract"]
66
Before you install {product-title}, you must provision the API and application Ingress load balancing infrastructure. 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.
77

88
[NOTE]
99
====
10-
These requirements do not apply to single-node OpenShift clusters using the platform `none` option.
11-
====
10+
* These requirements do not apply to {sno} clusters using the platform `none` option.
1211
13-
[NOTE]
14-
====
15-
If you want to deploy the API and application Ingress load balancers with a {op-system-base-full} instance, you must purchase the {op-system-base} subscription separately.
12+
* If you want to deploy the API and application Ingress load balancers with a {op-system-base-full} instance, you must purchase the {op-system-base} subscription separately.
1613
====
1714

1815
The load balancing infrastructure must meet the following requirements:
@@ -123,8 +120,6 @@ If you are using HAProxy as a load balancer and SELinux is set to `enforcing`, y
123120
====
124121

125122
.Sample API and application Ingress load balancer configuration
126-
[%collapsible]
127-
====
128123
[source,text]
129124
----
130125
global
@@ -147,43 +142,43 @@ defaults
147142
timeout http-keep-alive 10s
148143
timeout check 10s
149144
maxconn 3000
150-
listen api-server-6443 <1>
145+
listen api-server-6443
151146
bind *:6443
152147
mode tcp
153148
server master0 master0.ocp4.example.com:6443 check inter 1s
154149
server master1 master1.ocp4.example.com:6443 check inter 1s
155150
server master2 master2.ocp4.example.com:6443 check inter 1s
156-
listen machine-config-server-22623 <2>
151+
listen machine-config-server-22623
157152
bind *:22623
158153
mode tcp
159154
server master0 master0.ocp4.example.com:22623 check inter 1s
160155
server master1 master1.ocp4.example.com:22623 check inter 1s
161156
server master2 master2.ocp4.example.com:22623 check inter 1s
162-
listen ingress-router-443 <3>
157+
listen ingress-router-443
163158
bind *:443
164159
mode tcp
165160
balance source
166161
server worker0 worker0.ocp4.example.com:443 check inter 1s
167162
server worker1 worker1.ocp4.example.com:443 check inter 1s
168-
listen ingress-router-80 <4>
163+
listen ingress-router-80
169164
bind *:80
170165
mode tcp
171166
balance source
172167
server worker0 worker0.ocp4.example.com:80 check inter 1s
173168
server worker1 worker1.ocp4.example.com:80 check inter 1s
174169
----
175170

176-
<1> Port `6443` handles the Kubernetes API traffic and points to the control plane machines. You must configure health checks on this port to ensure that the API server is available before routing traffic.
177-
<2> Port `22623` handles the machine config server traffic and points to the control plane machines.
178-
<3> Port `443` handles the HTTPS traffic and points to the machines that run the Ingress Controller pods. The Ingress Controller pods run on the compute machines by default.
179-
<4> Port `80` handles the HTTP traffic and points to the machines that run the Ingress Controller pods. The Ingress Controller pods run on the compute machines by default.
171+
* Port `6443` handles the Kubernetes API traffic and points to the control plane machines. You must configure health checks on this port to ensure that the API server is available before routing traffic.
172+
* Port `22623` handles the machine config server traffic and points to the control plane machines.
173+
* Port `443` handles the HTTPS traffic and points to the machines that run the Ingress Controller pods. The Ingress Controller pods run on the compute machines by default.
174+
* Port `80` handles the HTTP traffic and points to the machines that run the Ingress Controller pods. The Ingress Controller pods run on the compute machines by default.
180175
+
181176
[NOTE]
182-
=====
177+
====
183178
If you are deploying a compact three-node cluster with zero compute nodes, the Ingress Controller pods run on the control plane nodes. In three-node cluster deployments, you must configure your application Ingress load balancer to route HTTP and HTTPS traffic to the control plane nodes.
184-
=====
185179
====
186180

181+
187182
[TIP]
188183
====
189184
If you are using HAProxy as a load balancer, you can check that the `haproxy` process is listening on ports `6443`, `22623`, `443`, and `80` by running `netstat -nltupe` on the HAProxy node.

0 commit comments

Comments
 (0)