kubernetes-in-action/app.js at master · luksa/kubernetes-in-action

레플리케이션과 그 밖의 컨트롤러 : 관리되는 파드 배포

수동적인 개입 없이도 안정적인 상태로 배포한 애플리케이션이 자동으로 실행되고 유지되길 원한다면, 레플리케이션컨트롤러또는 디플로이먼트와 같은 유형의 리소스를 생성해 실제 파드를 생성하고 관리한다.

4.1 파드를 안정적으로 유지하기

파드 안에 있는 컨테이너가 죽으면 어떻게 해야할까?

파드가 노드에 스케줄링 되는 즉시, 해당 노드의 Kubelet은 파드의 컨테이너를 실행하고, 파드가 존재하는 한 컨테이너가 계속 실행되도록 할것이다.

컨테이너의 주 프로세스에서 crash가 발생하면, Kubelet이 컨테이너를 다시 시작한다.

• 쿠버네티스가 애플리케이션을 자동으로 재시작 한다.

• 애플리케이션이 무한 루프, 교착 상태에 빠져 응답하지않아 내부에서 재시작이 안될경우?

→ 외부에서 app 상태를 체크해야함

4.1.1 라이브니스 프로브

liveness probe 를 통해 컨테이너가 살아있는지 확인할 수 있다.

파드의 스펙 *specfication 에 각 컨테이너의 라이브니스 프로브를 지정할 수 있다!

• 쿠버네티스는 주기적으로 프로브를 실행하고 실패할 경우 컨테이너를 다시 시작한다.

레디니스 프로브(readiness probe)도 지원한다.

쿠버네티스의 컨테이너에 프로브 실행 방법

• HTTP GET 프로브 : 지정한 IP, 포트, 경로에 HTTP GET 요청을 수행함. 응답이 오류가 아닐 경우, 프로브 성공했다고 간주함. 아닐경우 컨테이너 재시작
• TCP 소켓 프로브: 컨테이너의 지정된 포트에 TCP연결 시도. 연결에 성공하면 프로브 성공, 그렇지 않으면 컨테이너 재시작
• Exec 프로브 : 컨테이너 임의의 명령 실행하고 명령의 종료 상태 코드를 확인함. 상태코드 ==0 일경우, 프로브 성공 모든 다른 코드는 실패로 간주.

4.1.2 HTTP 기반 라이브니스 프로브 생성

라이브니스 프로브 추가하는방법 알아보자.

웹서버이므로, 웹서버 요청처리 체크하는 라이브니스프로브 추가하자.

• 파드 yaml 파일

kubia-liveness-probe.yaml

apiVersion: v1
kind: Pod
metadata:
  name: kubia-liveness
spec:
  containers:
  - image: luksa/kubia-unhealthy : 문제가있는 애플리케이션이미지이름
    name: kubia
    livenessProbe: 라이브니스 프로브
      httpGet:
        path: / http요청 경로
        port: 8080

• 파드 생성

$ k create -f kubia-liveness-probe.yaml

4.1.3 동작중인 라이브니스 프로브 확인

kubectl get po kubia-liveness

RESTARTS 열에 몇번 시작했는지 표시

크래시된 컨테이너의 애플리케이션 로그 얻기

$kubectl logs mypod --previous

다시 시작된 이유

#kubectl describe po kubia-libveness

컨테이너가 돌아가고있다 → Running

Error 의 이유로 Terminated되었으며 코드가 137이다.

컨테이너가 4번 다시 시작되었다.

<aside> 💡 137 : 프로세스가 외부 신호에 의해 종료됐음을 의미한다. 128+x다. 이때 x 는 프로세스에 전송된 시그널 번호이며, 이 시그널에 의해 컨테이너가 강제로 종료됨을 의미한다. (SIGKILL) 종료코드 143은 128+15 **(SIGTERM)**에 해당

</aside>

Events는 컨테이너가 종료된 이유를 명시한다.

컨테이너가 종료되면 완전히 새로운 컨테이너가 생성된다. 동일한 컨테이너가 다시 시작되는 것이 아니다.

4.1.4 라이브니스 프로브의 추가 속성 설정

아까 그 describe..

프로브 옵션 외에도 지연, 제한시간, 기간 등과 같은 추가 속성을 볼 수도 있다.

→ 프로브를 정의할때 지정할 수 있다.

• delay=0s : 컨테이너가 시작된 후 바로 프로브가 시작된다는 것을 의미함.
• timeout = 1s: 제한시간, 컨테이너가 1초안에 응답해야함
• period=10s:컨테이너는 10초마다 프로브 수행하며, 프로브가 3번 연속 실패하면 컨테이너 재시작

초기 지연을 추가한 라이브니스 프로브

kubia-liveness-probe-initial-delay.yaml

apiVersion: v1
kind: Pod
metadata:
  name: kubia-liveness
spec:
  containers:
  - image: luksa/kubia-unhealthy
    name: kubia
    livenessProbe:
      httpGet:
        path: /
        port: 8080
      initialDelaySeconds: 15 :쿠버네티스는 첫번째 프로브 실행까지 15초 기다린다.

컨테이너가 시작되자마다 프로브를 시작한다. 이 경우 애플리케이션이 요청을 받을 준비가 안되어있기 때문에 프로브 실패 횟수가 증가해버리기 때문에 지정해주는것.

파드시작시, 이 문제 발생했다면 initialDelaySeconds를 적절하게 설정하지 않았기 때문이다.

4.1.5 효과적인 라이브니스 프로브 생성

라이브니스 프로브가 확인해야 할 사항

• 특정 URL 경로에 요청하도록 프로브를 구성해 애플리케이션 내에서 실행중인 모든 주요 구성요소가 살아있는지 또는 응답이 없는지 확인하도록 구성할 수 있다.
• 애플리케이션의 내부만 체크하고, 외부 요인의 영향을 받지 않도록 해야 한다.

프로브를 가볍게 유지하기

• 프로브는 너무 많은 연산 리소스를 사용해서는 안되며, 완료하는데 너무 오래 걸리지 않아야 한다.
• 프로브는 비교적 자주 실행되며 1초내에 완료해야한다.
• 프로브를 무겁게 만들면 메인 애플리케이션 프로세스에서 사용할 수 있는 CPU시간이 줄어들게 된다.

프로브에 재시도 루프를 구현하지 말자

실패 임계값을 1로 설정하더라도, 쿠버네티스는 실패를 한번 했다고 간주하기전에 프로브를 여러번 재시도 하기때문

라이브니스 프로브 요약

컨테이너를 계속 실행되도록 하는 + 프로브 확인 작업은 파드를 호스팅하는 노드의 kubelet에서 수행한다. 마스터 플레인 구성요소는 이 프로세스에 관여하지 x

but, 노드 크래시는 컨트롤 플레인의 몫.

4.2 레플리케이션 컨트롤러 소개

레플리케이션 컨트롤러: 쿠버네티스 리소스로서, 파드가 항상 실행되도록 보장한다. 파드가 사라지면,사라진 파드를 감지해 교체 파드를 생성한다. 보통 하나의 파드만 관리하지만, 일반적으로 파드의 여러 복제본을 작성하고 관리하기 위한것이다.

→ 노드가 실패하면, 레플리케이션 컨트롤러가 관리하는 파드만 다시 생성된다.

4.2.1 레플리케이션 컨트롤러의 동작

• 실행중인 파드의 목록을 지속적으로 모니터링
• 특정 “유형”의 파드수가 의도하는 수와 일치하는지 항상 확인

→ 유형이라는 것은 사실 존재하지 않고, 특정 레이블 셀렉터와 일치하는 파드 세트에 작동한다.