[k8s] Kubernetes DaemonSet vs StaticPod 개념[1/2]

Kubernetes에는 많은 형태의 Pod 배포 방법이 존재한다. 그렇기에 많은것을 공부해야되고 아직까지도 새로운것이 많다.

이번에는 DaemonSet 과 StaticPod에 대해서 알아보자!!

 

먼저 DaemonSet이란?

DaemonSet 기본

DaemonSet은 노드별로 Pod를 배포할 때 사용하는 서비스이다.  예를들어서 클러스터에 5개의 Node가 존재한다면 Daemonset이 있다면 각 노드별로 Pod가 배포되고 총 5개의 Pod가 배포된다.

일반적으로 Node별로 Pod 정보를 수집하거나, Node 정보를 수집하거나 또는 각 Node에 필수로 실행되어야하는 Pod가 있을 때 DaemonSet을 많이 사용한다.

 

현재 재직중인 회사에서도 Node의 상태를 모니터링하는 오픈소스 플랫폼을 사용하는데, 이를 DaemonSet으로 지정해서 사용한다.

 

물론, 각 Node별로 Deployment 또는 기타 다른 방법으로 Pod를 생성하는 방법도 있다. 하지만 Node 생길때마다 반복적으로 해야하고, 실수로 배포를 못할수도 있으므로 이런것을 미연에 방지하고자 DaemonSet을 사용한다.

 

DaemonSet의 생성방법은 어떻게될까?

생성방법은 Deployment를 생성하는것과 매우 유사하다. 중요한 부분은 matchLabels와 template 아래 부분이 될것 같다.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: daemonset-test1
  namespace: default
  labels:
    k8s-app: fluentd-logging
spec:
  selector:
    matchLabels: #DaemonSet으로 배포할 때 배포대상을 지정하는 것이다.
      name: daemonset
  template: #여기서부터는 내가 각 Node에 배포할 Pod 정보를 입력하면 된다.
    metadata:
      labels:
        name: daemonset
    spec:
      containers:
      - name: daemonset-test
        image: nginx

 

DaemonSet을 생성하면 kubelctl get daemonset으로 조회를 할 수 있고, node01에 daemonset-test1 pod가 배포되었다.

DaemonSet 모습

근데, 조금 이상한 점이 있다. 분명 DaemonSet은 각 노드별로 동일한 Pod를 배포하는 서비스라고 배웠다.

위 예시에는 현재 controlplane /node01 2개의 node가 존재하는데, daemonset으로 배포된 pod는 node01에만 있다.

controlplane taint 설정

왜 그럴까? 그 답은 contolplane node에 taint 설정이 되어 있기 때문이다. 이전에 Taint에 대해서 공부하였고 Taint가 설정되어 있으면 Pod 배포시에 Tolerations 설정을 해야지만 정상적으로 배포가 되는것을 공부하였다!!

[k8s] Kubernetes Node Taint & Tolerations의 개념정리

 

그렇다면 Taint 설정을 해제하면 어떻게될까?

node taint 해제

Taint가 해제되면, 해제 즉시 controlplane node에 daemonset-test pod가 배포된다!!

Taint 해제 후 모습

 

그렇다면 DaemonSet으로 배포한 Pod을 삭제하면 어떻게될까?

DaemonSet이 Deployment와 비슷하기 때문에 예상가능하듯이 pod 삭제 즉시 pod가 다시 생성된다.

Pod 재생성

 

마지막으로 DaemonSet의 Pod Image를 업데이트는 어떻게할까?

두가지 방법이 있다.

 - 1. 새로운 DaemonSet을 만들고 배포하고, 기존의 DaemonSet을 삭제한다.

 - 2. DaemonSet Pod를 롤링 업데이트한다.

 

아마 대다수의 사람들은 2.의 방법으로 진행할 것이다. 1.의 방법도 가능하지만 DaemonSet을 새로 만들어야하는 번거로움이 있다.

그에 반해 2.의 방법은 간단한 명령어로 자동으로 Pod 삭제/재생성까지 해주므로 훨씬 편하다.

 

기존의 DaemonSet으로 배포하고 있는 Image는 nginx:1.9.1 버전을 사용하고 있었다.

기존 DaemonSet

그리고 Image를 nginx로 업데이트 해주었다.

kubectl set image daemonset daemonset-test1 *=nginx

kubectl set image daemonset <daemonset name> *=<update image name>

 

그러면 DaemonSet의 Image가 업데이트된 nginx로 업데이트 되었으며, 기존의 pod가 삭제되고 신규 pod가 생성되었다.

신규 DaemonSet

DaemonSet 업데이트로 인한 pod 변화

이번에는 DaemonSet에 대해서 공부해보았다. 다음에는 StaticPod을 공부할 예정인데, 슥 보면 DeamonSet와 StaticPod이 유사하다.

어떤 차이점이 있고, 어떤 공통점이 있는지 알아보자!!

 

끄읏!!