mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
f281db32b6
This commit break long command-line prompts into multiple lines so that the command is visible without scrolling.
127 lines
5.2 KiB
Plaintext
127 lines
5.2 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * hosted_control_planes/hcp-manage/hcp-manage-bm.adoc
|
|
// * hosted_control_planes/hcp-manage/hcp-manage-non-bm.adoc
|
|
|
|
:_mod-docs-content-type: PROCEDURE
|
|
[id="hcp-bm-scale-np_{context}"]
|
|
= Scaling the NodePool object for a hosted cluster
|
|
|
|
You can scale up the `NodePool` object by adding nodes to your hosted cluster. When you scale a node pool, consider the following information:
|
|
|
|
- When you scale a replica by the node pool, a machine is created. For every machine, the Cluster API provider finds and installs an Agent that meets the requirements that are specified in the node pool specification. You can monitor the installation of an Agent by checking its status and conditions.
|
|
|
|
- When you scale down a node pool, Agents are unbound from the corresponding cluster. Before you can reuse the Agents, you must restart them by using the Discovery image.
|
|
|
|
.Procedure
|
|
|
|
. Scale the `NodePool` object to two nodes:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ oc -n <hosted_cluster_namespace> scale nodepool <nodepool_name> --replicas 2
|
|
----
|
|
+
|
|
The Cluster API agent provider randomly picks two agents that are then assigned to the hosted cluster. Those agents go through different states and finally join the hosted cluster as {product-title} nodes. The agents pass through states in the following order:
|
|
+
|
|
* `binding`
|
|
* `discovering`
|
|
* `insufficient`
|
|
* `installing`
|
|
* `installing-in-progress`
|
|
* `added-to-existing-cluster`
|
|
|
|
. Enter the following command:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ oc -n <hosted_control_plane_namespace> get agent
|
|
----
|
|
+
|
|
.Example output
|
|
[source,terminal]
|
|
----
|
|
NAME CLUSTER APPROVED ROLE STAGE
|
|
4dac1ab2-7dd5-4894-a220-6a3473b67ee6 hypercluster1 true auto-assign
|
|
d9198891-39f4-4930-a679-65fb142b108b true auto-assign
|
|
da503cf1-a347-44f2-875c-4960ddb04091 hypercluster1 true auto-assign
|
|
----
|
|
|
|
. Enter the following command:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ oc -n <hosted_control_plane_namespace> get agent \
|
|
-o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}'
|
|
----
|
|
+
|
|
.Example output
|
|
[source,terminal]
|
|
----
|
|
BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: binding
|
|
BMH: ocp-worker-0 Agent: d9198891-39f4-4930-a679-65fb142b108b State: known-unbound
|
|
BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: insufficient
|
|
----
|
|
|
|
. Obtain the kubeconfig for your new hosted cluster by entering the extract command:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ oc extract -n <hosted_cluster_namespace> \
|
|
secret/<hosted_cluster_name>-admin-kubeconfig --to=- \
|
|
> kubeconfig-<hosted_cluster_name>
|
|
----
|
|
|
|
. After the agents reach the `added-to-existing-cluster` state, verify that you can see the {product-title} nodes in the hosted cluster by entering the following command:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ oc --kubeconfig kubeconfig-<hosted_cluster_name> get nodes
|
|
----
|
|
+
|
|
.Example output
|
|
[source,terminal]
|
|
----
|
|
NAME STATUS ROLES AGE VERSION
|
|
ocp-worker-1 Ready worker 5m41s v1.24.0+3882f8f
|
|
ocp-worker-2 Ready worker 6m3s v1.24.0+3882f8f
|
|
----
|
|
+
|
|
Cluster Operators start to reconcile by adding workloads to the nodes.
|
|
|
|
. Enter the following command to verify that two machines were created when you scaled up the `NodePool` object:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ oc -n <hosted_control_plane_namespace> get machines
|
|
----
|
|
+
|
|
.Example output
|
|
[source,terminal]
|
|
----
|
|
NAME CLUSTER NODENAME PROVIDERID PHASE AGE VERSION
|
|
hypercluster1-c96b6f675-m5vch hypercluster1-b2qhl ocp-worker-1 agent://da503cf1-a347-44f2-875c-4960ddb04091 Running 15m 4.x.z
|
|
hypercluster1-c96b6f675-tl42p hypercluster1-b2qhl ocp-worker-2 agent://4dac1ab2-7dd5-4894-a220-6a3473b67ee6 Running 15m 4.x.z
|
|
----
|
|
+
|
|
The `clusterversion` reconcile process eventually reaches a point where only Ingress and Console cluster operators are missing.
|
|
|
|
. Enter the following command:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ oc --kubeconfig kubeconfig-<hosted_cluster_name> get clusterversion,co
|
|
----
|
|
+
|
|
.Example output
|
|
[source,terminal]
|
|
----
|
|
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS
|
|
clusterversion.config.openshift.io/version False True 40m Unable to apply 4.x.z: the cluster operator console has not yet successfully rolled out
|
|
|
|
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE
|
|
clusteroperator.config.openshift.io/console 4.12z False False False 11m RouteHealthAvailable: failed to GET route (https://console-openshift-console.apps.hypercluster1.domain.com): Get "https://console-openshift-console.apps.hypercluster1.domain.com": dial tcp 10.19.3.29:443: connect: connection refused
|
|
clusteroperator.config.openshift.io/csi-snapshot-controller 4.12z True False False 10m
|
|
clusteroperator.config.openshift.io/dns 4.12z True False False 9m16s
|
|
----
|