쿠버네티스 노드 헬스체크 원리(lease API)

 

 

1.  개요

이 글은 쿠버네티스가 어떻게 노드를 헬스체크하는지 설명합니다. 노드 헬스체크의 원리는 비정상 노드의 kubelet로그를 분석할 때 활용할 수 있습니다.

 

2.  이 글을 읽으면 알 수 있는 것

1. 노드 헬스체크에 사용하는 kubernetes lease API
2. 헬스체크가 실패한 node를 not ready로 변경하는데 걸리는 시간

 

3.  헬스체크 알고리즘: lease

쿠버네티스의 노드 헬스체크는 lease 알고리즘을 사용합니다. lease는 번역하면 임대라는 뜻입니다.

 

lease라는 개념은 일정 시간 동안만 자원을 빌린다는 뜻입니다. 쿠버네티스는 노드를 lease 객체로 등록하여 노드자원을 lease 합니다.

kubectl get leases -n kube-node-lease

 

lease 알고리즘은 일정 시간동안 자원을 빌리는 개념이기 때문에 자원 반납이라는 끝나는 시간이 있습니다. 쿠버네티스 노드를 계속 lease하려면 주기적으로 업데이트(renew)해야 합니다.

kubectl describe  leases -n kube-node-lease
Spec:
  Holder Identity:         demo-worker
  Lease Duration Seconds:  40
  Renew Time:              2025-01-12T12:15:30.504664Z

 

lease 알고리즘에서 주기적으로 lease상태를 업데이트해야 하는 특징을, 쿠버네티에서는 노드 헬스체크에 사용합니다

4.  lease 업데이트 하는 주체와 주기

쿠버네티스 노드 헬스체크 알고리즘은 lease 알고리즘을 사용하는 것을 알았습니다. 그러면 누가 lease를 업데이트할까요?

 

바로, kubelet입니다. kubelet은 lease API를 사용하여 10초마다 lease를 업데이트 합니다. 업데이트 하는 과정은 kube API server가 etcd에 데이터를 저장합니다.

 

5.  lease 만료시간

lease 만료시간은 디폴트 40초입니다. lease 객체를 describe하면 "Lease Duration Seconds"필드가 만료시간입니다.

$ kubectl describe  leases -n kube-node-lease
Spec:
  Holder Identity:         demo-worker
  Lease Duration Seconds:  40
  Renew Time:              2025-01-12T12:15:30.504664Z

 

6.  lease가 만료되면 무슨 일이 일어날까?

lease가 만료되었다는 의미는 kubelet에 업데이트 요청을 못받은 겁니다. 또는 kube API server, etcd가 비정상 상태일 수 있습니다. 이 글은 kubelet에 업데이트 요청을 못받았다는 전제만 가정합니다.

 

kubelet이 업데이트 요청을 받지 못했다면, kube API server입장에서는 노드가 비정상 상태라고 간주합니다. 따라서 node (lifecycle) controller가 노드 상태를 not ready로 변경합니다.

 

Node controller는 etcd에 직접 데이터를 업데이트 하지 못하므로 kube API server에 요청합니다.

 

6. node controller는 바로 node를 not ready로 변경하지 않는다. 

node controller는 현재시간 - 노드 lease > 50(node-monitor-grace-period 설정)가 성립해야 노드를 not ready로 변경합니다. 검사 시간은 5초마다 실행됩니다.

 

7.  왜 node 상태를 바로 업데이트 하지 않을까?(추측)

왜 node controller은 바로 노드 상태를 업데이트 하지 않을까요?

 

2가지 이유 때문에 바로 업데이트하지 않는다고 생각합니다.

1. 네트워크 등의 이슈를 고려하여 바로 업데이트 하지 않음

2. 노드 상태 업데이트 비용이 저렴하지 않음

 

2번째 이유는 Efficient Node Heartbeats문서에 설명되어 있습니다. node controller가 바로바로 노드 상태를 업데이트하면 kube API etcd에 부하가 걸립니다. 저 문서의 기준은 heartbeat를 개선 전의 기준이지만 지금 상황에 생각해봐도, 노드 객테 상태는 약 20kb이고 작지 않은 크기입니다. 노드 개수가 몇천개 몇만개가 되면 kube API server와 etcd는 노드 상태 업데이트 하기 위해 cpu, memory를 많이 사용합니다.

kubectl get node -oyaml

 

8. 노드 상태 확인

헬스체크가 실패한 노드 상태는 status: Unknown 상태입니다. 

$ kubectl get node {node name} -oyaml
- lastHeartbeatTime: "2025-01-18T11:13:11Z"
    lastTransitionTime: "2025-01-18T11:17:32Z"
    message: Kubelet stopped posting node status.
    reason: NodeStatusUnknown
    status: Unknown
    type: Ready

 

9. 소스코드 분석 

소스코드 분석은 아래 hwchiu 미디엄 블로그에 자세히 설명되어 있습니다. node life cycle controller와 kubelet 코드가 분석되어 있습니다.

- 링크: https://hwchiu.medium.com/handling-pods-when-nodes-fail-4daae20213b

 

참고자료

• 쿠버네티스 노드 헬스체크 디자인 문서: https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/589-efficient-node-heartbeats/README.md
• 쿠버네티스 노드 헬스체크 소스코드 분석: https://hwchiu.medium.com/handling-pods-when-nodes-fail-4daae20213b
• 쿠버네티스 노드 상태 문서: https://kubernetes.io/docs/reference/node/node-status/#heartbeats
• https://www.alibabacloud.com/blog/how-does-alibaba-ensure-the-performance-of-system-components-in-a-10000-node-kubernetes-cluster_595469
• 컴퓨터 과학에서 lease 개념: https://computing-jhson.tistory.com/122