sentimental programmer: kyverno out of memory

# kyverno 는 k8s 정책엔진으로 리소스를 검사,변경,생성하는 규칙을 yaml 로 정의한다.

# Admission Controller(k8s api 요청을 가로채서 검증,변경,생성 수행) 형태로 작동한다.

# 리소스 사용량은 다음과 같이 설정되어 있는데 메모리 사용량이 100%가 되는 순간이 자주 발생했다.

resources:

limits:

memory: 384Mi

requests:

cpu: 100m

memory: 128Mi

# limits.memory 를 늘려주뎐 되지만 어떤 과정에서 메모리가 올라갔는지 확인해 보자.

# 정책들 background : true 면 모든 정책들이 한번에 몰려 메모리 사용량이 증가될 수 있다.

# 확인 결과 모두 false 로 이 문제는 아니였다.

kubectl get clusterpolicies | rg -i "background"

# 메트릭 서비스를 포트포워딩해서

kubectl port-forward svc/kyverno-svc-metrics 8000:8000 -n kyverno

# 정책 평균 수행 시간을 확인해 보면 0.0x 초로 이상이 없어 보인다.

# *_sum : 해당 작업의 총 누적 시간

# *_count : 해당 작업의 총 실행 횟수

# 평균 실행 시간 = sum / count

curl -s http://localhost:8000/metrics | rg -i kyverno_policy_execution_duration_seconds_sum

# OOM(Out Of Memory) 발생으로 kyverno 가 재시작해서 kyverno 가 새로 시작하는 로그 밖에 남지 않았다.

# 참고로 수동 삭제가 아니라 pod age 는 유지됐다.

kubectl describe pod

# kyverno(v1.9.3기준) deployment 에서 다음과 같이 로그 레벨을 올려서 다시 띄운다.

# 로그 레벨(verbose 정도) 기본은 2고 1~6으로 설정할 수 있다.

# -v=2: 정책이 어떤 리소스에 적용됐는지 간단히

# -v=3: 정책 매칭 여부, 정책 실행 결과, 실행시간(어떤 정책이 실행됐고 결과가 무엇이었는지 파악)

# -v=4: 3 정보에 조건/패턴 세부 평가 과정, 변수 바인딩/값 추출 과정(왜 이 정책이 pass/fail 됐는지 파악)

# -v=5: 4 정보에 kyverno 내부 로직까지 출력해서 로그 폭주

# 추적을 위해 4 정도로 설정했다. 원인 파악이 끝나면 2나 3 정도로 변경하자.

containers:

- args:

- -v=4

# oom 으로 kyverno 가 재시작되면 로그를 볼수 없어 follow 옵션 활성화한다.