openshift-docs/modules/ztp-adding-worker-nodes.adoc

// Module included in the following assemblies:
//
// * scalability_and_performance/ztp_far_edge/ztp-sno-additional-worker-node.adoc

:_mod-docs-content-type: PROCEDURE
[id="ztp-additional-worker-sno-proc_{context}"]
= Adding an additional worker node {sno} clusters with {ztp}

You can add an additional worker node to existing {sno} clusters to increase available CPU resources in the cluster.

.Prerequisites

* Install and configure {rh-rhacm} 2.12 or later in an {product-title} 4.11 or later bare-metal hub cluster
* Install {cgu-operator-full} in the hub cluster
* Install {gitops-title} in the hub cluster
* Use the {ztp} `ztp-site-generate` container image version 4.12 or later
* Deploy a managed {sno} cluster with {ztp}
* Configure the Central Infrastructure Management as described in the {rh-rhacm} documentation
* Configure the DNS serving the cluster to resolve the internal API endpoint `api-int.<cluster_name>.<base_domain>`

.Procedure

. If you deployed your cluster by using the `example-sno.yaml` `ClusterInstance` CR, add your new worker node to the `spec.nodes` list:
+
[source,yaml]
----
apiVersion: siteconfig.open-cluster-management.io/v1alpha1
kind: ClusterInstance
metadata:
  name: "example-sno"
  namespace: "example-sno"
spec:
  # ... existing cluster configuration ...
  nodes:
      - hostName: "example-sno.example.com"
        role: "master"
        # ... existing master node configuration ...
      - hostName: "example-node2.example.com"
        role: "worker"
        bmcAddress: "idrac-virtualmedia+https://[1111:2222:3333:4444::bbbb:1]/redfish/v1/Systems/System.Embedded.1"
        bmcCredentialsName:
          name: "example-node2-bmh-secret"
        bootMACAddress: "AA:BB:CC:DD:EE:11"
        bootMode: "UEFI"
        nodeNetwork:
          interfaces:
            - name: eno1
              macAddress: "AA:BB:CC:DD:EE:11"
          config:
            interfaces:
              - name: eno1
                type: ethernet
                state: up
                macAddress: "AA:BB:CC:DD:EE:11"
                ipv4:
                  enabled: false
                ipv6:
                  enabled: true
                  address:
                  - ip: 1111:2222:3333:4444::1
                    prefix-length: 64
            dns-resolver:
              config:
                search:
                - example.com
                server:
                - 1111:2222:3333:4444::2
            routes:
              config:
              - destination: ::/0
                next-hop-interface: eno1
                next-hop-address: 1111:2222:3333:4444::1
                table-id: 254
----

. Create a BMC authentication secret for the new host, as referenced by the `bmcCredentialsName` field in the `spec.nodes` section of your `ClusterInstance` CR:
+
[source,yaml]
----
apiVersion: v1
data:
  password: "password"
  username: "username"
kind: Secret
metadata:
  name: "example-node2-bmh-secret"
  namespace: example-sno
type: Opaque
----

. Commit the changes in Git, and then push to the Git repository that is being monitored by the {ztp} ArgoCD application.
+
When the ArgoCD `cluster` application synchronizes, two new manifests appear on the hub cluster generated by the SiteConfig Operator:
+
* `BareMetalHost`
* `NMStateConfig`
+
[IMPORTANT]
====
The `cpuset` field should not be configured for the worker node. Workload partitioning for the worker node is added through management policies after the node installation is complete.
====

.Verification

You can monitor the installation process in several ways.

* Check if the preprovisioning images are created by running the following command:
+
[source,terminal]
----
$ oc get ppimg -n example-sno
----
+
.Example output
[source,terminal]
----
NAMESPACE       NAME            READY   REASON
example-sno     example-sno     True    ImageCreated
example-sno     example-node2   True    ImageCreated
----

* Check the state of the bare-metal hosts:
+
[source,terminal]
----
$ oc get bmh -n example-sno
----
+
.Example output
[source,terminal]
----
NAME            STATE          CONSUMER   ONLINE   ERROR   AGE
example-sno     provisioned               true             69m
example-node2   provisioning              true             4m50s <1>
----
<1> The `provisioning` state indicates that node booting from the installation media is in progress.

* Continuously monitor the installation process:

.. Watch the agent install process by running the following command:
+
[source,terminal]
----
$ oc get agent -n example-sno --watch
----
+
.Example output
[source,terminal]
----
NAME                                   CLUSTER   APPROVED   ROLE     STAGE
671bc05d-5358-8940-ec12-d9ad22804faa   example-sno   true       master   Done
[...]
14fd821b-a35d-9cba-7978-00ddf535ff37   example-sno   true       worker   Starting installation
14fd821b-a35d-9cba-7978-00ddf535ff37   example-sno   true       worker   Installing
14fd821b-a35d-9cba-7978-00ddf535ff37   example-sno   true       worker   Writing image to disk
[...]
14fd821b-a35d-9cba-7978-00ddf535ff37   example-sno   true       worker   Waiting for control plane
[...]
14fd821b-a35d-9cba-7978-00ddf535ff37   example-sno   true       worker   Rebooting
14fd821b-a35d-9cba-7978-00ddf535ff37   example-sno   true       worker   Done
----

.. When the worker node installation is finished, the worker node certificates are approved automatically. At this point, the worker appears in the `ManagedClusterInfo` status. Run the following command to see the status:
+
[source,terminal]
----
$ oc get managedclusterinfo/example-sno -n example-sno -o \
jsonpath='{range .status.nodeList[*]}{.name}{"\t"}{.conditions}{"\t"}{.labels}{"\n"}{end}'
----
+
.Example output
[source,terminal]
----
example-sno	[{"status":"True","type":"Ready"}]	{"node-role.kubernetes.io/master":"","node-role.kubernetes.io/worker":""}
example-node2	[{"status":"True","type":"Ready"}]	{"node-role.kubernetes.io/worker":""}
----