쿠버네티스의 시스템 데몬

환경마다 다르겠지만 Kubernetes라고 해서 OS 데몬에서 완전히 자유로운건 아니다.

일부 클러스터 운영 환경에선 ETCD를 데몬의 형태로 사용하기도하고 몇몇 컴포넌트를 레거시한 방법으로 사용한다.

흔히 우리가 알고있는 Kubernetes 클러스터가 동작중일때 가장 중요하다 알고있는 데몬은 Kubelet이다.

kubelet

Synopsis

The kubelet is the primary "node agent" that runs on each node. It can register the node with the apiserver using one of: the hostname; a flag to override the hostname; or specific logic for a cloud provider.

The kubelet works in terms of a PodSpec. A PodSpec is a YAML or JSON object that describes a pod. The kubelet takes a set of PodSpecs that are provided through various mechanisms (primarily through the apiserver) and ensures that the containers described in those PodSpecs are running and healthy. The kubelet doesn't manage containers which were not created by Kubernetes.

 

출처:https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/#synopsis

kubelet

 

말이 굉장히 어려운데 일단 잘보이는 단어가 있다.

 

" node agent "

비단 kubernetes 뿐만 아니라 다른 많은 어플리케이션또한 node agent라는 단어를 사용한다.

기본적으로 알고있는 상식을 끄집어 내본다면 node agent는 특정한 노드에 상주하며 주기적으로 원하는 행위를 하는

상주 어플리케이션 정도로 해석 해볼 수 있다.

 

" PodSpecs are running and healthy "

POD( 혹은 POD내 libray및 정보들이) 살아있는지 그것도 건강한 상태로 살아있는지 주기적으로 확인한다.

그렇다고 kubelet 데몬이 그저 헬스 체크만 하는것은 아니다.

여러 절차가 있겠지만 최종적으로 Node에 POD생성 명령을 하달받는 컴포넌트는 kubelet이다.

아래 간단한 yaml 파일로 node affinity를 사용해 Pod를 생성해보자

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: affinity
  name: affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: name
            operator: In
            values:
            - mn3
  containers:
  - image: nginx
    name: affinity
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

 

pod 상태 확인

kubectl get po
NAME                          READY   STATUS    RESTARTS   AGE
affinity                      1/1     Running   0          2s

 

위와 같이 정상적으로 생성이 되었다면 이제 mn3이라는 노드의 kubelet 데몬을 살펴보자 pod ID 확인

kubectl get pod affinity -ojson |grep -i id
            "cni.projectcalico.org/containerID": "a76c742b231db28e7f2e56b068d690afc12c3125b3141af0c3b8b649a4083b12",
        "uid": "02dc3e1f-4351-4578-8f5f-089adc9c2af0"
                "containerID": "containerd://e97d4c1c2f227673a6c215a25bbd88fbff1dbf8dce96f00f2352cd6399926bc2",

 

mn3 노드의 kubelet 데몬 로그 ( 로그가 잘 보이지 않아 로그레벨=5로 변경 )

I1109 16:04:02.587275 1853838 config.go:281] "Setting pods for source" source="api"
I1109 16:04:02.588120 1853838 config.go:386] "Receiving a new pod" pod="default/affinity"
I1109 16:04:02.588197 1853838 kubelet.go:2096] "SyncLoop ADD" source="api" pods=[default/affinity]
I1109 16:04:02.588235 1853838 topology_manager.go:205] "Topology Admit Handler"
I1109 16:04:02.588264 1853838 config.go:100] "Looking for sources, have seen" sources=[api file] seenSources=map[api:{} file:{}]
I1109 16:04:02.588359 1853838 config.go:100] "Looking for sources, have seen" sources=[api file] seenSources=map[api:{} file:{}]
I1109 16:04:02.588505 1853838 pod_workers.go:585] "Pod is being synced for the first time" pod="default/affinity" podUID=02dc3e1f-4351-4578-8f5f-089adc9c2af0
I1109 16:04:02.588550 1853838 pod_workers.go:902] "Processing pod event" pod="default/affinity" podUID=02dc3e1f-4351-4578-8f5f-089adc9c2af0 updateType=0
I1109 16:04:02.588574 1853838 kubelet.go:1523] "syncPod enter" pod="default/affinity" podUID=02dc3e1f-4351-4578-8f5f-089adc9c2af0
I1109 16:04:02.588586 1853838 kubelet_pods.go:1447] "Generating pod status" pod="default/affinity"
I1109 16:04:02.588627 1853838 kubelet_pods.go:1412] "Pod waiting > 0, pending"

 

Receiving a new pod" pod="default/affinity 새로운 파드를 받았다고 나온다. 그럼 저 시점의 containerd 로그를 살펴보자 (CRI를 containerd를 사용하고있다.)

Nov 09 16:04:03 sh-mn3 containerd[3059543]: time="2023-11-09T16:04:03.486333605+09:00" level=info msg="CreateContainer within sandbox \"a76c742b231db28e7f2e56b068d690afc12c3125b3141af0c3b8b649a4083b12\" for &ContainerMetadata{Name:affinity,Attempt:0,} returns container id \"e97d4c1c2f227673a6c215a25bbd88fbff1dbf8dce96f00f2352cd6399926bc2\""
Nov 09 16:04:03 sh-mn3 containerd[3059543]: time="2023-11-09T16:04:03.487410768+09:00" level=info msg="StartContainer for \"e97d4c1c2f227673a6c215a25bbd88fbff1dbf8dce96f00f2352cd6399926bc2\""
Nov 09 16:04:03 sh-mn3 containerd[3059543]: time="2023-11-09T16:04:03.598763090+09:00" level=info msg="StartContainer for \"e97d4c1c2f227673a6c215a25bbd88fbff1dbf8dce96f00f2352cd6399926bc2\" returns successfully"

 

ContainerMetadata{Name:affinity,Attempt:0,}  컨테이너를 생성하는걸 볼 수 있다.

ctr -n k8s.io c ls |grep e97d4c1c2f227673a6c215a25bbd88fbff1dbf8dce96f00f2352cd6399926bc2
e97d4c1c2f227673a6c215a25bbd88fbff1dbf8dce96f00f2352cd6399926bc2    docker.io/library/nginx:latest                         io.containerd.runc.v2

(잘 있군!)

 

생성되는 시점의 모든 로그를 기재한건 아니기에 짧아 보일수 있지만 CNI가 네트워크를 생성하는 과정이나 호스트를 찾고 affinity하는 과정들을 좀 더 자세하게 볼 수 있다.

 

또 kubelet 로그를 보면 pod-phase에 대한 업데이트를 주기적으로 하는걸 볼 수 있다.

https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase

Pod Lifecycle

---

다음편으로 계속