728x90
DaemonSet
파드의 복사본이 모든 노드에 하나씩 호스트되는 것을 보장한다.
- 사용사례: 모니터링 에이전트, 로깅 콜렉터
- manifest 파일은 ReplicaSet과 매우 흡사하다.( Kind만 다름)
- spec.metadata.labels(파드의 라벨)과 spec.selector.matchLabels(데몬셋의 라벨 셀렉터)가 일치해야한다.
apiVersion: apps/v1 kind: DaemonSet metadata: name: custom-daemon-set labels: spec: template: metadata: labels: app: daemon-set-app containers: - name: daemon-set-container image: nginx selector: matchLabels: app: daemon-set-app
- 만약, 특정 이미지를 가지고 동작하는 파드의 데몬셋을 생성해야할 때는 deploy 생성 커맨드를 이용해 yaml 파일 템플릿만 만들고(dry-run=client -o yaml) 여기서 spec.replicas 필드와 status, spec.strategy 필드 등을 제거한 후 이를 create하는 방법이 있다.
- 조회: kubectl get daemonsets
- 상세 조회: kubectl describe daemonsets [name]
- 동작 원리: 버전 1.12까지는 파드 생성시 파드마다 nodeName을 지정해주었으나 이후에는 Node Affinity와 스케쥴러 사용
Static Pods
기본적으로 kubelet은 API Server를 통해 파드의 정보를 받아 이를 생성하는 역할을 수행한다. 즉, 파드를 생성하는 방법을 알고 있다. 만약 쿠버네티스 클러스터가 존재하지 않는 상태로 kubelet만 존재하는데 파드를 생성하려면 어떻게 해야할까? 파드에 대한 정보를 kubelet에 전달할 수 있어야 한다.
kubelet은 정해진 경로 하위에 파드 정보를 가진 파일(.yaml)을 두게되면, 해당 파일의 정보를 가지고 파드를 생성할 뿐만 아니라 해당 파드의 유지를 보장한다. 파드 내부의 애플리케이션이 오류를 발생시켜 종료되어도 kubelet은 이를 다시 실행시킨다. 이렇게 직접 해당 경로에 파드 설정 파일을 두어 생성한 파드를 Static Pod라고 한다. kubelet은 해당 경로를 주기적으로 확인하여, 파일이 생성되면 파드를 생성하고, 파일이 수정되면 파드를 변경한다. 만약 파일이 지워지면 파드를 지운다.
즉, Static Pods는 kube-api server의 관여 없이 특정 노드의 kubelete 에 의해서 관리되는 파드를 의미한다.
ExecStart=/usr/local/bin/kubelet
...
#정적 파드 정의 파일들이 존재하는 위치
--pod-manifest-path=/etc/Kubenetes/manifests
#static pod 정의 파일들이 존재하는 위치를 정의하는 파일(.yaml)
--kubeconfig=/var/lib/kubelet/kubeconfig
...
아래와 같이 경로를 가지고 있는 파일을 제공할 수도 있다.
--config=kubeconfig.yaml
- Static Pod는 설정 경로의 파일을 통해서만 생성, 수정, 삭제될 수 있다.
- API Server는 kubelete이 생성한 Static Pod를 인식한다. 이는 kubelet이 Static Pod를 생성할 때 클러스터의 파드라고 인식하고 API Server에 Mirror Object를 생성하기 때문이다. API Server를 통해 조회하는 파드(kubectl get pods)는 해당 Mirror Object로, 편집하거나 삭제할 수 없다.
Static Pods DaemonSets
Created by Kubelete | Created by Kube-API Server(DaemonSet Controller) |
Deploy Control Plane components as Static Pods | Deploy Monitoring Agents, Logging Agents on nodes |
Ignored by the Kube-Scheduler | Ignored by the Kube-Scheduler |
Static Pods 위치
- Master Node(controlplane)인 경우
- /etc/kubernetes/manifests
- Worker Node인 경우
- # node 조회 kubectl get node -o wide # node ssh 접근 ssh [node-name] # config 파일에서 staticPodPath 키워드 조회(해당 필드의 값이 static pod 경로) cat /var/lib/kubelete/config.yaml | grep staticPodPath
Static Pod 조회
- 모든 네임스페이스의 파드 조회(-노드명의 형태인 파드가 Static Pod)
kubectl get pods -A
kubectl get pods --all-namespaces
- 확실하지 않은 경우 하나의 파드를 자세히 보는 방법이 존재(ownerReferences[*].kind가 Node인 경우 해당 파드의 주인이 노드임을 보고 이것이 Static Pod임을 알 수 있다.)
kubectl get pod [pod-name] -n [namespace-name] -o yaml
반응형
'Kubernetes' 카테고리의 다른 글
k8s) Application Lifecycle Management (0) | 2023.11.17 |
---|---|
k8s) Scheduling - 5. Scheduler (1) | 2023.11.17 |
k8s) Scheduling - 3. Requirements & Limits (1) | 2023.11.17 |
k8s) Scheduling - 2. Node Selector & Node Affinity (1) | 2023.11.17 |
k8s) Scheduling - 1. Taints & Tolerations (0) | 2023.11.17 |