Kubernetes Events 에 대하여

Kubernetes Events는 하나의 Kubernetes 리소스 타입으로서 Kubernetes 리소스들의 state 변화, 에러 또는 시스템에 특정 메세지를 전파해야할 때 자동으로 만들어집니다. 이러한 Kubernetes Events 리소스는 Kubernetes 개발 및 운영하며 디버깅시에 매우 유용하게 사용됩니다 (공식문서에서도 디버깅 시에 Event를 활용하고 있습니다).

 

Events 조회

Kubernetes Event는 어떻게 조회할 수 있을까요? 사실 Kubernetes를 다뤄보았다면 한번 쯤은 Events 리소스를 본 적이 있을겁니다. 가장 흔한 예로 이미지 Pull 실패 가 있겠네요.

 

• 잘못된 컨테이너 이미지를 입력해서 Deployment 또는 Pod를 생성해서 조회하면 아래와 같은 오류가 나올 것입니다.

 

• 공식문서대로 자세한 오류를 보고 싶으면 kubectl describe pod pod-name 으로 조회를 하게 될 것입니다. 그러면 맨 아래 쯤 Events 항목을 볼 수 있습니다. 이게 앞서 말한 Kubernetes Events 리소스를 의미합니다.

 

 

특정 Pod 뿐 아니라 현재 namespace 에 발생하는 모든 Events를 조회하고 싶다면 kubectl get events 를 통해 조회할 수 있습니다. 하지만 모든 리소스들의 Events들이 조회되기 때문에 상용환경 같이 리소스가 많은 상황이라면 원하는 정보를 찾기 힘들 것입니다.

• 하지만 전체 리소스에서 특정 셀렉터를 통해 원하는 정보만 찾아볼 수 있도록 kubectl 에서 --field-selector 옵션을 지원하고 있습니다.

# Warning 타입만 조회
kubectl get events --field-selector type=Warning

# Pod events를 제외한 다른 events 조회
kubectl get events --field-selector involvedObject.kind!=Pod

# minikube 라는 이름의 node에서 발생한 events만 조회
kubectl get events --field-selector involvedObject.kind=Node,involvedObject.name=minikube

•  

 

Events는 계속해서 유지되는 리소스가 아닙니다.

• Kubernetes를 사용하다보면 Events가 계속 쌓이게 되는데 이걸 계속 유지하다보면 용량 및 성능에서 악영향이 있을 수 있습니다.
• 그래서 default 1시간동안 유지되고 자동으로 제거됩니다.

 

Events 필드 (events.k8s.io v1 Events)

위의 describe 부분의 사진에서 Events 정보를 보시면 아시겠지만 여러 필드를 가지고 있는 것을 볼 수 있습니다. Events의 모든 필드는 Kubernetes Reference에서 확인하실 수 있습니다.

간략하게 위에서 출력된 필드만 살펴보겠습니다.

• type: Normal, Warning 2가지의 값 중 하나를 가지며 추후 추가될 수 있습니다. 말 그대로 일반적인 작업에 의해 생겨난 Event인지, 아니면 어느 오류 및 실패로 인해 생겨난 Event인지 표현합니다.
• reason: 왜 해당 Event가 발생했는지를 나타냅니다. 딱히 정해진 형식은 없고, 128자 이하의 사람이 이해할 수 있는 정보를 작성합니다. kubelet 에서는 다음과 같은 Reason을 정해두고 사용하고 있습니다.
• eventTime: Age로 출력된 부분의 값을 나타냅니다. Event 발생한 시각을 의미하며 MicroTime 타입의 데이터로 이루어져있습니다.
• reportingController: From으로 출력된 부분의 값을 나타냅니다. 말 그대로 해당 Event를 발생시킨 Controller의 이름을 의미합니다.
• note: Events가 발생된 작업. 그 작업의 상태(status)에 대한 설명을 의미합니다.

 

 

다양한 Events 리소스들

위에서 Events 필드를 살펴보았는데요. 사실 Kubernetes 기본 리소스 중 Events는 한 가지가 아닙니다. 이게 말이 잘 이해가 안가실 수 있는데요. 아무런 crd를 추가하지 않은 상태에서 api resource를 출력하면 다음과 같이 출력됩니다 (Kubernetes 1.22v)

> kubectl api-resources -o wide                                                                                           

NAME                              SHORTNAMES   APIGROUP                       NAMESPACED   KIND                             VERBS
...
events                            ev                                          true         Event                            [create delete deletecollection get list patch update watch]
...
events                            ev           events.k8s.io                  true         Event                            [create delete deletecollection get list patch update watch]

보시다시피 2개가 존재하는 것을 보실 수 있고, 위에 있는 events는 core API GROUP(공백인 경우 core group을 의미)에 속해있고, 아래에 있는 events는 events.k8s.io API GROUP에 속해있는 것을 보실 수 있습니다.

 

 

API GROUP을 제외한 모든게 같은데 왜 2가지나 존재하는 걸까요?

• 그 내용은 kubernetes/enhancement 에 잘 설명되어져 있습니다.

 

왜 그런가에 대해 요약해서 설명드리면 기존의 먼저 core 그룹의 Events가 존재했습니다. 하지만 이 Events에는 2가지 문제점이 존재했습니다.

1. Events는 어플리케이션 개발자에게 해당 어플리케이션에 무슨 일이 일어나고 있는지 명확하게 알려줄 수 있어야 합니다. 하지만 core 그룹의 Events는 불명확한 의미를 가진 스팸성이었습니다.
2. Events는 Kubernetes의 성능에 문제를 일으키거나 영향을 주어서는 안됩니다. 하지만 core 그룹의 Events는 여러 알려진 성능문제가 존재했습니다.

이러한 문제로 인해 계속해서 변화 요구가 있었고, 이에 새로운 events.k8s.io API GROUP의 events가 나오게 된 것 입니다.

 

 

현재까진 여러 어플리케이션에서 계속해 core.Event → events.Event 로 넘어가고 있는 상태입니다.

• https://github.com/kubernetes/kubernetes/pull/102832
• https://github.com/kubernetes/kubernetes/pull/92724

등이 있습니다.

 

 

core.Event 와 events.Event 의 필드는 조금씩 다릅니다. 모든 필드 차이들은 여기에서 확인할 수 있습니다. 살펴보시면 아시겠지만 events.Event 로 옮겨왔다해서 core.Event 가 삭제된 것은 아닙니다. 하위호환성을 지키기 위해 core.Event 에서 제거할 필드들은 제거 없이 앞에 Deprecated prefix가 붙은 상태로 유지되어졌습니다.

 

대략적으로 차이를 살펴보면 다음과 같습니다.

• FirstTimestamp, LastTimestamp, Count ... → DeprecatedFirstTimestamp, DeprecatedLastTimestamp, DeprecatedCount ...
• Message → Note
• InvolvedObject ObjectReference → Regarding ObjectReference
• ...

Kubernetes v1.19 부터 events.k8s.io Events는 v1 (stable)로 사용이 가능합니다.

 

---

 

## Update (2022.08.06)

최근에 아래의 글을 보았다.

쿠버네티스에서 노드가 추가될 때마다 슬랙 알람 쏘기

 

Event와 Operator를 활용해서 slack으로 알림을 보내준다는 내용인 글이다.

 

이처럼 일회성인 Event를 외부 툴/플랫폼으로 옮기거나 보내서 기록 및 저장할 수 있다.

 

위 글은 예시로 간단하게 구현해 본 결과지만, 보통 이를 목적으로 구현이 되어있는 툴들이 있다.

 

사용해본 결과, 오픈소스로는 BotKube가 괜찮고 유료 툴로는 Datadog이 좋았다.

 

사내에서는 둘 다 사용하고 있는데, 서비스의 안정성을 위해 BotKube를 적극적으로 모니터링하고 있다. 파드/서비스/노드 등의 리소스 변화를 내 맘대로 로그 레벨을 정해서 알림을 추가할 수 있고, 이를 슬랙이나 팀즈 등의 툴로 전달을 해주고 있기 때문에 활용도가 좋다.