Before Learning K8S

이번 포스팅은 컨테이너 오케스트레이션의 De facto인 쿠버네티스에 대한 글입니다.

 

그러나, 쿠버네티스와 관련된 내용들을 자세하게 기재하기엔 너무나도 복잡하고 어렵기 때문에 다음과 같이 쿠버네티스를 알아가기 위한 기본 배경지식에 대한 정리를 하고자 준비했습니다.

• 쿠버네티스 사전적 정의
• 컨테이너 오케스트레이션이란?
• 쿠버네티스 Control Loop
• 쿠버네티스 아키텍처

쿠버네티스 사전적 정의

쿠버네티스란, 컨테이너화된 애플리케이션들의 배포, 스케일링, 관리 등을 자동화 하기위한 오픈소스 시스템입니다.

 

그렇다면 우리는 몇가지 궁금증이 생길 수 있습니다.

- 쿠버네티스가 어떤 역할을 하는지 알겠는데, 그래서 왜 사용하는건데?
- 쿠버네티스는 언제 사용하는게 적절할까?

이러한 자문은 너무나도 당연하고, 쿠버네티스가 클라우드 인프라를 구축하는데 있어 어떻게 de-facto가 되었을지 의문을 풀어야할 필요가 있다 생각합니다.

 

• 쿠버네티스를 왜 사용하는걸까?

우선 쿠버네티스를 왜 사용하는지를 알아보기 이전에, 클라우드의 등장배경을 알아볼 필요가 있습니다.

 

클라우드가 등장하기 전, 기업은 컴퓨팅 리소스들을 관리하고 서비스를 런칭하기 위해서는 직접 시스템 환경을 구축(온프레미스)할 필요가 있었습니다. 이러한 온프레미스 환경을 위해서는 데이터 센터가 필요하게 되는데요. 이때 데이터 센터를 구축하기 위해서 초기 비용이 무수히 많이 발생한다는 문제(건설 비용, 통신 장비, 유지보수 비용, 인건비 등등..)가 있었습니다.

 

따라서 이러한 문제로 인해 서비스를 개발하는 것에 있어서, 어떤 서비스를 개발하는지, 해당 서비스를 이용할 고객의 수는 얼마나 될지, 회사가 감당할 수 있는 수준의 서비스 런칭일지 등등 다방면에서 고려하여 시스템 환경을 구축하게 된다는 것입니다. 뿐만 아니라, 초기 자본이 부족한 스타트업들은 서비스 아이디어가 있다 하더라도 이러한 환경을 구축하는 것에 부담을 느낄 수 밖에 없는 구조를 가지고 있습니다.

 

이 문제를 해결해주는 기술이 바로 클라우드 기술입니다. 클라우드 기술로 인해 거의 모든 문제들을 해결할 수 있게 되었습니다. 간략하게 말씀드리자면,

1. 직접 시스템 환경을 구축하지 않고 클라우드 서비스를 사용한 만큼 요금이 부과되기 때문에, 서비스를 개발하는 비용을 이전과 같이 크게 고민하지 않아도 됩니다.
2. 컴퓨팅 리소스에 제한이 없기 때문에, 운영 및 관리하는 것에 있어 트래픽을 탄력적으로 관리할 수 있습니다.
3. 시간이 지남에 따라 무수히 쌓이는 데이터들을 관리할 수 있기 때문에 데이터의 가치는 더욱 높아지게 됩니다.

그외로, 클라우드 기술을 사용하게 됨으로써 얻게 되는 이점은 매우 많습니다.

 

하지만, 클라우드 기술의 단점 또한 존재하는데요. 그 대표적인 단점은 보안 취약성 및 CSP(Cloud Solution Provider) 종속성 입니다.

(+ 의도치 않은 비용 발생, 과도한 클라우드 의존으로 온프레미스 환경을 구축하는 것보다 더 많은 비용이 발생, 규제 및 법적 이슈, 책임 소재의 부재 등이 있습니다.)

 

클라우드는 물리적 리소스들을 가상화하여 구현하는 것이기 때문에, 물리적으로 분리된 환경보다 더욱 보안에 약할 수 밖에 없습니다. 따라서 외부에 유출되지 않아야할 데이터들이 노출될 수도 있고, CSP에서 컴퓨팅 리소스들이 되는 데이터 센터에 문제가 발생한다면 예상치 못한 시스템 장애가 야기될 수 있습니다.

더불어 한 번 CSP를 선택하여 서비스를 런칭하게 된다면 해당 CSP 클라우드 서비스에 종속될 수 있고, 이로 인해 다른 CSP 클라우드 서비스로 데이터를 이동해야할 때 lock-in으로 어려움을 경험하실 수 있습니다.

따라서 위와 같은 문제들을 해결하기 위해 여러 CSP에서는 다양한 솔루션들을 보여주며 고객들에게 만족할 수 있는 서비스를 제공하고 있습니다. 

 

그렇다면 쿠버네티스를 굳이 사용하지 않고 CSP에서 제공해주는 서비스들을 이용하면 되지 않을까? 라는 의문이 들 수 있다고 생각하는데요.

 

여기서부턴 저는 선택의 문제라고 생각합니다. 그 이유는 각 회사의 사정에 따라 AWS, Azure, GCP 중 한 가지만을 사용하는 것이 이득이 될 수도 있고 두 개 이상의 클라우드 서비스를 이용하는 것이 합리적인 선택이 될 수도 있고, 마찬가지로 쿠버네티스를 사용하여 클라우드 인프라를 관리하는 것이 서비스의 품질을 높일 수도 있습니다.

 

따라서 왜 쿠버네티스를 사용하는걸까? 라는 것은 사실 쿠버네티스의 기술적 특징들에 대해 정리하여 말씀드릴 수 밖에 없다고 설명하고 싶었습니다.
왜 쿠버네티스를 사용하는 걸까? == 쿠버네티스의 기술적 특징은 뭘까?

즉, 질문을 수정하여 합리적인 질문을 만들기 위해서는 "언제 쿠버네티스를 사용하는 것이 적절한 것일까?"가 되어야한다고 생각합니다.

 

• 쿠버네티스는 언제 사용하는 것이 적절할까?

쿠버네티스는 컨테이너 오케스트레이션 오픈소스 툴입니다. 즉, 컨테이너를 관리할 수 있는 환경을 제공해준다는 것인데요. 여기서 왜 가상머신이 아닌 컨테이너에 기술적인 포커스를 맞추고 있는지 이해할 필요가 있습니다. 

마이크로 서비스 아키텍처가 발전하게 됨으로써 서비스들은 기능 단위로 세분화되기 시작했고, 그 결과 아주 작은 단위의 서비스들이 다수 등작하기 시작했습니다. 따라서 가상머신으로 이러한 작은 단위의 서비스들을 운영 및 관리하기에는 리소스 낭비가 심하고 배포 및 portability 문제가 있기 때문에, 컨테이너가 MSA 구조에 적합한 기술이 되었습니다.

이 뿐만 아니라 이러한 MSA 구조의 발전으로 클라우드 인프라의 다양한 디자인 패턴들, DevOps 모델 및 CI/CD라는 것이 등장하며 컨테이너 기술의 중요도는 더욱 커지고 있습니다.

이제 본격적으로 쿠버네티스를 언제 사용하는 것이 좋을지 알아보겠습니다.

 

우선, 쿠버네티스를 분석해보겠습니다.

 

쿠버네티스는 Go 언어로 구현되었습니다.

Go 언어

1. 동시성
   클라우드 환경을 제어하기 위해서는 API를 이용하여 제어합니다. 만약 이때 API 요청 및 응답이 동시성을 제공하지 않는다면 어떻게 될까요? 데이터베이스의 무수히 많은 서버를 제어해야하는 상황에서 API는 한 대씩 처리할 때마다 인증 및 권한, 보안 그룹, 요청 및 응답, 네트워크 서브넷 등 여러 과정을 거치며 서버 관리 및 운영을 책임져야할 것입니다. 따라서 동시성을 제공하는 Go언어로 쿠버네티스를 구현하였습니다.
2. 배포
   쿠버네티스는 대규모 클라우드 인프라를 관리 및 운영합니다. 따라서 이러한 대규모 클라우드 인프라 환경에 배포하는 단위는 빠른 속도는 물론 가벼워야 관리 및 운영하기가 수월해집니다. 이러한 쿠버네티스 환경에 적합한 언어는 Go 언어입니다. Go 언어는 운영체제와 프로그램 바이너리만 있으면 동작합니다. 즉, portable한 특징이 있어 어떤 환경에서도 잘 동작합니다. 따라서 배포는 쉽고 크기는 작아 쿠버네티스 동작 목적에 적합한 언어라고 할 수 있습니다.
3. 동적 시스템 환경에 적합
   클라우드 시스템 환경은 자주 변합니다. 그렇기 때문에 원하는 상태를 끊임없이 유지하기 위해(동적 시스템 환경에 맞게) Control Loop 메커니즘을 갖습니다. Go 언어는 이러한 매커니즘에 적합한 환경을 제공해줍니다.

따라서 쿠버네티스는 Go 언어로 구현되었기 때문에, 특정 벤더에 종속되지 않아 퍼블릭 클라우드, 프라이빗 클라우드, 베어메탈에도 배포가 가능하다는 장점이 있습니다. 이러한 이유로 여러 퍼블릭 클라우드 간의 호환성을 지원해야하는 환경이나 퍼블릭 클라우드와 온프레미스 환경을 혼합하여 사용하는 환경까지 응용할 수 있기 때문에 멀티 클라우드, 하이브리드 클라우드 솔루션으로 각광받고 있습니다.

컨테이너 오케스트레이션이란?

컨테이너 오케스트레이션이란, 컨테이너의 배포, 관리, 확장, 네트워킹을 자동화해주는 것을 말합니다.

• 프로비저닝 및 배포
• 리소스 할당
• 워크로드 밸런싱 기반 컨테이너 스케일링 또는 제거
• 로드 밸런싱 및 트래픽 라우팅
• 컨테이너 상태 모니터링
• 실행될 컨테이너 기반 애플리케이션 설정
• 컨테이너 간 상호 작용의 보안 유지

해당 기능들이 쿠버네티스의 주된 기능이라고 설명드릴 수 있습니다.

쿠버네티스 Control Loop

앞서 말씀드린 컨테이너 오케스트레이션의 기능이 중요하다고 말씀드렸었지만, 결국 이 모든 기능들이 나올 수 있게 된 핵심 내용은 쿠버네티스의 Control Loop라고 생각합니다. 그 이유는 Control Loop라는 메커니즘이 있기 때문에 쿠버네티스의 컨테이너 오케스트레이션 기능들이 효과를 볼 수 있었다고 생각하기 때문입니다.

 

쿠버네티스 Control Loop 메커니즘은 쿠버네티스 인프라 위에 올라와 있는 Object들의 원하는 상태가 무엇인지 확인하여 이것을 유지시켜주는 일련의 과정을 말합니다. 그 과정은 다음과 같습니다.

1. Object들의 Desired state가 무엇인지 확인합니다.
2. Object들의 Actural state가 어떠한지 보고, Desired state와 비교하여 그 차이를 찾습니다.
3. Actual state를 Desired state 상태로 만들어줍니다.

즉 위와 같은 과정을 거치며 쿠버네티스는 Object들의 상태를 주기적으로 모니터링 및 유지보수를 할 수 있게 된 것입니다.

 

따라서 해당 메커니즘을 이해해야 쿠버네티스를 이해할 수 있다고 판단했습니다.

쿠버네티스 아키텍처

쿠버네티스는 위 그림과 같이 Master Node와 Worker Node로 이루어져 있습니다.

해당 노드들에 대하여 설명드리겠습니다.

 

Master Node

• 마스터 노드는 API서버, 스케줄러, 컨트롤러 매니저, etcd로 구성되어 있습니다.
• 클러스터링된 환경 전체를 제어하는 시스템입니다.

API 서버

- 모든 요청을 처리하는 마스터 노드의 핵심 모듈

- RESTful 웹 서비스를 제공

- 사용자의 요청뿐만 아니라, 내부 모듈들의 요청까지 처리하며 권한을 확인하여 요청을 거부할 수도 있음

- Actual state를 etcd에 저장 및 조회하는 역할

 

스케줄러

- 할당되지 않은 Pod를 조건에 따라 적절한 Worker Node에 할당

 

컨트롤러 매니저

- kube-controller-manager, cloud-controller-manager로 나뉨

- 큐브 컨트롤러 : 쿠버네티스의 Object들의 상태를 관리

- 클라우드 컨트롤러 : AWS, Azure 등 클라우드에 특화된 모듈

 

etcd

- kye-value 저장소

- 여러 개로 분산하여 복제 가능

- 상태 변화를 확인하는 로직을 수행

 

Worker Node

• 워커 노드는 kubelet, kube-proxy, 도커 엔진 및 OS로 구성되어 있습니다.

kubelet

- 워커 노드에 할당된 Pod의 생명주기를 관리

- Pod를 생성

- Pod 내부 컨테이너에 이상이 없는지 확인 -> 마스터 노드에게 컨테이너 상태 전달

 

kube-proxy

- 네트워크 proxy

- Pod로 연결되는 네트워크를 관리

- 로드밸런싱 제공

- UDP, TCP 등을 이용하지만, HTTP는 이해하지 못함.(Layer7 X)

 

추가적으로 Pod가 생성되는 과정을 이해하기 쉽게 설명한 그림을 보여드리며 오늘의 포스팅은 마무리하겠습니다. 부족한 글 읽어주셔서 감사드리고, 피드백 해주실 내용이 있거나 이해가지 않는 부분이 있다면 망설임 없이 댓글 남겨주세요!

 

참고문헌

https://kubernetes.io/

https://www.predicagroup.com/blog/why-kubernetes-2021/

https://thenewstack.io/do-i-really-need-kubernetes/

https://bcho.tistory.com/1255

https://andromedarabbit.net/%EC%99%9C-golang%EC%9D%B8%EA%B0%80/

https://subicura.com/2019/05/19/kubernetes-basic-1.html

쿠버네티스 시작하기 - Kubernetes란 무엇인가?