{"id":13581540,"url":"https://github.com/medik8s/node-healthcheck-operator","last_synced_at":"2026-02-25T17:26:48.757Z","repository":{"id":37003695,"uuid":"348615268","full_name":"medik8s/node-healthcheck-operator","owner":"medik8s","description":"K8s Node Health Check Operator","archived":false,"fork":false,"pushed_at":"2025-07-14T07:22:08.000Z","size":21822,"stargazers_count":111,"open_issues_count":6,"forks_count":23,"subscribers_count":7,"default_branch":"main","last_synced_at":"2025-07-14T10:00:01.575Z","etag":null,"topics":["availability","k8s","kubernetes","remediation"],"latest_commit_sha":null,"homepage":"","language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/medik8s.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"docs/contributing.md","funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2021-03-17T07:19:31.000Z","updated_at":"2025-07-14T07:22:13.000Z","dependencies_parsed_at":"2023-10-16T22:38:20.773Z","dependency_job_id":"1a292137-7db2-48d3-a921-ebd54e5758a3","html_url":"https://github.com/medik8s/node-healthcheck-operator","commit_stats":null,"previous_names":[],"tags_count":30,"template":false,"template_full_name":null,"purl":"pkg:github/medik8s/node-healthcheck-operator","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/medik8s%2Fnode-healthcheck-operator","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/medik8s%2Fnode-healthcheck-operator/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/medik8s%2Fnode-healthcheck-operator/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/medik8s%2Fnode-healthcheck-operator/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/medik8s","download_url":"https://codeload.github.com/medik8s/node-healthcheck-operator/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/medik8s%2Fnode-healthcheck-operator/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":268291278,"owners_count":24226799,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","status":"online","status_checked_at":"2025-08-01T02:00:08.611Z","response_time":67,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["availability","k8s","kubernetes","remediation"],"created_at":"2024-08-01T15:02:05.141Z","updated_at":"2026-02-25T17:26:43.725Z","avatar_url":"https://github.com/medik8s.png","language":"Go","funding_links":[],"categories":["Go"],"sub_categories":[],"readme":"# Node Healthcheck Operator\n\n\u003cp align=\"center\"\u003e\n\u003cimg width=\"200\" src=\"config/assets/nhc_blue.png\"\u003e\n\u003c/p\u003e\n\n## Introduction\n\nHardware is imperfect, and software contains bugs. When node level failures such\nas kernel freezes or dead NICs occur, the work required from the cluster does not\ndecrease - workloads from affected nodes need to be restarted somewhere.\n\nHowever, some workloads, such as RWO volumes and StatefulSets, may require\nat-most-one semantics.  Failures affecting these kind of workloads risk data\nloss and/or corruption if nodes (and the workloads running on them) are assumed\nto be dead whenever we stop hearing from them.  For this reason it is important\nto know that the node has reached a safe state before initiating recovery of the\nworkload.\n\nUnfortunately it is not always practical to require admin intervention in order\nto confirm the node's true status. In order to automate the recovery of exclusive\nworkloads, the Medik8s project presents a collection of operators that can be installed on any\nkubernetes-based cluster to automate failure detection and fencing / remediation.\nFor more information visit our [homepage](https://www.medik8s.io)\n\n## Failure detection with the Node Healthcheck operator\n\n### Handling unhealthy nodes\n\nA Node entering an unready state after 5 minutes is an obvious sign that a\nfailure occurred. However, there may be other criteria or thresholds that are\nmore appropriate based on your particular physical environment, workloads,\nand tolerance for risk.\n\nThe [Node Healthcheck operator](https://www.medik8s.io/failure_detection/#node-healthcheck-controller)\nchecks each Node's set of [NodeConditions](https://kubernetes.io/docs/concepts/architecture/nodes/#condition)\nagainst the criteria and thresholds defined in NodeHealthCheck (NHC) custom\nresources (CRs).\n\nIf the Node is deemed to be in a failed state, and remediation is appropriate,\nthe controller will instantiate a remediation custom resources based on the\nremediation template(s) as defined in the NHC CR. NHC offers to configure\na single remediation method, or a list of remediation methods which will be\nused one after another with specified order and timeout.\n\nThis template based mechanism allows cluster admins to use the best remediator\nfor their environment, without NHC having to know them beforehand. Remediators\nmight use e.g. Kubernetes' ClusterAPI, OpenShift's MachineAPI, BMC, Watchdog\nor software based reboots for fencing the workloads.\nFor more details see the [remediation documentation](https://www.medik8s.io/remediation/remediation/).\n\nWhen the Node recovers and gets healthy again, NHC will delete the\nremediation CR for signalling that node recovery was successful.\n\n### Special cases\n\n#### Control plane problems\n\nRemediation is not always the correct response to a failure. Especially in\nlarger clusters, we want to protect against failures that appear to take out\nlarge portions of compute capacity but are really the result of failures on or\nnear the control plane. For this reason, the NHC CR includes the ability to\ndefine a minimum number of healthy nodes, by percentage or absolute number.\nAlternatively, a complementary `maxUnhealthy` parameter can be used to specify\nthe maximum number of unhealthy nodes. This is useful in high-availability scenarios\nwhere the system must continue functioning even if one or more nodes become unhealthy\n(commonly referred to as N-1 or N-2 scenarios), such as in storage hyperconverged environments.\nThese terms indicate that the system should tolerate the failure of one or two nodes,\nrespectively, without impacting overall functionality. This approach is particularly helpful\nwhen the total number of selected nodes is not known in advance or is expected to change over time.\nWhen the cluster is falling short of this threshold, no further remediation\nwill be started.\n\n#### Cluster Upgrades\n\nCluster upgrades usually draw workers reboots, mainly to apply OS updates.\nThese nodes might get unhealthy for some time during these reboots.\nThis disruption can also cause other nodes to overload and appear unhealthy,\nwhen compensating for the lost compute capacity. Making remediation decisions\nat this moment may interfere with the upgrade and may even fail it completely.\nFor that reason NHC will stop remediating new unhealthy nodes in case it\ndetects that a cluster is upgrading.\n\nAt the moment this is only supported on OpenShift, by monitoring the\n[ClusterVersionOperator](https://github.com/openshift/cluster-version-operator).\n\n#### Manual pausing\n\nBefore running cluster upgrades on kubernetes, or for any other reason, cluster\nadmins can prevent new remediation by pausing the NHC CR.\n\n## Further information\n\nFor more details about using or contributing to Node Healthcheck, check out our\n[docs](docs/readme.md).\n\n## Help\n\nPlease join our [Google group](https://groups.google.com/g/medik8s) for asking\nquestions. When you find a bug, please open an issue in this repository.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmedik8s%2Fnode-healthcheck-operator","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fmedik8s%2Fnode-healthcheck-operator","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmedik8s%2Fnode-healthcheck-operator/lists"}