이제 쿠버네티스에 대해 좀 더 본격적으로 알아보자.
1️⃣ Kubernetes Components
쿠버네티스 컴포넌트를 크게 분류를 하자면,
- Control Plane: 쿠버네티스 기능 제어를 전체적으로 담당
- Node: 컴포넌트와 컨트로로 플레인 컴포넌트의 요청을 받아 각 노드에서 동작을 담당
이 둘은 세부적으로 많은 개별 구성 요소를 갖는다.
전체적인 구조
Control Plane과 Node를 회사 조직과 업무에 비유하기
Control Plane → 회사 전반에 해당하는 ‘본사의 업무’
Node → 각 지역별 ‘지사의 업무’
2️⃣ Control Plane Components
💁 kube-apiserver
마치 건물 프론트에 있는 안내데스크와 같은 역할을 한다.
kube-apiserver는 쿠버네티스 클러스터로 들어오는 요청을 가장 앞에서 접수하는 역할을 한다.
예를 들어, 쿠버네티스 커맨드 라인 도구인 kubectl을 사용해 각종 명령을 수행할 경우 이 명령은 kube-apiserver로 전송된다. 이렇게 전달된 요청에 대하여 kube-apiserver는 이 요청의 처리 흐름에 따라 적절한 컴포넌트로 요청을 전달하는 역할까지 맡고 있다.
💁 etcd
겉으로는 쉽게 드러나지 않아 놓치기 쉽지만 매우 중요한 역할을 담당하고 있는 컴포넌트.
쿠버네티스 클러스터가 동작하기 위해서는 클러스터 및 리소스의 구성 정보, 상태 정보 및 명세 정보 등이 필요하다. etcd는 이를 키-값 형태로 저장하는 저장소이다.
만약 etcd가 정상적으로 동작하지 않는다면?
쿠버네티스 클러스터에 존재하는 리소스들은 그저 바다에 떠다니는 난파선과 다를게 없다.
etcd는 안정적인 동작을 위해 자료를 분산해서 저장하는 구조를 채택하고 있다.
💁 kube-scheduler
기본 작업 단위라고 할 수 있는 파드(pod)는 여러 노드 중 특정 노드에 배치되어 동작하게 된다. 이때 새로 생성된 파드를 감지하여 어떤 노드로 배치할지 결정하는 작업을 스케줄링 이라고 한다.
이것을 담당하는 컴포넌트가 kube-schedulerdler 이다.
스케줄링을 위해 노드 및 파드의 각종 요구사항과 제약 사항을 종합적으로 판단할 필요가 있는데, 이러한 판단 또한 kube-scheduler의 역할이다.
회사로 비유하자면, 각 부서 인력 소요 계획과 신입사원 역량을 고려해 적절한 부서로 배치하는 인사 담당 부서에 비유할 수 있다.
💁 kube-controller-manager
목표를 달성한 후 이를 유지하기 위한 관리자 같은 역할
다운된 노드가 없는지, 파드가 의도한 복제 숫자(Replicas)를 유지하고 있는지, 서비스와 파드는 적절하게 연결되어 있는지, 네임스페이스에 대한 기본 계정과 토큰이 생성되어 있는지를 확인하고 적절하지 않다면 조치를 취한다.
3️⃣ Node Component
💁♀️ Kubelet
노드에서 컨테이너가 동작하도록 관리해주는 핵심 요소
각 노드에서 파드를 생성하고 정상적으로 동작하는지 관리하는 역할을 담당하며, 실제로 쿠버네티스의 워크로드를 관리하기 위해 내려지는 명령은 kubelet을 통해 수행된다고 볼 수 있다.
우리가 쿠버네티스 파드를 관리하기 위해 적성하는 YAML을 쿠버네티스 클러스터에 적용하기 위해 kubectl 명령어를 사용할 때, 이 YAML이 kube-apiserver로 전송된 수 kubelet으로 전달된다.
kubelet은 이 YAML을 통해 전달된 파드를 생성 혹은 변경하고, 이후 이 YAML에 명시된 컨테이너가 정상적으로 실행되고 있는지 확인한다.
💁♀️ Container runtime
컨테이너 런타임은 파드에 포함된 컨테이너 실행을 실질적으로 담당하는 애플리케이션을 의미.
단, 컨테이너 런타임은 쿠버네티스 구성 요소에 기본적으로 포함되어 있거나, 특정 소프트웨어를 지칭하는 것이 아니다.
쿠버네티스가 컨테이너를 제어하기 위해 제공하는 표준 규약인 CRI(Container runtime Interface)를 준수하여 쿠번네티스와 함께 사용할 수 있는 외부 애플리케이션들을 의미한다.
쿠버네티스는 컨테이너 관리를 위해 특정 애플리케이션을 사용할 것을 강제하지는 않고 단지 쿠버네티스가 제공하는 규약에 따라 쿠버네티스와 연계할 것을 요구하고 있다.
💁♀️ Kube-proxy
쿠버네티스 클러스터 내부에서 네트워크 요청을 전달하는 역할
💡이해하기 쉽게 비유해보기
윈터가 윤찬이에게 선물은 보낸다고 해보자. 하지만 윈터는 윤찬이가 한국외대를 다닌다는 것만 알고 있다. 윈터가 그냥 한국외대로 선물을 보내면, 그것은 아마도 서울 캠퍼스로 갈 것이다. 하지만 윤찬이는 글로벌 캠퍼스 소속이기 때문에, 서울 캠퍼스에서 글로벌캠퍼스로 선물을 보내서 윤찬이에게 전달할 것이다.
위 예시에서 윤찬이가 어느 캠퍼스에 있는지 관리하고, 윤찬이에게 오는 선물이 타 캠퍼스로 도착했더라도 다시 윤찬이가 위치한 캠퍼스로 전달해주는 역할을 kube-proxy가 수행한다.
윤찬이가 pod라고 가정하면, kube-proxy가 없었다면 쿠버네티스 내부에 위치한 특정 파드로 요청을 보내기 위해서 해당 파드의 IP를 정확히 알아야 하며, 이 IP가 외부에서 접근 가능하도록 구성되어야 할 것이다.
하지만 쿠버네티스 파드 IP는 파드가 배포될 때마다 매번 바뀌기 때문에, IP를 통해 파드에 요청을 전달하기란 쉽지 않다.
쿠버네티스는 파드 IP가 매번 바뀌는데서 오는 어려움을 해결하기 위해 오브젝트를 통해 고정적으로 파드에 접근할 수 있도록 하는 방법을 제공한다.
그리고 서비스로 들어온 요청이 파드에 실제로 접근할 수 있는 방법을 관리한다. 이때 이 관리를 담당하는 컴포넌트가 kube-proxy이다. 즉, 파드 IP는 매번 변하지만 kube-proxy가 이 파드에 접근할 수 있는 방법을 그때마다 관리하고 갱신하며, 서비스 오브젝트는 이 정보를 사용하여 파드가 외부에서 접근할 수 있는 경로를 제공한다.
