Kubernetes Node 가용성 검증

개요

클라우드 환경에서의 가용성 테스트는 레가시 환경과는 다르다. 직접 테스트를 수행하면서 알게된 Lessons learned을 통해 Kubernetes Node Failover에 대한 가용성 검증 과정에 대해 알아보자. Kubernetes가 관리하는 클러스터 내의 노드 장애 발생 시 어떻게 빠르게 인지하고 대응할 것인지 과정에 대해 검증해 보고, 최적 구성에 대해 알아보자.

---

Kubernetes 노드 가용성 관련 구성

1) kubelet

• node-status-update-frequency : default 10s (api-server에 노드의 상태를 게시하는 주기) / recommand 4s
• node-status-report-frequency : default 5m (node-status-update-frequency가 구성될 경우 대체)

2) controller-manager

• node-monitor-period : default 5s (nodecontroller에서 node status를 동기화하는 시간) / etcd 노드가 분리된 경우 recommand 2s, master node 통합 구성 시 5s 유지
• node-monitor-grace-period : default 40s (node로부터 해당 시간 동안 응답을 받지 못한 경우 상태를 Not Ready 상태로 변경, node-monitor-grace-period = (N — 1) * node-status-update-frequency #N은 kubelet Node Staus Retry Count) / recommand 20s
• pod-eviction-timeout : default 5m (노드에서 Pod를 삭제하기 위한 대기 시간)

3) api-server

• default-not-ready-toleration-seconds / default-unreachable-toleration-seconds : default 5m (toleration 지정되지 않은(default toleration - unreachable:NoExecute) Pod에 toleration을 적용하기 위한 tolerationSeconds) / recommand 30s

---

노드 다운 시 상태 변화

위와 같이 노드가 중지되면, default 구성  시 노드의 가용성을 확보하는데 5분 40초(node-monitor-grace-period + pod-eviction-timeout)의 시간이 소요된다. 5분 40초라는 시간이 프로젝트 마다 다르겠지만, 가용할 수도 불가할 수도 있다. 따라서 각 프로젝트에 맞게 node-monitor-grace-period와 pod-eviction-timeout을 조정할 수 있도록 구성하는 것이 중요하다.

## 특히 노드 가용성을 확보하기 위해 무작정 default 시간을 줄일 경우 역효과가 날 수 있다. node unhealty & endpoint에서 제거되면, 해당 pod는 타 노드에서 requires 수 많큼의 pod를 유지하기 위해 기동된다. 이는 scaling이 발생되며, pod 기동 시 발생하는 load와 일시적인 지연 현상이 발생될 수 있다. pod-eviction-timeout은 이를 방지하기 위해 해당 시간 내 node의 상태가 복구되면, 해당 pod를 다시 서비스에 포함하는 역할을 한다.

1) kubelet 변경 (node-status-update-frequency 변경)

• 모든 노드 대상으로 /var/lib/kubelet/kubeadm-flags.env 파일 수정
• "--node-status-update-frequency=5s " 옵션 추가 (KUBELET_KUBEADM_ARGS="...... --node-status-update-frequency=5s")
• 파일 저장 후 kubelet 재시작

2) kube-controller node-monitor-period 및 node-monitor-grace-period 변경

• 모든 master node에서 /etc/kubernetes/manifests/kube-controller-manager.yaml 수정
• (kube-controller-manager) --node-monitor-period=3s, --node-monitor-grace-period=20s
• docker restart

3) kube-controller pod-eviction-timeout 변경

• 모든 master node의 /etc/kubernetes/manifests 하위에 kubeadm-apiserver-update.yaml 파일 생성

apiVersion: kubeadm.k8s.io/v1beta2
kind: ClusterConfiguration
kubernetesVersion: v1.18.3
apiServer:
	extraArgs:
		enable-admission-plugins: DefaultTolerationSeconds
		default-not-ready-toleration-seconds: "20"
		default-unreachable-toleration-seconds: "20"

• kubeadm init phase control-plane apiserver --config=kubeadm-apiserver-update.yaml 실행
• /etc/kubernetes/manifests/kube-apiserver.yaml 변경 사항 적용 여부 확인

---

Recommendations Case 구성

1) 높은 노드 가용성 확보

• --node-status-update-frequency=4s
• --node-monitor-period=2s
• --node-monitor-grace-period=20s
• --default-not-ready-ready-readeration-seconds=30s
• --default-readable-readeration-seconds=30s

node 다운 20s (node-monitor-grace-period)

pod 다운 50s (node-monitor-grace-period + default-not-ready-tolleration-seconds or default-unreachable-tolleration-seconds)

# 권고사항

모든 노드가 2초마다 상태를 업데이트하려고 하기 때문에 etcd에 오버헤드 발생 가능. etcd 전용 노드 구성 필요.

2) 일반적인 구성

• --node-status-update-frequency=20s
• --node-monitor-grace-period=2m
• --default-not-ready-tolleration-seconds=60s

node 다운 2m (node-monitor-grace-period)

pod 다운 3m (node-monitor-grace-period + default-not-ready-tolleration-seconds or default-unreachable-tolleration-seconds)

# 권고사항

nodeStatusUpdateFrequency에 따라 Pod 당(분당) 3번의 etcd 업데이트를 필요로 하기 때문에 중간 규모의 환경에 적합.

3) 안정적인 구성과 pod 복원 고려

• --node-status-update-frequency=1m
• --node-monitor-grace-period=5m
• --default-not-ready-tolleration-seconds=60

node 다운 5m (node-monitor-grace-period)

pod 다운 6m (node-monitor-grace-period + default-not-ready-tolleration-seconds or default-unreachable-tolleration-seconds)

# 권고사항

master node내 etcd를 함께 구성하는 경우 적합. Pod eviction 처리 보다 재 사용성을 고려한 환경 구성.

---

결론

Kubernetes 노드의 가용성은 프로젝트의 요구사항에 따라 달라질 수 있다. 구성의 변경은 민감하게 작용할 수 있기 때문에 그 역할과 SideEffect는 없는지 다시한번 확인할 필요가 있을 것이다.

특히, 가장 중요한 점은 바로 해당 노드 위에 운영되는 어플리케이션의 특성을 이해하고 구성해야 한다는 점이다.  빠른 노드 복원력과 안정적인 운영의 니즈에 맞게 Kubernetes를 변경하여 실 운영환경에 적용해 보도록 하자.