지난 번 Deployment를 이용해 pod를 실행시키는 실습까지 알아보았습니다.
kubectl run 명령어 실행 시 클러스터 내부적으로 어떤 일이 일어나는 지 알아보겠습니다.
우선 쿠버네티스 클러스터는 컨테이너를 실행시키는 노드로 구성되어있습니다.
노드는 하나의 VM이며, 노드의 역할에 따라 마스터노드(컨트롤 플레인)과 워커 노드로 분류됩니다.
워커 노드는 실제 Pod의 실행을 담당하는 오브젝트이며,
마스터 노드는 워커 노드에게 Pod의 실행을 전달하는 오브젝트입니다.
마스터 노드와 워커 노드의 여러 컴포넌트 들이 있는데,
마스터 노드에는
-API Server : 사용자와의 상호 작용
-etcd : 저장 공간
-controller manager : 컨트롤러 실행과 클러스터 상태 확인
-scheduler : Pod를 Node에 할당을 결정
워커 노드에는
-kubelet : Pod 관리
-kube-proxy : 네트워크 프록시
-container-runtime : 컨테이너 엔진(Docker)
이렇게 구성되어 있습니다.
사용자가 kubectl 명령을 입력하면
1. API Server가 명령을 확인
2. 컨트롤러를 통해 etcd에 저장된 노드의 리소스나 상태를 보고 어떤 노드에 Pod를 배치할지 선택
3. kubelet에게 Pod 실행 명령 전달
4. Container runtime이 Pod 내 컨테이너 이미지를 찾아와 실행
간단하게 요약하면 이런 방식으로 명령이 처리됩니다.
이는 클러스터와 통신에 대한 이해가 없다는 가정하에 이해하기 쉽게 가볍게 설명드린 내용이고,
추후 각각의 개념을 설명할 기회가 된다면 상세히 설명을 드리겠습니다.
deployment 기능을 통해 replicaset을 조정해 pod의 수를 늘려보겠습니다.
kubectl scale deploy nginx-app --replicas=2
replicaset을 조정하자마자 pod가 2개로 늘어난 것을 확인할 수 있습니다.
이는 클러스터 내부의 컨트롤러 매니저가 deployment 상태와 실제 pod 수를 확인하고 있어
해당 상태를 사용자가 지정한 상태로 맞춘 것이라 이해하시면 됩니다.
이렇게 특정 Pod를 어떻게 , 얼만큼 실행할 지 최종 결과 상태를 선언한다고 해서
쿠버네티스는 선언적 API 특성을 가진다고 볼 수 있습니다.
방금 설명드린 최종 상태 값을 지정할 수 있는 쿠버네티스의 특징 덕분에
이후에 나올 셀프 힐링과 오토 스케일링이 가능합니다.
이번에는 deployment와 남은 pod를 모두 삭제 후, 파드를 조회해보니 namespace라는 용어가 나왔습니다.
namespace란 ?
namespace는 노드를 논리적인 영역으로 나누는 기술입니다.
사내 여러 부서에서 배포하는 Pod 등의 오브젝트의 이름이 겹칠 수도 있고, 다른 여러 이유로 서로 격리된 공간이 필요할 때 사용되곤 합니다.
namespace를 나눈다고 해서 Node의 리소스 자체를 물리적으로 나누는게 아니라 일종의 권한을 부여한다고 생각하시면 편합니다.
ns를 사용해 Node에 대한 특별한 설정 없이 해당 노드에서 특정 부분만을 논리적으로 격리해 사용할 수 있습니다.
ns는 default 값이 기본 값이며, 사용자가 원하는 ns를 생성해 본인이 작업할 ns를 선택할 수도 있고,
기본값을 변경 가능합니다.
