Kubernetes Lessons Learned 시리즈 (1)

PROLOGUE

Cloud를 채택하는 대부분의 프로젝트는 컨테이너 오케스트레이션으로 Kubernetes(이하 K8S로 지칭)를 사용하게 됩니다.

본 시리즈에서는 Cloud 환경하에서의 성능테스트를 통해 ＂부하 상황에서의 Scale/배포 작업 시 Request 오류율 Zero＂를 위해 고려해야 할 K8S 옵션에 대해 언급합니다.

한 번에 많은 양을 기술하기 보다는 시리즈별로 핵심 포인트만 기술할 예정입니다.

Liveness 와 Readiness Probe

K8S는 주기적으로 Pod과 Container의 상태를 체크하여 비정상 상태의 Pod의 컨테이너를 Restart하거나 서비스에서 제외 시키는 동작을 수행하게 되는데 이때 이를 판단하는 것이 liveness probe와 readiness probe입니다.

K8S 성능테스트 시에는 시나리오 상에 항상 Auto Scale-out & 무중단 배포 검증 테스트가 포함되는데, 이 설정이 적절치 않을 경우에는 Scale/배포 시점에 일정 부분(수건~수십건)의 Request 오류가 발생되게 됩니다.

체크 방법은 크게 다음과 같은 3가지가 있으며, 세부적으로는 다시 언급하겠습니다.

• HTTP 체크 (Liveness/Readiness에 많이 사용)

• Command 체크 (Liveness 많이 사용)

• TCP 체크

※ liveness Probe는 Pod의 컨테이너 상태를 체크하기 때문에 굳이 App의 특정 URL(HTTP 체크)로 지정할 필요는 없습니다. 특히 JSP 같은 것을 호출하지 말고 간략하게 cat /tmp/healthCheck 등과 같은 간단한 Command 체크면 충분합니다.

Liveness Probe

Pod의 현재 상태를 체크하기 위한 기능입니다. 주기적으로 체크해서 Pod이 비 정상적일 경우 Restart 시켜 줍니다. (Restart 행위 자체는 K8S 노드의 Kubelet이 수행)

Liveness Probe에는 몇가지 설정이 있는데 SWAT 성능테스트를 통해 대략적으로 아래와 같은 설정이 최적인 것으로 판단됩니다. (물론 시스템 특성에 따라 변동)

항목	정의	권고
initialDelaySeconds	Probe 가 최초 수행하기 전의 대기시간	- App 로딩 시간에 의존적이며 Tomcat 등 startup time을 보고 결정할 것 - 대략 100초 정도 권고
periodSeconds	Probe 의 체크 주기 (interval)	- 대략 10초 내외 권고
timeoutSeconds	Probe 체크에 대한 timeout	- 보통 1초를 많이 주는데, 이렇게 짧게 정할 경우 부하 상황에서 1초 응답을 넘는 경우가 발생하여 Pod이 Restart 되버림 → 3초 정도 권장
successThreshold	성공 판단을 위한 회수	- 성공은 1회로 충분
failureThreshold	실패 판단을 위한 회수	- 실패는 보통 2~3회 내외로 설정

다음 시리즈에서는 Readiness Probe에 대하여 알아봅니다.