| layout | title | nav_order |
|---|---|---|
default |
FAQ |
9 |
{: .no_toc }
{: .no_toc .text-delta }
- TOC {:toc}
Medik8s is intended to be a playful misspelling of the English word "medicates" and is pronouced the same way.
No. Medik8s can run on any kubernetes cluster.
No. Medik8s puts Nodes at the center of failure detection and recovery and can run on any kubernetes cluster.
No. While Medik8s can take advantage of hardware watchdogs and/or BMCs, it also has options for shared-nothing recovery.
No. Medik8s operators can work on any platform, unless specified otherwise by a specific remediator.
No. The Node Healthcheck configuration includes a node selector, so you can treat the control plane differently to workers, and have pools of workers with different conditions and thresholds to provide a variety of SLAs.
Yes. Node Healthcheck determines node health based on NodeConditions. There are a set of basic conditions built into Kubernetes, but additional conditions can be defined and then referenced by Node Healthcheck. Node Problem Detector is a common tool for creating and updating NodeConditions based on log scraping.
Yes. Node Healthcheck uses the sig-cluster's External Remediation API to uniquely associate a node failure with a specific recovery mechanism of your choosing.
Reach out to the google group or submit a PR to one of the Medik8s projects.
The Medik8s team has worked with the sig-cluster community for many years. While we have many things in common, they are naturally focussed on furthering the Machine/Cluster APIs. Basing our solution on those APIs would limit the types of clusters we can provide a solution for.
The original implementation put Machines at the center of failure detection and exclusively used the Machine API for recovery. Node Healthcheck Controller can use the Machine API if it is available, but also supports other mechanisms.
Apart from the Medik8s team being actively involved with the Machine Healthcheck Controller, the Node Healthcheck Controller also shares much of the same code.
The primary difference between the two implementations is putting Nodes at the
center of failure detection to avoid a dependency on Machine objects, which
are not common to all kubernetes installations.
The original MHC implementation assumed that using the Machine API to destroy the bad node and replace it with a new one was the only necessary recovery mechanism.
The Medik8s team partnered with Ericsson to convince the sig-cluster community that other mechanisms were needed (particularly on bare metal). Together we created the External Remediation API that is used by both the Machine and Node Healthcheck Controllers.
The Medik8s team is employed at Red Hat, where we leverage 20 years of personal experience creating HA architectures to create a kubernetes-native HA experience for workloads such as Stateful sets and RWO Volumes.