공부하다가 우연히 본 '쿠버네티스', 전에도 본 적 있었어서 이번에 공부해보니까, 꼭 알고 기록해야겠다고 생각이 들었어요.
'쿠버네티스(Kubernetes)', 컨테이너 오케스트레이션(Orchestration)으로 불리는 시스템입니다. 그럼 '컨테이너'는 뭘까요? 다음에 오는 문장을 해결하기 위해 만들어진 실행환경입니다.
"내 컴퓨터에선 되는데 서버(다른 컴퓨터)에선 왜 안 돼?"
우리가 프로그램을 만들었을때, 다른 컴퓨터에서도 동작하기 위해선 내 컴퓨터와 같은 환경이 조성되어 있어야합니다. (ex. OS설정, Java버전, 라이브러리 등)
예전에는 일일이 설치하거나 스크립트, 가상머신을 사용했는데, 일일이 설치하거나 스크립트는 하나만 틀어져도 실행이 안되고 가상머신은 용량이 너무 크다는 단점이 있었습니다.
그래서 등장한게 바로 '컨테이너'입니다. 컨테이너는 이전 방법처럼 '설치'하는 것이 아닌 '비닐하우스' 같이 재배하고자 하는 작물(프로그램)이 잘 자랄 수 있도록(실행) 별도의 환경을 구축하는 것을 말합니다.
재배지(내 컴퓨터 환경) 한쪽에 놓인 비닐하우스(컨테이너)라고 생각하시면 될 것 같습니다.
(이러한 컨테이너 환경을 만들어주는 것을 '도커(Docker)'라고 합니다!)
쿠버네티스의 최소 단위 : 'Pod(파드)'
쿠버네티스의 실제 동작은 컨테이너를 하나하나 다루지 않고 'Pod'를 다뤄요.
컨테이너는 서로 간섭하지 않고 독립적이에요. 하지만 동작하기 위해서 컨테이너가 같이 쓰여야 하는 경우가 있는데 이를 위해서 Pod에 '1개 이상'의 컨테이너를 담아요.
쿠버네티스의 중요한 역할 중 하나가 바로 'Pod'의 개수를 조절하는거에요! 여기서 나오는 개념이 'Self-healing(자가치유)' 입니다.
예를들어, Pod를 3개로 지정했는데 Pod 2개가 종료되면 다시 2개를 만들어주고 Pod가 4개가 만들어지면 하나를 종료해서 최종적으로 3개를 유지해주는 것을 말합니다.
위 과정에서 Pod가 변경될때마다 IP주소가 바뀌는데 쿠버네티스는 'Service'라는 고정 IP를 만들어 요청을 받고 적절한 Pod에 효율적으로 분산을 해주는 로드 밸런싱(Load Balancing)역할을 해줍니다.
이렇게 쿠버네티스가 Pod를 관리하는 방법을 'HPA(Horizontal Pod Autoscaler)'라고 합니다.
CPU의 임계치(Threshold)를 지정해서 Pod의 개수를 조정할 수 있습니다. 이때 개수 조정은 Max/min 즉, 최대/최소 값을 지정해야 합니다.
이를통해 트래픽 변화에 따른 유연하고 탄력적인 관리가 가능합니다.
쿠버네티스가 관리하는 서버 : '노드(Node)'
노드는 "쿠버네티스 시스템에 연결된 서버"이며,쿠버네티스의 자원이라는 것을 직관적으로 알기 위해 서버가 아닌 노드라고 합니다.
노드는 실제 '물리적인 컴퓨터'일 수도 있고, '클라우드(AWS, GCP 등)에서 빌린 가상 머신(VM)'일 수도 있습니다. 쿠버네티스는 여러 대의 노드를 묶어서 하나의 큰 컴퓨터처럼 사용합니다.
노드는 크게 두 가지로 나뉩니다.
1. 마스터 노드 (Master node/Control Plane)
: 시스템의 두뇌 역할입니다. 전체적인 상태를 관리하며, 워커 노드에게 명령하는 역할을 합니다.
2. 워커 노드 (Worker Node)
: 마스터 노드의 명령을 받아 실제 Pod가 실행되고 관리되는 서버입니다.
워커 노드 Pod를 잘 실행하고 관리하기 위해서는 아래 3가지가 필요합니다.
1) 컨테이너 런타임 : 컨테이너 박스를 실제로 열고 실행하는 엔진입니다.
2) Kubelet(쿠블릿) : 마스터 노드의 명령을 받습니다. 명령 받은 Pod를 컨테이너 런타임에게 전달해서 실행하고, 잘 실행되는지 감시합니다.
3) Kube-proxy(쿠브 프록시) : 네트워크 통신을 트래픽을 관리합니다. 외부에서 들어온 접속자가 어떤 파드로 가야 할지 길을 안내합니다.
"혹시 'HPA' 설정을 잘못하면 서버가 다운되진 않을까?"
다행히 위와 같은 대참사에 대한 안전장치가 있습니다.
1. Resource Requests & Limits
-
Requests(최소 보장) : Pod를 배치할 때 필요한 할당량을 지정합니다.(ex. 최소 CPU 0.5개, 메모리 512MB)
지정한 할당량을 근거로 노드에 남는 자원이 없으면 쿠버네티스는 Pod를 'Pending(대기)상태'로 만듭니다. -
Limits : Pod가 최대로 쓸 수 있는 자원의 상한선 입니다.
2. OOM Killer(Out Of Memory Killer)
갑자기 어떤 Pod 하나가 갑자기 메모리를 엄청나게 소비한다면 쿠버네티스는 그런 '비정상적인 Pod'만 강제로 종료(Kill) 시켜버립니다.
예외로 노드 전체의 메모리가 부족한 경우엔 비정상적인 Pod가 아닌데도 강제 종료시키기도 합니다.
이때, 종료시키는 우선순위(QoS:Quality of Service)에 따라 종료시킵니다.
- BestEffort(1순위)
: 할당량(Request/Limit)을 아예 설정 안 한 파드들입니다.
위에서 말한 '비정상적인 Pod'가 될 수 있는 Pod 입니다. - Burstable(2순위)
: 최소(Request)와 최대(Limit)를 다르게 설정한 파드들입니다.
최소한도는 보장받지만, 최대치까지 쓰고 있을 때 서버가 위험해지면 타겟이 됩니다. - Guaranteed(3순위)
: 최소와 최대 할당량을 똑같이 설정한 아주 중요한 파드들입니다.
"Pod 처럼 Node 개수도 조절할 순 없을까요?"
노드가 물리적인 컴퓨터가 아닌 클라우드 환경에서는 가능합니다!
'CA(Cluster Autoscaler)'라는 기능으로 노드의 개수를 조절할 수 있습니다.
기존 노드에 자원이 부족해 POD가 Pending 상태일때는 클라우드 회사에 API 요청을 보내 노드를 추가하고 노드에 자원이 낭비되고 있을때는 노드를 반납합니다.
'HPA'와 'CA'를 적절히 설정하여 함께 사용하는 것이 중요합니다. 이는 서비스 관리에서도 중요하지만 비용관리 측면에서 큰 부분을 차지하기 때문입니다.
이번 포스팅을 진행하며, 수많은 사용자에게 중단 없는 일관된 서비스를 제공하면서도 비용 효율성까지 챙길 수 있는 최적의 솔루션은 결국 쿠버네티스라는 생각이 들었습니다. 결국, 급격히 변하는 대규모 트래픽을 유연하게 관리하고 인프라의 안정성을 확보해야 하는 환경이라면 쿠버네티스는 필수라는 생각이 듭니다.
