Installer-provisioned post-installation configuration

After successfully deploying an installer-provisioned cluster, consider the following post-installation procedures.

(Optional) Configuring NTP for disconnected clusters

OKD installs the chrony Network Time Protocol (NTP) service on the cluster nodes. Use the following procedure to configure NTP servers on the control plane nodes and configure worker nodes as NTP clients of the control plane nodes after a successful deployment.

Configuring NTP for disconnected clusters

OKD nodes must agree on a date and time to run properly. When worker nodes retrieve the date and time from the NTP servers on the control plane nodes, it enables the installation and operation of clusters that are not connected to a routable network and thereby do not have access to a higher stratum NTP server.

Procedure

  1. Create a Butane config, 99-master-chrony-conf-override.bu, including the contents of the chrony.conf file for the control plane nodes.

    See “Creating machine configs with Butane” for information about Butane.

    Butane config example

    1. variant: openshift
    2. version: 4.10.0
    3. metadata:
    4.   name: 99-master-chrony-conf-override
    5.   labels:
    6.     machineconfiguration.openshift.io/role: master
    7. storage:
    8.   files:
    9.     - path: /etc/chrony.conf
    10.       mode: 0644
    11.       overwrite: true
    12.       contents:
    13.         inline: |
    14.           # Use public servers from the pool.ntp.org project.
    15.           # Please consider joining the pool (https://www.pool.ntp.org/join.html).
    17.           # The Machine Config Operator manages this file
    18.           server openshift-master-0.<cluster-name>.<domain> iburst (1)
    19.           server openshift-master-1.<cluster-name>.<domain> iburst
    20.           server openshift-master-2.<cluster-name>.<domain> iburst
    22.           stratumweight 0
    23.           driftfile /var/lib/chrony/drift
    24.           rtcsync
    25.           makestep 10 3
    26.           bindcmdaddress 127.0.0.1
    27.           bindcmdaddress ::1
    28.           keyfile /etc/chrony.keys
    29.           commandkey 1
    30.           generatecommandkey
    31.           noclientlog
    32.           logchange 0.5
    33.           logdir /var/log/chrony
    35.           # Configure the control plane nodes to serve as local NTP servers
    36.           # for all worker nodes, even if they are not in sync with an
    37.           # upstream NTP server.
    39.           # Allow NTP client access from the local network.
    40.           allow all
    41.           # Serve time even if not synchronized to a time source.
    42.           local stratum 3 orphan
    1You must replace <cluster-name> with the name of the cluster and replace <domain> with the fully qualified domain name.

  2. Use Butane to generate a MachineConfig object file, 99-master-chrony-conf-override.yaml, containing the configuration to be delivered to the control plane nodes:

    1. $ butane 99-master-chrony-conf-override.bu -o 99-master-chrony-conf-override.yaml

  3. Create a Butane config, 99-worker-chrony-conf-override.bu, including the contents of the chrony.conf file for the worker nodes that references the NTP servers on the control plane nodes.

    Butane config example

    1. variant: openshift
    2. version: 4.10.0
    3. metadata:
    4.   name: 99-worker-chrony-conf-override
    5.   labels:
    6.     machineconfiguration.openshift.io/role: worker
    7. storage:
    8.   files:
    9.     - path: /etc/chrony.conf
    10.       mode: 0644
    11.       overwrite: true
    12.       contents:
    13.         inline: |
    14.           # The Machine Config Operator manages this file.
    15.           server openshift-master-0.<cluster-name>.<domain> iburst (1)
    16.           server openshift-master-1.<cluster-name>.<domain> iburst
    17.           server openshift-master-2.<cluster-name>.<domain> iburst
    19.           stratumweight 0
    20.           driftfile /var/lib/chrony/drift
    21.           rtcsync
    22.           makestep 10 3
    23.           bindcmdaddress 127.0.0.1
    24.           bindcmdaddress ::1
    25.           keyfile /etc/chrony.keys
    26.           commandkey 1
    27.           generatecommandkey
    28.           noclientlog
    29.           logchange 0.5
    30.           logdir /var/log/chrony
    1You must replace <cluster-name> with the name of the cluster and replace <domain> with the fully qualified domain name.

  4. Use Butane to generate a MachineConfig object file, 99-worker-chrony-conf-override.yaml, containing the configuration to be delivered to the worker nodes:

    1. $ butane 99-worker-chrony-conf-override.bu -o 99-worker-chrony-conf-override.yaml

  5. Apply the 99-master-chrony-conf-override.yaml policy to the control plane nodes.

    1. $ oc apply -f 99-master-chrony-conf-override.yaml

    Example output

    1. machineconfig.machineconfiguration.openshift.io/99-master-chrony-conf-override created

  6. Apply the 99-worker-chrony-conf-override.yaml policy to the worker nodes.

    1. $ oc apply -f 99-worker-chrony-conf-override.yaml

    Example output

    1. machineconfig.machineconfiguration.openshift.io/99-worker-chrony-conf-override created

  7. Check the status of the applied NTP settings.

    1. $ oc describe machineconfigpool

Enabling a provisioning network after installation

The assisted installer and installer-provisioned installation for bare metal clusters provide the ability to deploy a cluster without a provisioning network. This capability is for scenarios such as proof-of-concept clusters or deploying exclusively with Redfish virtual media when each node’s baseboard management controller is routable via the baremetal network.

You can enable a provisioning network after installation using the Cluster Baremetal Operator (CBO).

Prerequisites

  • A dedicated physical network must exist, connected to all worker and control plane nodes.

  • You must isolate the native, untagged physical network.

  • The network cannot have a DHCP server when the provisioningNetwork configuration setting is set to Managed.

  • You can omit the provisioningInterface setting in OKD 4.10 to use the bootMACAddress configuration setting.

Procedure

  1. When setting the provisioningInterface setting, first identify the provisioning interface name for the cluster nodes. For example, eth0 or eno1.

  2. Enable the Preboot eXecution Environment (PXE) on the provisioning network interface of the cluster nodes.

  3. Retrieve the current state of the provisioning network and save it to a provisioning custom resource (CR) file:

    1. $ oc get provisioning -o yaml > enable-provisioning-nw.yaml

  4. Modify the provisioning CR file:

    1. $ vim ~/enable-provisioning-nw.yaml

    Scroll down to the provisioningNetwork configuration setting and change it from Disabled to Managed. Then, add the provisioningOSDownloadURL, provisioningIP, provisioningNetworkCIDR, provisioningDHCPRange, provisioningInterface, and watchAllNameSpaces configuration settings after the provisioningNetwork setting. Provide appropriate values for each setting.

    1. apiVersion: v1
    2. items:
    3. - apiVersion: metal3.io/v1alpha1
    4.   kind: Provisioning
    5.   metadata:
    6.     name: provisioning-configuration
    7.   spec:
    8.     provisioningNetwork: (1)
    9.     provisioningOSDownloadURL: (2)
    10.     provisioningIP: (3)
    11.     provisioningNetworkCIDR: (4)
    12.     provisioningDHCPRange: (5)
    13.     provisioningInterface: (6)
    14.     watchAllNameSpaces: (7)
    1The provisioningNetwork is one of Managed, Unmanaged, or Disabled. When set to Managed, Metal3 manages the provisioning network and the CBO deploys the Metal3 pod with a configured DHCP server. When set to Unmanaged, the system administrator configures the DHCP server manually.
    2The provisioningOSDownloadURL is a valid HTTPS URL with a valid sha256 checksum that enables the Metal3 pod to download a qcow2 operating system image ending in .qcow2.gz or .qcow2.xz. This field is required whether the provisioning network is Managed, Unmanaged, or Disabled. For example: http://192.168.0.1/images/rhcos-<version>.x86_64.qcow2.gz?sha256=<sha>.
    3The provisioningIP is the static IP address that the DHCP server and ironic use to provision the network. This static IP address must be within the provisioning subnet, and outside of the DHCP range. If you configure this setting, it must have a valid IP address even if the provisioning network is Disabled. The static IP address is bound to the metal3 pod. If the metal3 pod fails and moves to another server, the static IP address also moves to the new server.
    4The Classless Inter-Domain Routing (CIDR) address. If you configure this setting, it must have a valid CIDR address even if the provisioning network is Disabled. For example: 192.168.0.1/24.
    5The DHCP range. This setting is only applicable to a Managed provisioning network. Omit this configuration setting if the provisioning network is Disabled. For example: 192.168.0.64, 192.168.0.253.
    6The NIC name for the provisioning interface on cluster nodes. The provisioningInterface setting is only applicable to Managed and Unmanaged provisioning networks. Omit the provisioningInterface configuration setting if the provisioning network is Disabled. Omit the provisioningInterface configuration setting to use the bootMACAddress configuration setting instead.
    7Set this setting to true if you want metal3 to watch namespaces other than the default openshift-machine-api namespace. The default value is false.

  5. Save the changes to the provisioning CR file.

  6. Apply the provisioning CR file to the cluster:

    1. $ oc apply -f enable-provisioning-nw.yaml

Configuring an external load balancer

You can configure an OKD cluster to use an external load balancer in place of the default load balancer.

Prerequisites

  • On your load balancer, TCP over ports 6443, 443, and 80 must be available to any users of your system.

  • Load balance the API port, 6443, between each of the control plane nodes.

  • Load balance the application ports, 443 and 80, between all of the compute nodes.

  • On your load balancer, port 22623, which is used to serve ignition startup configurations to nodes, is not exposed outside of the cluster.

  • Your load balancer must be able to access every machine in your cluster. Methods to allow this access include:

    • Attaching the load balancer to the cluster’s machine subnet.

    • Attaching floating IP addresses to machines that use the load balancer.

External load balancing services and the control plane nodes must run on the same L2 network, and on the same VLAN when using VLANs to route traffic between the load balancing services and the control plane nodes.

Procedure

  1. Enable access to the cluster from your load balancer on ports 6443, 443, and 80.

    As an example, note this HAProxy configuration:

    A section of a sample HAProxy configuration

    1. ...
    2. listen my-cluster-api-6443
    3.     bind 0.0.0.0:6443
    4.     mode tcp
    5.     balance roundrobin
    6.     server my-cluster-master-2 192.0.2.2:6443 check
    7.     server my-cluster-master-0 192.0.2.3:6443 check
    8.     server my-cluster-master-1 192.0.2.1:6443 check
    9. listenmy-cluster-apps-443
    10.         bind 0.0.0.0:443
    11.         mode tcp
    12.         balance roundrobin
    13.         server my-cluster-worker-0 192.0.2.6:443 check
    14.         server my-cluster-worker-1 192.0.2.5:443 check
    15.         server my-cluster-worker-2 192.0.2.4:443 check
    16. listenmy-cluster-apps-80
    17.         bind 0.0.0.0:80
    18.         mode tcp
    19.         balance roundrobin
    20.         server my-cluster-worker-0 192.0.2.7:80 check
    21.         server my-cluster-worker-1 192.0.2.9:80 check
    22.         server my-cluster-worker-2 192.0.2.8:80 check

  2. Add records to your DNS server for the cluster API and apps over the load balancer. For example:

    1. <load_balancer_ip_address> api.<cluster_name>.<base_domain>
    2. <load_balancer_ip_address> apps.<cluster_name>.<base_domain>

  3. From a command line, use curl to verify that the external load balancer and DNS configuration are operational.

    1. Verify that the cluster API is accessible:

      1. $ curl https://<loadbalancer_ip_address>:6443/version --insecure

      If the configuration is correct, you receive a JSON object in response:

      1. {
      2.   "major": "1",
      3.   "minor": "11+",
      4.   "gitVersion": "v1.11.0+ad103ed",
      5.   "gitCommit": "ad103ed",
      6.   "gitTreeState": "clean",
      7.   "buildDate": "2019-01-09T06:44:10Z",
      8.   "goVersion": "go1.10.3",
      9.   "compiler": "gc",
      10.   "platform": "linux/amd64"
      11. }

    2. Verify that cluster applications are accessible:

      You can also verify application accessibility by opening the OKD console in a web browser.

      1. $ curl http://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure

      If the configuration is correct, you receive an HTTP response:

      1. HTTP/1.1 302 Found
      2. content-length: 0
      3. location: https://console-openshift-console.apps.<cluster-name>.<base domain>/
      4. cache-control: no-cacheHTTP/1.1 200 OK
      5. referrer-policy: strict-origin-when-cross-origin
      6. set-cookie: csrf-token=39HoZgztDnzjJkq/JuLJMeoKNXlfiVv2YgZc09c3TBOBU4NI6kDXaJH1LdicNhN1UsQWzon4Dor9GWGfopaTEQ==; Path=/; Secure
      7. x-content-type-options: nosniff
      8. x-dns-prefetch-control: off
      9. x-frame-options: DENY
      10. x-xss-protection: 1; mode=block
      11. date: Tue, 17 Nov 2020 08:42:10 GMT
      12. content-type: text/html; charset=utf-8
      13. set-cookie: 1e2670d92730b515ce3a1bb65da45062=9b714eb87e93cf34853e87a92d6894be; path=/; HttpOnly; Secure; SameSite=None
      14. cache-control: private