Este conteúdo não está disponível no idioma selecionado.
Chapter 4. Installing a cluster with customizations
Use the following procedures to install an OpenShift Container Platform cluster with customizations using the Agent-based Installer.
4.1. Prerequisites Copiar o linkLink copiado para a área de transferência!
- You reviewed details about the OpenShift Container Platform installation and update processes.
- You read the documentation on selecting a cluster installation method and preparing it for users.
- If you use a firewall or proxy, you configured it to allow the sites that your cluster requires access to.
4.2. Installing OpenShift Container Platform with the Agent-based Installer Copiar o linkLink copiado para a área de transferência!
The following procedures deploy a single-node OpenShift Container Platform in a disconnected environment. You can use these procedures as a basis and modify according to your requirements.
4.2.1. Downloading the Agent-based Installer Copiar o linkLink copiado para a área de transferência!
Procedure
Use this procedure to download the Agent-based Installer and the CLI needed for your installation.
- Log in to the OpenShift Container Platform web console using your login credentials.
- Navigate to Datacenter.
- Click Run Agent-based Installer locally.
- Select the operating system and architecture for the OpenShift Installer and Command line interface.
- Click Download Installer to download and extract the install program.
- Download or copy the pull secret by clicking on Download pull secret or Copy pull secret.
-
Click Download command-line tools and place the
openshift-installbinary in a directory that is on yourPATH.
4.2.2. Creating the preferred configuration inputs Copiar o linkLink copiado para a área de transferência!
Use this procedure to create the preferred configuration inputs used to create the agent image.
Procedure
Install
nmstatedependency by running the following command:sudo dnf install /usr/bin/nmstatectl -y
$ sudo dnf install /usr/bin/nmstatectl -yCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Place the
openshift-installbinary in a directory that is on yourPATH. Create a directory to store the install configuration by running the following command:
mkdir ~/<directory_name>
$ mkdir ~/<directory_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteThis is the preferred method for the Agent-based installation. Using GitOps ZTP manifests is optional.
Create the
install-config.yamlfile by running the following command:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Specify the system architecture, valid values are
amd64andarm64. - 2
- Required. Specify your cluster name.
- 3
- Specify the cluster network plugin to install. The supported values are
OVNKubernetesandOpenShiftSDN. The default value isOVNKubernetes. - 4
- Specify your pull secret.
- 5
- Specify your SSH public key.
NoteIf you set the platform to
vSphere,baremetal, ornone, you can configure IP address endpoints for cluster nodes in three ways:- IPv4
- IPv6
- IPv4 and IPv6 in parallel (dual-stack)
Example of dual-stack networking
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteWhen you use a disconnected mirror registry, you must add the certificate file that you created previously for your mirror registry to the
additionalTrustBundlefield of theinstall-config.yamlfile.Create the
agent-config.yamlfile by running the following command:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- This IP address is used to determine which node performs the bootstrapping process as well as running the
assisted-servicecomponent. You must provide the rendezvous IP address when you do not specify at least one host’s IP address in thenetworkConfigparameter. If this address is not provided, one IP address is selected from the provided hosts'networkConfig. - 2
- Optional: Host configuration. The number of hosts defined must not exceed the total number of hosts defined in the
install-config.yamlfile, which is the sum of the values of thecompute.replicasandcontrolPlane.replicasparameters. - 3
- Optional: Overrides the hostname obtained from either the Dynamic Host Configuration Protocol (DHCP) or a reverse DNS lookup. Each host must have a unique hostname supplied by one of these methods.
- 4
- Enables provisioning of the Red Hat Enterprise Linux CoreOS (RHCOS) image to a particular device. It examines the devices in the order it discovers them, and compares the discovered values with the hint values. It uses the first discovered device that matches the hint value.
- 5
- Optional: Configures the network interface of a host in NMState format.
4.2.3. Using ZTP manifests Copiar o linkLink copiado para a área de transferência!
As an optional task, you can use GitOps Zero Touch Provisioning (ZTP) manifests to configure your installation beyond the options available through the install-config.yaml and agent-config.yaml files.
GitOps ZTP manifests can be generated with or without configuring the install-config.yaml and agent-config.yaml files beforehand. If you chose to configure the install-config.yaml and agent-config.yaml files, the configurations will be imported to the ZTP cluster manifests when they are generated.
Prerequisites
-
You have placed the
openshift-installbinary in a directory that is on yourPATH. -
Optional: You have created and configured the
install-config.yamlandagent-config.yamlfiles.
Procedure
Generate ZTP cluster manifests by running the following command:
openshift-install agent create cluster-manifests --dir <installation_directory>
$ openshift-install agent create cluster-manifests --dir <installation_directory>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ImportantIf you have created the
install-config.yamlandagent-config.yamlfiles, those files are deleted and replaced by the cluster manifests generated through this command.Any configurations made to the
install-config.yamlandagent-config.yamlfiles are imported to the ZTP cluster manifests when you run theopenshift-install agent create cluster-manifestscommand.Navigate to the
cluster-manifestsdirectory by running the following command:cd <installation_directory>/cluster-manifests
$ cd <installation_directory>/cluster-manifestsCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Configure the manifest files in the
cluster-manifestsdirectory. For sample files, see the "Sample GitOps ZTP custom resources" section. Disconnected clusters: If you did not define mirror configuration in the
install-config.yamlfile before generating the ZTP manifests, perform the following steps:Navigate to the
mirrordirectory by running the following command:cd ../mirror
$ cd ../mirrorCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Configure the manifest files in the
mirrordirectory.
4.2.4. Creating and booting the agent image Copiar o linkLink copiado para a área de transferência!
Use this procedure to boot the agent image on your machines.
Procedure
Create the agent image by running the following command:
openshift-install --dir <install_directory> agent create image
$ openshift-install --dir <install_directory> agent create imageCopy to Clipboard Copied! Toggle word wrap Toggle overflow NoteRed Hat Enterprise Linux CoreOS (RHCOS) supports multipathing on the primary disk, allowing stronger resilience to hardware failure to achieve higher host availability. Multipathing is enabled by default in the agent ISO image, with a default
/etc/multipath.confconfiguration.-
Boot the
agent.x86_64.isooragent.aarch64.isoimage on the bare metal machines.
4.2.5. Verifying that the current installation host can pull release images Copiar o linkLink copiado para a área de transferência!
After you boot the agent image and network services are made available to the host, the agent console application performs a pull check to verify that the current host can retrieve release images.
If the primary pull check passes, you can quit the application to continue with the installation. If the pull check fails, the application performs additional checks, as seen in the Additional checks section of the TUI, to help you troubleshoot the problem. A failure for any of the additional checks is not necessarily critical as long as the primary pull check succeeds.
If there are host network configuration issues that might cause an installation to fail, you can use the console application to make adjustments to your network configurations.
If the agent console application detects host network configuration issues, the installation workflow will be halted until the user manually stops the console application and signals the intention to proceed.
Procedure
- Wait for the agent console application to check whether or not the configured release image can be pulled from a registry.
If the agent console application states that the installer connectivity checks have passed, wait for the prompt to time out to continue with the installation.
NoteYou can still choose to view or change network configuration settings even if the connectivity checks have passed.
However, if you choose to interact with the agent console application rather than letting it time out, you must manually quit the TUI to proceed with the installation.
If the agent console application checks have failed, which is indicated by a red icon beside the
Release image URLpull check, use the following steps to reconfigure the host’s network settings:Read the
Check Errorssection of the TUI. This section displays error messages specific to the failed checks.- Select Configure network to launch the NetworkManager TUI.
- Select Edit a connection and select the connection you want to reconfigure.
- Edit the configuration and select OK to save your changes.
- Select Back to return to the main screen of the NetworkManager TUI.
- Select Activate a Connection.
- Select the reconfigured network to deactivate it.
- Select the reconfigured network again to reactivate it.
- Select Back and then select Quit to return to the agent console application.
- Wait at least five seconds for the continuous network checks to restart using the new network configuration.
-
If the
Release image URLpull check succeeds and displays a green icon beside the URL, select Quit to exit the agent console application and continue with the installation.
4.2.6. Tracking and verifying installation progress Copiar o linkLink copiado para a área de transferência!
Use the following procedure to track installation progress and to verify a successful installation.
Prerequisites
- You have configured a DNS record for the Kubernetes API server.
Procedure
Optional: To know when the bootstrap host (rendezvous host) reboots, run the following command:
./openshift-install --dir <install_directory> agent wait-for bootstrap-complete \ --log-level=info$ ./openshift-install --dir <install_directory> agent wait-for bootstrap-complete \1 --log-level=info2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
................................................................... ................................................................... INFO Bootstrap configMap status is complete INFO cluster bootstrap is complete
................................................................... ................................................................... INFO Bootstrap configMap status is complete INFO cluster bootstrap is completeCopy to Clipboard Copied! Toggle word wrap Toggle overflow The command succeeds when the Kubernetes API server signals that it has been bootstrapped on the control plane machines.
To track the progress and verify successful installation, run the following command:
openshift-install --dir <install_directory> agent wait-for install-complete
$ openshift-install --dir <install_directory> agent wait-for install-complete1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- For
<install_directory>directory, specify the path to the directory where the agent ISO was generated.
Example output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
If you are using the optional method of GitOps ZTP manifests, you can configure IP address endpoints for cluster nodes through the AgentClusterInstall.yaml file in three ways:
- IPv4
- IPv6
- IPv4 and IPv6 in parallel (dual-stack)
IPv6 is supported only on bare metal platforms.
Example of dual-stack networking
4.3. Sample GitOps ZTP custom resources Copiar o linkLink copiado para a área de transferência!
You can optionally use GitOps Zero Touch Provisioning (ZTP) custom resource (CR) objects to install an OpenShift Container Platform cluster with the Agent-based Installer.
You can customize the following GitOps ZTP custom resources to specify more details about your OpenShift Container Platform cluster. The following sample GitOps ZTP custom resources are for a single-node cluster.
Example agent-cluster-install.yaml file
Example cluster-deployment.yaml file
Example cluster-image-set.yaml file
Example infra-env.yaml file
Example nmstateconfig.yaml file
Example pull-secret.yaml file
4.4. Gathering log data from a failed Agent-based installation Copiar o linkLink copiado para a área de transferência!
Use the following procedure to gather log data about a failed Agent-based installation to provide for a support case.
Prerequisites
- You have configured a DNS record for the Kubernetes API server.
Procedure
Run the following command and collect the output:
./openshift-install --dir <installation_directory> agent wait-for bootstrap-complete --log-level=debug
$ ./openshift-install --dir <installation_directory> agent wait-for bootstrap-complete --log-level=debugCopy to Clipboard Copied! Toggle word wrap Toggle overflow Example error message
... ERROR Bootstrap failed to complete: : bootstrap process timed out: context deadline exceeded
... ERROR Bootstrap failed to complete: : bootstrap process timed out: context deadline exceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow If the output from the previous command indicates a failure, or if the bootstrap is not progressing, run the following command to connect to the rendezvous host and collect the output:
ssh core@<node-ip> agent-gather -O >agent-gather.tar.xz
$ ssh core@<node-ip> agent-gather -O >agent-gather.tar.xzCopy to Clipboard Copied! Toggle word wrap Toggle overflow NoteRed Hat Support can diagnose most issues using the data gathered from the rendezvous host, but if some hosts are not able to register, gathering this data from every host might be helpful.
If the bootstrap completes and the cluster nodes reboot, run the following command and collect the output:
./openshift-install --dir <install_directory> agent wait-for install-complete --log-level=debug
$ ./openshift-install --dir <install_directory> agent wait-for install-complete --log-level=debugCopy to Clipboard Copied! Toggle word wrap Toggle overflow If the output from the previous command indicates a failure, perform the following steps:
Export the
kubeconfigfile to your environment by running the following command:export KUBECONFIG=<install_directory>/auth/kubeconfig
$ export KUBECONFIG=<install_directory>/auth/kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow Gather information for debugging by running the following command:
oc adm must-gather
$ oc adm must-gatherCopy to Clipboard Copied! Toggle word wrap Toggle overflow Create a compressed file from the
must-gatherdirectory that was just created in your working directory by running the following command:tar cvaf must-gather.tar.gz <must_gather_directory>
$ tar cvaf must-gather.tar.gz <must_gather_directory>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
Excluding the
/authsubdirectory, attach the installation directory used during the deployment to your support case on the Red Hat Customer Portal. - Attach all other data gathered from this procedure to your support case.