-
Notifications
You must be signed in to change notification settings - Fork 1.9k
OCPDOCS CQA MACH-6: CPMSO Provider Configurations and Health Checks Redux #117206
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,62 @@ | ||
| // Module included in the following assemblies: | ||
| // | ||
| // * machine_management/deploying-machine-health-checks.adoc | ||
| // * post_installation_configuration/node-tasks.adoc | ||
|
|
||
| :_mod-docs-content-type: CONCEPT | ||
| [id="machine-health-checks-short-circuiting_{context}"] | ||
| = About short-circuiting machine health check remediation | ||
|
|
||
| [role="_abstract"] | ||
| You can use machine health check short-circuiting to ensure that machine health checks remediate machines only when the cluster is healthy, by configuring the `maxUnhealthy` field in the `MachineHealthCheck` resource. | ||
|
|
||
|
mburke5678 marked this conversation as resolved.
|
||
| If you define a value for the `maxUnhealthy` field, before remediating any machines, the `MachineHealthCheck` compares the value of `maxUnhealthy` with the number of machines within its target pool that it has determined to be unhealthy. Remediation is not performed if the number of unhealthy machines exceeds the `maxUnhealthy` limit. | ||
|
|
||
| [IMPORTANT] | ||
| ==== | ||
| If `maxUnhealthy` is not set, the value defaults to `100%` and the machines are remediated regardless of the state of the cluster. | ||
| ==== | ||
|
|
||
| The appropriate `maxUnhealthy` value depends on the scale of the cluster you deploy and how many machines the `MachineHealthCheck` covers. For example, you can use the `maxUnhealthy` value to cover multiple compute machine sets across multiple availability zones so that if you lose an entire zone, your `maxUnhealthy` setting prevents further remediation within the cluster. In global Azure regions that do not have multiple availability zones, you can use availability sets to ensure high availability. | ||
|
|
||
| [IMPORTANT] | ||
| ==== | ||
| If you configure a `MachineHealthCheck` resource for the control plane, set the value of `maxUnhealthy` to `1`. | ||
|
|
||
| This configuration ensures that the machine health check takes no action when multiple control plane machines appear to be unhealthy. Multiple unhealthy control plane machines can indicate that the etcd cluster is degraded or that a scaling operation to replace a failed machine is in progress. | ||
|
|
||
| If the etcd cluster is degraded, manual intervention might be required. If a scaling operation is in progress, the machine health check should allow it to finish. | ||
| ==== | ||
|
|
||
| The `maxUnhealthy` field can be set as either an integer or percentage. | ||
| There are different remediation implementations depending on the `maxUnhealthy` value. | ||
|
|
||
| Setting maxUnhealthy by using an absolute value:: | ||
| If `maxUnhealthy` is set to `2`: | ||
| + | ||
| -- | ||
| * Remediation will be performed if 2 or fewer nodes are unhealthy | ||
| * Remediation will not be performed if 3 or more nodes are unhealthy | ||
| -- | ||
| + | ||
| These values are independent of how many machines are being checked by the machine health check. | ||
|
|
||
| Setting maxUnhealthy by using percentages:: | ||
| If `maxUnhealthy` is set to `40%` and there are 25 machines being checked: | ||
| + | ||
| -- | ||
| * Remediation will be performed if 10 or fewer nodes are unhealthy | ||
| * Remediation will not be performed if 11 or more nodes are unhealthy | ||
| -- | ||
| + | ||
| If `maxUnhealthy` is set to `40%` and there are 6 machines being checked: | ||
| + | ||
| -- | ||
| * Remediation will be performed if 2 or fewer nodes are unhealthy | ||
| * Remediation will not be performed if 3 or more nodes are unhealthy | ||
| -- | ||
| + | ||
| [NOTE] | ||
| ==== | ||
| The allowed number of machines is rounded down when the percentage of `maxUnhealthy` machines that are checked is not a whole number. | ||
| ==== | ||
|
mburke5678 marked this conversation as resolved.
|
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,131 @@ | ||
| // Module included in the following assemblies: | ||
|
|
||
| // * machine_management/deploying-machine-health-checks.adoc | ||
|
|
||
| :_mod-docs-content-type: PROCEDURE | ||
| [id="mgmt-power-remediation-baremetal-about-creating-mhc-baremetal_{context}"] | ||
| = Creating a MachineHealthCheck resource for bare metal | ||
|
|
||
| [role="_abstract"] | ||
| You control how a machine health check remediates unhealthy machines by using a `MachineHealthCheck` resource to configure health criteria, remediation limits, and startup timeouts for machines in a targeted pool. | ||
|
|
||
|
mburke5678 marked this conversation as resolved.
|
||
| .Prerequisites | ||
|
|
||
| * The {product-title} is installed using installer-provisioned infrastructure. | ||
| * Access to Baseboard Management Controller (BMC) credentials or BMC access to each node. | ||
| * Network access to the BMC interface of the unhealthy node. | ||
| * For a metal3-based remediation, a `Metal3RemediationTemplate` resource must exist. | ||
| + | ||
| .Sample `Metal3RemediationTemplate` resource for bare metal, metal3-based remediation | ||
| [source,yaml] | ||
| ---- | ||
| apiVersion: infrastructure.cluster.x-k8s.io/v1beta1 | ||
| kind: Metal3RemediationTemplate | ||
| metadata: | ||
| name: metal3-remediation-template | ||
| namespace: openshift-machine-api | ||
| spec: | ||
| template: | ||
| spec: | ||
| strategy: | ||
| type: Reboot | ||
| retryLimit: 1 | ||
| timeout: 5m0s | ||
| ---- | ||
|
|
||
| .Procedure | ||
|
|
||
| . Create a `healthcheck.yaml` file that contains the definition of your machine health check. | ||
| + | ||
| .Sample `MachineHealthCheck` resource for bare metal, annotation-based remediation | ||
| [source,yaml] | ||
| ---- | ||
| apiVersion: machine.openshift.io/v1beta1 | ||
| kind: MachineHealthCheck | ||
| metadata: | ||
| name: example | ||
| namespace: openshift-machine-api | ||
| annotations: | ||
| machine.openshift.io/remediation-strategy: external-baremetal | ||
| spec: | ||
| selector: | ||
| matchLabels: | ||
| machine.openshift.io/cluster-api-machine-role: <role> | ||
| machine.openshift.io/cluster-api-machine-type: <role> | ||
| machine.openshift.io/cluster-api-machineset: <cluster_name>-<label>-<zone> | ||
| unhealthyConditions: | ||
| - type: "Ready" | ||
| timeout: "300s" | ||
| status: "False" | ||
| - type: "Ready" | ||
| timeout: "300s" | ||
| status: "Unknown" | ||
| maxUnhealthy: "40%" | ||
| nodeStartupTimeout: "10m" | ||
| ---- | ||
| + | ||
| where | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Mix of prescriptive and descriptive sentence construction here, can they be made more consistent?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For this one, |
||
| + | ||
| -- | ||
| `metadata.name`:: Specifies the name of the machine health check to deploy. | ||
| `metadata.annotations`:: For bare-metal clusters, you must include the `machine.openshift.io/remediation-strategy: external-baremetal` annotation in the `annotations` section to enable power-cycle remediation. With this remediation strategy, unhealthy hosts are rebooted instead of removed from the cluster. | ||
| `spec.selector.matchLabels`:: Specifies the machine pool and machine set to check by adding labels: | ||
| * `machine.openshift.io/cluster-api-machine-role`: Specifies a label for the machine pool that you want to check. | ||
| * `machine.openshift.io/cluster-api-machine-type`: Specifies a label for the machine pool that you want to check. | ||
| * `machine.openshift.io/cluster-api-machineset`: Specifies the machine set to track in the `<cluster_name>-<label>-<zone>` format. For example, `prod-node-us-east-1a`. | ||
| `spec.unhealthyConditions.timeout`:: Specifies the timeout duration for a node condition. If a condition is met for the duration of the timeout, the machine will be remediated. Long timeouts can result in long periods of downtime for a workload on an unhealthy machine. | ||
| `spec.maxUnhealthy`:: Specifies the amount of machines allowed to be concurrently remediated in the targeted pool. This can be set as a percentage or an integer. If the number of unhealthy machines exceeds the limit set by `maxUnhealthy`, remediation is not performed. | ||
| `spec.nodeStartupTimeout`:: Specifies the timeout duration that a machine health check must wait for a node to join the cluster before a machine is determined to be unhealthy. | ||
| -- | ||
| + | ||
| .Sample `MachineHealthCheck` resource for bare metal, metal3-based remediation | ||
| [source,yaml] | ||
| ---- | ||
| apiVersion: machine.openshift.io/v1beta1 | ||
| kind: MachineHealthCheck | ||
| metadata: | ||
| name: example | ||
| namespace: openshift-machine-api | ||
| spec: | ||
| selector: | ||
| matchLabels: | ||
| machine.openshift.io/cluster-api-machine-role: <role> | ||
| machine.openshift.io/cluster-api-machine-type: <role> | ||
| machine.openshift.io/cluster-api-machineset: <cluster_name>-<label>-<zone> | ||
| remediationTemplate: | ||
| apiVersion: infrastructure.cluster.x-k8s.io/v1beta1 | ||
| kind: Metal3RemediationTemplate | ||
| name: metal3-remediation-template | ||
| namespace: openshift-machine-api | ||
| unhealthyConditions: | ||
| - type: "Ready" | ||
| timeout: "300s" | ||
| ---- | ||
| + | ||
| where: | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Mix of prescriptive and descriptive sentence construction here, can they be made more consistent? |
||
| + | ||
| -- | ||
| `metadata.name`:: Specifies the name of the machine health check to deploy. | ||
| `spec.selector.matchLabels`:: Specifies the machine pool and machine set to check by adding labels: | ||
| * `machine.openshift.io/cluster-api-machine-role`: Specifies a label for the machine pool that you want to check. | ||
| * `machine.openshift.io/cluster-api-machine-type`: Specifies a label for the machine pool that you want to check. | ||
| * `machine.openshift.io/cluster-api-machineset`: Specifies the machine set to track in the `<cluster_name>-<label>-<zone>` format. For example, `prod-node-us-east-1a`. | ||
| `spec.remediationTemplate`:: The metal3 remediation template to use. Specify the following information: | ||
| * `apiVersion`. Specify the API version as `infrastructure.cluster.x-k8s.io/v1beta1`. | ||
| * `kind`. Specify `Metal3RemediationTemplate`. | ||
| * `name`. Specify the name of the template. | ||
| * `namespace`. Specify the namespace of the template. | ||
| `spec.unhealthyConditions.timeout`:: Specifies the timeout duration for a node condition. If a condition is met for the duration of the timeout, the machine will be remediated. Long timeouts can result in long periods of downtime for a workload on an unhealthy machine. | ||
| -- | ||
| + | ||
| [NOTE] | ||
| ==== | ||
| The `matchLabels` are examples only; you must map your machine groups based on your specific needs. | ||
| ==== | ||
|
|
||
| . Apply the `healthcheck.yaml` file to your cluster using the following command: | ||
| + | ||
| [source,terminal] | ||
| ---- | ||
| $ oc apply -f healthcheck.yaml | ||
| ---- | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,17 @@ | ||
| // Module included in the following assemblies: | ||
|
|
||
| // * machine_management/deploying-machine-health-checks.adoc | ||
|
|
||
| :_mod-docs-content-type: PROCEDURE | ||
| [id="mgmt-power-remediation-baremetal-about-troubleshooting_{context}"] | ||
| = Troubleshooting issues with power-based remediation | ||
|
mburke5678 marked this conversation as resolved.
|
||
|
|
||
| [role="_abstract"] | ||
| To troubleshoot issues you are having with power-based remediation, check the connection to the Baseboard Management Controller (BMC). | ||
|
|
||
| .Procedure | ||
|
|
||
| * Verify the following conditions: | ||
|
|
||
| ** You have access to the BMC. | ||
| ** The BMC is connected to the control plane node that is responsible for running the remediation task. | ||
Uh oh!
There was an error while loading. Please reload this page.