8장. 상태 점검을 사용하여 애플리케이션 상태 모니터링
소프트웨어 시스템에서는 일시적인 문제(예: 일시적인 연결 끊김, 구성 오류 또는 외부 종속 항목의 문제)로 인해 구성 요소가 비정상 상태가 될 수 있습니다. OpenShift Container Platform 애플리케이션에는 비정상 상태의 컨테이너를 탐지하고 처리하는 다양한 옵션이 있습니다.
8.1. 상태 점검 이해
상태 점검에서는 준비 상태, 활성 상태, 시작 상태 점검을 함께 사용하여 실행 중인 컨테이너에서 정기적으로 진단을 수행합니다.
상태 점검을 수행할 컨테이너가 포함된 Pod 사양에 프로브를 1개 이상 포함할 수 있습니다.
기존 Pod에서 상태 점검을 추가하거나 편집하려면 Pod DeploymentConfig
오브젝트를 편집하거나 웹 콘솔에서 개발자 화면을 사용해야 합니다. CLI에서는 기존 Pod의 상태 점검을 추가하거나 편집할 수 없습니다.
- Readiness 프로브
준비 상태 프로브는 컨테이너가 서비스 요청을 수락할 준비가 되었는지 확인합니다. 컨테이너에 대한 준비 상태 프로브가 실패하면 kubelet에서 사용 가능한 서비스 끝점 목록에서 Pod를 제거합니다.
프로브는 실패 후에도 Pod를 계속 검사합니다. Pod를 사용할 수 있게 되면 kubelet은 사용 가능한 서비스 끝점 목록에 Pod를 추가합니다.
- 활성 상태 점검
활성 상태 프로브는 컨테이너가 계속 실행 중인지 확인합니다. 교착 상태와 같은 상태로 인해 활성 상태 프로브가 실패하면 kubelet에서 컨테이너를 종료합니다. 그런 다음 Pod는 재시작 정책에 따라 작업을 수행합니다.
예를 들어
restartPolicy
가Always
또는OnFailure
인 Pod의 활성 상태 프로브는 컨테이너를 종료한 후 다시 시작합니다.- Startup 프로브
시작 프로브는 컨테이너 내 애플리케이션이 시작되었는지를 나타냅니다. 기타 모든 프로브는 시작 프로브가 성공할 때까지 비활성화됩니다. 시작 프로브가 지정된 기간 내에 성공하지 못하면 kubelet에서 컨테이너를 종료하고 컨테이너에 Pod의
restartPolicy
가 적용됩니다.일부 애플리케이션에는 첫 번째 초기화 시 추가 시작 시간이 필요할 수 있습니다. 시작 프로브를 활성 상태 또는 준비 상태 프로브와 함께 사용하여
failureThreshold
및periodSeconds
매개변수를 사용하여 해당 프로브를 긴 시작 시간을 처리할 수 있습니다.예를 들어 실패 30회의
failureThreshold
와 10초의periodSeconds
를 사용하면(30 * 10s = 300s) 최대 5분 동안 시작 프로브를 활성 상태 프로브에 추가할 수 있습니다. 시작 프로브가 처음으로 성공하면 활성 상태 프로브가 시작됩니다.
다음과 같은 테스트 유형을 사용하여 활성 상태 프로브, 준비 상태 프로브, 시작 프로브를 구성할 수 있습니다.
HTTP
GET
: HTTPGET
테스트를 사용하는 경우 테스트는 웹 후크를 사용하여 컨테이너의 상태를 결정합니다. HTTP 응답 코드가200
에서399
사이인 경우 테스트가 성공한 것입니다.HTTP
GET
테스트는 완전히 초기화되었을 때 HTTP 상태 코드를 반환하는 애플리케이션에 사용할 수 있습니다.-
컨테이너 명령: 컨테이너 명령 테스트를 사용하는 경우 프로브는 컨테이너 내부에서 명령을 실행합니다. 테스트가 상태
0
으로 종료되면 프로브가 성공한 것입니다. - TCP 소켓: TCP 소켓 테스트를 사용하는 경우 프로브는 컨테이너에 소켓을 열려고 합니다. 컨테이너는 프로브에서 연결을 설정할 수 있는 경우에만 정상 상태로 간주됩니다. TCP 소켓 테스트는 초기화가 완료된 후 수신 대기를 시작하는 애플리케이션에 사용할 수 있습니다.
다음과 같은 다양한 필드를 구성하여 프로브 동작을 제어할 수 있습니다.
-
initialDelaySeconds
: 컨테이너를 시작한 후 프로브를 예약할 수 있는 시간(초)입니다. 기본값은 0입니다. -
periodSeconds
: 프로브 수행 사이의 지연 시간(초)입니다. 기본값은10
입니다. 이 값은timeoutSeconds
보다 커야 합니다. -
timeoutSeconds
: 프로브가 시간 초과되고 컨테이너가 실패한 것으로 간주되는 비활성 시간(초)입니다. 기본값은1
입니다. 이 값은periodSeconds
보다 작아야 합니다. -
successThreshold
: 실패 후 프로브에서 컨테이너 상태를 성공으로 재설정해야 하는 횟수입니다. 활성 상태 프로브는 값이1
이어야 합니다. 기본값은1
입니다. failureThreshold
: 프로브가 실패할 수 있는 횟수입니다. 기본값은 3입니다. 지정된 시도 횟수 후에는 다음이 수행됩니다.- 활성 상태 프로브의 경우 컨테이너가 재시작됩니다.
-
준비 상태 프로브의 경우 Pod가
Unready
로 표시됩니다. -
시작 프로브의 경우 컨테이너가 종료되고 Pod의
restartPolicy
가 적용됩니다.
프로브 예
다음은 오브젝트 사양에 나타나는 다양한 프로브 샘플입니다.
Pod 사양에 컨테이너 명령 준비 상태 프로브가 포함된 샘플 준비 상태 프로브
apiVersion: v1 kind: Pod metadata: labels: test: health-check name: my-application ... spec: containers: - name: goproxy-app 1 args: image: k8s.gcr.io/goproxy:0.1 2 readinessProbe: 3 exec: 4 command: 5 - cat - /tmp/healthy ...
Pod 사양에 컨테이너 명령 테스트가 포함된 샘플 컨테이너 명령 시작 프로브 및 활성 상태 프로브
apiVersion: v1 kind: Pod metadata: labels: test: health-check name: my-application ... spec: containers: - name: goproxy-app 1 args: image: k8s.gcr.io/goproxy:0.1 2 livenessProbe: 3 httpGet: 4 scheme: HTTPS 5 path: /healthz port: 8080 6 httpHeaders: - name: X-Custom-Header value: Awesome startupProbe: 7 httpGet: 8 path: /healthz port: 8080 9 failureThreshold: 30 10 periodSeconds: 10 11 ...
Pod 사양의 타임아웃을 사용하는 컨테이너 명령 테스트가 포함된 샘플 활성 상태 프로브
apiVersion: v1 kind: Pod metadata: labels: test: health-check name: my-application ... spec: containers: - name: goproxy-app 1 args: image: k8s.gcr.io/goproxy:0.1 2 livenessProbe: 3 exec: 4 command: 5 - /bin/bash - '-c' - timeout 60 /opt/eap/bin/livenessProbe.sh periodSeconds: 10 6 successThreshold: 1 7 failureThreshold: 3 8 ...
배포에 TCP 소켓 테스트를 사용하는 샘플 준비 상태 프로브 및 활성 상태 프로브
kind: Deployment apiVersion: apps/v1 ... spec: ... template: spec: containers: - resources: {} readinessProbe: 1 tcpSocket: port: 8080 timeoutSeconds: 1 periodSeconds: 10 successThreshold: 1 failureThreshold: 3 terminationMessagePath: /dev/termination-log name: ruby-ex livenessProbe: 2 tcpSocket: port: 8080 initialDelaySeconds: 15 timeoutSeconds: 1 periodSeconds: 10 successThreshold: 1 failureThreshold: 3 ...