쿠버네티스 완벽 가이드 5장 - 2
5.5 데몬셋
데몬셋은 레플리카셋의 특별한 형태라고 할 수 있는 리소스다.
레플리카셋은 각 쿠버네티스 노드에 총 N개의 파드를 노드의 리소스 상황에 맞게 배치한다.
따라서 각 노드의 파드 수가 동일하다고 할 수 없다.
그러나 데몬셋은 각 노드에 파드를 하나씩 배치하는 리소스다.
따라서 데몬셋은 각 파드가 출력하는 로그를 호스트 단위로 수집하는 Fluentd나
각 파드 리소스 사용 현황 및 노드 상태를 모니터링하는 Datadog 등
모든 노드에서 반드시 동작해야 하는 프로세스를 위해 사용하는 것이 유용하다.
5.5.2 데몬셋 업데이트 전략
디플로이먼트와 마찬가지로 두 가지 업데이트 전략 중 하나를 선택할 수 있다.
OnDelete
OnDelete에서는 데몬셋 매니페스트를 수정하여 이미지 등을 변경했더라도
기존 파드는 업데이트 되지 않는다.
RollingUpdate
데몬셋도 디플로이먼트와 마찬가지로 RollingUpdate를 사용한 업데이트가 가능하다.
하지만 데몬셋은 하나의 노드에 하나의 파드만 가능하므로 동시 생성할 수 있느 최대 파드 수(maxSurge)를 설정할 수 없다.
동시에 정지 가능한 최대 파드 수(maxUnavailable)만 지정할 수 있다.
5.6 스테이트풀셋
스테이트풀셋 역시 레플리카셋의 특수한 형태라고 할 수 있는 리소스다.
데이터베이스 등과 같은 stateful한 워크로드에 사용하기 위한 리소스다.
레플리카셋과의 주된 차이점은 다음과 같다.
- 생성되는 파드명의 접미사는 숫자 인덱스가 부여된 것이다.
- sample-statefultset-0, sample-statefultset-1, ..., sample-statefultset-N
- 파드명이 바뀌지 않는다.
- 데이터를 영구적으로 저장하기 위한 구조로 되어 있다.
- 7장에서 설명할 PersistentVolume을 사용하는 경우에는 파드를 재기동할 때 같은 디스크를 사용하여 다시 생성한다.
5.6.2 스테이트풀셋 스케일링
스테이트풀셋도 레플리카셋과 같은 방법인 kubectl apply -f 또는 kubectl scale을 사용하여 스케일링할 수 있다.
기본적으로 파드를 동시에 하나씩만 생성하고 삭제하기 때문에 조금 시간이 걸린다.
스케일 아웃일 때는 인덱스가 가장 작은 것부터 하나씩 생성하여 Ready 상태가 되고 나면 다음 파드를 생성한다.
반대로 스케일 인일 때는 인덱스가 가장 큰 파드부터 삭제된다.
레플리카셋의 경우 파드가 무작위로 삭제되기 때문에 특정 파드가 마스터가 되는 애플리케이션에는 맞지 않는다.
스테이트풀셋은 0번째 파드가 항상 가장 먼저 생성되고 가장 늦게 삭제되기 때문에 0번째 파드를 마스터 노드로 사용하는
이중화 구조 애플리케이션에 적합하다.
5.6.3 스테이트풀셋의 라이프사이클
파드를 동시에 하나씩만 생성하고 삭제한다했으나 병렬로 동시에 기동시킬 수 있다.
spec.podManagementPolicy를 Parallel로 설정하면 가능하다.
5.6.4 스테이트풀셋 업데이트 전략
스테이트풀셋도 OnDelete와 RollingUpdate 전략을 쓴다.
OnDelete
영속성 영역을 가진 DB나 클러스터 등에서 많이 사용하기 때문에 수동으로 업데이트하고 싶을 경우
OnDelete를 사용하여 임의의 시점이나 다음에 재기동할 때 업데이트를 진행하게 되어 있다.
RollingUpdate
스테이트풀셋에는 영속성 데이터가 있으므로 디플로이먼트와 다르게 추가 파드를 생성해서 롤링 업데이트를 할 수 없다.
또한, 동시에 지정 가능한 최대 파드 수(maxUnavailable)를 지정하여 롤링 업데이트를 할 수도 없으므로
파드마다 Ready 상태인지를 확인하고 업데이트하게 된다.
스테이트풀셋의 RollingUpdate에서는 partition이라는 특정 값이 있다. 이 값을 설정하면 전체 파드 중
어떤 파드까지 업데이트할지를 지정할 수 있다.
5.7 잡
잡(Job)은 컨테이너를 사용하여 한 번만 실행되는 리소스다.
N개의 병렬로 실행하면서 지정한 횟수의 컨테이너 실행(정상 종료)을 보장하는 리소스다.
5.7.1 레플리카셋과의 차이점과 잡의 용도
'기동 중인 파드가 정지되는 것을 전제로 만들어졌는지'가 제일 큰 차이점이다.
예를 들어 '특정 서버와의 rsync'나 'S3 등의 오브젝트 스토리지에 파일 업로드' 와 같이 파드의 정지가
정상 종료되는 작업에 적합하다.
레플리카셋 등에서는 정상 종료 횟수 등을 셀 수 없기 대문에 배치 처리인 경우에는 잡을 적극적으로 사용하자.
5.7.3 restartPolicy에 따른 동작 차이
잡의 매니페스트에는 spec.template.spec.restartPolicy에 OnFailure 또는 Never 중 하나를 지정해야 한다.
Never의 경우 파드에 장애가 발생하면 신규 파드가 생성된다.
OnFailure의 경우 다시 동일한 파드를 사용하여 잡을 다시 시작한다.
5.7.4 태스크와 작업 큐 병렬 실행
| 워크 로드 | completions | parallelism | backofLimit |
| 1회만 실행하는 태스크 | 1 | 1 | 0 |
| N개 병렬로 실행시키는 태스크 | M | N | P |
| 한 개씩 실행하는 작업 큐 | 미지정 | 1 | P |
| N개 병렬로 실행하는 작업 큐 | 미지정 | N | P |
M, N, P는 임의의 수이다.
1회만 실행하는 태스크
성공 유무에 관계 없이 반드시 1회만 실행하고 싶은 경우
N개 병렬로 실행시키는 태스크
M번 정상 종료할 때까지 N개 병렬로 실행한다. M < N이어도 파드는 M개만 생성된다.
한 개씩 실행하는 작업 큐
한 번 정상 종료할 때까지 한 개씩 실행하는 작업을 하고 싶은 경우
N개 병렬로 실행하는 작업 큐
N개 만큼의 파드를 병렬 실행하고, 하나라도 정상 종료하면 그 이후는 파드를 생성하지 않는다.
성공 횟수보다는 큰 처리 전체가 정상 종료할 때까지 몇 개의 병렬 수로 계속 실행하고 싶은 경우 적합하다.
정상 종료된 파드 이후에도 실행 중인 파드는 강제적으로 정지하지 않고 개별 처리가 종료할 때까지 계속 동작한다.
5.7.5 일정 기간 후 잡 삭제
잡 리소스는 한번만 실행하는 태스크로 생성하는 경우가 있는데, 종료 후에도 삭제 되지 않는다.
spec.ttlSecondsAfterFinished를 설정하여 잡이 종료한 후에 일정 기간(초) 경과 후 삭제할 수 있다.
5.8 크론잡
크론잡은 크론과 같이 스케줄링된 시간에 잡을 생성한다.
잡의 변형된 상태로 보이지만, 크론잡과 잡의 관계는 디플로이먼트와 레플리카셋의 관계와 비슷하다.
즉, 크론잡이 잡을 관리하고 잡이 파드를 관리하는 3계층 구조라고 할 수 있다.
5.8.2 크론잡 일시 정지
크론잡은 지정한 시간에 잡을 계속 생성한다.
점검 등의 이유로 잡 생성을 원하지 않을 경우 suspend를 할 수 있다.
spec.suspend가 true로 설정되어 있으면 스케줄 대상에서 제외된다(기본값은 false).
kubectl patch cronjob cronjob이름 -p '{"spec": {"suspend":true}}'
5.8.3 크론잡을 임의의 시점에 실행
--from 옵션을 사용하여 크론잡으로 잡을 생성할 수 있다.
kubectl create job 만드려는job이름 --from cronjob/cronjob이름
5.8.4 동시 실행 제어
크론잡에서는 잡을 생성하는 특성상 동시 실행에 대한 정책을 설정할 수 있다.
잡 실행이 의도한 시간 간격 안에서 정상 종료할 때는 명시적으로 지정하지 않아도 동시 실행되지 않고 새로운 잡을 실행한다.
한편 기존 잡이 아직 실행되고 있을 때는 정책으로 새로운 잡을 실행할지 말지를 제어하고 싶은 경우가 있다.
동시 실행에 대한 정책은 spec.concurrencyPolicy에 지정한다.
| 정책 | 개요 |
| Allow(기본값) | 동시 실행에 대한 제한을 하지 않음 |
| Forbid | 이전 잡이 종료되지 않았을 경우 다음 잡은 실행하지 않음(동시 실행하지 않음) |
| Replace | 이전 잡을 취소하고 잡을 시작 |
5.8.5 실행 시작 기한 제어
크론잡은 지정한 시간이 되면 쿠버네티스 마스터가 잡을 생성한다.
따라서 쿠버네티스 마스터가 일시적으로 정지되는 경우 등과 같이 시작 시간이 지연되면,
그 지연 시간을 허용하는 시간(초, spec.startingDeadlineSeconds)을 지정할 수 있다.
기본값에서는 아무리 시작 시간이 늦어져도 잡을 생성하게 되어 있다.
5.8.6 크론잡 이력
크론잡 설정 항목에는 저장할 잡 개수를 지정할 수 있다.
| 설정 항목 | 개요 |
| spec.successfulJobHistoryLimit | 성공한 잡을 저장하는 개수 |
| spec.failedJobHistoryLimit | 실패한 잡을 저장하는 개수 |
잡이 남아 있다는 것은 잡에 연결되어 있는 파드도 'Completed(정상 종료)', 'Error(이상 종료)'의 상태로 남아 잇고
kubectl log 명령어로 로그를 확인할 수 있다는 의미다.
그러나 실제 운영 환경에서는 컨테이너 로그는 외부 로그 시스템을 통해 운영하는 것을 추천한다.
5.9 정리
| 리소스 종류 | 사용 방법 |
| 파드 | 디버깅이나 확인 용도로 사용 |
| 레플리케이션 컨트롤러 | 추천하지 않음. 대신 레플리카셋 사용 |
| 레플리카셋 | 파드를 스케일링하여 관리 기본적으로 디플로이먼트를 통해 사용 |
| 디플로이먼트 | 스케일링할 워크로드에 사용 |
| 데몬셋 | 각 노드에 파드 하나씩 배포할 때 사용 |
| 스테이트풀셋 | 영속성 데이터 등의 상태를 가진 워크로드에 사용 |
| 잡 | 작업 큐나 태스크 등 컨테이너 종료가 필요한 워크로드에 사용 |
| 크론잡 | 정기적으로 잡을 생성하고 싶은 경우 사용 |
