T- 데몬셋은 드레인된 노드에도 파드를 배치하나
개요
데몬셋은 자신이 관리하는 파드에 알아서 몇 가지 테인트, 톨러레이션을 부여해주고, 이를 통해 온갖 노드에 배치될 수 있도록 만든다.
이중에 매우 흥미로운 게, node.kuberntes.io/unschedulable
인데, 이거 설마 드레인된 노드에도 배치될 수 있게 해주는 걸까?
세팅
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentd-elasticsearch
labels:
k8s-app: fluentd-logging
spec:
selector:
matchLabels:
name: fluentd-elasticsearch
template:
metadata:
labels:
name: fluentd-elasticsearch
spec:
tolerations:
- key: node-role.kubernetes.io/control-plane
operator: Exists
effect: NoSchedule
- key: node-role.kubernetes.io/master
operator: Exists
effect: NoSchedule
initContainers:
- name: test
image: bash
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
priorityClassName: system-node-critical
volumes:
- name: varlog
hostPath:
path: /var/log
데몬셋에 나온 기본 양식에서 내가 조금 커스텀했다.
이걸 드레인 시킨 이후에 적용시켜볼 것이다.
드레인시키기
내 클러스터에 드레인해보는 건 처음이라 굳이 남겨둔다.
코든이 먼저 적용되고 축출이 일어나기 이전에, 데몬셋 관련 이슈가 터진다.
아울러 연결돼있던 CSI에 대해서도 말을 내뿜는다.
밀어버려!
사실상 이건 처음 알았는데, 데몬셋을 무시하라는 게 진짜 그냥 무시해버리는 거구나;;
디플로이먼트들은 죄다 발을 뺐는데 데몬셋들은 그대로 남아있는 게 보인다.
아무튼 해당 worker2
노드는 이제 테인트도 걸리고, unschedulable 필드도 true가 됐다.
드레인된 노드에 데몬셋이 배치되는가?
역시나 정답은 yes입니다.
unschedulable 필드는 하등 고려 안 하시는 갓몬셋 ㄷㄷ
실제로 해당 노드에 컨테이너가 띄워진 것도 확인된다.
결론
열심히 파드 정보를 훑어봤지만, 톨러레이션 말고는 해당 노드에 지정될 수 있을 만한 더 특별한 근거를 찾을 수 없었다.
그러니까, 데몬셋은 그냥 붙어있다고 판명난 노드라면 일단 배치하고 봅니다!
CNI 같은 네트워크 플러그인들이 붙어야 클러스터가 잘 돌아가니, 이런 방식으로 움직이는 것은 당연하다고 생각된다.
부가 실험: cordon하는 원리
여태 잘 몰랐으나, 드레인은 사실 그냥 테인트를 거는 방식으로 동작한다고 또다른 추측을 해볼 수 있을 것 같다.
그렇다면 내가 그냥 파드를 만들더라도 톨러레이션만 잘 걸어주면 드레인된 노드에 배치될 수 있을 것이다.
이렇게 파드를 만든다.
;; 진짜로 만들어진다.
공부할수록 느끼는 거지만, 쿠버네티스도 결국 몇 가지 핵심 원리만 두고 그것을 활용하는 기능들을 만들어준 것에 불과하다.
정말 엄청난 것은 결국 그 핵심 원리들, 스케줄러와 컨트롤러, 그리고 그 모든 통신과 조작을 진행하는 api서버..