소프트웨어 업계에서 버그 없는 코드를 작성하는 것은 불가능하다. 게다가 분산 애플리케이션으로 작업할 때는 장애가 일어날 확률이 훨씬 더 높아진다. 결국, 장애에 대한 세간의 관심은 장애를 피하는 것에 오류를 감지하고 복구하는 쪽으로 이동했다.
장애에 대한 정의가 천차만별이기 때문에, 장애 감지는 모든 애플리케이션에 동등하게 적용할 만큼 간단한 작업이 아니다. 또한 수 많은 유형의 장애별로 각기 그에 알맞은 장애 조치가 필요하다. 일시적인 장애는 충분한 시간이 주어지면 자체 복구 될 수 있으며, 애플리케이션 재시작이 필요한 장애도 있다. 쿠버네티스가 장애를 감지하고 해결하는데 쓰이는 여러 가지 확인 단계를 살펴보자.
프로세스 정상상태 확인은 큐블렛이 컨테이너 프로세스에 대해 지속적으로 수행하는 가장 간단한 정상상태 확인이다. 컨테이너 프로세스가 실행 중이 아니라면, 점검은 다시 시작된다.
따라서 또 다른 정상상태 확인을 하지 않더라도, 애플리케이션은 이런 일반적인 확인 단계로 좀 더 견고해진다. 애플리케이션이 모든 종류의 장애를 감지할 수 있고 자기 스스로 종료될 수 있다면, 프로세스 정상상태 확인만으로도 충분하다.
그러나 대부분의 경우 이것만으로는 충분치 않아, 다른 유형의 정상상태 확인이 필요하다.
애플리케이션이 교착 상태에 빠지면, 프로세스 정상상태 확인으로는 여전히 정상으로 간주된다. 이런 종류의 문제와 애플렠이션 비즈니스 로직에 따른 도 다른 형태의 장애를 감지하기 위해 쿠버네티스에는 라이브니스 점검이 있다.
라이브니스(생존상태) 점검일나 큐블릿 에이전트가 정기적으로 검사를 수행해 컨테이너가 여전히 정상상태인지 확인하는 과정이다. 일부 장애는 애플리케이션 워치독이 장애 보고를 못할 수 있으므로, 애플리케이션 자체 내부보다는 외부에서 정상상태 확인을 수행하는 것이 중요하다.
장애 조치와 관련해서는 장애가 감지되는 경우 컨테이너가 재시작되기 때문에 이 라이브니스 점검은 프로세스 정상상태 확인과 유사하다. 그러나 애플리케이션 정상상태 확인 시에 어떤 방법을 쓰는지에 대해서는 다음과 같이 좀 더 융통성을 부여한다.
HTTP 기반의 라이브니스 점검은 아래 예제에서 볼 수 있다.
apiVersion: v1
kind: Pod
metadata:
name: pod-with-liveness-check
spec:
containers:
-image: k8spatterns/random-genertor:1.0
name: random-generator
env:
- name: DELAY_STARTUP
value: "20"
ports:
- contanerPort: 8080
protocol: TCP
livenessProbe:
httpGet:
path: /actuator/health #정상상태 확인 종단점
port: 8080
initialDelaySeconds: 30 # wait time
애플리케이션의 특성에 따라 가장 적합한 방법을 선택할 수 있다. 애플리케이션이 정상상태인지 아닌지 여부를 판별하는 것은 개발자의 구현에 달려 있기 하지만, 정상상태 확인을 통과하지 못하면 컨테이너가 다시 시작된다는 사실을 기억해야 한다.
컨테이너를 재시작하는 것이 소용 없는 경우라면, 근본적인 문제 해결 없이 쿠버네티슥가 컨테이너를 재시작하므로 정상상태 확인 실패는 아무런 도움이 되지 않는다.
라이브니스 점검은 비정상적인 컨테이너를 죽이고 새로운 컨테이너로 대체함으로 애플리케이션의 정상상태를 유지하는데 유용하다. 그러나 때로는 컨테이너가 정상상태가 아닐 수 있어, 재시작하는 것도 도움이 안될 때가 있을 수 있다.
가장 일반적인 예는 컨테이너가 여전히 시작 중이고 아직 요청을 처리할 준비가 안 됐을 경우다. 혹은, 컨테이너에 과부하가 걸릴 수도, 지연 시간이 증가할 수도 있으며, 또 다른 부하로부터 잠시 보호받길 원할 수도 있다.