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

파드를 안정적으로 유지하기 위한 방법

1. 라이브니스 프로브(liveness probe)

파드의 specification에 각 컨테이너의 liveness porbe를 지정할 수 있다. 쿠버네티스는 주기적으로 프로브를 실행하고 프로브가 실패할 경우 컨테이너를 다시 시작한다.

 

쿠버네티스가 프로브를 실행하는 방식은 3가지이다.

• HTTP GET 프로브. 지정한 IP 주소, 포트, 경로에 HTTP GET 요청을 수행한다. 응답을 수신해 실패했다고 판단하면 컨테이너를 다시 시작한다.
• TCP 소켓 프로브. 컨테이너의 지정된 포트에 TCP 연결을 시도한다. 연결에 실패하면 컨테이너가 다시 시작된다.
• Exec 프로브는 컨테이너 내의 임의의 명령을 실행하고 명령의 종료 상태 코드 확인.

컨테이너에 크래시가 발생하거나 liveness probe가 실패한 경우 노드의 kubelet이 컨테이너를 재시작하게 하고 마스터에서 실행중인 쿠버네티스 컨트롤 플레인 구성 요소는 관여하지 않는다.

그러나 노드 자체에 크래시가 발생한 경우 이로 인해 중단된 파드를 대체할 파드 생성은 컨트롤 플레인의 몫이다. kubelet은 노드에서 실행되기 때문에 노드가 고장나면 동작하지 않는다.

따라서 다른 노드에서 애플리케이션을 실행시키려면 레플리케이션 컨트롤러를 이용해야 한다.

2. 레플리케이션 컨트롤러

레플리케이션 컨트롤러는 사라진 파드를 감지해 교체 파드를 생성한다. 실행 중인 파드 목록을 지속적으로 모니터링한다.

레플리케이션컨트롤러는 다음과 같은 3가지 필수 요소가 있다.

• label selector : 레플리케이션 범위에 있는 파드 결정
• replica count : 파드의 desired 수 지정
• pod template : 새로운 파드 레플리카 만들 때 사용

파드가 충분하지 않으면 pod template에서 새 파드가 만들어진다.

 

레플리케이션컨트롤러 생성 후 kubectl get 명령으로 정보를 얻어올 수 있다.

원하는 파드 수, 현재 파드 수, 준비된 파드 수가 표시된다.

 

2-1 컨트롤러가 파드를 생성한 원인 이해

레플리케이션컨트롤러는 삭제된 파드에 대해 즉시 통지를 받지만 이 통지가 대체 파드를 생성하게 하는 것은 아니다.

컨트롤러가 실제 파드 수를 확인하게 하는 트리거 역할을 한다.

2-2 레플리케이션컨트롤러의 레이블 셀렉터

레플리케이션컨트롤러는 레이블 셀렉터와 일치하는 파드만을 관리한다.

파드의 레이블을 변경했을 때 : 해당 파드가 레이블 셀렉터와 일치하지 않게 되므로 그 파드를 관리하지 않게 되고 레플리케이션컨트롤러는 사라진 파드를 대체하기 위해 새로운 파드를 기동한다.

레플리케이션컨트롤러의 레이블 셀렉터를 변경했을 때 : 모든 파드가 레플리케이션컨트롤러의 범위를 벗어나 전부 새로운 파드를 생성한다.

2-3 레플리케이션컨트롤러의 파드 탬플릿

이미 만들어진 파드에는 영향이 없다. 새 파드를 생성할 때 사용이 된다.

2-4 수평 스케일링

kubectl scale rc kubia --replicas=10

다음과 같은 명령어로 레플리케이션컨트롤러 리소스의 replicas field 값을 변경할 수 있다. 이 명령은 쿠버네티스에게 무엇을 해야할 지 알려주는 명령으로 보이지만 사실 그렇지 않다.

레플리케이션컨트롤러의 정의를 편집해 선언적인 방식으로 수평 스케일링을 하는 것을 보자

kubectl edit rc kubia

이 명령을 수행하면 레플리케이션컨트롤러의 정의가 담긴 YAML파일이 열리고 여기서 replicas의 수를 변경해 주면 확장 시킬 수 있다.

kubectl scale 명령 역시 레플리케이션컨트롤러의 desired states를 선언적으로 변경하는 것이다. 

파드를 수평으로 확장한다는 것은 x개의 인스턴스가 실행되게 하고 싶다와 같이 의도되는 상태를 지정하는 것이다.

이를 선언적 접근 방식이라고 한다.

2-5 레플리케이션컨트롤러 삭제

kubectl delete로 하면 파드들도 삭제되지만 파드는 관리만 받는 것이기 때문에 --cascade=false 옵션을 추가해 파드는 계속 실행시킬 수 있다.

 

레플리케이션컨트롤러 VS 레플리카셋

레플리카셋은 차세대 레플리케이션컨트롤러이다.

똑같이 동작하지만 더 풍부한 표현식을 사용하는 파드 셀렉터를 가지고 있다.

레플리케이션컨트롤러의 레이블 셀렉터는 특정 레이블이 있는 파드를 매칭시킬 수 있는 반면, 레플리카셋의 셀렉터는 특정 레이블이 없는 파드나 레이블의 값과 상관이 없는 특정 레이블의 키를 갖는 파드를 매칭시킬 수 있다.

데몬셋

레플리케이션컨트롤러와 레플리카셋은 클러스터 내 어딘가에 지정된 수만큼 파드를 실행하는데 사용된다.

그러나 클러스터의 모든 노드에, 노드당 하나의 파드만 실행되길 원하는 경우 데몬셋을 사용해야 한다.

예를 들자면 로그 수집기나 리소스 모니터와 같이 인프라 관련 퍼드를 들 수 있다.

 

데몬셋은 원하는 복제본 수의 개념이 없다. 파드 셀렉터와 일치하는 파드 하나가 각 노드에서 실행 중인지 확인하는 것이 데몬셋이 수행하는 역할이기 때문에 복제본 개념이 필요가 없다.

 

데몬셋 정의인 파드 템플릿에서 node-Selector 속성을 지정하여 파드를 배포해야하는 노드를 정의할 수 있다.

완료 가능한 단일 태스크를 수행하는 파드 실행

위에서 다룬 레플리케이션컨트롤러, 레플리카셋, 데몬셋은 지속적인 태스크를 실행. 이런 파드의 프로세스는 종료되면 다시 시작된다.

잡 리소스

쿠버네티스는 잡 리소스로 컨테이너 내부에서 실행 중인 프로세스가 성공적으로 완료되면 컨테이너를 다시 시작하지 않는 파드를 실행할 수 있다.

잡의 예로는 데이터를 어딘가에 저장하고 있고, 이를 변환해서 어딘가로 전송하는 경우를 들 수 있다.

잡으로 여러 파드 인스턴스를 실행할 때 spec에 completion 속성과 parallelism 속성을 이용해 병렬 또는 순차적으로 실행할 건지 설정할 수 있다.

CronJob

일정 시간 또는 지정된 간격으로 반복 실행을 해야할 때 Cronjob 리소스를 구성한다.

리눅스와 유닉스에서 지원하는 cron 작업을 지원하는 것이다.