Static Pods는 노드에서 직접 실행되는 Pod로, API 서버를 통해 관리되지 않고 Kubelet에 의해 직접 실행된다.
Static Pod는 일반적으로 시스템 구성 요소(예: etcd, kube-apiserver, kube-scheduler) 또는 Kubernetes 클러스터 외부에서 관리되어야 하는 특수한 워크로드를 실행하는 데 사용된다.
Static Pod의 특징
- Kubelet에 의해 관리:
- Static Pod는 노드의 Kubelet에 의해 직접 실행된다.
- Kubernetes apiserver에서 관리되지 않으며, 클러스터 상태와 무관하게 동작.
- 노드 특정:
- Static Pod는 특정 노드에서만 실행된다.
- Static Pod의 definition파일은 해당 노드의 파일 시스템에 저장되어야 한다. (/etc/kubernetes/manifest)
- Kubelet의 staticPodPath 디렉토리에 저장되어야 하며 이는 kubelet-config.yaml에서 지정한다.
- /etc/kubernetes/manifest 여기에 Pod definition을 저장하면 kubelet은 주기적으로 디렉토리 안의 파일을 확인하고, Pod를 만든다.
- Pod를 만들 뿐 아니라 alive할 수 있도록 보장해준다.
- 자동으로 Mirror Pod 생성:
- Static Pod가 실행되면 Kubernetes는 해당 Pod의 "Mirror Pod"를 API 서버에 자동으로 생성하여 클러스터 상태를 반영.
- 자체 복구:
- Static Pod가 종료되거나 삭제되면 Kubelet이 이를 감지하고 자동으로 재시작.
- 일반적으로 시스템 구성 요소에 사용:
- Kubernetes 자체 핵심 구성 요소(예: kube-apiserver, kube-scheduler, etcd 등)은 Static Pod로 실행되는 경우가 많음.
replicaset이나 deployments, service 등은 이렇게 특정 디렉토리에 definition files을 놓음으로서 만들 수 없다.
apiVersion: v1
kind: Pod
metadata:
name: static-pod-example
labels:
app: static-pod
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
Static Pod | 일반 Pod | |
관리 주체 | Kubelet | Kubernetes API 서버 |
YAML 위치 | 노드의 파일 시스템 | Kubernetes API 서버를 통해 정의 |
스케줄링 | 특정 노드에서만 실행 | 스케줄러가 적절한 노드를 선택 |
복제본 관리 | 수동 관리 | ReplicaSet, Deployment 등으로 자동 관리 |
Mirror Pod 생성 | Mirror Pod가 API 서버에 생성됨 | Mirror Pod 없음 |
Static Pods | DaemonSets |
Created by the kubelet | Created by Kube-API server (DaemonSet Controller) |
Deploy Control Plane component as Static Pods | Deploy Monitoring Agents, Logging, Agent on nodes |
Ignored by the Kube-Scheduler |
kubelet은 자동으로 각각의 static Pod를 위해 API server에 mirror pod를 만들도록 노력한다.
이것은 node에서 동작중인 Pod가 API server에서 visible하다는 것이지만, API Server로부터 control될 수는 없다는 것을 의미한다.
--pod-manifest-path=/etc/kubernetes/manifests/
- 일반 Pod와 동일하게 확인할 수 있다. (Static Pod는 실행 중인 노드의 이름으로 접미사가 붙음)
# 모든 namespace에 static pods를 얼마나 가지고 있나?
$ kubectl get pods -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-flannel kube-flannel-ds-6k654 1/1 Running 0 12m
kube-flannel kube-flannel-ds-7xn9q 1/1 Running 0 11m
kube-system coredns-69f9c977-nhsqf 1/1 Running 0 12m
kube-system coredns-69f9c977-rnvsg 1/1 Running 0 12m
kube-system etcd-controlplane 1/1 Running 0 12m
kube-system kube-apiserver-controlplane 1/1 Running 0 12m
kube-system kube-controller-manager-controlplane 1/1 Running 0 12m
kube-system kube-proxy-4kjbl 1/1 Running 0 11m
kube-system kube-proxy-hjwrq 1/1 Running 0 12m
kube-system kube-scheduler-controlplane 1/1 Running 0 12m
# 뒤에 hash값이 붙지 않은 4개가 해당된다.(etcd-controlplane, apiserver...)
# 전부 controlplane위에서 생성됐다.
$ cat /var/lib/kubelet/config.yaml
apiVersion: kubelet.config.k8s.io/v1beta1 # kubelet configuration.
authentication:
anonymous:
enabled: false
webhook:
cacheTTL: 0s
enabled: true
x509:
clientCAFile: /etc/kubernetes/pki/ca.crt
...
shutdownGracePeriod: 0s
shutdownGracePeriodCriticalPods: 0s
staticPodPath: /etc/kubernetes/manifests # 여기!
streamingConnectionIdleTimeout: 0s
syncFrequency: 0s
volumeStatsAggPeriod: 0s
# static-pods 만드는데 사용되는 yaml 파일들
$ ls /etc/kubernetes/manifests
etcd.yaml kube-apiserver.yaml kube-controller-manager.yaml kube-scheduler.yaml
# static-pod 만들기
# Create a static pod named static-busybox that uses the busybox image and the command sleep 1000
# 명령어 옵션을 --command 뒤에 들어가지 않도록 조심한다.
/etc/kubernetes/manifests ➜ kubectl run static-busybox --image=busybox --dry-run=client -o yaml --command -- sleep 1000 > static-busybox.yaml
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: static-busybox
name: static-busybox
spec:
containers:
- command:
- sleep
- "1000"
image: busybox
name: static-busybox
resources: {}
dnsPolicy: ClusterFirst
restartPolicy: Always
status: {}
# 생성되어 Running중인 것 확인
controlplane /etc/kubernetes/manifests ➜ kubectl get pods
NAME READY STATUS RESTARTS AGE
static-busybox-controlplane 1/1 Running 0 59s
# Edit the image on the static pod to use busybox:1.28.4
controlplane /etc/kubernetes/manifests ➜ cat static-busybox.yaml
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: static-busybox
name: static-busybox
spec:
containers:
- command:
- sleep
- "1000"
image: busybox:1.28.4
name: static-busybox
resources: {}
dnsPolicy: ClusterFirst
restartPolicy: Always
status: {}
# Static-pod 삭제하기
# static-pod는 아무리 삭제해도 다시 create된다.
# greenbox 삭제하기
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
static-busybox-controlplane 1/1 Running 0 59s
static-greenbox-node01 1/1 Running 0 20s
controlplane /etc/kubernetes/manifests ➜ kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
controlplane Ready control-plane 34m v1.29.0 192.30.108.3 <none> Ubuntu 22.04.3 LTS 5.4.0-1106-gcp containerd://1.6.26
node01 Ready <none> 33m v1.29.0 192.30.108.6 <none> Ubuntu 22.04.3 LTS 5.4.0-1106-gcp containerd://1.6.26
controlplane /etc/kubernetes/manifests ➜ ssh 192.30.108.6
node01 ~ ➜ ls /etc/kubernetes/manifests/
# static-pod의 path가 여기가 아님을 알 수 있다.
node01 ~ ➜ cd /var/lib/kubelet/
node01 /var/lib/kubelet ➜ ls
config.yaml kubeadm-flags.env plugins pods
cpu_manager_state memory_manager_state plugins_registry
device-plugins pki pod-resources
node01 /var/lib/kubelet ➜ cat config.yaml
...
staticPodPath: /etc/just-to-mess-with-you
streamingConnectionIdleTimeout: 0s
syncFrequency: 0s
volumeStatsAggPeriod: 0s
node01 /var/lib/kubelet ➜ cd /etc/just-to-mess-with-you/
node01 /etc/just-to-mess-with-you ➜ ls
greenbox.yaml
node01 /etc/just-to-mess-with-you ➜ rm greenbox.yaml
node01 /etc/just-to-mess-with-you ➜ exit
logout
Connection to 192.30.108.6 closed.
# controlplane에서 static pod 사라졌는지 확인하기
controlplane /etc/kubernetes/manifests ➜ kubectl get pods --watch
NAME READY STATUS RESTARTS AGE
static-busybox-controlplane 1/1 Running 0 5m32s
static-greenbox-node01 1/1 Running 0 4m53s
static-greenbox-node01 0/1 Error 0 5m
static-greenbox-node01 0/1 Terminating 0 5m1s
static-greenbox-node01 0/1 Terminating 0 5m1s
controlplane /etc/kubernetes/manifests ✖ kubectl get pods
NAME READY STATUS RESTARTS AGE
static-busybox-controlplane 1/1 Running 0 5m58s
반응형
'Container > Kubernetes' 카테고리의 다른 글
[K8S] ConfigMap (0) | 2025.01.08 |
---|---|
[K8S] Rollout (0) | 2025.01.08 |
[K8S] Endpoints (0) | 2025.01.02 |
[K8S] Deployment (0) | 2024.12.31 |
[K8S] kube-proxy (0) | 2024.12.28 |