<p>What does  "level-based" and "edge-based" mean in general?</p>

<p>I read "In other words, the system's behavior is level-based rather than edge-based" from kubernetes documentation:
<a href="https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/api-conventions.md" rel="noreferrer">https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/api-conventions.md</a></p>

<p>with Google, I only find:
<a href="http://www.keil.com/forum/9423/edge-based-vs-level-based-interrupt/" rel="noreferrer">http://www.keil.com/forum/9423/edge-based-vs-level-based-interrupt/</a></p>

<p>Thank you.</p>

<p>It also has a more general definition (at least the way we tend to use it in the documentation). A piece of logic is "level based" if it only depends on the current state. A piece of logic is "edge-based" if it depends on history/transitions in addition to the current state.</p>

<p>"Level based" components are more resilient because if they crash, they can come back up and just look at the current state. "Edge-based" components must store the history they rely on (or depend on some other component that stores it), so that when they come back up they can look at the current state and the history. Also, if there is some kind of temporary network partition and an edge-based component misses some of the updates, then it will compute the wrong output.</p>

<p>However, "level based" components are usually less efficient, because they may need to scan a lot of state in order to compute an output, rather than just reading deltas.</p>

<p>Many components are a mixture of the two.</p>

<p>Simple example: You want to build a component that reports the number of pods in READY state. A level-based implementation would fetch all the pods from etcd (or the API server) and count. An edge-based implementation would do that once at startup, and then just watch for pods entering and exiting READY state.</p>
