Rzecz dzieje się w ramach AWS EKS. Mam taki case do analizy: "był pod i nie ma poda, bo został ubity OOMKIlled. POD zaistniał z uwagi na konieczność wykonania joba.
Czy są jakieś narzędzia pozwalające sprawdzić dynamikę wykorzystania zasobów per pod i umożliwić przeprowadzenie takiej analizy po fakcie?
To chyba pytanie czy macie takie monitoringi włączone.
Nie wiem jak w AWS EKS, ale w odpowiedniku na Azure, czyli AKS, domyślnie nie będziesz miał dostępu do takich metryk. Dla AKS trzeba albo włączyć monitoring za pomocą Container Insights, i wtedy jak najbardziej masz dostęp do takich metryk jak CPU/Memory usage itp. (zbierane chyba są nawet co minutę), albo doinstalować jakieś open source'owe toole - np. Prometheus.
OOMKilled nie kasuje poda. Ubija tylko proces w kontenerze, który zostanie zrestartowany w tym samym podzie. Inaczej nie widziałbyś statusu OOMKilled jak robisz describe.
Po fakcie (w sensie teraz) raczej nic już nie zrobisz, bo nic w K8s nie trzyma historii. Musisz mieć metryki i tam będziesz widział wszystko. Czy te AWS-owe, czy Prom+Grafana.
@kelog w ogólności masz rację co do samego OOMKilled i kasowania poda. Warto dodać, że są dodatkowe czynniki, które mogą tego poda usunąć, np. polityka określającego ma się stać po zakończeniu joba.
Żeby nie być gołosłownym załączam prosty job symulujący OOM i usuwający poda po 10 sekundach od awarii.
apiVersion: batch/v1
kind: Job
metadata:
name: oom-memory-job
spec:
ttlSecondsAfterFinished: 5
template:
spec:
containers:
- name: oom-simulator
image: polinux/stress
command: ["stress"]
args: ["--vm", "1", "--vm-bytes", "1024M", "--vm-hang", "1"]
resources:
limits:
memory: "64Mi"
requests:
memory: "64Mi"
restartPolicy: Never
backoffLimit: 0
I użycie:
kubectl create -f oom-job.yaml && while true; do echo -e ":: ---> checking PODs\n"; kubectl get pods -A ; echo -e "\n:: <--- \n"; sleep 3; done
oraz rezultat:
job.batch/oom-memory-job created
:: ---> checking PODs
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system calico-node-tnhrl 1/1 Running 1 (16m ago) 12d
kube-system calico-kube-controllers-7cbf9bdf68-jvg6t 1/1 Running 1 (16m ago) 12d
kube-system coredns-7745f9f87f-lj5gm 1/1 Running 11 (16m ago) 60d
default oom-memory-job-fqdbb 0/1 ContainerCreating 0 1s
:: <---
:: ---> checking PODs
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system calico-node-tnhrl 1/1 Running 1 (16m ago) 12d
kube-system calico-kube-controllers-7cbf9bdf68-jvg6t 1/1 Running 1 (16m ago) 12d
kube-system coredns-7745f9f87f-lj5gm 1/1 Running 11 (16m ago) 60d
default oom-memory-job-fqdbb 0/1 OOMKilled 0 5s
:: <---
:: ---> checking PODs
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system calico-node-tnhrl 1/1 Running 1 (16m ago) 12d
kube-system calico-kube-controllers-7cbf9bdf68-jvg6t 1/1 Running 1 (16m ago) 12d
kube-system coredns-7745f9f87f-lj5gm 1/1 Running 11 (16m ago) 60d
default oom-memory-job-fqdbb 0/1 OOMKilled 0 9s
:: <---
:: ---> checking PODs
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system calico-node-tnhrl 1/1 Running 1 (16m ago) 12d
kube-system calico-kube-controllers-7cbf9bdf68-jvg6t 1/1 Running 1 (16m ago) 12d
kube-system coredns-7745f9f87f-lj5gm 1/1 Running 11 (16m ago) 60d
:: <---