이 부분은 쿠버네티스를 이해하는 데 매우 중요한 부분입니다. 쿠버네티스는 작업을 순서대로 진행하는 워크플로(workflow, 작업 절차) 구조가 아니라 선언적인(declarative) 시스템 구조를 가지고 있습니다. 즉, 각 요소가 추구하는 상태(desired status)를 선언하면 현재 상태(current status)와 맞는지 점검하고 그것에 맞추려고 노력하는 구조로 돼 있다는 뜻입니다.

따라서 추구하는 상태를 API 서버에 선언하면 다른 요소들이 API 서버에 와서 현재 상태와 비교하고 그에 맞게 상태를 변경하려고 합니다. 여기서 API는 현재 상태 값을 가지고 있는데, 이것을 보존해야 해서 etcd가 필요합니다. API 서버와 etcd는 거의 한몸처럼 움직이도록 설계됐습니다. 다만, 여기서 워커 노드는 워크플로 구조에 따라 설계됐습니다. 쿠버네티스가 kubelet과 컨테이너 런타임을 통해 파드를 새로 생성하고 제거해야 하는 구조여서 선언적인 방식으로 구조화하기에는 어려움이 있기 때문입니다. 또한 명령이 절차적으로 전달되는 방식은 시스템의 성능을 높이는 데 효율적입니다. 하지만 마스터 노드는 이미 생성된 파드들을 유기적으로 연결하므로 쿠버네티스 클러스터를 안정적으로 유지하려면 선언적인 시스템이 더 낫습니다.

▲ 그림 3-16 쿠버네티스의 상태 유지 방법

이렇듯 쿠버네티스는 굉장히 잘 설계된 시스템 구조를 가지고 있어서 구조적으로 이해하기 쉽고 문제가 생기면 이를 쉽게 파악하고 조치할 수 있습니다. 그러면 앞의 구성 요소 중에서 몇 가지를 검증해 실제로 어떻게 작동하는지 살펴봅시다.