Skip to content

Installing a two-node OpenShift cluster with fencing

Important

Two-node OpenShift cluster with fencing is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.

You can deploy a two-node OpenShift cluster with fencing by using either the installer-provisioned infrastructure or the user-provisioned infrastructure installation method. The following examples provide sample install-config.yaml configurations for both methods.

Sample install-config.yaml for a two-node installer-provisioned infrastructure cluster with fencing

You can use the following install-config.yaml configuration as a template for deploying a two-node OpenShift cluster with fencing by using the installer-provisioned infrastructure method:

Note

Do an etcd backup before proceeding to ensure that you can restore the cluster if any issues occur.

Sample install-config.yaml configuration
apiVersion: v1
baseDomain: example.com
compute:
- name: worker
  replicas: 0
controlPlane:
  name: master
  replicas: 2
  fencing:
    credentials:
      - hostname: <control_0_hostname>
        address: https://<redfish-api-url>
        username: <username>
        password: <password>
        certificateVerification: Disabled
      - hostname: <control_1_hostname>
        address: https://<redfish-api-url>
        username: <username>
        password: <password>
        certificateVerification: Enabled
metadata:
  name: <cluster_name>
featureSet: TechPreviewNoUpgrade
platform:
  baremetal:
    apiVIPs:
      - <api_ip>
    ingressVIPs:
      - <wildcard_ip>
    hosts:
      - name: <control_0_hostname>
        role: master
        bmc:
          address: <bmc_address>
          username: <bmc_username>
          password: <bmc_password>
        bootMACAddress: <boot_mac>
      - name: <control_1_hostname>
        role: master
        bmc:
          address: <bmc_address>
          username: <bmc_username>
          password: <bmc_password>
        bootMACAddress: <boot_mac>
pullSecret: '<pull_secret>'
sshKey: '<ssh_public_key>'

  • compute.replicas: Set this field to 0 because a two-node fencing cluster does not include worker nodes.

  • controlPlane.replicas: Set this field to 2 for a two-node fencing deployment.

  • fencing.credentials.hostname: Provide the Baseboard Management Console (BMC) credentials for each control plane node. These credentials are required for node fencing and prevent split-brain scenarios.

  • fencing.credentials.certificateVerification: Set this field to Disabled if your Redfish URL uses self-signed certificates, which is common for internally-hosted endpoints. Set this field to Enabled for URLs with valid CA-signed certificates.

  • metadata.name: The cluster name is used as a prefix for hostnames and DNS records.

  • featureSet: Set this field to TechPreviewNoUpgrade to enable two-node OpenShift cluster deployments.

  • platform.baremetal.apiVIPs and platform.baremetal.ingressVIPs : Virtual IPs for the API and Ingress endpoints. Ensure they are reachable by all nodes and external clients.

  • pullSecret: Contains credentials required to pull container images for the cluster components.

  • sshKey: The SSH public key for accessing cluster nodes after installation.

Sample install-config.yaml for a two-node user-provisioned infrastructure cluster with fencing

You can use the following install-config.yaml configuration as a template for deploying a two-node OpenShift cluster with fencing by using the user-provisioned infrastructure method:

Note

Do an etcd backup before proceeding to ensure that you can restore the cluster if any issues occur.

Sample install-config.yaml configuration
apiVersion: v1
baseDomain: example.com
compute:
- name: worker
  replicas: 0
controlPlane:
  name: master
  replicas: 2
  fencing:
    credentials:
      - hostname: <control_0_hostname>
        address: https://<redfish-api-url>
        username: <username>
        password: <password>
      - hostname: <control_1_hostname>
        address: https://<redfish-api-url>
        username: <username>
        password: <password>
metadata:
  name: <cluster_name>
featureSet: TechPreviewNoUpgrade
platform:
  none: {}
pullSecret: '<pull_secret>'
sshKey: '<ssh_public_key>'

  • compute.replicas: Set this field to 0 because a two-node fencing cluster does not include worker nodes.

  • controlPlane.replicas: Set this field to 2 for a two-node fencing deployment.

  • fencing.credentials.hostname: Provide BMC credentials for each control plane node.

  • metadata.name: Cluster name is used as a prefix for hostnames and DNS records.

  • featureSet: Enables two-node OpenShift cluster deployments.

  • platform.none Set the platform to none for user-provisioned infrastructure deployments. Bare-metal hosts are pre-provisioned outside of the installation program.

  • pullSecret: Contains credentials required to pull container images for the cluster components.

  • sshKey: The SSH public key for accessing cluster nodes after installation.