Kubernetes Liveness Probe - 예제 및 일반 트랩

Kubernetes는 이미 전통적인 배치 방법을 깨뜨리고 매우 유행하게 되었다.비록 이것은 매우 좋은 배치 플랫폼이지만, 또한 복잡성과 도전을 가져왔다.Kubernetes는 노드와 작업 부하를 빈틈없이 관리할 수 있는데 이런 용기화 배치 플랫폼의 중요한 기능은 바로 자기 복구이다.컨테이너 레벨에서 자체 복구를 하기 위해서, 우리가 종료 코드에 의존하지 않는 한, Kubernetes에서 탐지기라고 불리는 건강 검사를 해야 합니다.
활성탐지기는 크레인이 건강한지 검사하고 크레인이 건강하지 않다고 여겨지면 다시 시작할 수 있다.이 작업은 Readiness Probes I discussed in my previous post의 작업과 다릅니다.
탐측기의 부품을 살펴보고 활동 탐측기의 고장을 어떻게 설정하고 제거하는지 깊이 있게 알아보자.

탐측하다
탐지기는 kubelet이 수행하는 건강 검사입니다.
모든 탐지기는 설정에 매우 중요한 다섯 개의 매개 변수를 가지고 있다.

initial DelaySeconds: 컨테이너가 시작된 후 기다리는 시간입니다.(기본값: 0)

periodSeconds: 실행 빈도 탐색(기본값: 10)

timeoutSeconds: 응답을 기다리는 시간(기본값: 1)

successThreshold: 용기 건강의 성공 탐지 실행 횟수 표시 (기본값: 1)

failureThreshold: 용기가 건강하지 않은 실패 탐지 실행 횟수 표시 (기본값: 3)

이 탐지 파라미터를 설정하려면 프로그램의 행동을 분석해야 합니다.
프로브 유형에는

실행 탐지기
Exec probe는 셸이 없는 컨테이너 내에서 명령을 실행합니다.명령의 퇴출 상태가 건강 상태를 결정한다. 0은 건강 상태이다.다른 어떤 것도 건강하지 않다.

        livenessProbe:
          initialDelaySeconds: 1
          periodSeconds: 5
          timeoutSeconds: 1
          successThreshold: 1
          failureThreshold: 1
          exec:
            command:
            - cat
            - /etc/nginx/nginx.conf

TCP 탐지기
TCP probe는 TCP 연결이 지정된 포트에서 열릴 수 있는지 확인합니다.포트를 열면 성공, 포트를 닫거나 재설정하면 실패로 간주됩니다.

        livenessProbe:
          initialDelaySeconds: 1
          periodSeconds: 5
          timeoutSeconds: 1
          successThreshold: 1
          failureThreshold: 1
          tcpSocket:
            host:
            port: 80

HTTP 프로브
HTTP probe가 HTTP 호출을 진행하고 상태 코드는 200을 포함하여 400을 포함하지 않는 것을 성공으로 간주합니다.상기 코드를 제외한 모든 상태 코드는 건강하지 않은 것으로 간주된다.
다음은 구성할 HTTP 탐지기 추가 매개 변수입니다.

호스트: 연결할 IP 주소(기본값:pod IP)

스키마:HTTP 스키마(기본값:HTTP)

경로:호출할 HTTP 경로

httpHeaders: 보내려는 사용자 정의 헤더입니다.

포트:포트 연결.

Tip: If Host header is required, then use httpHeader.

HTTP 탐지기의 예

        livenessProbe:
          initialDelaySeconds: 1
          periodSeconds: 2
          timeoutSeconds: 1
          successThreshold: 1
          failureThreshold: 1
          httpGet:
            host:
            scheme: HTTP
            path: /
            httpHeaders:
            - name: Host
              value: myapplication1.com
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 5

쿠베르네트스의 활력 탐색
Kubelet은 크레인을 다시 시작해야 하는지 확인하기 위해 liveness 탐색을 실행합니다.예를 들어 Go로 작성된 마이크로서비스가 있다고 가정하면 이 마이크로서비스는 코드의 일부 부분에 버그가 있어서 실행할 때 동결될 수 있다.오류가 발생하지 않도록 liveness 탐지기를 설정해서 마이크로 서비스가 동결되었는지 확인할 수 있습니다.이렇게 하면, microsoft 용기가 다시 시작되고 원시 상태로 회복됩니다.
만약 응용 프로그램이 이러한 문제에 부딪혔을 때 우아하게 종료된다면, liveness 탐지기를 설정할 필요는 없지만, 모르는 버그가 있을 수도 있습니다.pod는 설정/기본 리셋 정책에 따라 다시 시작합니다.

활력 탐지기의 흔한 함정
탐지기는 탐지기의 대답을 통해서만 운행 상황을 확인할 수 있으며, 그들은 우리의 마이크로 서비스/응용 프로그램의 시스템 동태를 모른다.만약 어떤 이유로든 탐지기의 회신 지연이 주기초를 초과하면,FailureReshold microservice/응용 프로그램은 건강하지 않은 것으로 확인되고pod 리셋을 촉발합니다.따라서 모든 응용 프로그램의 행위에 파라미터를 설정하는 것이 매우 중요하다.

종속 연결 장애
Similar to readiness probes liveness Probe를 잘못 설정하면 등급 연결 고장이 발생할 수 있습니다.만약 건강 단점이 외부 의존 관계를 가지거나 다른 답변 제공을 막을 수 있는 조건이 있다면 등급 연결 고장을 초래할 수 있다.따라서 이런 행위를 감안하면 탐지기를 배치하는 것이 중요하다.

충돌 회로
만약 우리 프로그램이 일정 시간마다 대량의 데이터를 캐시에 읽어야 한다고 가정한다면이때 반응이 없으면 가짜 양성을 초래할 수도 있다. 왜냐하면 탐침이 실패할 수 있기 때문이다.이 경우 livenessprobe의 고장으로 용기가 다시 시작되고 연속적인 재부팅 주기에 들어갈 수 있습니다.이러한 상황에서, 준비된 탐지기는 사용하기에 더욱 적합할 수 있습니다.pod는 서비스에서만 제거하여 유지보수 작업을 수행할 것입니다. 데이터가 수신될 준비가 되면, 탐지기에 응답하기 시작할 수 있습니다.
Google 마이크로서비스의 Liveness 포트 (탐지기가 명중할 것) 는 프로그램이 실행 중인 절대적인 최저 요구 사항을 검사해야 합니다.이렇게 하면 활동성 검사가 성공하고pod가 다시 시작되지 않으며 저희는 서비스 데이터가 제 방식대로 흐르도록 확보할 것입니다.

예: Nginx 배포의 예
Nginx를 예제로 배포합니다.다음은 배치와 서비스 설정입니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: k8s-probes
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
        livenessProbe:
          initialDelaySeconds: 1
          periodSeconds: 2
          timeoutSeconds: 1
          successThreshold: 1
          failureThreshold: 1
          httpGet:
            host:
            scheme: HTTP
            path: /
            httpHeaders:
            - name: Host
              value: myapplication1.com
            port: 80

이 설정을 k8s probes deployment라는 파일에 씁니다.yaml, kubectl apply -f k8s-probes-deployment.yaml 명령을 사용하여 적용합니다.

apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx
  name: nginx
  namespace: default
spec:
  ports:
  - name: nginx-http-port
    port: 80
  selector:
    app: nginx
  sessionAffinity: None
  type: NodePort

또한 이 설정을 k8s probes svc라는 파일에 씁니다.yaml 및 다음 명령을 사용하여 적용합니다.

kubectl apply -f k8s-probes-svc.yaml

활력 탐지기 고장 제거
Liveness 탐지기는 특정한 단점이 없습니다. kubectl describe pods <POD_NAME> 명령을 사용하여 이벤트와 현재 상태를 보아야 합니다.

kubectl get pods

이곳에서, 우리는 우리의 크레인이 운행 상태에 있는 것을 볼 수 있으며, 그것은 이미 유량을 받을 준비가 되어 있다.

NAME                         READY   STATUS    RESTARTS   AGE
k8s-probes-7d979f58c-vd2rv   1/1     Running   0          6s

응용 프로그램의 설정을 검사합시다.

 kubectl describe pods k8s-probes-7d979f58c-vd2rv | grep Liveness

여기서 우리는 우리가 설정한 매개 변수를 볼 수 있다.

    Liveness:       http-get http://:80/ delay=5s timeout=1s period=5s #success=1 #failure=1

이 사건들을 살펴보자.

Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  45s   default-scheduler  Successfully assigned default/k8s-probes-7d979f58c-vd2rv to k8s-probes
  Normal  Pulling    44s   kubelet            Pulling image "nginx"
  Normal  Pulled     43s   kubelet            Successfully pulled image "nginx" in 1.117208685s
  Normal  Created    43s   kubelet            Created container nginx
  Normal  Started    43s   kubelet            Started container nginx

보시다시피 실패나 성공의 기미가 없다.성공 조건에는 이벤트가 기록되지 않습니다.
이제 livenessProbe를 바꿉시다.httpGet.'/존재하지 않음' 의 경로를 가리키고pod 상태를 보십시오.

kubectl get pods

경로를 변경하면 liveness 탐지기가 실패하고 용기가 다시 시작됩니다.

NAME                          READY   STATUS    RESTARTS   AGE
k8s-probes-595bcfdf57-428jt   1/1     Running   4          74s

우리는 용기가 이미 네 차례 재부팅된 것을 볼 수 있다.
이 사건들을 좀 봅시다.

...
Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  53s                default-scheduler  Successfully assigned default/k8s-probes-595bcfdf57-428jt to k8s-probes
  Normal   Pulled     50s                kubelet            Successfully pulled image "nginx" in 1.078926208s
  Normal   Pulled     42s                kubelet            Successfully pulled image "nginx" in 978.826238ms
  Normal   Pulled     32s                kubelet            Successfully pulled image "nginx" in 971.627126ms
  Normal   Pulling    23s (x4 over 51s)  kubelet            Pulling image "nginx"
  Normal   Pulled     22s                kubelet            Successfully pulled image "nginx" in 985.155098ms
  Normal   Created    22s (x4 over 50s)  kubelet            Created container nginx
  Normal   Started    22s (x4 over 50s)  kubelet            Started container nginx
  Warning  Unhealthy  13s (x4 over 43s)  kubelet            Liveness probe failed: HTTP probe failed with statuscode: 404
  Normal   Killing    13s (x4 over 43s)  kubelet            Container nginx failed liveness probe, will be restarted
  Warning  BackOff    13s                kubelet            Back-off restarting failed container

위에서 말한 바와 같이 "Liveness probe failed: HTTP probe failed with status code: 404"는 probe failed with HTTP code 404를 나타낸다.상태 코드도 고장 제거에 도움이 된다.그 후에 kubelet은 용기를 다시 시작할 것이라고 알려 줍니다.

결론
Google 프로그램이 불확정 상태일 때, Kubernetes liveness 탐지기는 생명을 구하는 볏짚입니다.그것들은 용기를 다시 켜서 프로그램을 원시 상태로 복구합니다.그러나 정확하게 배치해야 한다는 점이 중요하다.물론 정확한 방법은 없다.이것은 완전히 응용 프로그램과 Kubernetes가 특정한 고장 장면에서 어떻게 작동하길 원하는지에 달려 있습니다.상응하는 값을 설정하고 실제 사례 장면을 통해 이 값을 테스트한다.

한층 더 읽다

Kubernetes Start Up Probes - Examples & Common Pitfalls

Kubernetes Readiness Probes - Examples & Common Pitfalls

Kubernetes Core Probe Documentation

Configure Liveness, Readiness and Startup Probes

Kubernetes Container probes Documentation

Container Lifecycle Hooks Documentation

사진 작성자Mario Caruso가 Unsplash