Pod 배포 컨트롤러 종류와 차이

pod를 배포할 수 있는 built-in 컨트롤러는 아래 표와 같이 여러가지 종류가 있습니다.

Deployment	상태 비 저장(state-less) App에 주로 사용 됩니다. (예: web server, proxy server, 등)
ReplicaSet	가용성을 위해 복제본 관리를 해주는 컨트롤러 입니다. ReplicationController의 새로운 버전입니다. ReplicaSet이 단독으로 쓰이기 보다 Deployment에 종속적인 사용이 권장됩니다.
StatefulSet	상태 저장이 필요한 App에 사용됩니다. (예: database,  지정된 볼륨의 재할당이 필요한 상황, 등) 각 pod의 독자성을 유지합니다. 동일한 스펙으로 생성되었지만 서로 교체는 불가능합니다.
DaemonSet	클러스터의 모든 노드에 배포 됩니다. 새로운 노드가 클러스터에 추가되면 새로운 노드에 pod가 생성 됩니다. 노드가 클러스터에서 제거되면 해당 pod는 garbage로 수집 됩니다. 모든 노드에서 로그를 수집해야 하는 경우 사용될 수 있습니다.
Job	일회성으로 실행되어야 하는 pod를 배포 하고 pod가 완료되면 pod를 삭제 합니다.
CronJob	크론 스케줄에 의해 반복적인 일정에 따라 pod를 배포합니다.

 

 

728x90

 

 

이 중에서도 대표적인 배포 컨트롤러는 세 가지가 있습니다.

1. Deployment
2. StatefulSet
3. DaemonSet

 

Deployment - k8s docs

StatefulSet - k8s docs

 

DaemonSet - k8s docs

 

 

 

ReplicaSet controller로도 pod를 배포할 수 있지만 Deployment의 .spec.replicas로 정의할 수 있게 되면서 ReplicaSet을 별도로 정의할 필요가 없어졌습니다.

• 

 

replicaset, job, cronjob 얘들은 나중에 궁굼해 지거나 기회가 될 때 따로 알아 보기로 하구요

daemonset은 살짝 배포 정도만 해보고 지금 당장 너무 궁굼한 deployment, statefulset만 살펴보겠습니다.

 

 

---

 

DaemonSet

 

DaemonSet의 주 용도는 모니터링, 로그 수집이라고 하니 stateful 이 필요해 보이지는 않습니다.

(모니터링, 로그 수집의 흔한 아키텍처는 데이터 수집 후 특정 저장소에 기록할 수 있도록 전달해주는 역할입니다.)

 

DaemonSet은 일반적으로 클러스터의 모든 노드에 pod가 배포되지만,

테인트(taint)와 톨러레이션(toleration)옵션으로 특정 노드들에서만 실행 시킬 수 있다는 글을 보았습니다.

• 쿠버네티스 컨트롤러 : 데몬셋(DaemonSet) - 아리수

 

daemonset 찾아보고 있는데 갑자기 taint, toleration이라니 이 둘에 의해서 pod 배포가 되고 안되고 한다는데

그냥 넘어갈 수가 없어서 taint와 toleration에 대해 찾아 봤습니다.

 

참조

• 테인트(TAINTS) 및 톨러레이션(TOLERATIONS) - Red Hat docs
• taint와 toleration - k8s docs

 

위 두 개의 문서를 보면 뭔가 이해가 될 것 같으면서도 이해가 잘 안되는 느낌이 있었는데

taint, toleration의 뜻을 검색해보니 어떤 용도로 사용이 되는지 이해가 되네요

 

taint

toleration

 

반응형

 

 

taint로 얼룩진 node에는 pod가 배포될 수 없지만, toleration으로 이 얼룩을 허용해서 배포가 가능하게 해준다.

이렇게 보니 이름을 기가막히게 지어놓은거 같습니다. -0-

 

그런데 taint, toleration은 daemonset controller가 아니라 k8s scheduler에서 참조하는 값이라 DaemonSet에서 만 사용이 가능한 것은 아닙니다.

 

Scheduler는 언젠가 알아볼 날을 기약하고 서둘러 DaemonSet으로 pod를 배포해 보도록 합니다.

(daemonset보다 statefulset이 더 궁굼하니까~~~)

 

DaemonSet update는 updateStrategy에 정의된 업데이트 전략을 사용합니다.

• OnDelete : 객체 구성이 변경될 때 DaemonSet Pod를 삭제하고 다시 만들지 않습니다. 대신 컨트롤러가 변경사항이 반영된 새 pod를 만들도록 하려면 수동으로 pod 삭제해야 합니다.
• RollingUpdate : DaemonSet pod를 자동으로 삭제하고 다시 만듭니다. 변경사항이 유효하면 출시가 자동으로 트리거 됩니다. 이 전략이 DaemonSet의 기본 업데이트 전략입니다.

 

 

 

그냥 테스트 하면 재미 없을거 같은데...

docker image빌드를 하더라도  코딩좀 해서 자주 쓰인다는 모니터링, 로그수집 이런거 흉내를 좀 내봐야 겠어요

 

 

 

 

kubernetes controllers : replication, deployment, daemonset - 호롤리한 하루

 

 

---

 

 

 

Deployment와 StatefulSet으로 MySQL 배포 차이

 

일반적으로 stateful한 App은 StatefulSet을 이용하여 배포하고, state-less한 App은 Deployment로 배포한다고 하지만,

Deployment에서도 PV(PersistentVolume)를 사용할 수 있기에 Deployment로의 배포는 stateful한 App을 실행할 수 없다는 의미는 아닙니다.

다만 stateful 성격의 요건들이 많을수록 statefulset으로의 배포가 유리해질 수 있습니다.

 

아래 두 문서는 MySQL을 Deployment와 StatefulSet을 이용한 배포 가이드 이구요

k8s docs

• 단일 인스턴스 상태 저장 애플리케이션 실행 - with deployment
• 복제 된 상태 저장 애플리케이션 실행 - with statefulset

 

위의 두 문서 모두 PV로 stateful App인 MySQL을 다루는 내용이지만 단일 실행과, 복제된 상태의 실행이라는 차이가 있는 것으로 보여집니다.

• deployment는 single-instance
• statefulset은 replicated-state