### Probes Kubernetes probes make sure that the application is both live and ready to handle requests. Types: 1. Liveness: check if the app is up. 2. Readiness: check if the app is ready to get applications. > [!example] > If an app running but still is doing migration, the liveness is passing but readiness is not. > [!tip] > If the load on the app is too high, you can uncheck the readiness probe to avoid further requests. 3. Startup: check if the app is in startup mode. It is used for apps that their startup take too long. ### Resources Each Pod can (and for normal usage, should) specify their resource *request* and resource *limit*. Resource request is the amount of resource where the Kubernetes cluster at least deliver for the app. On the other hand, Resource limit the maximum resource designated for the application. ![[Pasted image 20250211022612.png]] If a Pod does not specify its resource request and limits, the cluster will put it in the least priority to scheduling. In case of priority in scheduling and eviction: 1. Guaranteed Class 2. Burstable Class 3. BestEffort Class ![[Pasted image 20250211023109.png]] > [!info] > It is a good practice to set resources for all Pods. At least a custom default is highly recommended. > [!important] > When resource allocating, consider 10% of the resources to Kubernetes agents, kubelet and OS itself. ### Pod to Node Is the process by which a Node is selected for a Pod to be resided in. This process can be altered in different ways: 1. *Node selector*: filters Nodes for the Pod. e.g. select only Nodes with large RAM for the Pod. The result is a group of Nodes suitable. 2. *Node name*: specifically select a Node for Pod to reside on. The result is a single Node suitable. 3. *Affinity/Anti-affinity*: like Node selectors, filters Nodes by one of their labels but gives more control over selection logic. 4. *Inter-Pod Affinity*: allows to constrain Pods *against labels on other Pods*. e.g. front-end Pods and back-end Pods be on a the same Node. 5. *Taint/Toleration*: Taints allow a Node to repel a set of Pods. Tolerations are applied to Pods. Tolerations allow the scheduler to schedule pods with matching taints. (e.g. used for dedicated Nodes) 6. *Pod disruption budget*: set the minimum available replica of a pod. e.g. [[etcd#Quorum|quarom]]-needed services. >[!warning] > By providing harsh pod-to-node rules, the risk of finding a suitable node for your pod will be get higher.