[쿠버네티스 인 액션] 4장. 레플리케이션과 그 밖의 컨트롤러 - 라이브니스 프로브, 레플리케이션 컨트롤러

4.1. 라이브니스 프로브 

- 라이브니스 프로브 liveness probe : 컨테이너가 살아 있는지 확인할 수 있음. 이 작업은 노드의 kubelet에서 수행함. 

but 노드 자체에 크래시가 발생한 경우, 노드 크래시로 중단된 모든 파드의 대체 파드는 컨트롤 플레인에서 관리해야함. 

 

- 3가지 종류 

1) HTTP GET 프로브 : 지정한 IP주소, 포트, 경로에 HTTP GET 요청 수행. 프로브가 응답 수신하고 응답 코드가 오류 내지 않는 경우 성공했다고 간주. 서버가 오류 코드 반환하거나 응답하지 않으면 프로브가 실패한 것으로 간주돼, 컨테이너 다시 시작 

2) TCP 소켓 프로브 : 컨테이너의 지정된 포트에 TCP 연결 시도. 연결 성공하면 프로브 성공, 그렇지 않으면 컨테이너 다시 시작 

3) Exec 프로브 : 컨테이너 내의 임의의 명령을 실행하고 명령의 종료 상태 코드를 확인. 상태 코드가 0이면 프로브 성공, 모든 다른 코드는 실패로 돌아간 것 

kubectl desribe po kubia-liveness

...
Last State : Terminated
  Resaon : Terminated
  Exit Code : 137 
...

 

- 확인해야 할 사항 

1) 특정 URL에 요청하도록 프로브를 구성해 어플리캐에션 내에서 실행 중인 모든 주요 구성 요소가 살아 있는지 또는 응답 없는지 확인하도록 수정 

2) 애플리케이션의 내부만 체크하고, 외부 요인의 영향을 받지 않도록 해야함 

ex, 프론트엔드 웹 서버의 라이브니스 프로브는 벡엔드 데이터베이스 연결할 수 없을 때 실패 반환해서 안됨

3) 너무 많은 연산 리소스 사용해서 안되며, 완료하는데 너무 오래 걸리지 않아야 함 (1초 내에 완료)

 

 

4.2 레플리케이션 컨트롤러 

 

- 레플리케이션 컨트롤러는 쿠버네티스 리소스로서 파드가 항상 실행되도록 보장하는 것 

파드가 사라지면, 레클리케이션 컨트롤러는 사라진 파드 감지해 교체 파드 생성한다. 

파드A는 직접 생성해 관리되지 않는 파드인 반면, 파드 B는 레플리케이션 컨트롤러에 의해 관리됨. 노드에 장애가 발생한 후 레플리케이션컨트롤러는 사라진 파드 B를 교체하기 위해 새로운 파드 B를 생성하지만, 파드 A는 완전히 유실됨.

 

- 동작 

1) 실행중인 파드 목록을 지속적으로 모니터링하고, 특정 "유형"의 실제 파드 수가 의도하는 수와 일치하는지 항상 확인 

2) 이런 파드가 너무 적게 실행중인 경우 파드 템플릿에서 새 복제본 만들고, 너무 많은 파드가 실행 중이면 초과 복제본이 제거. 

3) 이런 케이스로는 다음과 같은 케이스가 존재할 수 있다. 

- 누군가 같은 유형의 파드 수동으로 만들거나 

- 누군가 기존 파드의 유형 변경하거나 (레이블 셀렉터 변경) 

- 누군가 의도하는 파드 수를 변경 

 

- 세 가지 요소 이해 

 

1) 레이블 셀렉터 : 레플리케이션컨트롤러의 범위에 있는 파드 결정 

2) 레플리카 수 : 실행할 파드의 의도하는 수

3) 파드 템플릿 : 새로운 파드 레플리카 만들 때 사용 

 

 

- 삭제된 파드에 대해 레플리케이션컨트롤러가 새로운 파드 생성하도록 작동 

 

- 레플리케이션 컨트롤러에서 파드 제거 

특정 파드에 어떤 작업을 하려는 경우, 해당 파드를 레플리케이션컨트롤러 범위에서 제거하면 작업이 훨씬 수월해짐

ex, 일정 시간이 지난 후 또는 특정 이벤트가 발생한 후에 파드가 제대로 동작하지 않는 버그가 있는 경우, 레플리케이션컨트롤러 범위 밖으로 빼내 컨트롤러가 새 파드로 교체하도록 한 다음, 원하는 방식으로 디버그하거나 문제 재연 가능 

 

- 파드 템플릿 변경 

레플리케이션 컨트롤러의 파드 템플릿을 편집해 컨테이너 이미지 변경하고 기존 파드 삭제함으로써 새로운 템플릿 사용해 파드를 새로운 이미지로 업그레이드하는데 사용하지만, 9장(디플로이먼트) 통해 더 나은 방법으로 쓸 수 있음