mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
OSDOCS-5402: Updated IBM CLoud to IBM Cloud Bare Metal (Classic)
This commit is contained in:
dfitzmau
committed by
Kathryn Alexander
Kathryn Alexander
parent
f1e57a10f3
commit
aafa92ce16
@@ -146,6 +146,9 @@ endif::[]
|
||||
:SMProductVersion1x: 1.1.18.2
|
||||
//Windows containers
|
||||
:productwinc: Red Hat OpenShift support for Windows Containers
|
||||
// IBM Cloud
|
||||
:ibmcloudBMProductName: IBM Cloud Bare Metal (Classic)
|
||||
:ibmcloudBMRegProductName: IBM Cloud® Bare Metal (Classic)
|
||||
// IBM Power
|
||||
:ibmpowerProductName: IBM Power
|
||||
// IBM zSystems
|
||||
|
||||
@@ -360,7 +360,7 @@ Topics:
|
||||
File: ipi-install-expanding-the-cluster
|
||||
- Name: Troubleshooting
|
||||
File: ipi-install-troubleshooting
|
||||
- Name: Installing bare metal clusters on IBM Cloud
|
||||
- Name: Installing IBM Cloud Bare Metal (Classic)
|
||||
Dir: installing_ibm_cloud
|
||||
Distros: openshift-origin,openshift-enterprise
|
||||
Topics:
|
||||
|
||||
@@ -6,7 +6,7 @@ include::_attributes/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
You can use installer-provisioned installation to install {product-title} on IBM Cloud® nodes. This document describes the prerequisites and procedures when installing {product-title} on IBM Cloud nodes.
|
||||
You can use installer-provisioned installation to install {product-title} on {ibmcloudBMRegProductName} nodes. This document describes the prerequisites and procedures when installing {product-title} on IBM Cloud nodes.
|
||||
|
||||
[IMPORTANT]
|
||||
====
|
||||
@@ -20,6 +20,6 @@ Installer-provisioned installation of {product-title} requires:
|
||||
* One routable network
|
||||
* One provisioning network
|
||||
|
||||
Before starting an installer-provisioned installation of {product-title} on IBM Cloud, address the following prerequisites and requirements.
|
||||
Before starting an installer-provisioned installation of {product-title} on {ibmcloudBMProductName}, address the following prerequisites and requirements.
|
||||
|
||||
include::modules/install-ibm-cloud-setting-up-ibm-cloud-infrastructure.adoc[leveloffset=+1]
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
[id="configuring-the-install-config-file_{context}"]
|
||||
= Configuring the install-config.yaml file
|
||||
|
||||
The `install-config.yaml` file requires some additional details. Most of the information is teaching the installer and the resulting cluster enough about the available IBM Cloud® hardware so that it is able to fully manage it. The material difference between installing on bare metal and installing on IBM Cloud is that you must explicitly set the privilege level for IPMI in the BMC section of the `install-config.yaml` file.
|
||||
The `install-config.yaml` file requires some additional details. Most of the information is teaching the installer and the resulting cluster enough about the available {ibmcloudBMRegProductName} hardware so that it is able to fully manage it. The material difference between installing on bare metal and installing on {ibmcloudBMProductName} is that you must explicitly set the privilege level for IPMI in the BMC section of the `install-config.yaml` file.
|
||||
|
||||
.Procedure
|
||||
|
||||
@@ -59,7 +59,7 @@ pullSecret: '<pull_secret>'
|
||||
sshKey: '<ssh_pub_key>'
|
||||
----
|
||||
+
|
||||
<1> The `bmc.address` provides a `privilegelevel` configuration setting with the value set to `OPERATOR`. This is required for IBM Cloud.
|
||||
<1> The `bmc.address` provides a `privilegelevel` configuration setting with the value set to `OPERATOR`. This is required for {ibmcloudBMProductName} infrastructure.
|
||||
<2> Add the MAC address of the private `provisioning` network NIC for the corresponding node.
|
||||
+
|
||||
[NOTE]
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
[id="configuring-the-public-subnet_{context}"]
|
||||
= Configuring the public subnet
|
||||
|
||||
All of the {product-title} cluster nodes must be on the public subnet. IBM Cloud® does not provide a DHCP server on the subnet. Set it up separately on the provisioner node.
|
||||
All of the {product-title} cluster nodes must be on the public subnet. {ibmcloudBMRegProductName} does not provide a DHCP server on the subnet. Set it up separately on the provisioner node.
|
||||
|
||||
You must reset the BASH variables defined when preparing the provisioner node. Rebooting the provisioner node after preparing it will delete the BASH variables previously set.
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
:_content-type: PROCEDURE
|
||||
[id="preparing-the-provisioner-node-for-openshift-install-on-ibm-cloud_{context}"]
|
||||
= Preparing the provisioner node for {product-title} installation on IBM Cloud
|
||||
= Preparing the provisioner node on {ibmcloudBMProductName} infrastructure
|
||||
|
||||
Perform the following steps to prepare the provisioner node.
|
||||
|
||||
|
||||
@@ -3,9 +3,9 @@
|
||||
// installing_ibm_cloud/install-ibm-cloud-installing-on-ibm-cloud.adoc
|
||||
|
||||
[id="setting-up-ibm-cloud-infrastructure_{context}"]
|
||||
= Setting up IBM Cloud infrastructure
|
||||
= Setting up IBM Cloud Bare Metal (Classic) infrastructure
|
||||
|
||||
To deploy an {product-title} cluster on IBM Cloud®, you must first provision the IBM Cloud nodes.
|
||||
To deploy an {product-title} cluster on {ibmcloudBMRegProductName} infrastructure, you must first provision the IBM Cloud nodes.
|
||||
|
||||
[IMPORTANT]
|
||||
====
|
||||
@@ -29,7 +29,7 @@ Create all nodes with a single public VLAN and a single private VLAN.
|
||||
|
||||
IBM Cloud public VLAN subnets use a `/28` prefix by default, which provides 16 IP addresses. That is sufficient for a cluster consisting of three control plane nodes, four worker nodes, and two IP addresses for the API VIP and Ingress VIP on the `baremetal` network. For larger clusters, you might need a smaller prefix.
|
||||
|
||||
IBM Cloud private VLAN subnets use a `/26` prefix by default, which provides 64 IP addresses. IBM Cloud will use private network IP addresses to access the Baseboard Management Controller (BMC) of each node. {product-title} creates an additional subnet for the `provisioning` network. Network traffic for the `provisioning` network subnet routes through the private VLAN. For larger clusters, you might need a smaller prefix.
|
||||
IBM Cloud private VLAN subnets use a `/26` prefix by default, which provides 64 IP addresses. {ibmcloudBMProductName} uses private network IP addresses to access the Baseboard Management Controller (BMC) of each node. {product-title} creates an additional subnet for the `provisioning` network. Network traffic for the `provisioning` network subnet routes through the private VLAN. For larger clusters, you might need a smaller prefix.
|
||||
|
||||
.IP addresses per prefix
|
||||
[options="header"]
|
||||
@@ -138,11 +138,11 @@ Define a consistent clock date and time format in each cluster node's BIOS setti
|
||||
[discrete]
|
||||
== Configure a DHCP server
|
||||
|
||||
IBM Cloud does not run DHCP on the public or private VLANs. After provisioning IBM Cloud nodes, you must set up a DHCP server for the public VLAN, which corresponds to {product-title}'s `baremetal` network.
|
||||
{ibmcloudBMProductName} does not run DHCP on the public or private VLANs. After provisioning IBM Cloud nodes, you must set up a DHCP server for the public VLAN, which corresponds to {product-title}'s `baremetal` network.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
The IP addresses allocated to each node do not need to match the IP addresses allocated by the IBM Cloud provisioning system.
|
||||
The IP addresses allocated to each node do not need to match the IP addresses allocated by the {ibmcloudBMProductName} provisioning system.
|
||||
====
|
||||
|
||||
See the "Configuring the public subnet" section for details.
|
||||
@@ -164,7 +164,7 @@ Alternatively, contact IBM Cloud support and request that they increase the IPMI
|
||||
[discrete]
|
||||
== Create bare metal servers
|
||||
|
||||
Create bare metal servers in the link:https://cloud.ibm.com[IBM Cloud dashboard] by navigating to *Create resource* -> *Bare Metal Server*.
|
||||
Create bare metal servers in the link:https://cloud.ibm.com[IBM Cloud dashboard] by navigating to *Create resource* -> *Bare Metal Servers for Classic*.
|
||||
|
||||
Alternatively, you can create bare metal servers with the `ibmcloud` CLI utility. For example:
|
||||
|
||||
|
||||
@@ -34,7 +34,16 @@ A DNS forwarding configuration for the default domain can have both the default
|
||||
$ oc edit dns.operator/default
|
||||
----
|
||||
+
|
||||
This allows the Operator to create and update the config map named `dns-default` with additional server configuration blocks based on `Server`. If none of the servers have a zone that matches the query, then name resolution falls back to the upstream DNS servers.
|
||||
After you issue the previous command, the Operator creates and updates the config map named `dns-default` with additional server configuration blocks based on `Server`.
|
||||
ifdef::openshift-rosa,openshift-dedicated[]
|
||||
+
|
||||
[IMPORTANT]
|
||||
====
|
||||
When specifying values for the `zones` parameter, ensure that you only forward to specific zones, such as your intranet. You must specify at least one zone. Otherwise, your cluster can lose functionality.
|
||||
====
|
||||
+
|
||||
endif::[]
|
||||
If none of the servers have a zone that matches the query, then name resolution falls back to the upstream DNS servers.
|
||||
+
|
||||
.Configuring DNS forwarding
|
||||
[source,yaml]
|
||||
@@ -63,14 +72,6 @@ spec:
|
||||
----
|
||||
<1> Must comply with the `rfc6335` service name syntax.
|
||||
<2> Must conform to the definition of a subdomain in the `rfc1123` service name syntax. The cluster domain, `cluster.local`, is an invalid subdomain for the `zones` field.
|
||||
ifdef::openshift-rosa,openshift-dedicated[]
|
||||
+
|
||||
[IMPORTANT]
|
||||
====
|
||||
Only forward to specific zones, such as your intranet. You must specify at least one zone. Otherwise, your cluster can lose functionality.
|
||||
====
|
||||
+
|
||||
endif::[]
|
||||
<3> Defines the policy to select upstream resolvers. Default value is `Random`. You can also use the values `RoundRobin`, and `Sequential`.
|
||||
<4> A maximum of 15 `upstreams` is allowed per `forwardPlugin`.
|
||||
<5> Optional. You can use it to override the default policy and forward DNS resolution to the specified DNS resolvers (upstream resolvers) for the default domain. If you do not provide any upstream resolvers, the DNS name queries go to the servers in `/etc/resolv.conf`.
|
||||
@@ -79,8 +80,17 @@ endif::[]
|
||||
<8> You can specify two types of `upstreams` - `SystemResolvConf` and `Network`. `SystemResolvConf` configures the upstream to use `/etc/resolv.conf` and `Network` defines a `Networkresolver`. You can specify one or both.
|
||||
<9> If the specified type is `Network`, you must provide an IP address. The `address` field must be a valid IPv4 or IPv6 address.
|
||||
<10> If the specified type is `Network`, you can optionally provide a port. The `port` field must have a value between `1` and `65535`. If you do not specify a port for the upstream, by default port 853 is tried.
|
||||
|
||||
. Optional: When working in a highly regulated environment, you might need the ability to secure DNS traffic when forwarding requests to upstream resolvers so that you can ensure additional DNS traffic and data privacy.
|
||||
ifdef::openshift-rosa,openshift-dedicated[]
|
||||
+
|
||||
When working in a highly regulated environment, you might need the ability to secure DNS traffic when forwarding requests to upstream resolvers so that you can ensure additional DNS traffic and data privacy. Cluster administrators can configure transport layer security (TLS) for forwarded DNS queries.
|
||||
[IMPORTANT]
|
||||
====
|
||||
When specifying values for the `zones` parameter, ensure that you only forward to specific zones, such as your intranet. You must specify at least one zone. Otherwise, your cluster can lose functionality.
|
||||
====
|
||||
+
|
||||
endif::[]
|
||||
Cluster administrators can configure transport layer security (TLS) for forwarded DNS queries.
|
||||
+
|
||||
.Configuring DNS forwarding with TLS
|
||||
[source,yaml]
|
||||
@@ -119,14 +129,6 @@ spec:
|
||||
----
|
||||
<1> Must comply with the `rfc6335` service name syntax.
|
||||
<2> Must conform to the definition of a subdomain in the `rfc1123` service name syntax. The cluster domain, `cluster.local`, is an invalid subdomain for the `zones` field. The cluster domain, `cluster.local`, is an invalid `subdomain` for `zones`.
|
||||
ifdef::openshift-rosa,openshift-dedicated[]
|
||||
+
|
||||
[IMPORTANT]
|
||||
====
|
||||
Only forward to specific zones, such as your intranet. You must specify at least one zone. Otherwise, your cluster can lose functionality.
|
||||
====
|
||||
+
|
||||
endif::[]
|
||||
<3> When configuring TLS for forwarded DNS queries, set the `transport` field to have the value `TLS`.
|
||||
By default, CoreDNS caches forwarded connections for 10 seconds. CoreDNS will hold a TCP connection open for those 10 seconds if no request is issued. With large clusters, ensure that your DNS server is aware that it might get many new connections to hold open because you can initiate a connection per node. Set up your DNS hierarchy accordingly to avoid performance issues.
|
||||
<4> When configuring TLS for forwarded DNS queries, this is a mandatory server name used as part of the server name indication (SNI) to validate the upstream TLS server certificate.
|
||||
@@ -141,7 +143,9 @@ By default, CoreDNS caches forwarded connections for 10 seconds. CoreDNS will ho
|
||||
====
|
||||
If `servers` is undefined or invalid, the config map only contains the default server.
|
||||
====
|
||||
+
|
||||
|
||||
.Verification
|
||||
|
||||
. View the config map:
|
||||
+
|
||||
[source,terminal]
|
||||
|
||||
Reference in New Issue
Block a user