Kubernetes DaemonSet / 쿠버네티스, 데몬셋, 서비스, Pattern, 패턴

Kubernetes DaemonSet

---

DaemonSet을 이용하여 모든 노드 혹은 특정 노드에 동일한 Pod들을 실행가능

노드가 클러스터에 추가되면 해당 노드에도 자동으로 추가

노드 제거되면 Pod가 garbage로 수거가 됨

 

여기서 잠깐 확인해봐야할 것

Background process와 DaemonSet의 차이가 무엇인지 아십니까?

- Background process: 유저와 상호작용을 함, Parent process가 존재

- DaemonSet: 유저와 별도로 동작, process동작 Parent process와 연결을 해제

 

아무튼 그래서 모든 노드에서 log를 수집해야한다거나, 노드 정보를 따로 수집해야한다거나 할때 DaemonSet을 활용하면 됨

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
  namespace: kube-system
  labels:
    k8s-app: fluentd-logging
spec:
  selector:
    matchLabels:
      name: fluentd-elasticsearch
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      tolerations:
      # these tolerations are to have the daemonset runnable on control plane nodes
      # remove them if your control plane nodes should not run pods
      - key: node-role.kubernetes.io/control-plane
        operator: Exists
        effect: NoSchedule
      - key: node-role.kubernetes.io/master
        operator: Exists
        effect: NoSchedule
      containers:
      - name: fluentd-elasticsearch
        image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
        resources:
          limits:
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        volumeMounts:
        - name: varlog
          mountPath: /var/log
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log

https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/

fluentd-elasticsearch container를 각 노드에 띄우는 예시

tolerations를 통해 control-plane node에도 띄울지 말지 결정할 수 있음

앞서 말한 예시와 같이 모든 노드에서 log수집이 필요할 때 이렇게 DaemonSet으로 관리할 수 있음

 

DaemonSet와 ReplicaSet의 차이도 존재하는데,

DaemonSet	ReplicaSet
기본적으로 모든 노드에 하나의 Pod가 배치	ReplicaSet은 보통 노드위치와 개수를 명시
Scheduler에 영향을 받지 않음	Scheduler를 통해 배치
따라서 Scheduler가 없어도 배치 가능 즉, 다른 Pod가 배치되기 전에 먼저 실행할 수 있음	Scheduler가 있어야 배치 가능
노드의 unschedulable 필드의 영향을 받지 않음	해당 필드에 영향을 받음

이렇게 보면 또 DaemonSet은 모든 노드에 배치되는 것이 보장되는가? 생각할 수 있지만, 앞선 예시와 같이 taint / toleration으로 제한이 가능함

또, 노드의 unschedulable 필드의 영향을 받지 않는다고 되어있음

노드 점검을 위해 클러스터에서 제외하는 작업인 cordon, drain을 사용해봐도 안되는 것을 알 수 있음

$ kubectl drain dev-chicken-node --ignore-daemonsets=true

그럴땐 --ignore-daemonsets=true 옵션을 줘서 해결 가능

 

DaemonSet에 접근을 하고 싶다면 아래의 방식들을 사용가능

Service: DaemonSet와 동일한 Pod selector를 갖는 Service를 생성하고 사용하여 임의의 노드로 접근

DNS: 동일한 Pod selector로 headless-service를 만들고 IP / port 정보를 갖는 DNS와 A레코드로 접근

HostPort + NodeIP: DaemonSet pod에서 hostPort를 지정하고 노드 IP와 port를 통해 접근

Push: DaemonSet에서 외부 다른 서비스로 push하는 방식으로 데이터를 가져옴

 

추가로 다양한 방식으로 DaemonSet과 비슷한 기능을 제공할 수 있음

- 모든 node에서 실행되는 Deployment

- kubelet이 정보를 확인할 수 있는 디렉토리에 파일을 사용하도록 하는 static pod (api server말고 kubelet으로만 관리됨)

등등의 방식이 있음

어떤 방식을 사용하는 것이 본인의 개발환경에 알맞은지 파악하고 적절하게 활용하는 것이 중요