OOMKilled will only be reported for containers that have been terminated by the kernel OOM killer. It's important to note that it's the container that exceeds its memory limit that gets terminated (and by default restarted) as opposed to the whole pod (which can very well have other containers). Evictions on the other hand happen at the pod level, and are triggered by Kubernetes (specifically by the Kubelet running on every node) when the node is running low on memory*. Pods that have been evicted will report a status of Failed and a reason of Evicted.
Details about the reason can be seen in the Kubelet events for pod evictions (including details about how the sorting of the pods based on memory usage and QoS class is done so the "victim" is selected - a movie showing this is here) and in the kernel logs in the case of containers that get terminated by the OOM killer (a movie showing this is here).
*A node low on memory is a nuanced concept. If the node is truly out of memory, the the OOM killer will act at the system level and terminate from the list of all processes one that it deems a suitable "target" (such a radical example is here). Kubernetes has a different approach: with the node allocatable feature enabled (which is the default currently) it "carves" only a part of the node's memory for use by the pods. How much that is depends on the value of 3 parameters, captured in the previous link (kube-reserved, system-reserved, and eviction-threshold).
The catch is that the memory reserved by these 3 parameters will usually be larger than the respective actual memory usage: e.g. on an AKS DS2_v2 node (7 GiB of memory) the kube-reserved value is set at 1,638 MiB. Here's how this looks like (AKS doesn't use the system-reserved flag currently):
kube-reserved is used to set aside memory for the Kubernetes system daemons (like Kubelet), so that the pods don't end up consuming too much, thus potentially starving those system daemons. If we assume the memory usage stays constant at 1,000 MiB for the Kubernetes daemons, the remaining 638 MiB in the black area above are still considered off-limits by Kubernetes. If the pods consume overall more than the "Allocatable" value for the node and start going into the red area above, and Kubernetes detects this in time (Kubelet checks every 10s by default) it will evict pods. So even though the node is not technically out-of-memory, Kubernetes uses its own "buffer" and takes corrective action way before the system would be in a real (and possibly crippling) low-memory situation.
If the allocations happen so fast so the red area above gets filled before the Kubelet has a chance to spot it (by default every 10s, as stated above) then the OOM killer will start terminating processes inside the pods' containers, and so you'll end up with OOMKilled events. You can very well not see a pod eviction in this case. Things can get tricky, and I tried doing a rough logical diagram of out-of-memory situations here: Flows leading to out-of-memory situations.
