Resource consumption in a Pod is governed by the distinction between requests and limits. Requests are the amount of a resource guaranteed to a container for scheduling purposes, while limits are the maximum amount the container is allowed to use and are enforced at runtime. When a container exceeds its memory limit, it is terminated with an OOMKilled exit status; for CPU, the container is throttled rather than killed. Together, requests and limits determine a Pod's Quality of Service (QoS) class, which in turn dictates its eviction priority under node pressure.
QoS classes are assigned as follows. Guaranteed applies when every container in the Pod has limits equal to requests for both CPU and memory. BestEffort applies when no container sets any requests or limits. Burstable covers every other configuration. Under node pressure, Pods are evicted in a predictable order: BestEffort first, then Burstable Pods that exceed their requests, then Burstable Pods within their requests, with Guaranteed Pods evicted last.
Kubernetes also uses probes to observe container health. A liveness probe determines when to restart a container: if the probe fails, the kubelet kills and restarts the container. A readiness probe determines whether a container is ready to receive traffic; Pods whose containers fail readiness are removed from Service endpoints until they recover. A startup probe indicates when an application has started and disables liveness and readiness checks until it succeeds, which is useful for slow-starting containers. Probes can be configured with handlers of type HTTPGetAction, TCPSocketAction, ExecAction, or grpc (added in 1.24), and their behavior is controlled by fields including initialDelaySeconds, periodSeconds, timeoutSeconds, successThreshold, failureThreshold, and terminationGracePeriodSeconds.